Every company works differently.You have your own users, groups, administrators, contractors, applications, networks, VPNs, offices, remote workers, authentication methods, and security requirements.

So why should you have to reorganize the way your company works around the limitations of your cybersecurity solution?

You shouldn’t. Your security should adapt to your organization and your rules.

That is one of the ideas behind WebADM Policies and Conditional Access mit OpenOTP. Instead of applying one authentication configuration to everyone, WebADM lets you get very specific about who can access what, when, from which networks, and under which conditions.

And once you combine that with OpenOTP, trusted contexts, Step-Up and Step-Down policies, badging, network conditions, approval workflows, and risk-based decisions, you can do something useful:

Increase security where it matters without adding friction everywhere else.

The problem with “MFA everywhere”

Meet Sarah. Sarah works in accounting. It’s Monday morning. She’s sitting at her usual desk, using her company laptop, on the corporate network. She logs in.

MFA

She opens another protected application.

MFA again.

Later she connects to another service.

Another MFA request.

By lunchtime, Sarah has become very good at pressing Approve.

Now imagine that on Tuesday night someone has Sarah’s password and attempts to authenticate through an IP address associated with suspicious infrastructure.

Should that authentication attempt get exactly the same Push notification as Sarah sitting at her desk?Probably not. The problem isn’t MFA.

The problem is treating very different situations as though they were identical.

One user doesn’t need one policy

WebADM starts with a layered policy model.

There is a default application configuration, but that configuration can be overridden for particular groups, individual users, client applications, groups within those client policies, and networks.

WebADM assigns priorities, or weights, to these policy layers. The more specific, higher-weight policy can override the more general configuration.

Conceptually, it looks something like this:

This is important because real security policies aren’t flat.

An employee accessing the intranet doesn’t necessarily need the same policy as an administrator accessing production A VPN doesn’t necessarily need the same configuration as Windows login. An internal network doesn’t necessarily need the same treatment as an external network. And a contractor doesn’t necessarily need the same access rules as a permanent employee.

WebADM lets you model those differences instead of pretending they don’t exist.

Who are you?

Let’s start with something simple.

Your standard OpenOTP configuration might require: LDAP + MFA

That’s your baseline. But now we have Bob. Bob is a Domain Administrator. Bob has considerably more power than the average employee, so you probably don’t want his access policy to be identical.

WebADM lets you override OpenOTP settings for a particular group.

In fact, RCDevs’ documentation demonstrates this with a Domain Admin group. The example changes the OpenOTP login mode to LDAP + FIDO authentication, disables OTP fallback, enables Fake Challenge protection and password checking, and requires a badge-in/check-in operation.

So:

Same OpenOTP infrastructure but different policy. Because who you are matters.

What are you trying to access?

Now let’s make it more interesting.

Bob isn’t simply a Domain Administrator. He’s a Domain Administrator trying to access a particular system.

WebADM’s Kundenrichtlinien let you configure policies for a specific application or a group of applications and servers. RCDevs recommends separate client policies when different applications require different settings.

Depending on the integration, WebADM can identify the client through mechanisms including a Client ID, RADIUS NAS-Identifier, NAS IP address, or client system IP.

That means:

• Bob accessing a normal application → One policy.
• Bob accessing an administrative system → Stronger policy.
• Bob connecting through the corporate VPN → VPN policy.

The question is no longer simply: Is Bob allowed to authenticate?

It becomes: How should Bob authenticate to this particular resource?

That’s a much more useful question.

Where are you?

Now add another piece of context: the network.

A Client Policy can contain Per-Network Application Settings.

WebADM can therefore change the OpenOTP configuration depending on the network the authentication originates from.

The RCDevs documentation gives an example where requests originating from an internal 192.168.3.0/24 network change OpenOTP’s LoginMode to LDAP. For this mechanism, the client integration needs to forward the user’s IP address to OpenOTP.

Now we know:

• Who are you?
• Which groups do you belong to?
• What are you accessing?
• Where are you connecting from?

And WebADM can use that information to decide which application settings should apply.

We’re already a long way from: MFA: ON/OFF.

But it gets more interesting.

What if something doesn’t look right?

This is where Dynamic Application Settings come in.

WebADM can dynamically change Web application or Web service settings when a source IP is identified as belonging to botnet infrastructure, TOR, or public VPN endpoints. RCDevs provides a cloud microservice that performs these checks against public IP databases.

Now we can introduce Step-Up.

