Who Decided This Token Is Good? A Field Guide to Conditional Access and Entra ID Protection

1. Who decided this token is good?#

It is 09:02 on a Tuesday in Lisbon. Alice opens Outlook on a managed laptop in a hotel and the reading pane populates with mail in under a second. She did not type a password. She did not approve a push. She did not touch a hardware key.

Who decided that was fine?

The question is harder than it looks. Alice's password lives in a token cache from yesterday's sign-in at the office. Outlook's client silently acquires a fresh access token from Entra. That request may match a Conditional Access policy. The policy may consult an Identity Protection risk score. The result is either an access token or a refusal. Exchange Online receives the token, validates it, and may yet revoke it mid-session because something changed in the last sixty seconds. Bytes return to Alice.

Every component in this chain is individually documented on Microsoft Learn. The Conditional Access policy schema is on the Graph reference ^[4]. The riskDetection resource is on the Graph reference too ^[5]. The cp1 client capability is in the claims-challenge document ^[6]. The "up to 15 minutes" propagation ceiling for CAE non-IP events is in the CAE concept document ^[3].

But the chain is not assembled anywhere. That is what this article does.

This article is for the architect or the detection engineer who already knows what a JWT is, what a service principal is, and what an MDM does. If you have ever stared at a Sign-in log entry that reads "Conditional Access: Success" and wondered what exactly the policy engine concluded, this is for you.

Three moments of insight are coming. First, why MFA without context fails not because MFA is weak but because the unit is wrong (Section 3). Second, why the architectural breakthrough was a separation and not a new algorithm (Section 5). Third, why the system has limits that no engineering will fix (Section 8).

How did the industry end up with a token-issuance and claims-challenge model? The answer begins in 1975, with a paper that did not mention identity once.

2. From perimeter to identity boundary#

In September 1975, Jerome Saltzer and Michael Schroeder published an eight-principle paper on operating-system protection that nobody at MIT thought of as a paper about cloud identity ^[7]. Half a century later, two of those eight -- complete mediation and least privilege -- are the implicit theorems every Conditional Access policy evaluates against. Where did the industry go in between?

Saltzer and Schroeder: the unstated theorems#

Complete mediation says "every access to every object must be checked for authority." Least privilege says "every program and every user of the system should operate using the least set of privileges necessary to complete the job." These are stated as design principles, not theorems. But they function as theorems for anyone building an access-control system: violate either of them and you have, by construction, a vulnerability. Conditional Access does not derive the principles. It re-states them as a JSON schema and a runtime evaluator.

Jericho Forum: the perimeter dissolves#

In 2003, David Lacey of the Royal Mail and a loose affiliation of corporate CISOs began arguing, against the prevailing castle-and-moat consensus, that the corporate network perimeter could no longer be relied on as the trust boundary. The Jericho Forum formally launched under the Open Group umbrella in January 2004 ^[8]. They coined the term "de-perimeterisation" to describe what their member firms were already living: data and identity travelling outside the firewall faster than the firewall could be moved.

Microsoft's own retrospective puts the quote precisely: the Jericho Forum "promoted a new concept of security called de-perimeterisation that focused on how to protect enterprise data flowing in and out of your enterprise network boundary instead of striving to convince users and the business to keep it on the corporate network" ^[9]. The first sentence of Microsoft Learn's CA overview today is a direct descendant: "modern security extends beyond an organization's network perimeter" ^[1].

Kindervag: the name#

John Kindervag, then a principal analyst at Forrester Research, gave the model its marketable name in a September 2010 report titled "No More Chewy Centers: Introducing the Zero Trust Model of Information Security" ^[10]. Three tenets: all resources are accessed securely regardless of location; access control is on strict need-to-know and strictly enforced; all traffic is inspected and logged.

The label stuck. Microsoft Learn now calls CA "Microsoft's Zero Trust policy engine" in its first sentence ^[1]. The lineage from Kindervag's 14-page Forrester report to that sentence is direct.

BeyondCorp: the alternative#

In December 2014, Rory Ward and Betsy Beyer published "BeyondCorp: A New Approach to Enterprise Security" in USENIX ;login: ^[11]. The paper described Google's internal Zero Trust deployment: every request authenticated and authorized by an access proxy, no implicit network trust, device inventory and user identity as the inputs to access decisions. A follow-up in 2016 documented the production rollout ^[12].

This is the architectural fork Section 7 returns to. BeyondCorp puts the policy engine in the data path, as a reverse proxy that sees every HTTP request. CA puts the policy engine at token issuance and re-evaluates via claims challenges. Both work. They are not interchangeable.

NIST SP 800-207: the vocabulary#

In August 2020, NIST published Special Publication 800-207, Zero Trust Architecture ^[13]. It codified the U.S. federal reference architecture: a Policy Engine that decides, a Policy Administrator that effects the decision, and a Policy Enforcement Point that intercepts the access.

That trio is the vocabulary the Microsoft Learn CA documentation now uses. In the SP 800-207 mapping, Conditional Access is the Policy Engine and Policy Administrator; Exchange Online, SharePoint Online, Teams, and Microsoft Graph are the Policy Enforcement Points; Entra ID Protection is the trust algorithm that feeds the Policy Engine.

The doctrine was settled by 2020. But Microsoft had already been trying to build a perimeter on identity for six years, starting in 2014 with a much smaller idea.

3. Per-user MFA and the limits of binary controls#

In 2014, Microsoft's only cloud-era access control was a per-user toggle that said MFA: yes or MFA: no. The toggle worked. It was a real improvement over passwords alone. It also produced the most exploited security failure of the next decade: MFA fatigue ^[14].

How does a control improve security and create a new attack class at the same time?

The per-user MFA state machine#

Per-user MFA lives on the user object as a tri-state: Disabled, Enabled, or Enforced. Microsoft Learn now says the quiet part out loud: "The best way to protect users with Microsoft Entra MFA is to create a Conditional Access policy" and "Don't enable or enforce per-user Microsoft Entra multifactor authentication if you use Conditional Access policies" ^[15]. That guidance carries a generation of operational pain inside it. Mixing the two surfaces, in practice, produces unpredictable prompts: a CA policy says "no MFA required for this location," the per-user state says "always MFA," and the user gets prompted twice.

Trusted IP rules: one-dimensional context#

Office 365 added a second knob in the same era: "trusted IPs." Sign-ins from a configured public IP range would skip the MFA challenge ^[16]. The idea was that "on the corporate network" meant "more trustworthy." This was reasonable in 2014. By 2017, it was already eroded by full-tunnel VPNs (every employee egresses through the corporate /16 from home), split-tunnel VPNs (some traffic does, some does not), and the realisation that "corporate network" had stopped being a useful synonym for "trusted." Trusted IP is one-dimensional context, and one dimension was not enough.

Security Defaults: the Free-SKU descendant#

