Conditional Access Guide

A correct password is no longer enough evidence to grant access, yet most tenants still issue tokens to any sign-in that no policy happens to catch. Conditional access, also called context-aware or adaptive access, is the policy layer that sits between authentication and token issuance: it looks at who is signing in, from what device, from where, to which resource and with what risk, then allows, blocks or demands more proof. This guide explains the vendor-neutral model first, then uses Microsoft Entra Conditional Access as the documented worked example, including its controls for service principals. It covers policy design, authentication strengths, device and app requirements, session lifetime, report-only testing, gap analysis, monitoring and the mistakes that leave gaps. It is written for identity engineers, security architects and the administrators who own the tenant.

Key takeaways

• Conditional access decides after the first factor. It does not replace good credentials; it decides what a presented credential is allowed to obtain.
• Coverage matters more than cleverness. In Entra, tokens are issued by default when no policy condition triggers a control, so a small set of broad policies targeting all users and all resources beats dozens of per-app rules.
• Block legacy authentication and require a named authentication strength. Legacy protocols cannot do MFA or pass device state, and authentication strengths let you require phishing-resistant methods for administrators rather than "any MFA".
• Test in report-only, roll back by disabling. Run each policy in report-only mode for at least a week, use the What If tool for specific cases, keep two excluded emergency access accounts and treat every other exclusion as a debt.
• Workload identities need their own policies. User-scoped policies do not block service principals; Entra can block single-tenant service principals by location or risk, but not managed identities or multitenant SaaS apps.

How conditional access works

Every conditional access product follows the same pattern, described in NIST SP 800-207 as a policy decision point feeding a policy enforcement point. Zero trust "assumes there is no implicit trust granted to assets or user accounts", so authentication and authorisation are completed for each request to a resource rather than once at the network edge. In identity platforms the identity provider is both: it evaluates policy at sign-in and enforces it by issuing, withholding or limiting tokens.

• If-then rules: Microsoft describes its policies "at their simplest" as "if-then statements": if a user wants to access a resource, then they must complete an action. Google Cloud expresses the same idea as access levels that "describe the requirements for requests to be honored", built from IP ranges, device attributes, identity and region.
• Evaluated after first-factor authentication: Entra policies "are enforced after first-factor authentication is completed", so password spraying still needs lockout and detection, and stolen passwords still need phishing-resistant methods.
• Decisions are made at token issuance: once a token is issued, the policy is not re-checked until the token is refreshed, unless the platform supports continuous evaluation. Entra notes that "Policies targeting roles or groups are evaluated only when a token is issued."
• Continuous evaluation narrows the window: Entra's continuous access evaluation (CAE), based on the OpenID Continuous Access Evaluation Profile, lets Exchange Online, SharePoint Online, Teams and Microsoft Graph act on critical events such as account disablement, password reset or high user risk within up to 15 minutes, and on IP location changes immediately. Tokens in CAE sessions can live up to 28 hours instead of one hour.

Signals and their limits

Some signals are verified by the platform; others are client claims an attacker can change.

Microsoft Entra Conditional Access: anatomy of a policy

An Entra policy is "an if-then statement of Assignments and Access controls". Assignments define who (users, groups, roles, guests, workload identities), what (target resources) and where (network and conditions). Access controls are grant controls and session controls. It requires Microsoft Entra ID P1 (or Microsoft 365 Business Premium); sign-in and user risk conditions require ID Protection, a P2 feature; policies for service principals require Workload Identities Premium. The tenant limit is 240 policies in any state.

Evaluation rules that catch people out

• All assignments are ANDed: a policy fires only if every assignment matches. Adding a condition narrows the policy; it never widens it.
• All applicable policies must be satisfied: there is no priority order. If any applicable policy uses Block, "enforcement stops here and the user is blocked."
• Default is allow: "Access tokens are issued by default if a Conditional Access policy condition doesn't trigger an access control." Anything outside your policies' scope gets a token after first-factor sign-in.
• Grant controls combine: by default multiple controls mean "Require all the selected controls"; "Require one of the selected controls" prompts in a fixed order (MFA, compliant device, hybrid join, approved client app, app protection policy, password change, terms of use, custom controls).
• Session controls apply after grant: sign-in frequency, persistent browser session, token protection, app enforced restrictions and Defender for Cloud Apps session control.

