Conditional access is a policy that is evaluated whenever someone signs in or an app asks for a new token: it looks at signals such as who the user is, which app they want, what device they are on and where the request comes from, and then decides whether to allow it, block it, or allow it only if the user does something extra, like completing MFA. Most people meet the term through Microsoft Entra ID, where it is a named product feature, but the idea is not Microsoft’s. Any identity provider that can make a different decision for different sign-ins is doing conditional access, and Keycloak does it with conditional authentication flows.
What is conditional access, in plain terms?
Without it, a login system has one rule for everybody: enter the password, maybe enter a code, and you are in. Conditional access replaces that single rule with a set of if/then statements. If the user is an administrator, require a hardware key. If the request comes from outside the office network, require MFA. If the app is the payroll system, require a fresh sign-in. If the user is on an unmanaged laptop, let them read email but not download files.
Microsoft describes its version as the “policy engine” of its zero trust approach, which combines signals to make decisions and enforce organizational policies (Microsoft Learn, “Microsoft Entra Conditional Access: Zero Trust policy engine”, 2026). The phrase “zero trust” here only means that being inside the network is not treated as proof of anything, so every sign-in is judged on its own evidence.
What signals does a conditional access policy use?
A policy can only decide on information it has, so the useful question when you design one is which signals your identity provider can actually see. The common ones are:
- User and group: who is signing in, including their role (administrator, contractor, employee).
- Application: which app or API the person is trying to reach, so a finance tool can be stricter than a wiki.
- Device: whether the device is managed or compliant, if your identity provider is connected to a device management system.
- Location and network: the IP address range or country the request comes from.
- Risk: a score from the identity provider, based on things like impossible travel or a password found in a breach list.
- Current authentication level: how the user already proved who they are in this session, for example a password only, or a passkey.
Not every provider can see every signal. Device compliance and risk scoring depend on integrations with other products (in Entra, risk-based policies need the Entra ID P2 license and Conditional Access itself needs P1), whereas user, application and authentication level are available in almost any modern identity provider.
What decisions can a policy make?
On the output side, a policy can block the sign-in, allow it, or allow it with conditions (a grant requirement, in Microsoft’s wording). The usual conditions are completing MFA, requiring a specific authentication strength (Microsoft’s term for a set of allowed methods, such as phishing-resistant ones), using a phishing-resistant method, using a compliant device, or accepting terms of use. A second kind of decision limits the session after sign-in, such as shortening how long the session lasts or restricting what can be done inside the app.
If you are choosing which MFA methods to demand, our guide to what phishing-resistant MFA is lists which methods qualify, and that list is a good source of “require a stronger method” decisions for your most sensitive policies.
What is the difference between MFA and conditional access?
MFA is a control, and conditional access is the logic that decides when to apply it. MFA answers the question “how does this person prove who they are?” by asking for a second factor. Conditional access answers “does this sign-in need that proof, and how strong should it be?” You can have MFA without conditional access, in which case everyone gets the same prompt every time, and you can have conditional access that sometimes blocks a sign-in outright without ever asking for a second factor.
In practice the two are used together. MFA for everyone all the time tends to produce prompt fatigue, while a conditional policy can ask for it where the risk is, such as a new location or a sensitive app, and stay out of the way elsewhere. Our features page on multi-factor authentication covers the factors themselves.
Which conditional access policies should you start with?
A short starting set covers most of the risk without becoming too complex to reason about:
- Administrators must use a phishing-resistant method. Admin accounts are the ones attackers want most, so this is the highest-value single policy.
- Block legacy authentication protocols. Older protocols that cannot do MFA at all give attackers a path around every other policy. In Keycloak, the closest equivalent is disabling Direct Access Grants (the password grant) on clients that do not need it, because that grant skips the browser flow and its MFA steps.
- Step up for sensitive apps. Allow normal access to the intranet, but ask for a stronger factor or a recent sign-in for payroll, source code hosting or the admin console.
- Require MFA from outside trusted networks. If you do not want to prompt people in the office, scope the requirement to everything else.
- Keep at least one break-glass account out of the policies. If a policy is wrong, you need a way back in. See what a break-glass account is for how to set one up and monitor it.
Resist the urge to add a policy for every edge case early on. Each additional policy interacts with the others, and the combined effect is what users actually experience.
What can go wrong when you exclude an app from a policy?
Exclusions are the most common reason a conditional access policy does not apply when you expect it to. A common pattern is a policy that targets all resources and carves out a few apps that cannot handle MFA. Microsoft changed how that pattern is enforced in 2026: previously, a policy targeting all resources with at least one resource exclusion was not enforced when a user signed in through a public client app that requested only baseline scopes (openid, profile, email, offline_access and a few basic Microsoft Graph scopes such as User.Read). Microsoft began closing that gap in 2026, so sign-ins that previously were not covered by such a policy now get the challenge (Petri, “Microsoft to Close Conditional Access Loophole in Entra ID Sign-Ins”, 2026). Trade-press coverage gives mid-June 2026 as the start of enforcement, but rollout timing varies by tenant, so check the Message Center notice for your own tenant.
The general lesson is independent of Microsoft: an exclusion is an exception to your policy, and exceptions deserve the same review as the policy itself. List them, give each one an owner, and re-check whether the reason for the exclusion still holds.
How does conditional access work outside Microsoft Entra?
The idea carries over to any identity provider, though the vocabulary changes. In Keycloak the building block is the authentication flow, a sequence of steps a user goes through at sign-in, and a flow can contain conditional sub-flows that only run when a condition is true. The conditions that ship with Keycloak include the user’s role, a user attribute, whether the user has configured a given authenticator, and the level of authentication that the application requested (Keycloak documentation, “Server administration guide: Authentication flows”). So “administrators must use a security key” becomes a conditional sub-flow with a user role condition that contains the WebAuthn step. Place the conditional sub-flow after the step that identifies the user (the username and password form), because a role or attribute condition cannot be evaluated before Keycloak knows who is signing in. Putting it earlier is a common reason these flows appear to do nothing.
Step-up is the second half. An application that needs a stronger sign-in for a sensitive action sends the acr_values parameter on the authorization request, and Keycloak maps that value to a level of authentication and runs the extra steps only if the current session has not reached that level yet. Our step-up authentication guide walks through the configuration end to end.
Be aware of what core Keycloak does not do out of the box. It has no built-in device compliance signal or risk score, and network location is something you typically handle in front of Keycloak (with a reverse proxy or a network rule) or with an extension. The built-in conditions are rule-based, so adaptive access that reacts to a risk score needs extensions. If those signals are central to your policy design, plan for that gap early. For a side-by-side look at how the two products divide this work, see our Keycloak vs Microsoft Entra ID comparison.
On a managed Keycloak service such as Skycloak, the flows and conditions are the same upstream Keycloak features, with the server operated for you, so the work that remains is designing the policy. Network-level allow and block rules are covered by IP access control and geo-blocking, which can block by network or country but do not by themselves require MFA from outside the office. Workforce deployments tend to need more of these rules than customer-facing apps do, which is covered on our workforce IAM page, and session limits are described under session management.
How do you roll out policies without locking everyone out?
Plan the rollout around the fact that a wrong policy affects everybody at once:
- Test in a mode that does not enforce. Entra has a report-only mode that logs what a policy would have done, which lets you see the effect on real sign-ins first. In Keycloak, create the new flow, bind it to a test client or a test realm first, and only then bind it to the production browser flow.
- Start with a pilot group. Apply the policy to a handful of people who will tell you quickly when something breaks.
- Keep a way back in. Have a break-glass account that is excluded from the policy, protected by a long unique password and monitored with an alert on any use.
- Write down the intent of each policy. In six months nobody will remember why the finance app has a two-hour session limit.
Start with the five policies above, test each one in report-only mode or against a test client before it applies to everyone, and write down which signals your identity provider cannot see so that nobody assumes a rule exists when it does not.
FAQ
What is conditional access in simple words?
It is an if/then rule that is checked at every sign-in. The “if” uses signals such as the user, the app, the device and the location, and the “then” is a decision to allow, block, or allow after an extra step like MFA.
Is conditional access only a Microsoft feature?
No. Microsoft Entra ID has a product called Conditional Access, which requires the Entra ID P1 license (P2 for risk-based policies), but the technique is general. Keycloak, Okta, Auth0 and others all offer ways to choose different sign-in requirements for different situations, under different names.
What is the difference between MFA and conditional access?
MFA is the extra proof of identity, and conditional access is the policy that decides when to ask for it. Conditional access can also block a sign-in, limit a session, or require a specific method, none of which MFA does by itself.
Does conditional access replace a firewall or VPN?
No, they work at different layers. A firewall or VPN controls network reachability, whereas conditional access controls who gets an authenticated session to an application. Zero trust designs use both, with conditional access carrying the identity decision.
Can Keycloak do conditional access?
Yes, for the signals it can see. Conditional authentication flows cover user role, user attributes, configured authenticators and requested level of authentication, and step-up with acr_values covers sensitive actions. Device compliance, risk scoring and location usually need something in front of or alongside Keycloak.