Since 22 October 2019, every new Entra ID tenant has Security Defaults turned on by default at creation ^[17]. Security Defaults is a tenant-wide on/off switch that requires MFA for all admin roles, MFA for users when they show risk, blocks legacy authentication, and forces MFA registration. Microsoft's number on the impact is striking: "more than 99.9% of those common identity-related attacks are stopped by using multifactor authentication and blocking legacy authentication" ^[17].

For Entra ID Free tenants in 2026, Security Defaults is still the only available baseline. There is no per-app policy, no per-risk gating, no Conditional Access. This is the licensing reality Section 10 returns to.

The four failure modes of the binary toggle#

The first-generation controls -- per-user MFA, trusted IPs, Security Defaults -- share four documented limits:

1. No expression of context. The toggle is either on or off. It cannot say "MFA from a new country but not from the office."
2. Trusted IP is thin context. A public IP range is one bit of information; modern attacks include matching network egress.
3. No per-app policy. The toggle applies to all apps the user accesses. You cannot say "MFA for the admin portal, not for Outlook."
4. No exclusion semantics for break-glass accounts. Emergency-access accounts need to be reachable when everything else has failed. The binary toggle either includes them or excludes them; it does not let you say "exclude these accounts but log every sign-in as a high-priority alert."

MFA fatigue: when a control becomes a credential#

The canonical failure of the binary toggle is push-bombing. The attacker has the password. The system requires MFA. The user gets four "approve sign-in?" notifications during a morning meeting. One gets a thumbs-up by reflex. The system did exactly what it was configured to do.

The attack works because the control has no concept of whether this is a normal sign-in. The same flow runs whether the request originates from the user's office WiFi or an anonymizing proxy in another country. The MFA challenge carries no risk-weighted information; the user has no signal that this prompt is different from yesterday's prompt. Fatigue is the consequence. Microsoft's own Entra blog catalogued the attack pattern and the operational mitigations in the wake of the 2022 incident cluster ^[19].

"Focusing on password rules, rather than things that can really help -- like multi-factor authentication (MFA), or great threat detection -- is just a distraction." -- Alex Weinert, Microsoft Identity, July 2019 ^[20]

Weinert's 2019 piece is now infamous in the identity community for its title alone -- "Your Pa$$word doesn't matter." The argument was that a password's composition rules carry no information that helps the system tell a real user from an attacker; what does carry information is context. The system needed a place to put that context.

If MFA yes/no cannot express context, the next step is obvious: make context the input. But to make context the input, the system needs a place to put it. The history of CA from 2015 forward is the history of giving context a home.

4. Generation by generation#

The next eight years produced six generations of access control, each one closing a specific failure of the previous one. They look like product launches in a marketing chronology. They are something more interesting: a sequence of negative results, each followed by a positive engineering response.

timeline
title Conditional Access timeline
2014 : Gen 1 per-user MFA and trusted IPs
2015 : CA enters public preview
2016 : Gen 2 Conditional Access general availability
2016 : ID Protection enters preview
2018 : Gen 3 risk-based CA conditions broadly available
2020 : CAE enters preview
2022 : Gen 4 Continuous Access Evaluation general availability
2023 : Gen 5 CA for workload identities
2023 : Gen 6 Microsoft-managed policies and Authentication Strengths
2026 : CA for AI agent identities

The 2026 milestone -- Conditional Access for AI agent identities -- is itself still emerging; Microsoft's current framing in the Conditional Access Optimization Agent announcement names it explicitly as a frontier rather than a finished generation ^[21]. Section 9.1 returns to the open problems.

Gen 1 (2014 to 2016): per-user MFA#

Documented in Section 3. The control has no concept of context. The failure motivates Gen 2.

Gen 2 (September 2016 GA): Conditional Access with static rules#

The September 27, 2016 CloudBlogs post announcing CA general availability framed it as "Protect your data at the front door" -- the "front door" framing that Microsoft documentation still uses ^[22]. The policy schema (users + cloud apps + conditions to grants) was introduced in the 2015 preview ^[23] and survived essentially unchanged into 2016 GA.

Gen 2 closed Gen 1's failure mode: context now had a home. A policy could match on network location, on the app being accessed, on the user's group membership, on the device platform. It could express "block country X" or "require MFA when not on the corporate network."

The remaining documented limit: no risk feed. The engine could express what to check for but not whether this specific sign-in looks suspicious. A policy could block credential-stuffing attempts only if you happened to know in advance which IPs to deny. Motivated Gen 3.

Gen 3 (2017 to 2018): risk-based fusion#

Identity Protection had been generating risk signals since its March 2016 preview. Through 2017 and 2018, two new condition keys appeared in the CA policy schema: signInRiskLevels and userRiskLevels. Both take values from the set low, medium, high. The risk feed plugged into the policy plane through exactly two keys. The legacy ID-Protection-side risk policies (which were a parallel policy surface inside ID Protection itself) are now retiring on 1 October 2026; the canonical surface is CA ^[24].

The remaining limit: pre-issuance only. The CA evaluator runs at sign-in time. Once a token is issued, the policy plane has no way to undo the decision until the token expires. Microsoft's own retrospective is honest about what they tried first: "Microsoft experimented with the 'blunt object' approach of reduced token lifetimes but found they degrade user experiences and reliability without eliminating risks" ^[3]. A one-hour token cuts the worst-case revocation latency to an hour, but it also means a user with intermittent connectivity gets prompted every hour, and a mobile app with retry storms can hammer the IdP. The trade-off was unacceptable. Motivated Gen 4.

Gen 4 (January 2022 GA): Continuous Access Evaluation#

CAE inverted the trade-off. Instead of shortening the token, lengthen it -- up to 28 hours ^[3]. Then add a side channel: when a critical event fires (account disabled, password reset, high user risk, IP location change), the resource API issues an HTTP 401 with a WWW-Authenticate claims challenge, and the client replays to Entra for a fresh token. Latency on the side channel is bounded: "up to 15 minutes" for non-IP events, "instant" for IP locations ^[3]. CAE was tied to an emerging open standard from day one, the OpenID Continuous Access Evaluation Profile ^[3]. The general-availability announcement landed on 10 January 2022 ^[25].

Remaining limit: applies to humans only. Service principals do not consume CAE-aware client libraries; they cannot perform a claims challenge. Motivated Gen 5.

Gen 5 (2023 GA): Conditional Access for workload identities#

Same engine, constrained grant set. The Microsoft Learn page is blunt on the boundaries: "Workload Identities Premium licenses are required" and the constraint set is unusual -- "Policy can be applied to single tenant service principals that are registered in your tenant. Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies. Managed identities aren't covered by policy" and "Under Grant, Block access is the only available option" ^[26]. The public preview of CA filters for workload identities opened on 26 October 2022 ^[27]; the Microsoft Entra Workload Identities standalone product followed in late November 2022, and the Conditional Access feature for workload identities itself reached general availability later in 2023.

