Skip to main content

🔐🧑‍💼AS - Authentication Strengths

What this policy is about 🛡️​

Authentication Strengths are named bundles of acceptable auth methods that Conditional Access policies point at instead of saying "require MFA" and hoping for the best.

"MFA" means very different things in 2026. SMS + password is technically MFA. FIDO2 + biometric is MFA. They are not the same product. A Strength gives a CA a way to say exactly what flavor of MFA it wants, by name, in one place.

Without Strengths, every CA is on its own. With Strengths, you define "Phishing-Resistant" once and every CA that needs phishing-resistance just references it. Change the definition centrally; every CA picks up the new bar. ⚙️

Why this matters 🎭​

CA policies have a built-in dropdown that says "require multi-factor authentication". That checkbox is older than the company's accountant. It accepts anything Microsoft has ever called MFA, including the ones that got phished in 2023, the ones that got SIM-swapped in 2024, and the ones that got AiTM-bypassed last quarter.

Strengths replace that dropdown with a specific, named, auditable answer. Three Microsoft-shipped strengths plus optional custom ones:

Built-in strengthWhat it accepts
Multifactor authenticationAnything Microsoft calls MFA. The legacy bar.
Passwordless MFAMicrosoft Authenticator passwordless, FIDO2, Windows Hello, Certificate-based, Passkey
Phishing-resistant MFAFIDO2, Windows Hello, Certificate-based, Passkey only. No Authenticator push, no number match, nothing knowable.

You don't need to invent new strengths for most MKB scenarios. The three built-ins cover the use cases. The only common custom-strength addition is one that combines FIDO2 + Windows Hello only for tenants who don't issue Passkeys yet. ✋

🛠️ Strength definitions​

Configured under Entra admin center → Protection → Authentication methods → Authentication strengths. Tenant-scope.

Strengths to use (built-in)​

StrengthUse caseReferenced by
Multifactor authenticationBaseline for all users on standard sign-insThe CA - MFA for All Users policy
Phishing-resistant MFAAll admin role activations, high-priv access, Panic Room sign-insThe CA - MFA for Admin Roles family, the BTG CA
Passwordless MFAOptional. Targeted at "we want users off passwords entirely but FIDO2 isn't fleet-wide yet" rolloutsPer-tenant choice, not baseline

Custom strength (optional)​

StrengthDefinitionWhen to use
MKB Phishing-Resistant (no certificates)FIDO2 + Windows Hello + Passkey. Same as built-in Phishing-Resistant minus Certificate-based authentication.Tenants that don't have a managed PKI and want the cert-based branch removed for clarity in audits. Same effective bar as built-in, just less ambiguity about what's possible.

That's it. One optional custom strength. Resist the urge to invent five more. Every additional Strength is a thing the next person has to learn before they can read your CA stack. 🧠

Caveats ⚠️​

License fit. Authentication Strengths require Entra ID P1 (included in Business Premium). The built-in strengths are free to define. Using them in a CA requires P1.

The Authentication Methods policy enables, Strengths gate. Strengths reference methods. If FIDO2 isn't enabled in the Authentication Methods policy, the Phishing-Resistant Strength has nothing to gate on, and CAs referencing it will block legitimate users who should have FIDO2 but don't because the method is off. Wire Methods first, then Strengths. Order matters. 🪡

Don't reference "Multifactor authentication" Strength on admin CAs. That's the legacy bar. Admin role activation should require Phishing-Resistant. The whole reason Strengths exist is to give you a precise way to say "no, SMS doesn't count for admins."

Strength conflicts in nested CAs. If two CAs both apply to the same sign-in and reference different Strengths, the most restrictive one wins. Mostly fine; occasionally surprises someone debugging "why can't I sign in to this app with a Yubikey, I have a Yubikey." Check the resolved CA evaluation in the sign-in log. 🔍

Custom Strengths in the audit trail. Custom Strength names show up in admin audit logs verbatim. Name them like you'd want to read them at 2am during an incident review. "Strength_v3_FINAL_dontuse" is a documented anti-pattern. 📛

Reversibility. Strengths are clean-revert. Deleting a Strength fails if any CA references it (which is correct behavior; the CA would silently degrade). Update CAs to reference a different Strength first, then delete. Standard "remove the dependency before removing the thing" pattern.

💡 SuperVision tip​

Baseline policy. Golden Master → Entra → Authentication → Strengths. Same definitions across every tenant.

Tag candidates: none. Strengths are fleet identity. The whole point is centralized definition.

Drift detection. Lower priority than Methods (Strengths don't have on/off toggles that can flip via phishing). Watch for unauthorized new Strengths being created; legitimate workflow is "MSP-engineer creates strength via SuperVision flow", not "tenant admin invents one at 11pm."

Multi-tenant scaling. Identical. The three built-in Strengths + the one optional custom Strength is the entire library. Every tenant has the same library.

Custom Strength governance. If a customer asks for a custom Strength specific to their environment ("we need a Strength that's our FIDO2 keys only by AAGUID"), the answer is "we can do it, but it stays in your tenant's CA stack only and gets reviewed quarterly." Custom Strengths that scale across the MSP base get absorbed back into the Golden Master definition.

👥 Assignment scope​

Strengths are tenant-scoped objects, not user-scoped. CAs reference them. Users encounter them through whichever CA gates their sign-in.

🔗 Related​

Three built-ins, one optional custom. The library stays small on purpose. Every Strength is a thing your future self has to remember why exists. ⏳