Phishing-Resistant MFA in Entra ID: A Rollout Guide for SMBs

Phishing attacks increasingly target multifactor authentication (MFA) itself, using fake login pages or MFA-fatigue tactics to trick users into approving sign-ins they didn’t initiate. Traditional MFA methods like SMS codes or push notifications can be intercepted or socially engineered. Phishing-resistant MFA methods close this gap by requiring hardware-backed credentials that can’t be phished, making them particularly important for protecting admin accounts in small and mid-sized Microsoft 365 tenants.

This article explains what phishing-resistant authentication methods Microsoft Entra ID supports, what licensing and device prerequisites apply, and how SMB admins can roll out a Conditional Access policy that enforces phishing-resistant MFA for admin roles without accidentally locking themselves out of the tenant.

What counts as phishing-resistant MFA in Entra ID

According to Microsoft Entra ID documentation, phishing-resistant passwordless authentication methods fall into two broad categories:

Passkeys (FIDO2-based), which include:

• Windows Hello for Business
• Microsoft Entra passkey on Windows
• Platform credential for macOS (preview)
• Microsoft Authenticator app passkeys
• FIDO2 security keys (physical hardware keys)
• Synced passkeys, synced through providers such as Google Password Manager or iCloud Keychain

Certificate-based authentication (CBA), also referred to as smart card authentication.

Microsoft’s documentation distinguishes between portable credentials, which can be used across multiple devices (such as FIDO2 security keys, passkeys in Microsoft Authenticator, and CBA), and local credentials, which are tied to a single device and use that device’s own unlock method, such as Windows Hello for Business or Platform Credential for macOS. Microsoft recommends that most users end up with at least one portable credential plus local credentials on each device they regularly use.

These methods qualify as phishing-resistant because they rely on something the user physically has (a device or security key) combined with something the user knows or is (a PIN or biometric), using hardware-backed cryptography rather than a shared secret that can be intercepted or replayed.

Licensing and device prerequisites

Licensing

Microsoft documentation states that registering for and signing in with passwordless methods in Entra ID does not itself require a license. However, Microsoft recommends at least a Microsoft Entra ID P1 license to get the full set of capabilities needed for a real deployment — specifically, enforcing passwordless sign-in through Conditional Access policies and tracking rollout progress using the authentication method activity report.

For most SMB tenants planning to enforce phishing-resistant MFA on admin accounts using Conditional Access, this effectively means Entra ID P1 (or an equivalent bundle that includes it) is the practical licensing baseline, even though registration alone doesn’t strictly require it.

Device requirements

Microsoft’s deployment guidance lists minimum operating system versions needed for devices to natively support phishing-resistant passwordless credentials such as passkeys and Windows Hello for Business:

• Windows 10 22H2 (for Windows Hello for Business)
• Windows 11 22H2 (for the best passkey experience)
• macOS 13 Ventura
• iOS 17
• Android 14

Devices running older operating systems may still support phishing-resistant authentication, but typically only through an external authenticator such as a FIDO2 security key, rather than native platform credentials.

Required Entra ID roles

Microsoft documents the following least-privileged roles for setting up a phishing-resistant passwordless deployment:

Role	Purpose
User Administrator	Implement the combined registration experience
Authentication Administrator	Implement and manage authentication methods
Authentication Policy Administrator	Manage the Authentication methods policy
User	Configure Authenticator app and enroll a security key on their own device

Creating and enabling the Conditional Access policy itself requires at least the Conditional Access Administrator role.

Planning your rollout: admins first

Microsoft’s deployment guidance recommends grouping users into personas before rolling out phishing-resistant credentials, with “Admins and highly regulated users” as one persona and “Non-admins” as the other. Microsoft recommends starting enforcement with one persona first rather than attempting an organization-wide rollout simultaneously — and for most organizations, that means piloting with admin accounts before extending to the broader workforce.

For the admin persona specifically, Microsoft’s recommended portable credential is a FIDO2 security key, with passkeys in Microsoft Authenticator or certificate-based authentication listed as alternatives. For local (device-bound) credentials, Microsoft recommends Windows Hello for Business, Microsoft Entra passkey on Windows, or CBA on Windows devices for this persona, with corresponding platform-specific options for macOS, iOS, and Android.

Getting admins registered before enforcement

Before any enforcement policy goes live, admins need an actual phishing-resistant credential registered. Microsoft’s guidance describes a bootstrapping process: new or existing admins without a phishing-resistant method yet can be issued a Temporary Access Pass (TAP), which they use to register their first portable credential (such as a FIDO2 key), and then use that portable credential to bootstrap local credentials on their individual devices.

Microsoft documentation includes an explicit caution here: enabling a phishing-resistant MFA enforcement policy before administrators have registered the appropriate methods risks locking you out of your tenant. Registration must happen first.

Building the Conditional Access policy

Microsoft Entra ID offers three built-in authentication strengths that can be required through Conditional Access:

