Conditional access, device state and risk-based authentication

What Conditional Access is

Conditional Access is a policy engine that sits between authentication and authorisation. Authentication has produced a successful credential check; authorisation is the resource server's later decision about what the user may do; Conditional Access lives in the gap, evaluating signals about a sign-in and deciding whether to allow it, allow it under conditions, or block it. Other IdPs offer the same idea under other names: Okta's Adaptive Authentication, Google's Context-Aware Access, Auth0's Adaptive MFA. Authentication itself is left untouched: a user who authenticates with a valid password and MFA can still be blocked on the basis that the device is non-compliant or the risk is too high, while a user who fails the password check never reaches the engine at all.

The structure of a policy

A policy has two parts: assignments and access controls. Assignments describe who and what it applies to. The user assignment selects users by identity, group, role or 'all users' with exclusions. The cloud apps assignment selects applications by individual app, by category (Microsoft maintains thousands of pre-categorised SaaS, including a generative AI category), or by 'all cloud apps'. The conditions assignment narrows by sign-in risk, user risk, device platform, location, client app type, device state or authentication context.

Access controls describe what happens when assignments match. Grant controls operate at sign-in: block access, require MFA, require authentication strength, require a compliant device, require a hybrid-joined device, require an approved client app, require an app protection policy, and others, combined with a Boolean for whether all or any are needed. Session controls operate during the session: sign-in frequency, persistent browser session, app-enforced restrictions, and Conditional Access App Control, which routes the session through Defender for Cloud Apps. The combination logic matters: every policy whose assignments match is evaluated, and a sign-in must satisfy the grant controls of every matching policy. This is what makes a tenant with thirty policies hard to reason about, and it is also the source of the engine's reach.

The signals

User identity is who is signing in, with group and role membership; most tenants target privileged groups specifically. Cloud app is what they are signing in to, and the generative AI category is the natural target for shadow AI controls. (medium; the category name and membership move with vendor releases) Device platform names the operating system. Location combines source IP with named locations: a trusted location is a corporate range, and common policies require extra MFA from outside trusted locations, with the caveat that travelling staff and personal-VPN users appear to come from anywhere. Client app type distinguishes modern authentication from legacy authentication (older mail protocols) that cannot carry an MFA challenge, so any MFA requirement is bypassed wherever legacy authentication is still allowed; tenants that have not finished retiring it cannot enforce MFA universally.

Device state bridges to Part Three. 'Compliant' means the device has reported to Intune within its policy window and is passing compliance; 'hybrid joined' is a Windows device joined to on-premises Active Directory and registered in Entra. The device-state signal is what lets a policy say 'compliant device only', the most leveraged single grant control for shadow AI at the device boundary. Sign-in risk and user risk come from Entra ID Protection: sign-in risk is a real-time score (impossible travel, anonymous IP, atypical patterns), and user risk is cumulative (leaked credentials, prior risky sign-ins). ID Protection requires Entra ID P2, included in Microsoft 365 E5 and A5 but not E3 or A3. (medium; the licensing boundary has moved before) Authentication context is a custom signal a sensitive resource can require, so a finance application can demand stronger authentication on specific operations without the whole tenant carrying the friction.

Risk-based authentication and continuous evaluation

Risk-based authentication uses the ID Protection signals to drive decisions in real time, on the basis that risk is dynamic. Continuous Access Evaluation (CAE) is what makes near-real-time response possible after authentication: without it, an access token issued at 9am stays valid until it expires regardless of what happens to the user's risk; with it, when risk rises or an admin revokes sessions, supporting Microsoft 365 services re-evaluate and can revoke within a minute or two. CAE coverage is uneven: major Microsoft 365 services support it, many third-party SaaS do not, and a policy that depends on rapid revocation only gets it against services that support the protocol. (medium; the coverage list changes as services adopt it)

Authentication strength sits on top of the older 'require MFA' control. 'MFA' historically meant any second factor, including SMS and authenticator-app push. Authentication strength lets a policy require a specific class, such as phishing-resistant MFA (passkey or FIDO2 only). This matters for adversary-in-the-middle phishing: a password and an authenticator push can both be relayed by an AiTM page, but a passkey cannot, because it is bound to the legitimate origin and refuses to authenticate against an attacker-controlled domain.

The shadow AI lens

The natural place to write shadow AI policy is at the IdP, against the generative AI category. A single policy that says 'require compliant device to access generative AI tools' covers the AI estate federated to the corporate IdP and scales as new tools appear in the category. Combined with a tenant-wide 'block legacy authentication' policy and an 'all cloud apps require MFA' baseline, the corporate sign-in path to AI tools is closed to anything not coming from a managed device.

The personal-account boundary, restated mechanically: Conditional Access only evaluates authentications that reach the corporate Entra tenant. A personal Microsoft account, a personal Google account, an email-and-password sign-up against an AI tool, none of these reach Entra, so the engine is silent on them. This is why 'we have Conditional Access blocking AI tools, so we are fine' is incomplete. The 'require compliant device' grant control is the most leveraged single control at the device boundary, because even with valid corporate credentials and MFA, sign-in is denied unless the device is enrolled and passing compliance, which closes the path of using corporate credentials from a personal phone or a contractor's laptop, and produces a visible 'this device is not compliant' message rather than a silent allow. It does not, by itself, address the personal-account path: the same staff member can still sign in with a personal Gmail address, which the engine never sees.

Adversary-in-the-middle phishing is the contemporary attack, and phishing-resistant authentication strength is the response that stops the AiTM page relaying the authentication. For shadow AI, tokens stolen from a user's session against an AI tool can read corporate data through whatever scopes the tool was consented to until the token is revoked; CAE shortens the revocation window, and phishing-resistant strength prevents the theft in the first place, both implemented through Conditional Access. The most common failure in organisations that have invested in the product is the belief that the problem is solved by owning it. The architectural question is not 'do we have Conditional Access' but 'what does it reach, and what does it not', which the next chapter takes into the specific case of 'sign in with Microsoft' on consumer AI tools.

Last updated 9 August 2026