Conditional Access: Designing Policies That Adapt to Risk

Conditional access evaluates each authentication attempt against signals — who, from where, on what device, to what — and decides what is required. It replaces the binary question of whether the password was correct with a proportionate one, and it is the practical implementation of zero trust at the identity layer.

The signals

Identity. Who the user is, which groups they belong to, and whether the account is privileged. A global administrator warrants different requirements from a contractor with read access to one application.

Location. Network and geographic origin. Useful for requiring more from unfamiliar locations, and weak as a sole control — a corporate IP range is not proof of anything, given VPNs and compromised devices sitting inside it.

Device. Whether it is managed and enrolled, whether it meets compliance policy, and whether it holds a device certificate. This is the strongest signal available, because a managed device is one you have some assurance about.

Application. What is being accessed, and its sensitivity.

Risk. A calculated score from behavioural analytics — impossible travel, an unfamiliar sign-in pattern, credentials appearing in breach data, an address associated with anonymising infrastructure. This is where the analytics described under UEBA feed directly into an enforcement decision.

The controls a policy can require

Block outright. Require multi-factor authentication, with the option to demand a phishing-resistant method for sensitive access — the origin-bound properties under FIDO2 and passkeys. Require a compliant or managed device. Limit the session, permitting browser access without download, or shortening the session lifetime so re-evaluation happens sooner. Require terms acceptance or a password change.

Session controls are the underused one. Where access must be granted but the context is uncertain, a read-only browser session with no download is frequently the right answer rather than a binary allow or deny.

A baseline policy set

Most organizations converge on a similar starting point, and it is worth knowing as a pattern rather than a recipe.

Block legacy authentication everywhere. Older protocols cannot enforce multi-factor authentication, so every other policy is bypassable while they remain enabled — the entry point described under password spraying. This single policy does more than the rest combined.

Require MFA for all users, with phishing-resistant methods for administrators.

Require a compliant device for access to sensitive applications, and limit unmanaged devices to browser-only sessions.

Require MFA or block on elevated risk, driven by the risk score.

Block from locations you never operate in, accepting that this is easily evaded and removes background noise.

Restrict administrative access to managed devices from known locations, with stronger authentication and shorter sessions.

Locking yourself out

The failure mode that has taken organizations offline for days, and it is entirely avoidable.

A policy requiring a compliant device, applied to all users including administrators, locks out the administrators who would fix it — because their device enrolment depends on a service they can no longer reach.

Two protections. Break-glass accounts: two or more cloud-only administrator accounts excluded from every conditional access policy, with very long random passwords stored offline, monitored so any use raises an immediate alert, and tested periodically to confirm they still work. Report-only mode: deploy every new policy in a mode that logs what it would have done without enforcing, review the results against real sign-ins, then enable it.

Skipping report-only mode is how the outage happens, and it costs nothing.

What it does not solve

Conditional access evaluates at sign-in. A session already established continues under the conditions that existed when it started, which is why continuous access evaluation — re-evaluating mid-session on significant events such as a disabled account or a location change — matters, and why revoking sessions is a separate action from disabling an account, as under credential breach response.

It also cannot help where the attacker holds a valid session token, which is the infostealer scenario, and it does nothing about what an authorized user does once inside — that is authorization and monitoring.

Exam angles

Know conditional access as evaluating identity, location, device state, application and calculated risk to determine access requirements dynamically. Name block, require MFA, require a compliant device and session restriction as the controls. Recognize blocking legacy authentication as the foundational policy, break-glass accounts excluded from all policies as the lockout protection, and report-only mode as the safe deployment path.