Start with administrators, and enforce the built-in Phishing-resistant MFA authentication strength on them through Conditional Access. It allows only Windows Hello for Business or a platform credential, a FIDO2 security key, or Entra certificate-based authentication (multifactor). SMS and push approvals no longer satisfy the policy for those accounts on the resources it covers, although the password prompt remains (see What breaks).
Why admins go first
Microsoft's authentication overview says that MFA based on SMS, email OTP or authenticator apps is prone to remote phishing, where attackers steal passwords or one-time codes without touching the user's device. Microsoft recommends Windows Hello for Business, passkeys (FIDO2), FIDO2 security keys or certificate-based authentication instead. An admin account is where a stolen code costs the most, and a small team has only a handful to move.
Be careful with the middle built-in option. According to the authentication strengths documentation, Passwordless MFA strength includes Microsoft Authenticator phone sign-in. The Phishing-resistant strength does not.
Prepare the tenant
Passkeys (FIDO2) are available in all Entra ID editions with no extra licence. Conditional Access needs Entra ID P1.
The settings live under Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2). You need at least the Authentication Policy Administrator role. Three details matter:
- Opting in to passkey profiles is one-way. You cannot opt out afterwards, and your current global settings move into a Default profile. Up to three profiles, including Default, are supported.
- Allow self-service set up must be Yes, or users cannot register a passkey through Security info. It is a global setting, not a per-profile one.
- Registration requires MFA completed within the past five minutes.
For admins, the documentation's own example is a profile with passkey type Device-bound and Enforce attestation set to Yes. Device-bound means the private key never leaves one physical device, such as a security key or Microsoft Authenticator. Synced passkeys do not support attestation, and Microsoft says to treat them as phishing-resistant but with the security posture of other unattested authenticators. The NIST text requires a phishing-resistant authenticator with a non-exportable key at AAL3, its highest level, so device-bound keys are the closest match among Entra's options.
Enforce with an authentication strength
Create a Conditional Access policy, target your admin roles or group, and under grant controls choose Require authentication strength. Select Phishing-resistant MFA. You cannot combine this with Require multifactor authentication in the same policy, because the built-in MFA strength is equivalent to that control.
Built-in strengths cannot be edited, and Microsoft updates them when new methods appear. If you need a fixed set of allowed methods, create a custom strength.
You do not have to switch SMS off for everyone. The strength sits on top of the Authentication methods policy and narrows it for a scenario. Staff can keep a password and push approval for ordinary resources while admins are held to the stricter policy.
What breaks
An admin still types a password first. Conditional Access is evaluated after the initial authentication, so the strength only then demands a phishing-resistant method.
If a user signs in with a password as the primary method and the strength requires Windows Hello for Business, they are not prompted for it. They must restart the session, select Sign-in options and pick the required method. Put that in your admin instructions.
Two controls act at different moments. Enforce attestation applies only at registration, so a passkey registered without attestation is not blocked at sign-in once you switch it on. Re-register admin keys afterwards. Key restrictions by AAGUID apply to both registration and sign-in, so removing a previously allowed AAGUID locks out everyone who registered that model.
Profile overlap is permissive, and it affects registration and sign-in at the passkey-policy level. When a user falls under several profiles, a passkey is allowed if it fully satisfies at least one of them, in no particular order. An admin who also sits in an "all synced or device-bound" group can therefore register and use a synced passkey as far as the passkey policy is concerned. The sources do not say whether the Conditional Access strength accepts it, so test that case.
After opting in, check the Default profile under Enable and target. If its target is All users and it allows synced passkeys, retarget it to groups that do not contain your admins. Do not exclude admins in the Passkey (FIDO2) policy instead: an excluded group is blocked from FIDO2 registration and sign-in entirely, and that overrides any inclusion.
Sign-in frequency and strength can be met at different times. With a passkey strength and a 1-hour sign-in frequency, a passkey sign-in from 24 hours ago plus a Windows Hello device unlock today satisfies both. If you rely on short frequencies for admins, test this case.
Temporary Access Pass appears in the MFA strength but not the phishing-resistant one. Our own inference, which the sources do not state: a recovery or bootstrap flow built on a Temporary Access Pass will not satisfy the policy, so it needs an exclusion or a separate policy. Decide that before you enforce, not during the incident.
Where to start
- List every account with an admin role, and pick two or three for the pilot group.
- Opt in to passkey profiles, check the Default profile's target, create an admin profile with Device-bound and Enforce attestation set to Yes, and target it at the pilot group only.
- Register at least two authenticators per pilot admin, for example a security key and Windows Hello, and confirm sign-in works with each.
- Create the Conditional Access policy with the Phishing-resistant MFA strength for the pilot group. As general practice (the Microsoft pages used here do not cover break-glass accounts), exclude emergency access accounts and give each its own FIDO2 key.
- Extend to all admins. Remove passkeys registered before attestation was enforced only after each admin has re-registered an attested key, so nobody is locked out.
- Have the result tested. Our consulting team can review the policy, and a penetration test shows whether any admin path still accepts a weaker method.
