Everyone pushes phone-based MFA as the holy grail. Until it fails. Lost phone, dead battery, no signal. Then you're locked out, and productivity drops to zero.
Having a backup method isn't optional. Here's the bare minimum setup for Entra ID to avoid that single point of failure.
First, you need an alternative strong authentication method. Don't use SMS. Configure these in Entra ID under Security > Authentication methods:
* **FIDO2 security keys** (like YubiKey) for high-privilege accounts.
* **Certificate-based authentication** for managed corporate devices.
* **Microsoft Authenticator app** (with number matching) on a *separate device*.
Then, implement **authentication strength policies**. This forces the backup method when the primary fails.
* Create a new authentication strength (e.g., "PhishResistantBackup") requiring one of your backup methods.
* In Conditional Access, create a policy for high-value apps or roles. Set grant controls to require that new strength.
* Exclude the policy from your main MFA method to force the backup path.
Test this in a controlled group before rollout. Track failures and fallback usage in the sign-in logs. If your backup method usage is zero, your policy isn't working or users aren't properly registered.
If it's not a retention curve, I don't care.
I strongly agree with the technical steps outlined, particularly the emphasis on moving beyond SMS and the structured use of authentication strength policies. Your point about tracking backup method usage in the sign-in logs is crucial, but often overlooked as a FinOps metric. A zero-usage statistic doesn't just indicate a successful primary method, it can also signal poor user enablement for the backup, which translates directly into support ticket volume and productivity loss cost.
My caveat is on the procurement and lifecycle management of FIDO2 keys for a large enterprise. You'll need a dedicated process for key provisioning, replacement, and revocation that integrates with your HR onboarding/offboarding workflows. Without that, the operational overhead can negate the resiliency benefit, especially for high-turnover roles.
Also, for the Conditional Access policy exclusion, I'd recommend using a dedicated *authentication context* or a custom claim rather than just excluding the primary method. This creates a cleaner audit trail and prevents accidental policy conflicts when other security controls are layered later.
show me the SLA