The single-tenant restriction is a structural choice. Multi-tenant SaaS apps appear in many tenants' service principal directories at once; policy scoping on them would require a cross-tenant resolution protocol the engine does not have. Managed identities are excluded because they belong to Azure subscriptions, not to user identity, and Microsoft has chosen not to extend the surface there. Group assignments do not work either: "Conditional Access policies assigned to a group that contains a service principal are not enforced for that service principal" ^[26].

Remaining limit: under-configured in most tenants because the grant taxonomy is so narrow that admins do not see immediate value. Motivated Gen 6.

Gen 6 (November 2023 onwards): Microsoft-managed policies and Authentication Strengths#

In November 2023, Alex Weinert announced Microsoft-managed Conditional Access policies: a set of baselines that Microsoft would auto-deploy into tenants in Report-only mode and then auto-enable after a waiting period ^[14]. The launch announcement specified a 90-day window ^[28]. The current Microsoft Learn documentation specifies "Microsoft enables these policies no less than 45 days after they're introduced in your tenant if they're left in the Report-only state" with a 28-day pre-enablement notification ^[29].

Parallel to the managed policies, Microsoft shipped Authentication Strengths -- a named bundle of acceptable authentication methods that can be required as a grant. The three built-in strengths are MFA strength, Passwordless MFA strength, and Phishing-resistant MFA strength (FIDO2 security key, Windows Hello for Business, multifactor certificate-based authentication) ^[30]. The phishing-resistant strength is the modern way to express "no adversary-in-the-middle phishing kit should be able to defeat this grant."

The pattern: extension, not replacement#

From Gen 3 onward, each generation extends the prior schema rather than replacing it. The conditionalAccessPolicy JSON shape that shipped in 2016 still drives the engine in 2026 -- with new condition keys added, new grant types added, new session controls added. By the standards of cloud control surfaces, that is a long run without a rewrite.

The reason is the architectural decision the next section is about.

5. The two-plane separation#

The breakthrough is not a model, not a token format, not a wire protocol. It is a separation: the signal plane that produces risk detections from the policy plane that consumes them.

Stated like that, it sounds banal. Read it the other direction -- a policy engine whose risk model can change without changing the policy semantics, and whose policy can change without retraining the model -- and it is the design that makes the system maintainable at trillions of daily signals across hundreds of thousands of tenants.

The two planes, precisely#

The signal plane is Microsoft Entra ID Protection. It runs detection logic on every interactive sign-in (and, for offline detections, on historical sign-ins) and emits a riskDetection resource into a per-tenant log on Microsoft Graph at /identityProtection/riskDetections. Each detection carries five fields you care about: riskEventType (one of about two dozen named detection types like anonymizedIPAddress, leakedCredentials, unlikelyTravel), riskLevel (low, medium, high, plus the bookkeeping values hidden and none), riskState (atRisk, confirmedCompromised, dismissed, remediated), detectionTimingType (realtime, nearRealtime, offline), and additionalInfo (a JSON blob with user-agent, IP, alert URL, reason codes) ^[5][31].

The policy plane is Conditional Access. It is a JSON object at /identity/conditionalAccess/policies/{id} on the Graph API ^[4]. Each policy has displayName, state (enabled, disabled, enabledForReportingButNotEnforced), conditions, grantControls, and sessionControls. The conditions block contains the per-policy targeting: which users, which apps, which platforms, which network locations -- and two condition keys named signInRiskLevels and userRiskLevels.

Those two condition keys -- signInRiskLevels and userRiskLevels -- are the entire API surface between the signal plane and the policy plane. Everything else about ID Protection is hidden behind them. The policy plane does not know whether high came from a transformer or a logistic regression or a hardcoded rule. The signal plane does not know which policies will read its output. The contract is two strings.

flowchart LR
subgraph SP[Signal plane Entra ID Protection]
DET[Detection pipeline]
RD[(riskDetection log)]
RL[Risk level low medium high]
end
subgraph PP[Policy plane Conditional Access]
EV[Policy evaluator]
POL[(conditionalAccessPolicy JSON)]
TOK[Token issuer]
end
subgraph SES[Session plane CAE]
CH[Critical event channel]
RP[Resource API]
end
DET --> RD
DET --> RL
RL -. signInRiskLevels userRiskLevels .-> EV
POL --> EV
EV --> TOK
TOK -- access token --> RP
DET -. user risk events .-> CH
CH -. 401 insufficient claims .-> RP

Why the separation matters#

Three concrete consequences fall out of the design:

The risk model is re-trainable without policy rewrites. Microsoft's ID Protection team can change the underlying detection algorithm tomorrow. Add a new riskEventType. Replace the classifier for unlikelyTravel. Re-tune the threshold that maps a score to low/medium/high. None of these require tenants to rewrite their CA policies, because policies match on the level, not the signal.

Tenants without the licence simply do not use the risk conditions. An Entra ID P1 tenant can deploy CA policies that match on users, apps, locations, devices, client apps, and platforms. P2 unlocks the risk conditions. The schema accommodates both: P1 policies just leave the risk arrays empty. There is no parallel policy surface for the non-risk-aware tenants; they use the same engine.

CAE is a third plane layered onto the same skeleton. Continuous Access Evaluation did not require redesign of the policy plane. The CAE channel is a new event delivery mechanism; the events it propagates are things the signal plane already knew about (high user risk, password reset, account disabled) plus new ones the policy plane introduced (network-location-policy changed). The architecture absorbed CAE because the design was already a separation of concerns.

The signal plane and the policy plane are separable; the contract between them is two condition keys (signInRiskLevels and userRiskLevels). That is what makes the system maintainable across a decade of evolution.

The "pit of success" framing#

Alex Weinert calls this the "pit of success." His November 2023 piece on Microsoft-managed policies put the metric on it: a decade ago Microsoft turned on a "radical" tenant-wide policy requiring MFA for every consumer Microsoft account, and "today, 100 percent of consumer Microsoft accounts older than 60 days have multifactor authentication" ^[14].

The 100 percent number is achievable because the policy plane and the signal plane can each evolve independently. Microsoft can ship a managed policy that says "require MFA for high-risk sign-ins" without committing to a fixed definition of "high risk." The definition lives on the signal plane and changes weekly. The policy lives on the policy plane and is stable for years.

With the separation as the spine, the next section walks the end-to-end pipeline in one continuous trace, from signal to grant to token to session, on a real sign-in -- the trace no public Microsoft document assembles in one place.

6. The end-to-end pipeline#

Take Alice's Tuesday morning from Section 1 and walk it forward. This section has six subsections. By the end of them, the question "who decided?" has six independently sourced answers and one combined picture.

6.1 What the signal plane sees#

Identity Protection's detection taxonomy splits into five rough groups, based on what kind of information triggered the detection. The canonical taxonomy is the Microsoft Learn page on risk types ^[31]; the wire-format enum on the Graph schema is at ^[5].