Imagine Sarah normally authenticates using the company’s standard OpenOTP policy. Then an authentication involving Sarah’s account arrives through a public VPN endpoint. WebADM can react by entering Step-Up mode.

But here’s the interesting part.

Step-Up doesn’t simply mean “ask for MFA.”

YOU decide what Step-Up means.

In RCDevs’ example configuration, Step-Up changes OpenOTP to require LDAP + OTP, enables Push Login, and changes account-blocking settings.

So you could have:

You’re not limited to adding another factor. You’re changing the application’s security configuration for that situation.

Sometimes the correct response isn’t more MFA. It’s “No.”

WebADM’s risk-based mode can go further. With Risk-Based Policy Level 1, a matching suspicious source triggers the configured Step-Up settings.

Mit Level 2, a public VPN endpoint triggers Step-Up while an IP identified as belonging to botnet infrastructure results in access being denied. That’s an important distinction.

• If something looks unusual: Step Up.
• If something crosses the organization’s risk threshold: Deny.

There’s little value in sending a friendly Push notification to a user every time somebody tries their credentials from infrastructure you’ve already decided not to trust.

Here’s the fun part: security can also Step Down

Security discussions tend to focus on adding things.

• More authentication.
• More controls.
• More verification.
• More prompts.

But there’s another question: What if we already have enough trust?

Why bother the user again?

WebADM’s Dynamic Application Settings also support Step-Down settings.

The administrator defines what the application should do when the policy is operating in Step-Down mode.

For example:

You’re not turning MFA off for the company.

You’re saying: Under these specific circumstances, we have enough additional context to temporarily use a less restrictive authentication policy.

That’s very different.

Sarah just badged into the office. Shouldn’t that count for something?

This is where physical and digital security can meet.

Imagine Sarah arrives at headquarters at 8:55 AM.

She badges in using her OpenOTP-Token-App. (To learn more about Mobile Badging with OpenOTP, please read this blog).

That’s information. The organization has just received another signal that Sarah is physically present.

WebADM allows a Client Policy’s operating mode to be temporarily changed to Step-Down, Step-Up, or Deny for a defined period. The changed mode can also be applied together with Per-Group and/or Per-Network policies. Step-Down isn’t automatically triggered by the risk mechanism; it can be explicitly enabled through the policy’s Change Mode function.

For example:

That’s much more precise than saying: “MFA isn’t required in the office.”

You could instead build policy around a combination of: the user + their group + the network + the application + the current operating mode.

So perhaps: Employee + badged in + corporate network → Step Down for one hour.

But: Privileged administrator + corporate network → Still require phishing-resistant authentication.

And: Employee + external network → Normal MFA.

YOUR organization decides what makes sense.

Trusted Contexts: “Didn’t I just prove who I am?”

OpenOTP has another useful mechanism for reducing authentication friction: Contextual Login.

With Trusted Contexts enabled, OpenOTP can recognize a trusted user-device/IP context following successful two-factor authentication.

Subsequent requests matching that trusted context can switch the LoginMode to LDAP-only.

The trust doesn’t have to last forever either. Context Expiration determines when the trusted IP/device context expires, while Context Renewal can extend the context after successful logins up to a configured maximum lifetime.

So:

This gives you a useful principle: Trust is earned, scoped, and temporary.

The user isn’t simply being exempted from MFA. OpenOTP is using previously established context to determine whether another challenge is necessary.

Now put everything together

This is where WebADM-Richtlinien become much more interesting than a checkbox labeled “Require MFA.”

When somebody requests access, your policy can potentially take several dimensions into account:

That’s the story.

• Identity matters.
• Group membership matters.
• The application matters.
• The network matters.
• Risk matters.
• Previously established trust matters.
• Physical badging can matter.

And your company decides how much each of those things matters.

Fine-grained doesn’t mean painful

There’s an important point here.

We’ve just discussed a lot of controls. The user shouldn’t need to understand any of them.

Sarah doesn’t need to know that WebADM has evaluated her group, Client Policy, network, trusted context, risk state, and current policy operating mode.

She should simply get the appropriate experience.

• In a normal situation: Approve login.
• In an established trusted context: Maybe she doesn’t even see an MFA prompt.
• When risk increases: Additional authentication required.
• When the policy says the risk isn’t acceptable: Access denied.

The complexity belongs in the policy engine, not in the user’s daily experience.

That’s how fine-grained access controls can actually reduce friction instead of creating more of it.

