Conditional access

Conditional access is the policy decision point of an identity provider applied at token issuance. In NIST SP 800-207 terms the IdP's policy engine evaluates signals and the token service acts as enforcement point: if a request fails policy, no token is issued, or the token is issued only after an additional step. The term is Microsoft's product name in Entra ID, but equivalents exist elsewhere, such as Okta's authentication policies and Google's context-aware access. In Entra ID each policy is an if-then rule made of assignments (users, groups, workload or agent identities, target resources) plus conditions (sign-in and user risk, device platform, named locations and countries, client app type, device filters) and access controls. Grant controls block, or require MFA, an authentication strength, a compliant or hybrid-joined device, an approved client app or an app protection policy; session controls set sign-in frequency, persistent browser behaviour and app-enforced restrictions.

Evaluation details matter. Microsoft documents that policies are enforced after first-factor authentication, so conditional access does not stop password spraying or lockout attacks; it decides what happens after the password is right. All policies that match a sign-in are combined: every grant requirement must be satisfied and any block wins. Because the decision is taken when the token is issued, an already-issued access token remains usable until it expires unless the application supports Continuous Access Evaluation, which lets resource providers such as Exchange Online reject tokens promptly after critical events such as account disablement or password reset.

Typical baseline policies are MFA for all users, phishing-resistant authentication strength for administrator roles, blocking legacy authentication protocols (which cannot perform MFA and so bypass the rule), requiring managed devices for sensitive apps, and risk-based step-up. Licensing shapes design: conditional access requires Entra ID P1, while sign-in and user risk conditions depend on Entra ID Protection, a P2 feature.

Failure modes are mostly configuration gaps. Exclusions accumulate, whether for service accounts, a VIP or a legacy app, and each one is a hole; emergency break-glass accounts must be excluded to avoid lock-out, which makes their monitoring essential. IP location is weak evidence because VPNs and cloud hosting mask origin. Device-compliance checks rely on the MDM's view of the device. Stolen session cookies from adversary-in-the-middle phishing replay a token that already passed policy, which is why token binding and short sign-in frequency complement it. Microsoft recommends running new policies in report-only mode first and using the What If tool; changes should be versioned and reviewed like code, since one mistaken policy can lock out an entire tenant.