• Network signals. anonymizedIPAddress, maliciousIPAddress, nationStateIP, riskyIPAddress. The signal is the source IP and reputation databases that ID Protection ingests.
• Behavioural signals. unlikelyTravel, mcasImpossibleTravel, newCountry, unfamiliarFeatures, anomalousUserActivity. The signal is a deviation from the tenant's or the user's historical baseline.
• Credential signals. leakedCredentials, passwordSpray. The signal is a match against a corpus of breached credentials or a velocity-based pattern across tenants.
• Token and session signals. anomalousToken, tokenIssuerAnomaly, attemptedPrtAccess, attackerinTheMiddle, authenticatorPhishing. The signal is on the token itself or on the way the authenticator flow ran.
• Inbox behaviour. suspiciousInboxForwarding, mcasSuspiciousInboxManipulationRules. The signal is on what happened after the sign-in -- a post-compromise indicator that retroactively flags the sign-in that enabled it.

Each detection is also tagged with a timing: real-time, near-real-time, or offline. Microsoft Learn is precise about the latencies: "Detections triggered in real-time take 5-10 minutes to surface details in the reports. Offline detections take up to 48 hours" ^[32].

The detection is mapped to a risk level, not a probability. Microsoft Learn calls the level "calculated by our machine learning algorithms" and explicitly notes the meaning: low/medium/high "represent how confident Microsoft is that one or more of the user's credentials are known by an unauthorized entity" ^[32]. ※ "Confidence" here is meant in the everyday sense, not the strict statistical sense of a confidence interval. Microsoft has not published a calibration study that would let you map a "high" risk level to a frequentist probability of compromise.

Microsoft has not publicly disclosed the production model architecture, the feature vector size, or per-detection precision and recall. The 2021 Microsoft Security Blog interview with Maria Puertas Calvo describes the existence of the ML team and the operational scale ("hundreds of terabytes every day") but stops well short of architecture details ^[33]. The model class is publicly unspecified; the taxonomy and the operating output are both public.

6.2 How risk surfaces#

Two parallel logs matter for risk. The Sign-in log is the universe: every interactive and non-interactive sign-in produces an entry. The riskDetections log is the sparse overlay: a riskDetection is emitted only when a detection fires for the sign-in. Most sign-ins produce a Sign-in log entry with no corresponding riskDetection. Only flagged sign-ins do ^[5].

This is a common source of confusion. It is tempting to assume "ID Protection scored every sign-in," and in a sense it did -- the detectors ran -- but the durable artefact exists only when at least one detector fired. To compute a per-sign-in distribution of risk you need to join the Sign-in log with the riskDetections log and treat the unjoined rows as "no risk flagged at the moment of issuance."

There is one more wrinkle. The detection taxonomy on the Microsoft Learn concept page and the riskEventType enum on the Graph schema are not perfectly aligned. The concept page lists mcasImpossibleTravel and authenticatorPhishing as named detection types; the Graph enum lists impossibleTravel (without the mcas prefix). The two surfaces sometimes use different value names for the same logical detection -- a UI display string versus a Graph enum value. Detection engineers writing KQL against the Sign-in logs should account for both.

6.3 How CA consumes risk#

Conditional Access evaluation runs in a fixed order: assignments are checked first (does this sign-in match this policy at all?), then conditions (do all the condition predicates hold?), then grants (which controls are demanded?), then session controls (which token lifetime, sign-in frequency, persistent browser).

The key semantic, repeated across the Microsoft Learn documentation: a block grant in any policy matching the sign-in overrides any allow grant in any other policy. The policy plane is not just additive; it has an explicit precedence rule.

flowchart TD
A[Sign-in request] --> B[First-factor auth]
B --> C[Enumerate matching policies]
C --> D{Any policy matches?}
D -- No --> E[Default allow with token]
D -- Yes --> F[Evaluate conditions per policy]
F --> G{Block grant in any match?}
G -- Yes --> H[Deny access return error]
G -- No --> I[Aggregate required grants]
I --> J{All grants satisfied?}
J -- No --> K[Issue challenge MFA or device]
J -- Yes --> L[Apply session controls]
L --> M[Issue access token]

The pseudocode below is a compressed restatement of that flow. It is not Microsoft source code; it is the algorithmic shape an admin should keep in their head when reading a policy or debugging a sign-in.

function evaluate(signin) {
const matching = allPolicies.filter(p =>
  p.state !== 'disabled' &&
  matchesAssignments(p.conditions, signin) &&
  matchesConditions(p.conditions, signin)
);

// Block precedence: any block grant wins
if (matching.some(p => p.grantControls.builtInControls.includes('block'))) {
  return { decision: 'DENY', reason: 'block grant matched' };
}

// Aggregate required grants across matching policies
const requiredGrants = new Set();
for (const p of matching) {
  for (const g of p.grantControls.builtInControls) requiredGrants.add(g);
  if (p.grantControls.authenticationStrength) {
    requiredGrants.add('authStrength:' + p.grantControls.authenticationStrength.id);
  }
}

const satisfied = [...requiredGrants].every(g => signin.satisfies(g));
if (!satisfied) {
  return { decision: 'CHALLENGE', missing: [...requiredGrants].filter(g => !signin.satisfies(g)) };
}

// Apply session controls (token lifetime, sign-in frequency, persistent browser)
const session = mergeSessionControls(matching.map(p => p.sessionControls));
return { decision: 'ALLOW', session };
}

const result = evaluate({
user: 'alice@contoso.com',
app: 'Office365 Exchange Online',
location: { ip: '203.0.113.42', country: 'PT' },
device: { compliant: true, joinType: 'Entra' },
signInRisk: 'low',
userRisk: 'none',
satisfies(grant) {
  const mfa = ['mfa', 'authStrength:phishingResistantMfa'];
  return mfa.includes(grant) || grant === 'compliantDevice';
},
});
console.log(JSON.stringify(result, null, 2));

Risk-based conditions require Entra ID P2 ^[2]. Without that licence, the signInRiskLevels and userRiskLevels arrays in a policy are ignored. The rest of the engine works the same.

6.4 The grants#

Each policy declares a set of grants. The grants are additive within a policy (all required to satisfy the policy) but the block grant in any matching policy takes precedence over allow grants in any other policy. Here are the grants currently in the schema:

The Authentication Strength grant is where the phishing-resistance story lives in 2026. A policy that demands the phishing-resistant strength refuses to accept TOTP or SMS or push as the second factor. Only credentials with cryptographic binding to the device or hardware token will satisfy the grant. That class of credential, by construction, cannot be replayed by an adversary-in-the-middle phishing kit -- because the underlying WebAuthn ceremony is bound to the origin of the relying party.

6.5 The Windows-side handoff#

PRT issuance is an interactive sign-in. It goes through CA like any other.

