Microsoft SC-500: Conditional Access Authentication Strengths
Conditional Access authentication strengths let Microsoft Entra administrators require specific combinations of authentication methods instead of using one generic “require MFA” control for every scenario. Microsoft currently provides three built-in strengths—multifactor authentication, passwordless MFA, and phishing-resistant MFA—and supports custom authentication strengths for organizations that need a narrower allowed-method set.
This turns authentication policy into a question of method quality as well as method count. A privileged administrator, external collaborator, ordinary employee, and high-risk application may all need MFA, but they do not necessarily need the same authentication methods.
Authentication strengths are therefore a focused identity control inside Microsoft Identity & Security.
Understand the three built-in strengths
The built-in MFA strength accepts combinations that satisfy Entra multifactor authentication.
Passwordless MFA requires passwordless combinations.
Phishing-resistant MFA uses methods designed to resist credential phishing, such as FIDO2 security keys, Windows Hello for Business or platform credentials, and certificate-based authentication in supported combinations.
Use phishing-resistant MFA for privileged access
Microsoft recommends phishing-resistant authentication for important administrator roles.
Privileged access is strongest when Conditional Access and PIM combine strong authentication with time-bounded role activation.
Do not treat all MFA methods as equally resistant to modern phishing and adversary-in-the-middle attacks.
Use passwordless strength where user experience matters
Passwordless MFA can reduce reliance on passwords while still enforcing multifactor assurance.
It can be appropriate for broader user populations where the organization wants stronger authentication without requiring only the narrowest phishing-resistant method set.
Rollout should include method registration, device readiness, recovery, and support planning.
Create custom strengths for specific requirements
Custom authentication strengths let administrators define allowed method combinations when the built-in profiles are too broad.
Use custom strengths sparingly and document why the allowed methods differ from Microsoft’s built-in definitions.
Overly fragmented authentication policy can increase support and troubleshooting burden.
Apply strengths through Conditional Access
Authentication strength is a grant control inside Conditional Access.
Conditional Access remains a policy engine that evaluates user, app, device, location, risk, and other signals before applying the chosen control.
Authentication strength answers “which methods are acceptable,” while the rest of the policy answers “when should this requirement apply.”
Plan exclusions and break-glass access
Conditional Access policies can lock administrators out if deployed carelessly.
Microsoft guidance recommends protecting emergency access accounts from policy combinations that could prevent recovery.
Test in report-only or controlled scope before broad enforcement where appropriate.
Handle external users deliberately
External and guest users can be required to satisfy authentication strength policies for sensitive resources.
Conditional Access and MFA for B2B scenarios should account for whether the resource tenant trusts MFA from the home tenant and which methods are accepted.
External collaboration should not silently lower assurance for privileged applications.
Align method registration with policy
A policy cannot be satisfied if the target population has not registered an allowed method.
Rollout planning should include registration campaigns, supported device types, recovery procedures, and help-desk readiness.
Authentication design is broader than flipping on MFA; it includes the lifecycle of methods and user recovery.
Use strengths to express assurance tiers
Authentication strengths make it possible to align stronger methods with higher-consequence access.
AI access policy can use the same principle when agents, sensitive data, or administrative tools create different risk levels.
For current identity architecture, the durable pattern is to choose the right method strength, apply it to the right scope, test exceptions, and make method registration part of the deployment plan rather than assuming every MFA experience provides the same protection.
Review authentication-strength policy as methods and devices evolve. A strong policy today can become unnecessarily restrictive or insufficient if the allowed-method landscape changes.
Authentication-strength rollout should start with an inventory of registered methods. A phishing-resistant policy cannot succeed if most users only have methods that do not satisfy the requirement. Registration campaigns, hardware-key distribution, certificate enrollment, and device readiness are part of the security project.
Method assurance should match resource consequence. Ordinary productivity apps may use broad MFA, while privileged administration, sensitive finance systems, or high-value developer tools may justify phishing-resistant strength. One uniform policy can either overburden low-risk work or underprotect privileged access.
Authentication context can provide another layer for applications that need step-up authentication for specific actions rather than an entire session. Where supported, sensitive operations can require a stronger Conditional Access context without forcing the strongest method for every low-risk interaction.
External users need explicit design because their home tenant can satisfy MFA under cross-tenant trust settings. Decide which external populations can rely on home-tenant claims and which sensitive resources require stronger method combinations in the resource tenant.
Break-glass accounts should remain usable during policy failure, but they should be tightly monitored and protected through separate controls. An emergency account that bypasses Conditional Access should not become a convenient everyday admin identity.
User communication matters. A sudden stronger-method requirement can look like an outage if people have not registered the required authenticator or security key. Provide enrollment guidance, deadlines, support, and clear error interpretation before enforcement.
Report-only and pilot deployment can expose unexpected application dependencies, service-account behavior, or guest-user issues. Use staged scope where practical, then review sign-in logs and failure reasons before expanding the policy.
Authentication strengths should be reviewed together with the authentication-method policy. Allowing a method in one place but blocking or failing to register it elsewhere creates a policy users can never satisfy.
The durable identity strategy is to define assurance tiers, enroll users into appropriate methods, apply strengths through Conditional Access based on context, and keep recovery and external-user scenarios explicit. Strong authentication is a lifecycle and deployment program, not a one-line grant control.
Method migration should be staged. Organizations moving from SMS or app push toward phishing-resistant methods need a transition plan, device support, enrollment, and recovery. Stronger assurance is sustainable only when users can complete it reliably.
Authentication-strength policies should be paired with clear sign-in troubleshooting. Help desks need to recognize when a user failed because no registered method satisfies the policy rather than because the password or application is broken.
Use custom strengths only when the requirement is stable and meaningful. Too many one-off combinations can create overlapping Conditional Access policies that are difficult to reason about during incident response.
Review policy scope after acquisitions, guest-collaboration changes, and privileged-role redesign. Authentication assurance should follow current access patterns, not remain fixed around yesterday’s organization structure.
Method registration policies should be simplified where possible so users are not presented with authenticator choices that can never satisfy the applications they need. Registration experience and Conditional Access policy should tell the same assurance story.
For contractors and guests, test real cross-tenant scenarios. Home-tenant MFA trust, authentication strength, and device requirements can interact in ways that are not obvious from one policy screen.
Privileged users often need more than strong authentication: compliant devices, trusted administrative workstations, restricted locations, and time-bound role activation can add context around the phishing-resistant method.
Policy names should communicate intent, such as “Require phishing-resistant MFA for privileged roles,” rather than generic labels like “CA-12.” Clear naming helps incident responders understand what blocked a sign-in.
Review sign-in logs after enforcement to identify users repeatedly falling back to weaker or unsupported methods. Those patterns can reveal enrollment gaps or legacy applications that need modernization.
Authentication strengths are most effective as part of a broader identity lifecycle that includes onboarding, device trust, privileged access, recovery, guest access, and offboarding.
Authentication-strength policy should be validated after major changes to device platforms, certificate infrastructure, passkey support, or FIDO2 deployment. A policy can remain syntactically valid while operational readiness changes.
Keep an owner for each high-assurance policy and review the population, applications, exclusions, and accepted methods on a recurring cadence.
Use pilot groups that represent different devices, regions, job roles, and external-user scenarios before broad enforcement. A small technically homogeneous pilot can miss the operational problems that appear after enterprise rollout.
Recovery procedures should distinguish lost authenticator, lost device, certificate failure, and policy misconfiguration because each incident requires a different response path.
Authentication-strength governance should be coordinated with help-desk training, device-management policy, and privileged-access operations so stronger sign-in requirements remain practical during everyday work and during emergency recovery.
Review method readiness as device and authenticator support changes.
Strong authentication also needs usable recovery. Define emergency procedures for lost devices, unavailable certificates, inaccessible passkeys, and account compromise without creating a permanent weaker bypass that users learn to depend on.
Test authentication recovery with real support teams before relying on it during an incident.
Keep enrollment and recovery guidance current for every enforced method.
Test representative sign-in and recovery paths after material Conditional Access changes.