Conditional Access Authentication Strengths: What the Policy Accepts and Where the Guarantees End
Conditional Access Authentication Strengths: What the Policy Accepts and Where the Guarantees End
π― The Design Question Conditional Access Authentication Strengths Actually Answer
Consider an organization that has deployed phishing-resistant MFA as a formal security objective. The Conditional Access policy is in place. The policy uses the built-in Phishing-resistant MFA strength. The compliance dashboard shows coverage. The security team believes that users accessing sensitive applications cannot authenticate with a password.
That belief is not what the documentation supports.
The actual question that Conditional Access authentication strengths answer is narrower and more precise than it first appears: which combinations of authentication methods will satisfy a grant control, after the initial authentication has already occurred? That is the scope of the guarantee. And the precise boundary of that scope is where most access policy design decisions either hold or collapse.
Authentication strengths are a Conditional Access grant control. They define what an authenticated session must demonstrate before access is granted to a resource. They do not define what the user is allowed to attempt during sign-in. That distinction has architectural consequences that the method-combination table alone does not communicate.
The right framing is this: an authentication strength is a filter applied to a completed authentication, not a gate on the authentication options presented to the user. Designing access policy from the first framing produces a different architecture than designing it from the second.
ποΈ Where Authentication Strengths Fit in the Entra Authentication Architecture
Three separate controls govern authentication method behavior in Microsoft Entra ID, and they apply in a specific order. Confusing their responsibilities is where access policy drift starts.
The architectural implication of this layering is direct: an authentication strength definition that includes a method that is not enabled in the Authentication Methods policy will never be satisfied by that method in practice. The strength may list it; the method simply will not be available for the user to present. The documentation establishes that authentication strengths are based on the Authentication Methods policy; the strength does not override it.
Prerequisites are not optional in this architecture. Before designing any authentication strength, validate that every method combination the strength includes is actually enabled in the Authentication Methods policy for the users the Conditional Access policy targets. A strength that references an unenabled method produces a policy that behaves differently than intended, with no obvious error surface.
π Built-In Strengths: What Microsoft Defines and What It Guarantees
Microsoft provides three built-in authentication strengths. They are predefined, always available, and cannot be modified. Microsoft updates them when new methods become available. Source: Microsoft Learn: Conditional Access authentication strengths
The method-combination matrix below is the factual core of what each built-in strength accepts. A checkmark means that method combination satisfies the grant control. The absence of a checkmark means it does not.
| Authentication Method Combination | MFA Strength | Passwordless MFA Strength | Phishing-Resistant MFA Strength |
|---|---|---|---|
| FIDO2 security key | β | β | β |
| Windows Hello for Business or platform credential | β | β | β |
| Certificate-based authentication (multifactor) | β | β | β |
| Microsoft Authenticator (phone sign-in) | β | β | |
| Temporary Access Pass (one-time use and multiple use) | β | ||
| Password + something the user hasΒΉ | β | ||
| Federated single-factor + something the user hasΒΉ | β | ||
| Federated multifactor | β | ||
| Certificate-based authentication (single-factor) | |||
| SMS sign-in | |||
| Password | |||
| Federated single-factor | |||
| QR code |
ΒΉ Something the user has refers to: text message, voice, push notification, software OATH token, or hardware OATH token.
To inspect the exact definitions Microsoft has published for all built-in strengths, query the Graph API directly:
GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?$filter=policyType eq 'builtIn'Run this query before finalizing policy design and again after Microsoft updates built-in strengths. The response returns the exact method combinations each built-in strength accepts, which is the authoritative definition of what the grant control will evaluate. Treat it as the source of record, not documentation screenshots.
Three observations the table makes plain without requiring interpretation:
First, methods like single-factor CBA, SMS sign-in, plain password, federated single-factor, and QR code satisfy no built-in strength. They are listed in the documentation but excluded from every built-in combination. A policy requiring any built-in strength will reject sessions authenticated with only these methods.
Second, the phishing-resistant MFA strength accepts exactly three combinations: FIDO2 security key, Windows Hello for Business or platform credential, and multifactor CBA. Authenticator phone sign-in is in the passwordless MFA strength but not in phishing-resistant.
Third, Email one-time passcode (Guest) is not supported in any available combination. The documentation states this as a current limitation.
What the table does not tell you is what happens at the point of authentication before this evaluation runs. That is the more important question, and it is addressed next.
β οΈ What the Built-In Strengths Do Not Guarantee
The method-combination table defines what a strength accepts. It does not define what a user is restricted from attempting.
The documentation states this directly: Conditional Access policies are evaluated only after the initial authentication. As a result, an authentication strength does not restrict a user's initial authentication.
Read that again carefully. The policy evaluates what the user presented. It does not constrain the options the user sees during sign-in.
The documentation gives the exact consequence: when using the built-in Phishing-resistant MFA strength, a user can still enter a password but must sign in using a phishing-resistant method before they can continue. Source: Microsoft Learn: Conditional Access authentication strengths
This matters for any phishing-resistance claim the organization is making.
If the threat model includes credential interception during the initial authentication attempt, the authentication strength control does not address that alone. The strength ensures the session satisfies phishing-resistant criteria before access is granted. It does not prevent a password from being transmitted as a first factor in the sign-in flow.
The architectural consequence is that phishing-resistance at the access control layer and phishing-resistance at the authentication prompt layer are not the same guarantee. The strength control provides the former. The latter requires a separate control: disabling password authentication for the user, or configuring the application to not offer the password prompt. The documentation does not say which control achieves this; it simply establishes that authentication strength does not.
𧩠Custom Strengths: The Design Space and Its Constraints
Administrators can create custom authentication strengths to define exactly which method combinations will satisfy a grant control. The source confirms this is available and that it is intended for cases where the built-in strengths do not match the access requirements.
The documentation does not detail the constraint surface for custom strengths in the sections this article draws on. The documentation covered here does not say which specific combinations are valid, which are invalid, or whether custom strengths can reference combinations that include methods not currently in any built-in strength.
What the documentation does establish is that custom strengths operate within the same architectural layer as built-in strengths: they define what combinations satisfy a Conditional Access grant control, they depend on the Authentication Methods policy for their practical effect, and they are subject to the same post-authentication evaluation timing. Those constraints apply regardless of how a custom strength is defined.
π¨ The Limitations the Documentation States Plainly
Four documented limitations each carry a distinct architectural consequence. These conditions apply in normal operation.
Policy evaluation timing is addressed in the section above. It is restated here for completeness: the strength control evaluates the session post-authentication. It cannot restrict the initial sign-in options.
Unsupported grant control combination. You cannot use Require multifactor authentication and Require authentication strength in the same Conditional Access policy. The documentation states the reason: because the built-in Multifactor authentication strength is equivalent to the Require multifactor authentication grant control, the platform does not allow them to be combined. Source: Microsoft Learn: Conditional Access authentication strengths
If a policy review finds both the Require multifactor authentication grant control and a Require authentication strength grant control applied to the same policy, the platform will reject the combination. One must be removed. The authentication strength is the more precise control; keeping it and removing the MFA grant control is the correct direction if method-level specificity is the intent.
Email one-time passcode (Guest) is unsupported. The documentation states this explicitly as a current limitation. If a Conditional Access policy targeting guest users includes an authentication strength, and those guests authenticate with Email OTP, the strength cannot be satisfied by that method. This has direct consequences for B2B access policies where Email OTP is the primary guest authentication method.
Windows Hello for Business session dependency. The Windows Hello for Business session dependency has a direct and non-obvious effect on user experience. If a user signed in with a password as the primary authentication method, and the authentication strength requires Windows Hello for Business, the user is not prompted to switch to WHfB. They must restart the session, select Sign-in options, and choose a method the strength requires. The documentation is specific about this: WHfB can satisfy a strength requirement only when it was used as the primary authentication method in the current session. Source: Microsoft Learn: Conditional Access authentication strengths
This WHfB session dependency means a user can be enrolled in Windows Hello for Business, have it enabled in policy, and still be unable to satisfy a phishing-resistant MFA strength requirement in their current session β because they signed in with a password first. The resolution requires a session restart, not a credential re-registration. Help desk teams handling "can't access the sensitive application" tickets should check the sign-in method before escalating. This follows directly from the documented limitation.
π The Sign-In Frequency Known Issue: Why Two Controls Can Satisfy Each Other at Different Times
The documentation labels this a known issue, which means it is a documented behavior gap, not a configuration error.
The scenario: a resource requires both a phishing-resistant MFA strength (specifically a passkey or FIDO2 key) and a sign-in frequency of one hour. A user authenticated with a FIDO2 passkey 24 hours ago. When the user unlocks their Windows device with Windows Hello for Business, they can access the resource again. The documentation explains why: yesterday's FIDO2 sign-in satisfies the authentication strength requirement, and today's device unlock satisfies the sign-in frequency requirement. Two different events, two different methods, evaluated against two different controls at two different times. Source: Microsoft Learn β Conditional Access authentication strengths
The consequence is that a policy designed to force re-authentication with a specific method at a defined interval does not necessarily achieve that when authentication strength and sign-in frequency are combined. The frequency requirement can be satisfied by a different authentication event than the one the strength requires.
The documentation does not address how to close this gap. My read is that this is an inherent consequence of the two controls being evaluated independently against different events rather than being jointly evaluated against the same authentication act. Whether this gap matters for a given organization depends on how the sign-in frequency requirement is being used and what assurance level it is intended to maintain. But the assumption that "require phishing-resistant MFA strength plus a 1-hour session limit" forces a FIDO2 re-authentication every hour is not what the documentation supports.
π Authentication Methods Policy vs. Authentication Strength: Two Controls, One Decision
The documentation addresses the relationship between the Authentication Methods policy and authentication strengths directly in its FAQ, and the answer is architecturally important.
The Authentication Methods policy is the broader control. It configures which methods are enabled for which users and groups across the tenant. It is where Microsoft Authenticator is enabled, FIDO2 is scoped, and CBA is configured. Changing the Authentication Methods policy affects what methods are available to users everywhere in the tenant for the users and groups it covers.
An authentication strength applies a further restriction for a specific Conditional Access scenario: a sensitive resource, a high-risk user, a location-based condition. It does not change what methods are enabled; it selects from the enabled methods and requires a specific combination for a specific access decision.
The FAQ example in the documentation makes this concrete. An administrator enables Microsoft Authenticator for push notifications and passwordless phone sign-in at the methods-policy level. For the most sensitive application, a separate Conditional Access policy applies the Passwordless MFA strength. Users can authenticate with a password plus an Authenticator push for most resources. For the sensitive application, they must use Authenticator phone sign-in. The methods-policy enablement did not change; the strength layered a finer restriction on top of it for that specific access scenario. Source: Microsoft Learn: Conditional Access authentication strengths
The Authentication Methods policy sets the outer boundary. Authentication strengths draw tighter lines within it for specific access contexts. A method not enabled at the policy layer cannot be required at the strength layer, regardless of how the strength is defined.
π« What This Technology Does NOT Solve
Authentication strengths define which session credentials satisfy a Conditional Access grant. That is a precise and useful control. It is also a bounded one.
The control does not suppress password prompts at sign-in. A phishing-resistant MFA strength does not prevent a user from being offered a password entry field during their initial authentication. The strength evaluates the session after the fact.
The control does not change which methods are available to users. Enabling or disabling authentication methods is the Authentication Methods policy's responsibility. An authentication strength that references a method that is not enabled will not be satisfied by that method, but the strength itself does not control availability.
The control does not enforce re-authentication with the required method on a defined schedule without the interaction described in the sign-in frequency known issue. The combination of sign-in frequency and authentication strength can be satisfied by two different authentication events rather than forcing a single re-authentication that satisfies both.
The control does not address federation opacity. Federated multifactor is listed as satisfying the MFA strength. The documentation covered here does not address what the federation provider must assert for a federated multifactor combination to be accepted, or what happens when a federated MFA claim does not reflect the quality of the underlying authentication.
Authentication strengths do not provide a phishing-resistant authentication guarantee at the credential-entry layer. They provide a phishing-resistant grant control at the access decision layer. Both matter; they address different points in the authentication flow and should not be conflated when making a compliance or risk posture claim.
ποΈ Architecture and Governance Decisions This Control Forces
The documentation on authentication strengths, read carefully, forces several architecture decisions that cannot be deferred to implementation.
Method coverage must be verified before strength design. The strength definition is meaningless if the methods it references are not enabled for the users the Conditional Access policy targets. Before writing a strength-based policy, the Authentication Methods policy scope for the target population is the first thing to confirm. It is the prerequisite the entire grant control depends on.
The licensing floor is Entra ID P1. The documentation states this directly. Authentication strengths as a Conditional Access control require at minimum a Microsoft Entra ID P1 license. Source: Microsoft Learn β Conditional Access authentication strengths That constraint applies to every user the policy targets.
Phishing-resistance claims require two separate design decisions. The first is the grant control: which methods will satisfy the policy. The second is the sign-in surface: whether the password prompt is presented at all during initial authentication. An authentication strength handles the first. The second requires a different control β either disabling password authentication for the targeted users in the Authentication Methods policy, or ensuring the application flow does not offer it. Organizations making a formal phishing-resistance claim in their security posture need to address both, and the documentation establishes that authentication strength alone covers only one of them.
Windows Hello for Business as a strength method requires primary-method enrollment hygiene. If WHfB is intended to satisfy phishing-resistant MFA strength in a Conditional Access policy, the user population must reliably sign in with WHfB as the primary method. Users who default to password-based sign-in and complete WHfB enrollment as a secondary factor will trigger the session-restart behavior described in the documentation. Ensuring WHfB is the primary authentication path is an operational and device configuration decision that has to be made before the strength policy is relied upon for access control.
Guest access policies require explicit method verification. Email one-time passcode is unsupported in any available combination. If an organization applies an authentication strength to a policy that includes guest users who authenticate with Email OTP, those guests will not be able to satisfy the strength. The architecture decision is whether to exclude Email OTP guests from the policy scope, direct them to a different authentication method, or accept that the resource is inaccessible to that guest population under this policy.
If I were designing access policy architecture for a regulated workload today, my recommendation would be to treat the authentication strength as one layer in a three-part design: the Authentication Methods policy as the enablement layer, the authentication strength as the session-assertion layer, and a separate passwordless or password-suppression control as the prompt-layer control. Relying on authentication strength alone and describing the result as phishing-resistant sign-in is a posture claim the documentation does not fully support.