Grant and session controls

Designing a baseline policy set

Microsoft's deployment plan advises against "a policy for each app" and suggests grouping apps by the same requirements for the same users. Its phased baseline translates to other identity providers too.

Design rules

• Legacy authentication: Microsoft reports that, on its analysis, "more than 99 percent of password spray attacks use legacy authentication protocols." The Other clients option covers SMTP, IMAP4, POP3, EWS, MAPI over HTTP and similar basic-authentication endpoints. See the MFA Guide.
• Authentication strength over "require MFA": the plain MFA grant accepts SMS and push, which real-time phishing proxies relay. Require Phishing-resistant MFA for administrators first, then extend it. Custom strengths can restrict FIDO2 keys to specific models by AAGUID. See the Passwordless and Passkeys Guide and the MFA Fatigue and Bypass Guide.
• Named locations: limits are 195 named locations and 2,000 IP ranges per location, with CIDR masks larger than /8. Marking egress ranges as trusted improves ID Protection's risk scoring. Do not use a trusted location as a reason to skip MFA for privileged roles, and avoid the legacy "MFA trusted IPs" setting, which is IPv4 only and not recommended.
• Device filters: base rules on system or admin-set properties (trustType, isCompliant, deviceId, extensionAttribute1 to 15), not displayName, model or manufacturer. Unregistered devices have null properties, so use negative operators such as device.extensionAttribute1 -ne "SAW" with Block to catch them. Extension attributes are only readable on Intune-managed, compliant or hybrid joined devices.
• Authentication context: up to 99 contexts (c1 to c99) let an application or Privileged Identity Management demand step-up for a sensitive action, such as opening a labelled SharePoint site or activating a privileged role, without forcing it on every sign-in.
• Naming: encode sequence number, apps, response, users and condition; prefix contingency policies "ENABLE IN EMERGENCY".

Choosing between options

• Small organisations: if you lack P1, Entra security defaults give baseline MFA, but they cannot be combined with conditional access. Policy templates are created in report-only and exclude only the creating user, so add your emergency accounts.
• Large organisations: manage policies as code through Microsoft Graph with change control, use persona-based groups (admins, workforce, guests, frontline) and budget the 240-policy limit, which counts report-only and disabled policies.

Where identity fits: workload identities and service principals

User policies do not protect machine identities. Microsoft states that "Calls made by service principals aren't blocked by Conditional Access policies scoped to users." A stolen client secret or certificate for an app registration therefore bypasses every MFA and device policy in the tenant. The Microsoft Midnight Blizzard breach shows how a forgotten test tenant and an OAuth app can sit outside the controls applied to production users.

• What Entra covers: "single tenant service principals that are registered in your tenant". Policies can block a service principal when its token request comes from outside known IP ranges, or when ID Protection detects service principal risk, and can be combined with authentication contexts. Block is the only grant control. Workload Identities Premium is needed to create or edit these policies.
• What it does not cover: "Microsoft and third-party SaaS applications, including multitenant apps, are not covered", and "Managed identities aren't covered by policy." Govern these through access reviews, permission scoping and app governance instead. See the SaaS and OAuth App Governance Guide.
• Assign directly: policies assigned to a group that contains a service principal are not enforced for it; select the service principal itself as a workload identity, using the object ID from Enterprise applications, not from App registrations.
• Replace user accounts used by scripts: Microsoft recommends managed identities instead of user accounts in code. Excluding a "service account" user from MFA policies creates a password-only path an attacker can spray. Where an exclusion is unavoidable, pair it with a location or device filter policy. See the Service Account Security Guide and the Cloud Workload Identity Guide.

Rolling out and rolling back

1. Create emergency access accounts first. Two or more cloud-only accounts on the *.onmicrosoft.com domain, Global Administrator, passkey (FIDO2) or certificate-based authentication that differs from other admins, excluded from every policy that blocks or restricts sign-in. See the Break-Glass Account Guide.
2. Inventory current behaviour. Filter sign-in logs by the Client App column on both interactive and non-interactive tabs to find legacy protocols, and run the gap analyzer workbook to find apps, users and locations no policy covers.
3. Make sure users can comply. Confirm methods are registered and devices enrolled before requiring them.
4. Deploy in report-only. Microsoft advises at least one week per policy. Results show as Report-only: Success, Failure, User action required or Not applied. Exclude macOS, iOS and Android from report-only compliant-device policies, which can prompt for a certificate. User actions cannot be tested in report-only.
5. Simulate edge cases. Use the What If tool (users and single-tenant service principals) with identity, App ID, device platform and client app all set; it shows the first unmet condition per policy but does not model service dependencies.
6. Pilot, then expand in rings. IT staff, a business pilot group, then everyone. For token protection, review interactive and non-interactive logs covering normal use before enforcing.
7. Roll back cleanly. Disable the policy rather than deleting it, or exclude an affected user temporarily and put them back promptly. Deleted policies and named locations can be restored within 30 days.