The compliance state lands on the device object as isCompliant. Intune (or a third-party MDM through Intune's compliance-partner API) writes that field after evaluating the device against a compliance policy: disk encrypted, OS patched, antivirus running, jailbreak detection clean, and so on. CA reads it on subsequent policy evaluations. If a policy requires compliantDevice and the device object says isCompliant: false, the grant is not satisfied.

The operational seam to on-prem Active Directory runs the other direction. Kerberos and NTLM against on-prem domain controllers never consult Entra. The Microsoft Learn CA overview is explicit: CA is a cloud control plane; on-prem authentication is outside its scope ^[1]. This is the limit Section 8 will name precisely.

6.6 CAE in session#

The third plane. Wire format lives in two Microsoft Learn pages: the claims-challenge page ^[6] and the app-resilience CAE page ^[34].

A client opts in to CAE by advertising the cp1 capability via the xms_cc claim in token requests. In MSAL, that opt-in looks like WithClientCapabilities(new[] { "cp1" }) ^[34]. The Microsoft Learn claims-challenge page says it cleanly: "The only currently known value is cp1" ^[6].

When the policy plane sees a critical event after the token was issued, the resource API responds to the next call with HTTP 401 Unauthorized and a WWW-Authenticate header of the shape:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer authorization_uri="<entra-authorize-endpoint>", error="insufficient_claims", claims="<base64-encoded JSON>"

The claims value is a base64-encoded JSON object that the client passes verbatim to the token endpoint when acquiring a fresh token ^[6][34]. The IdP evaluates the embedded claims, runs CA again with the new context, and issues a new token (or refuses).

The Microsoft Learn CAE document enumerates five critical events: account disabled or deleted, password change or reset, MFA enabled by an administrator, administrator token revocation, and high user risk detected by ID Protection ^[3]. A parallel pathway, Conditional Access policy evaluation, propagates network-location and policy changes to CAE-aware resource providers on the same channel. For IP-location changes the latency is "instant"; for everything else the ceiling is up to 15 minutes ^[3].

sequenceDiagram
participant C as Client app
participant R as Resource API CAE aware
participant E as Entra token issuer
participant P as ID Protection
Note over C: Client holds long-lived CAE token
C->>R: GET messages with bearer token
R->>R: Token still cryptographically valid
P->>E: High user risk event for Alice
E->>R: Push critical event Alice high risk
C->>R: GET messages with bearer token again
R->>C: 401 WWW-Authenticate insufficient_claims claims base64
C->>E: Token request with claims blob and cp1 capability
E->>E: Re-run CA with new context
E-->>C: New token or definitive refusal
C->>R: Retry with new token

// Simplified MSAL.js-shaped pseudocode for CAE opt-in and challenge handling
const ENTRA_AUTHORITY = '<entra-authority-uri>';
const EXCHANGE_ENDPOINT = '<exchange-online-graph-endpoint>';
const MAIL_READ_SCOPE = '<exchange-mail-read-scope-uri>';

const msal = new PublicClientApplication({
auth: { clientId: '<your-client-id>', authority: ENTRA_AUTHORITY },
});

async function callExchange() {
let token = await msal.acquireTokenSilent({
  scopes: [MAIL_READ_SCOPE],
  clientCapabilities: ['cp1'], // advertise CAE awareness
});

let res = await fetch(EXCHANGE_ENDPOINT, {
  headers: { Authorization: 'Bearer ' + token.accessToken },
});

if (res.status === 401) {
  const header = res.headers.get('WWW-Authenticate') || '';
  const m = /claims="([^"]+)"/.exec(header);
  if (m) {
    // Replay the embedded claims to acquire a fresh token
    token = await msal.acquireTokenSilent({
      scopes: [MAIL_READ_SCOPE],
      claims: Buffer.from(m[1], 'base64').toString('utf8'),
      clientCapabilities: ['cp1'],
    });
    res = await fetch(EXCHANGE_ENDPOINT, {
      headers: { Authorization: 'Bearer ' + token.accessToken },
    });
  }
}

console.log('HTTP', res.status);
}

callExchange();

CAE inverts the conventional trade-off: lengthen the token, shorten the revocation. The token can live 28 hours because revocation is an event, not a clock.

The chain is now visible. The signal plane scored Alice's Tuesday sign-in. The policy plane evaluated the policies. The token issuer issued an access token (CAE-aware because Outlook advertises cp1). Exchange Online accepted the token and returned mail. If, twelve minutes from now, Alice's account is flagged high risk because a different sign-in attempt fires leakedCredentials, the critical event will fire, Exchange will issue a claims challenge, and Outlook will either acquire a fresh token (passing the new CA evaluation) or surface the refusal to the user.

Six independent components co-decided on one access event. Microsoft is one vendor. The same problem has been solved differently by Google, Okta, AWS, Cloudflare, and Zscaler. The Microsoft answer is not the only correct answer.

7. How others do it#

Microsoft chose to enforce at token issuance and claims challenge. Google chose to enforce at every HTTP request via a reverse proxy. AWS chose a decidable policy DSL. These are not minor variations; they are different answers to "where does the policy engine live in the data path?"

Both Microsoft's and Google's models scale. Neither is strictly better. The choice is a function of what the enterprise already runs.

Google BeyondCorp, IAP, Chrome Enterprise Premium#

Google's Identity-Aware Proxy puts the policy engine in the data path. The documentation calls it bluntly: "IAP lets you establish a central authorization layer for applications accessed by HTTPS, so you can use an application-level access control model instead of relying on network-level firewalls" ^[35]. Every HTTP request to an IAP-protected app passes through the proxy. The proxy authenticates the user (via Google Account, Workforce Identity Federation, or Identity Platform), evaluates a Common Expression Language policy against the request context, and -- on allow -- forwards the request to the backend with signed identity headers.

The BeyondCorp Enterprise product (recently rebranded as Chrome Enterprise Premium) layers context-aware access on top: device posture, geographic location, time of day ^[36]. The architecture matches the 2014 USENIX paper ^[11] and the 2016 production follow-up ^[12].

The strength is per-request authorization: every HTTP call is its own decision point. The weakness, from the M365 perspective, is that IAP does not gate Microsoft 365 first-party API traffic. The Outlook client does not route through Google's IAP; it routes through Entra and Exchange Online. For Microsoft 365 workloads, IAP is complementary at best.

Okta Identity Engine and ThreatInsight#

Okta's policy engine is closer to Microsoft's structurally: the identity provider is the policy engine, app sign-on policies live on the IdP, and the resource side relies on the IdP's token rather than a per-request proxy. The Okta Identity Engine documents the rule shape: "App sign-in policies define how a user must authenticate to gain access to an app. They verify ... group membership, the IP zone they're signing in from, risk level, and others" ^[37]. Every new app gets a default policy with a single catch-all rule that allows access with two factors.