• Multifactor authentication strength (least restrictive)
• Passwordless MFA strength
• Phishing-resistant MFA strength (most restrictive) — this is what Microsoft recommends requiring for privileged admin roles

Organizations can also build a custom authentication strength based on specific methods, but the built-in phishing-resistant strength covers the documented scenario of protecting admin accounts.

Roles Microsoft recommends covering

Microsoft’s guidance for this specific policy recommends requiring phishing-resistant MFA for at least the following directory roles:

• Global Administrator
• Application Administrator
• Authentication Administrator
• Billing Administrator
• Cloud Application Administrator
• Conditional Access Administrator
• Exchange Administrator
• Helpdesk Administrator
• Password Administrator
• Privileged Authentication Administrator
• Privileged Role Administrator
• Security Administrator
• SharePoint Administrator
• User Administrator

Organizations can add or remove roles based on their own needs. Note that Conditional Access policies only apply to built-in directory roles — they are not enforced against administrative unit-scoped roles or custom roles, according to Microsoft’s documentation.

Step-by-step policy creation (documented process)

Microsoft documents these steps for creating the policy in the Microsoft Entra admin center:

1. Sign in as at least a Conditional Access Administrator and go to Entra ID > Conditional Access > Policies.
2. Select New policy and give it a clear, meaningful name.
3. Under Assignments > Users or workload identities, include the Directory roles you want to cover (see the list above).
4. Under Exclude, add your organization’s emergency access (break-glass) account.
5. Under Target resources, include All resources.
6. Under Access controls > Grant, choose Grant access > Require authentication strength, and select Phishing-resistant MFA strength.
7. Set Enable policy to Report-only, then select Create.
8. After reviewing report-only results, switch Enable policy from Report-only to On.

Microsoft also notes a compatibility limitation: organizations using external authentication methods should be aware these are currently incompatible with authentication strengths, and should use the standard “Require multifactor authentication” grant control instead in that scenario.

Why exclude a break-glass account

Microsoft’s documentation explicitly recommends excluding emergency access (break-glass) accounts from this policy to prevent lockout if the policy is misconfigured. It also recommends excluding service accounts and service principals, since these noninteractive accounts aren’t tied to a specific user and Conditional Access policies scoped to users don’t block calls made by service principals; workload identity Conditional Access policies are the documented mechanism for covering those separately.

Maintaining at least one well-protected break-glass account outside the scope of this policy is a practical safeguard, not an optional nicety, if your goal is to avoid an administrative lockout scenario.

Rolling out safely: report-only mode first

Microsoft’s broader phishing-resistant deployment guidance describes a specific report-only approach for validating readiness before enforcement:

• Create the Conditional Access policy with All users, excluding break-glass accounts in scope, All resources as the target, Require Authentication Strength – Phishing-resistant MFA as the grant control, and Report-only as the enablement state.
• Create this policy early, ideally before starting user enrollment campaigns, so you build a historical dataset showing which sign-ins would have been blocked.
• Use the sign-in logs (optionally through Microsoft’s phishing-resistant passwordless workbook, if your organization exports logs to Azure Monitor) to identify which users and devices are ready for enforcement and which are not.
• Move users into enforcement incrementally as they become ready, rather than flipping enforcement on for everyone at once.

This report-only-first approach is documented Microsoft guidance, not just a cautious add-on — it’s the mechanism Microsoft describes for avoiding unexpected lockouts during rollout.

Practical recommendations for SMB admins

The following points are practical guidance based on the documented process above, rather than strict Microsoft requirements:

• Start small and specific. Given Microsoft’s persona-based approach, consider beginning with just your Global Administrator and a handful of other high-privilege roles before expanding the policy’s role list.
• Confirm registration before flipping enforcement on. Check that every in-scope admin has actually registered a phishing-resistant method (not just traditional MFA) before moving the policy out of report-only mode.
• Keep your break-glass account’s credentials outside your normal admin workflow. Since this account is excluded from the policy by design, treat its protection and monitoring as a separate, deliberate process.
• Don’t rush certificate-based authentication. Microsoft’s documentation notes that CBA is more complex to configure correctly than passkeys, requiring on-premises PKI integration and specific policy settings — it suggests using CBA only where necessary rather than as a default choice.

Conclusion

Entra ID gives SMB tenants documented, practical options for moving admin accounts away from phishable MFA methods — primarily passkeys (FIDO2) and certificate-based authentication, layered on top of the existing authentication methods policy and Conditional Access framework. The licensing bar for registration is low, but a full enforcement deployment with reporting realistically calls for Entra ID P1. The most important operational safeguard Microsoft documents is sequencing: register phishing-resistant credentials first, validate readiness using a report-only Conditional Access policy, exclude a break-glass account, and only then switch enforcement on. Following that order is what separates a successful rollout from an accidental lockout. As with any Conditional Access change, test thoroughly in report-only mode and have this draft reviewed by someone with hands-on access to your tenant before enforcing it in production.