Detection and measurement

• Policy changes: attackers with admin rights weaken policies to keep access, which MITRE ATT&CK tracks as T1556.009 Modify Authentication Process: Conditional Access Policies, for example by adding trusted IP ranges or removing MFA requirements. Alert on Entra audit log activity for conditional access policy and named location changes, and restrict the Conditional Access Administrator role (mitigation M1018).
• Emergency account use: alert on any emergency account sign-in in Log Analytics or a SIEM, and test the accounts at least every 90 days.
• Not applied sign-ins: the insights and reporting workbook (P1 plus Log Analytics) shows Success, Failure, User action required and Not applied over up to 90 days, by platform, client app, location, application and sign-in risk.
• Gaps: the gap analyzer workbook reports legacy authentication sign-ins, sign-ins to apps not covered by any policy, high-risk sign-ins bypassing policy, and locations not affected by policy.
• Token replay: hunt for sessions reused from a new IP or device without fresh interactive sign-in (ATT&CK T1539, T1550.001). See the Token and Session Security Guide and the ITDR Guide.

Framework mapping

Common failure patterns

• Policies scoped to a list of apps. New and unlisted applications receive tokens with no control. Target All resources and exclude by exception. The Snowflake breach shows what happens when a platform lets customer accounts sign in with a password alone.
• Exclusions that never expire. Service accounts, executives, travelling staff and a "temporary" vendor group excluded from MFA become the path attackers use.
• Forgotten tenants and app identities. Test tenants, legacy accounts and service principals sit outside the production policy set, as in the Microsoft Midnight Blizzard breach.
• MFA without phishing resistance or session binding. Adversary-in-the-middle kits relay codes and steal the session cookie, then replay it from another device. The CircleCI breach began with a stolen SSO session. Use phishing-resistant strengths, token protection where supported and shorter sign-in frequency for sensitive apps.
• Trusting what the client claims. Device platform and filters on displayName or model can be spoofed; pair them with compliance or app protection, and block unsupported platforms.
• Lockout by Block plus All resources. An untested block with no excluded emergency accounts locks out every administrator. See the Active Directory and Entra ID Hardening Guide.

Practitioner checklist

• Create two cloud-only emergency access accounts with FIDO2 or certificate authentication, exclude them from blocking policies and alert on every sign-in.
• Block legacy authentication for all users and all resources, after checking interactive and non-interactive logs for Client App usage.
• Require the Phishing-resistant MFA authentication strength for every privileged directory role and for admin portals.
• Target All resources in core policies and keep a register of exclusions with owner, reason and expiry.
• Protect the Register security information and Register or join devices user actions.
• Choose compliant device or app protection per persona, and set sign-in frequency and persistent browser session for unmanaged devices.
• Create location or risk policies for single-tenant service principals that hold privileged permissions, and move scripts off user accounts to managed identities.
• Deploy every new policy in report-only for at least a week, check the insights workbook and What If, then pilot before enforcing.
• Alert on conditional access policy and named location changes, and limit who holds the Conditional Access Administrator role.
• Run the gap analyzer monthly and track the Not applied sign-in count.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• Microsoft Learn: Plan a Microsoft Entra Conditional Access deployment
• Microsoft Learn: Building a Conditional Access policy
• Microsoft Learn: Conditional Access for workload identities
• Microsoft Learn: Conditional Access authentication strengths
• Microsoft Learn: Conditional Access report-only mode
• Microsoft Learn: Continuous access evaluation
• MITRE ATT&CK: T1556.009 Modify Authentication Process: Conditional Access Policies

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Identity Provider and SSO Security Guide · NHI Authentication Guide · Hardware Security Keys Guide