Okta ThreatInsight is the IP-reputation feed. The documentation describes it operationally: "Okta ThreatInsight aggregates data about sign-in activity across the Okta customer base to analyze and detect potentially malicious IP addresses ... password spraying, credential stuffing, brute-force cryptographic attacks" ^[38]. The signal coverage is narrower than ID Protection: ThreatInsight is IP-centric, where ID Protection runs a multi-detection ML pipeline on tokens, sessions, behaviour, and credentials.

AWS IAM Identity Center and Verified Access#

AWS splits the problem. IAM Identity Center handles workforce SSO and trusted identity propagation to AWS services ^[39]. AWS Verified Access handles per-request authorization for HTTPS-fronted apps -- the ZTNA piece. The Verified Access docs put it plainly: "Verified Access evaluates each application access request in real time" and "verifies the trustworthiness of users and devices against a set of security requirements" ^[40].

The interesting bit is the policy language: Cedar. Cedar is a deliberately decidable language for authorization policy. "Decidable" here is a precise term: the safety question (will some policy edit, in some future edit chain, leak this right?) is answerable by a static analyser for any Cedar policy ^[41].

Cloudflare Access and Zscaler Private Access#

Cloudflare Access is an edge proxy. Policies are deny-by-default, with four building blocks: Actions (Allow, Block, Bypass, Service Auth), Rule types (Include, Require, Exclude), Selectors, and Values ^[42]. The deny-by-default semantics are explicit: "Since Access is deny by default, users who do not match a Block policy will still be denied access unless they explicitly match an Allow policy" ^[42]. Cloudflare also ships a policy tester that lets administrators dry-run a policy against the existing user population ^[43].

Zscaler Private Access is a broker-based ZTNA: the user connects to a Zscaler edge node, the broker establishes a connection to the private app, and "users never access the corporate network, and apps are never exposed to the public internet" ^[44]. Zscaler's own marketing surveys put the VPN-replacement framing in numbers: "91% of organizations are concerned that VPNs compromise their security" and "56% of organizations suffered one or more VPN-related attacks in 2023-2024" ^[44].

Architecturally, Cloudflare Access and ZPA both sit closer to BeyondCorp than to Microsoft CA: the policy engine is in the data path; the protected resource is fronted by the proxy rather than gated at token issuance.

OpenID Shared Signals Framework and CAEP#

Not a competitor: the cross-vendor wire format for what Microsoft built into CAE. On 22 September 2025, the OpenID Foundation approved three Final Specifications: the Shared Signals Framework 1.0, the Continuous Access Evaluation Profile 1.0, and the Risk Incident Sharing and Coordination Profile 1.0 ^[45][46]. CAEP defines five event types -- Session Revoked, Token Claims Change, Credential Change, Assurance Level Change, Device Compliance Change -- as the cross-vendor revocation vocabulary.

Microsoft's CAE implementation is, in Microsoft's own words, "an industry standard based on Open ID Continuous Access Evaluation Profile" ^[3]. The Final Specifications from September 2025 are the canonical post-2025 reference; older drafts at OpenID's site are superseded.

Head-to-head comparison#

The differences worth memorising:

flowchart LR
subgraph TOK[Token issuance model Microsoft Okta]
U1[User] --> AT[Acquire token]
AT --> CA1[CA evaluator]
CA1 --> IS[Issue token]
IS --> R1[Resource API validates token]
R1 -. CAE 401 .-> AT
end
subgraph PRX[Data path proxy model Google BeyondCorp AWS Verified Access Cloudflare Zscaler]
U2[User] --> PXY[Proxy intercepts every request]
PXY --> POL[Policy evaluator at the proxy]
POL --> BCK[Backend application]
end

The honest observation worth sitting with: none of the proxy systems gates M365 first-party API traffic. Outlook, Teams, SharePoint, and Microsoft Graph route through Entra. For those workloads, Entra remains the only effective policy plane. The proxy systems gate the apps that sit behind the proxy -- internal apps, partner-facing apps, custom workloads. That makes BeyondCorp, Okta, Cloudflare Access, and ZPA complementary to Entra CA in an M365 environment, not substitutes for it.

Six systems, six architectural choices. None of them wrong. But what do they all leave on the table?

8. What Conditional Access fundamentally cannot do#

Section 7 cannot be the ending. There are at least five things Conditional Access -- and every peer in Section 7 -- cannot do. Some are engineering limits; some are theorems. Both classes are worth naming.

(a) On-prem authentication#

CA is a cloud control plane. Kerberos and NTLM against on-prem domain controllers do not consult Entra. There is no policy hook for the legacy Windows protocols. If a domain user signs in to a domain-joined workstation, authenticates to a file server, and accesses a share, no piece of that flow touches Conditional Access. The Microsoft Learn overview is explicit about the scope ^[1].

This is the operational seam between cloud identity and on-prem identity. State it plainly; do not soften.

(b) Post-issuance token theft#

Once a refresh token is exfiltrated -- whether via an adversary-in-the-middle phishing kit like Evilginx ^[47], an infostealer that scrapes the token cache, or a malicious browser extension -- the pre-issuance CA evaluation is bypassed. The attacker has a bearer token. They can present it to the resource API directly. CAE-aware resource providers can revoke mid-session on the published critical-event list, but the latency ceiling is "up to 15 minutes" for non-IP events ^[3]. In fifteen minutes a competent attacker has done plenty.

The mitigation is device-bound credentials: Primary Refresh Tokens bound to TPM hardware, FIDO2 with hardware attestation, certificate-based authentication with hardware-protected keys ^[48]. A bearer token bound to a TPM is not exfiltratable in the same way; the wrapped key material never leaves the device.

(c) Consent-grant phishing#

CA evaluates authentication, not authorization grants that a user makes to a malicious OAuth app. A user who clicks "Allow" on a permissions-consent prompt for an attacker-controlled app has performed an OAuth authorization, not a sign-in. The malicious app now has the user's delegated permissions for whatever scopes were granted. CA was not invoked because CA gates the user's sign-ins; it does not inspect the user's OAuth grants. Microsoft Defender for Cloud Apps documents the attack class as "risky OAuth apps" and ships investigation and remediation tooling on a separate plane from CA ^[49].

Admin consent settings, app governance policies, and explicit allow-listing of acceptable publishers live on that different plane. The policy admin who deploys CA needs to deploy app governance separately.

(d) Risk evaluation is probabilistic#

Identity Protection produces a score, not a proof. A "high" risk level is a confidence; it is not the assertion "this sign-in is definitely an attack." No vendor in the Section 7 survey publishes precision or recall numbers for its risk engine. The operating point -- the threshold that maps a continuous score to discrete buckets -- is a trade-off that the vendor calibrates and the customer does not see.

