These days I rarely work on an Entra ID or Microsoft 365 project where phishing-resistant MFA for admin accounts isn't near the top of the list. Push notifications and SMS codes are known weak spots by now, and attackers keep finding new ways around them. If you really want to protect privileged access, enforcing strict authentication strengths in Conditional Access is the only practical route. In 2025 this has moved past best-practice territory and become urgent. It also breaks some old habits, and a few legacy tools along with them.

Entra ID ships three built-in authentication strengths

Authentication strengths are how Microsoft Entra ID lets you define exactly which authentication methods count as strong enough for a given access scenario. A plain "require MFA" grant leaves a lot open. With a strength, you can require the user to sign in with a specific high-assurance method. Three strengths come built in:

  • "Multifactor authentication": any two-factor method, including weaker ones like SMS or app push
  • "Passwordless MFA": FIDO2 security keys, Windows Hello for Business and passkeys, with no password involved
  • "Phishing-resistant MFA": only FIDO2 keys and certificate-based authentication (genuinely phishing-resistant)

For admins, "Phishing-resistant MFA" is normally the one you want. Microsoft's documentation lays out the differences well (Authentication strengths explained). What I often find in tenants is that privileged accounts still run on weaker methods. Usually that's inertia. Sometimes the strong methods simply haven't been rolled out or registered yet.

Custom authentication strengths can target specific FIDO2 AAGUIDs

Custom authentication strengths are where it gets interesting, particularly if compliance requires you to limit which FIDO2 keys or certificate types are allowed. In the Entra portal, go to Protection → Authentication methods → Authentication strengths, create a new strength and select only the FIDO2 AAGUIDs you've approved (specific YubiKey models, for example). This is also very useful for emergency access accounts. You can build a custom strength that accepts nothing but one dedicated, locked-down FIDO2 key. I cover that in Emergency access accounts in Entra ID: How to get them right.

Conditional Access, PIM and authentication context bind strengths to admin roles

To enforce the strength you picked, create a Conditional Access policy and target Users → Directory roles in the assignment. Use the grant control "Require authentication strength" and select "phishing-resistant MFA", and only those sign-ins will be accepted for members of the chosen admin roles.

In most environments I work in, the standard setup is one policy covering Global Admin, Privileged Role Admin, Conditional Access Admin, Application Admin and Security Admin, all required to use phishing-resistant methods. You can go a step further and require strong authentication on every PIM (Privileged Identity Management) elevation by referencing an authentication context in your CA policy. My hands-on steps for the core CA policies are in Conditional Access in Microsoft Entra ID: The First Policies Every Tenant Needs.

For high-risk operations such as deleting directory objects, Microsoft's Protected Actions feature now lets you demand step-up authentication with strong methods. The advanced options are described in Microsoft's documentation.

This simple diagram shows how roles, PIM, authentication strengths and break-glass accounts connect:

flowchart TD
    User["Admin user"] --> PIM["PIM role activation"]
    PIM --> CA1["CA policy: Directory roles"]
    CA1 --> AuthStrength["Phishing-resistant MFA"]
    PIM --> CA2["CA policy: Auth context"]
    CA2 --> AuthStrength
    BreakGlass["Break-glass account with FIDO2"] --> CA1
    AuthStrength --> Access["Admin access granted"]

Figure: Authentication strengths combined with CA for admin roles, PIM and emergency access

Enforcement breaks legacy tools, so the migration needs phases

Here's the catch. As soon as you enforce "phishing-resistant MFA" on admin roles, legacy tools that depend on device code flow or older authentication methods stop working. That covers the aging MSOnline and AzureAD PowerShell modules (see the retirement and migration guide) and any admin tool without FIDO2 or certificate-based auth support. Device code flow is blocked for the affected accounts as well.

Practical tip: Before you roll this out to all admin roles, assign the policy to a dedicated pilot group (with test roles!) and run through all your scripts and tools. You'll find out fast what breaks, and you can plan replacements, which usually means moving to the Microsoft Graph PowerShell SDK and modern auth.

I always recommend a phased rollout. Start with Security Admins or a small IT group, get support processes and communication in place, and then extend to the other roles. For admin scripting, the Microsoft Graph PowerShell SDK is where things are heading (automation with Graph).

To check whether device code flow is already blocked for privileged users in your tenant, look in the Entra portal under Protection → Conditional Access → Authentication strengths and go through the sign-in logs for failed legacy auth attempts.

Break-glass accounts should use dedicated FIDO2 keys

Classic break-glass accounts become a risk when they're excluded from CA policies and end up with weak or legacy MFA. Custom authentication strengths combined with dedicated FIDO2 keys let you enforce emergency access that is strong and policy-compliant, without falling back on username/password or SMS. The details are in Emergency access accounts in Entra ID: How to get them right.

If you'd like to go fully with passkeys for admin rollout and recovery, I've written up practical tips and the pitfalls I've run into in Passkeys Entra ID: From pilot to full rollout.

I treat authentication strengths as baseline security

In 2025, running admin accounts without enforced authentication strengths is playing with fire, because phishing and misuse of legacy tools are simply too common. Conditional Access, PIM, protected actions and custom strengths have matured into a solid toolkit, and they push organizations to modernize how admins work. More and more of the tenants I see now separate daily and admin identities properly, set up secure emergency accounts and move admin scripting to modern modules. Roll it out step by step, keep the usual pitfalls in mind, and you'll meet Microsoft's recommendations while also defending against the attacks your privileged users are most likely to face.