Sometimes the policy should say: “Ask someone”

Not every access decision can, or should, be fully automated.

Imagine a contractor requesting access to a sensitive system. Everything might be technically valid, but the organization still wants a manager or system owner to approve the request.

WebADM unterstützt Access Approval Conditions for this.

Access can require approval from one or more designated approvers. WebADM and OpenOTP generate the approval request, and authorized approvers can receive it through the OpenOTP Token application’s Push functionality. The approval email can also contain transaction details such as the user, domain, source IP, and Client ID.

Sometimes the correct security decision really is: Ask Jane.

“Sign this before you get access”

There’s another interesting Client Policy feature: User Access Consent / Contract Signing.

WebADM can require users to sign a document before they’re allowed to access a system.

That document could be an NDA, Terms and Conditions, an acceptable-use policy, or another agreement. The signed document can have a validity period, and if the original document changes, WebADM can require the user to sign the updated version before authenticating again. (RCDevs | Dokumentationszentrum)

That creates workflows such as:

That’s a good example of why conditional access doesn’t have to stop at authentication.

Sometimes your company’s access rule really is: You can access this system after you’ve signed this document and your manager has approved it.

Why shouldn’t the security system enforce that rule?

How does this compare with Microsoft Conditional Access?

There’s an obvious comparison with Microsoft Entra Conditional Access.

Both approaches share an important idea: Don’t make access decisions based on credentials alone. Evaluate context and apply the appropriate controls.

But I wouldn’t frame WebADM as “our version of Microsoft Conditional Access.” That’s not the interesting part.

The interesting question is: What does your actual infrastructure look like?

Many companies don’t live entirely inside one identity ecosystem.

They may have:

• Active Directory
• LDAP
• RADIUS
• VPNs
• Firewalls
• Windows
• Linux
• SAML applications
• OpenID Connect applications
• On-premise systems
• Cloud services
• Legacy applications that are still doing their job perfectly well

WebADM Client Policies can match integrations using mechanisms such as RCDevs Client IDs, RADIUS NAS identifiers and IP addresses. RCDevs also supports SAML and OpenID Connect integrations through its Identity Provider.

So rather than forcing your access-policy architecture to follow a particular cloud ecosystem, WebADM and OpenOTP can sit across the mixed infrastructure many organizations already operate.

That’s an important distinction.

Your infrastructure doesn’t need to become somebody else’s idea of an infrastructure before you can apply contextual authentication to it.

Build policies around how your company actually works

Instead of starting an OpenOTP deployment by asking: “Where should we turn MFA on?”

Try asking: “What level of authentication do we actually need under each condition?”

You might end up with something like:

There is no universal table that works for every organization. And that’s exactly the point.

Your rules. Your policy.

Every company already has access rules.

The problem is that they’re often scattered across Active Directory groups, VPN configurations, firewall rules, MFA settings, physical access systems, application permissions, spreadsheets, internal procedures, and instructions that end with: “If that happens, call Mike.“

WebADM’s policy model gives you a way to express more of those rules around the authentication itself.

• Who is requesting access?
• What group are they in?
• What are they accessing?
• Where are they?
• Has trust already been established?
• Has the situation become riskier?
• Did they badge in?
• Does somebody need to approve this?
• Do they need to sign something first?

And then OpenOTP can adapt.

• Normal? Use the normal policy.
• Trusted? Reduce unnecessary friction.
• Risk increased? Step Up.
• Need authorization? Ask for approval.
• Risk unacceptable? Deny.

The objective isn’t to put more security prompts in front of users. It’s to make better access decisions.

• When everything looks normal, use the normal policy.
• When trust has already been established, get out of the user’s way.
• When the context changes, adapt.
• When risk increases, increase security.
• When human authorization makes sense, ask for it.
• And when the risk is unacceptable, simply say NEIN.

That’s what fine-grained access policies should do.

Your company already has its own users, groups, applications, networks, workflows, physical access controls, exceptions, and security requirements. Your cybersecurity solution shouldn’t force you to reorganize all of that around a predefined model.

It should adapt to the way your company actually works.

With WebADM Policies and OpenOTP, you define the rules. OpenOTP applies the appropriate authentication requirements according to the context.

The result isn’t more authentication. It’s the right authentication, at the right time, for the right access.

And for the user? Ideally, they don’t even notice how much is happening behind the scenes.

Your business. Your rules. Cybersecurity that adapts.