This is a structural lower bound on any ML-driven risk plane, not a Microsoft-specific failure. Any classifier has false positives and false negatives. A risk-aware CA policy that says "block at high risk" will, with non-zero probability, block a legitimate sign-in. A policy that says "require MFA at medium risk" will, with non-zero probability, let through a sophisticated attacker whose detections fall under the threshold.

(e) Workload-identity CA is constrained by design#

Block-only grants. No managed identities. No group assignments. The full human grant taxonomy does not transfer because a service principal cannot perform an MFA challenge, cannot register a FIDO2 key, cannot accept a terms-of-use document. The Microsoft Learn page on workload-identity CA enumerates the constraints precisely ^[26]. Section 9 will name this as an open problem; for now, treat it as a documented limit.

The theorems behind the limits#

Some of these limits are engineering choices that could be different in a future product. Some are deeper.

Saltzer and Schroeder 1975 ^[7] give the upper bound on aspirations: complete mediation across every authentication and authorization decision within scope of mediation. The principle does not constrain what is in scope. It constrains what you must do for whatever you have decided is in scope. On-prem AD is out of scope for CA by Microsoft's product decision; complete mediation cannot fix that, because the principle is about consistency within the boundary, not about expanding the boundary.

Harrison-Ruzzo-Ullman 1976 -- usually shortened to HRU ^[50] -- gives the lower bound on static analysis. The safety question in the general access-matrix model is undecidable. In informal terms: there is no general algorithm that proves a Conditional Access policy edit cannot, under some future edit chain, leak a sensitive right. This is why every vendor in the survey relies on evaluation-time mediation (the engine decides at the moment of the request) rather than static-proof analysis (the engine certifies in advance that no edit can ever leak). Cedar's intentional restriction to a decidable fragment, in AWS Verified Access, is the counter-strategy: trade expressiveness for analysability.

The bearer-token revocation trade-off is informal but real: the worst-case revocation latency is bounded below by the token's natural lifetime, unless a side channel exists. CAE is that side channel. Its latency is bounded by the propagation time of the channel (up to 15 minutes for non-IP events, instant for IP). Shorten the channel further and you discover that the IdP-to-resource-API event delivery has its own infrastructure costs.

Naming the limits clears the way to name the active unsolved problems -- the ones the field is still working on, where the current state of the art admits it is partial.

9. Where the policy plane is still incomplete#

Microsoft's own 2026 documentation for Conditional Access on AI agents calls the current implementation "a lightweight enforcement mechanism designed to block unauthorized or risky agents, not a full policy suite." That is not marketing modesty. It is an admission that the most active frontier of policy enforcement -- agent identities -- is deliberately under-specified.

Five open problems sit on that frontier in 2026.

"Organizations are expanding Zero Trust across more users, applications, and now a growing population of AI agent identities ... the Conditional Access Optimization Agent moves beyond static guidance to continuous, context-aware identity posture optimization." ^[21]

9.1 Agent identity policy semantics#

What grants should exist for AI agents beyond block and allow? Useful candidate grants include: "read-but-not-move" for mail or files; "business-hours-only"; "any autonomous action requires a fresh sign-off from the on-behalf-of human." None of these exist as first-class CA grant types in 2026.

What does exist: CA targeting of agent identities -- the ability to match a policy on the agent identity rather than the human -- and the Conditional Access Optimization Agent, which gives administrators continuous recommendations on policy posture ^[21]. The targeting is there. The grant taxonomy is still mostly the human one, applied imperfectly.

9.2 Cross-vendor CAEP interop#

The wire format was finalised in September 2025 ^[45][46]. Production receiver coverage outside Microsoft Entra-internal resource providers is partial. Two large vendors agreeing on an event schema is necessary but not sufficient for cross-vendor revocation to work in practice; the receiving side needs to act on the events. The next eighteen months are the period in which CAEP either becomes the cross-vendor wire format for revocation, or it does not.

9.3 Workload-identity grant set#

What richer expressions could exist for non-human identities? The current Microsoft Learn page lists workload-identity detections: investigationsThreatIntelligence, suspiciousSignins, adminConfirmedServicePrincipalCompromised, leakedCredentials, maliciousApplication, suspiciousApplication, anomalousServicePrincipalActivity, suspiciousAPITraffic ^[51]. The detections exist; the grant taxonomy stops at block.

Candidate richer grants: "workload attestation" (the service principal proves it is running on attested infrastructure), "verifiable claim from a trusted attester" (a third party signs a statement about the workload), "step-up authorization for sensitive scopes" (a higher-privilege scope requires a separate per-request authorization step). None of these is generally available in 2026.

9.4 The break-glass paradox#

Emergency-access accounts must be excluded from CA. If a CA misconfiguration locks out every admin, the break-glass account is the recovery path. But exclusion creates a high-value bypass: an attacker who compromises a break-glass account inherits its exclusion.

There is no clean answer. Microsoft's guidance is exclusion plus FIDO2 binding plus alerting: the break-glass accounts have hardware-bound FIDO2 keys (so they cannot be phished), they are excluded from all CA policies (so misconfiguration cannot lock them out), and every sign-in is alerted on (so misuse is detected within minutes) ^[52].

9.5 The risk-engine transparency problem#

No vendor in the Section 7 survey publishes model architecture, feature vector size, or per-detection precision and recall. Microsoft does not. Okta does not. Google does not. Defenders, auditors, and regulators must accept a black-box score.

This matters in three places. First, for incident response: when an "atypical travel" detection fires for an executive, the responder cannot see which features contributed and how strongly. Second, for compliance: an auditor asked to evidence the effectiveness of the control plane gets the operating output (3-tier risk levels) but not a quantitative evaluation. Third, for the risk-engine vendors themselves, who must respond to legitimate regulatory questions about model bias and operational reliability without revealing the architecture that attackers would use to evade detection.

The article does not predict a resolution. It names the gap.

The architecture is incomplete by admission. It is also actionable today. A competent tenant administrator can deploy a sensible baseline in an afternoon.

10. Using Conditional Access today#

The architectural story ends; the operational story begins. Here is what a competent tenant looks like in 2026.

The licensing reality#

Conditional Access is not a feature every Microsoft 365 tenant gets. It is a feature gated by SKU. The licensing tiers are:

• Entra ID Free. Security Defaults only ^[17]. No Conditional Access policies. No risk-based conditions. No CA-driven CAE (the critical-event-evaluation subsystem -- for events like account disable, password reset, and high user risk -- still propagates to CAE-aware M365 services at the service layer regardless of SKU; see Section 6.6) ^[3].
• Entra ID P1. Conditional Access is unlocked ^[1]. You can author policies with any of the non-risk conditions: users, apps, locations, devices, client app, platform. You can demand any of the non-risk grants.
• Entra ID P2. Adds risk-based conditions. signInRiskLevels and userRiskLevels become usable ^[2]. ID Protection's full report pane (risky users, risky sign-ins, risk detections) is accessible. The legacy ID-Protection-side risk policies retire 1 October 2026 ^[24].
• Workload Identities Premium. A separate SKU. Unlocks CA scoped to service principals ^[26].

This corrects a premise discarded earlier: "Conditional Access is the policy plane every M365 tenant runs on" is not true. Many tenants run on Security Defaults. The "policy plane every tenant runs on" is the cloud sign-in pipeline; CA is the configurable richer layer that P1+ tenants opt into.

Start with the managed baselines#

Microsoft-managed Conditional Access policies are the recommended starting point ^[29]. They auto-deploy in Report-only mode, run for at least 45 days while administrators review the impact in the Sign-in logs, and are auto-enabled with a 28-day pre-enablement notification unless administrators opt out ^[29]. The currently shipping baselines, per Microsoft Learn, include:

• MFA for admins accessing Microsoft admin portals (the most-privileged roles).
• MFA for users who already have per-user MFA enabled (a migration aid).
• MFA and reauthentication for risky sign-ins (the P2 baseline).
• Block legacy authentication.
• Block access for high-risk users (P2-tier protection on the user-risk surface).
• Block all high-risk agents accessing all resources (Preview, AI-agent surface).

The original announcement called for a 90-day report-only window ^[14][28]. The current default is 45 days ^[29]; the window shrank as Microsoft gained confidence that customers were not surprised by the auto-enablement.

Five custom policies on top of the baselines#

Beyond the managed policies, every well-run tenant in operational experience runs five custom policies on top of the baselines ^[53]: block legacy authentication unconditionally ^[29]; require the phishing-resistant Authentication Strength for any user in a privileged role ^[30]; require compliantDevice for admin centres, finance apps, and customer-data exports ^[54]; restrict privileged sign-ins to a named-location allow-list with block-or-step-up outside it ^[16]; and, where Entra ID P2 is licensed, demand a sign-in-risk-based step-up (MFA at high risk, a passwordless or phishing-resistant method at medium risk) ^[24].

Automation entry points (Microsoft Graph)#

The Graph endpoints administrators care about:

• GET /identity/conditionalAccess/policies -- list policies. POST to create, PATCH to update ^[4].
• GET /identityProtection/riskDetections -- the per-detection log. Filterable by riskLevel, riskState, userPrincipalName, activityDateTime ^[5].
• GET /identityProtection/riskyUsers -- the per-user risk view.

A policy authored in code looks like this (truncated for readability):

{
  "displayName": "Require phishing-resistant for admins",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": { "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"] },
    "applications": { "includeApplications": ["All"] }
  },
  "grantControls": {
    "operator": "OR",
    "authenticationStrength": { "id": "00000000-0000-0000-0000-000000000004" }
  }
}

The recommended deployment dance is enabledForReportingButNotEnforced first; let the Sign-in log show you the impact for a calibration window; promote to enabled only after the report-only data matches expectations ^[55].

Audit-time visibility#

Three surfaces matter:

• Sign-in logs in the Entra portal show the per-sign-in evaluation, including which CA policies matched and which grants were satisfied.
• Risk-detection log in Identity Protection (P2 only) shows the per-detection narrative: which riskEventType fired, with what additionalInfo, against which user.
• The What-If tool simulates a policy evaluation for a hypothetical sign-in, before you enable a policy.

Detection engineering#

For E5 tenants, the Sign-in logs and risk detections flow into Microsoft Sentinel (via the Microsoft Entra ID connector) or Defender XDR ^[56]. A KQL skeleton for high-risk-with-CA-failure looks like:

SigninLogs
| where ResultType != 0
| join kind=inner (AADRiskDetections | where RiskLevel == "high") on UserPrincipalName, CorrelationId
| project TimeGenerated, UserPrincipalName, IPAddress, ConditionalAccessStatus, RiskEventType, FailureReason

The aggregate scale figure is worth remembering: Microsoft processes "more than 100 trillion security signals" daily across all identity products ^[29]. The detection engineer is consuming a small slice that landed in their tenant.

let window = 7d;
SigninLogs
| where TimeGenerated > ago(window)
| where ResultType == 0
| where ConditionalAccessStatus == "success"
| join kind=inner (
    AADRiskDetections
    | where TimeGenerated > ago(window)
    | where RiskLevel == "high"
) on UserPrincipalName, CorrelationId
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, RiskEventType, ConditionalAccessPolicies
| order by TimeGenerated desc

Break-glass#

Two emergency-access accounts. FIDO2-bound. Excluded from every CA policy. Stored as separate hardware tokens in separate safes. Every sign-in is wired to a P1 alert. Per Section 9.4 and Microsoft Learn's emergency-access guidance, this is the acknowledged operational compromise to the break-glass paradox ^[52].

The article has answered "who decided?" five times over: by signal, by policy, by token, by session, by operational pattern. One section remains: the misconceptions that keep recurring.

11. Misconceptions that recur#

Every time these questions come up in practice, the same wrong answers come back. The corrections are worth memorising.

12. Two planes, one boundary#

Replay Alice's Tuesday.

Identity Protection's signal plane scored her 09:02 sign-in. The score was below the medium-risk threshold. Conditional Access's policy plane evaluated four matching policies. Two demanded MFA; her cached refresh token already satisfied that grant from yesterday. One demanded a compliant device; Intune had marked her laptop compliant overnight. None demanded the block grant. The token issuer issued a CAE-aware bearer token with a 28-hour lifetime. Exchange Online accepted the token. Outlook's data path opened. Bytes returned to Alice.

If, twelve minutes later, an attacker tries to sign in with Alice's credentials from an anonymizing proxy, ID Protection will fire a detection. The detection will lift her user risk to high. CAE will deliver the high-user-risk event to Exchange. Exchange will issue a claims challenge on the next call from Alice's Outlook. Outlook will replay the challenge to Entra. Entra will re-run CA, see the elevated risk, demand step-up MFA, and either issue a fresh token (after Alice satisfies the step-up) or refuse.

The modern identity boundary is not a wall. It is a conversation between planes.

The boundary is a conversation between planes, not a wall.

The open frontier is real. Agent identities want a richer grant taxonomy than the human one provides. Cross-vendor CAEP wants production receivers outside Microsoft. Workload-identity policy wants grants that go beyond block. The break-glass paradox wants an answer that does not depend on operational discipline. None of these problems will resolve in 2026. They are the next frontier.

What the reader should now be able to do: trace a sign-in through the signal, policy, token, and session planes; read a conditionalAccessPolicy JSON and predict the evaluation outcome; identify which class of attack each grant defends against; and name, by reference to specific Microsoft Learn pages, what CA does not defend against. The promise from Section 1 is delivered.

"Today, 100 percent of consumer Microsoft accounts older than 60 days have multifactor authentication." -- Alex Weinert, Microsoft Identity, November 2023 ^[14]

Who decided this token is good? The boundary itself decided, by composing the work of every plane named above.