Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID

When you deploy and operationalize phishing-resistant passwordless authentication in your environment, we recommend a user persona-based approach. Different phishing-resistant passwordless methods are more effective than others for certain user personas. This deployment guide helps you see which types of methods and rollout plans make sense for user personas in your environment. The phishing-resistant passwordless deployment approach commonly has 6 steps, which roughly flow in order, but don't have to be 100% completed before moving on to other steps:

Determine your user personas

Determine the user personas relevant for your organization. This step is critical to your project because different personas have different needs. Microsoft recommends you consider and evaluate at least 4 generic user personas in your organization.

Microsoft recommends that you broadly deploy phishing-resistant passwordless authentication across your organization. Traditionally, information workers are the easiest user persona to begin with. Don't delay rollout of secure credentials for information workers while you resolve issues that affect IT Pros. Take the approach of "don’t let perfect be the enemy of good" and deploy secure credentials as much as possible. As more users sign in using phishing-resistant passwordless credentials, you reduce the attack surface of your environment.

Microsoft recommends that you define your personas, and then place each persona into a Microsoft Entra ID group specifically for that user persona. These groups are used in later steps to roll out credentials to different types of users, and when you begin to enforce the use of phishing-resistant passwordless credentials.

Plan device readiness

Devices are an essential aspect of any successful phishing-resistant passwordless deployment, since one of the goals of phishing-resistant passwordless credentials is to protect credentials with the hardware of modern devices. First, become familiar with FIDO2 supportability for Microsoft Entra ID.

Ensure that your devices are prepared for phishing-resistant passwordless by patching to the latest supported versions of each operating system. Microsoft recommends your devices are running these versions at a minimum:

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

These versions provide the best support for natively integrated features like passkeys, Windows Hello for Business, and macOS Platform Credential. Older operating systems may require external authenticators, like FIDO2 security keys, to support phishing-resistant passwordless authentication.

Register users for phishing-resistant credentials

Credential registration and bootstrapping are the first major end-user facing activities in your phishing-resistant passwordless deployment project. This section covers the rollout of portable and local credentials.

• For new users, the registration and bootstrapping process takes a user with no existing enterprise credentials, and verifies their identity. It bootstraps them into their first portable credential, and uses that portable credential to bootstrap other local credentials on each of their computing devices. After registration, the admin may enforce phishing-resistant authentication for users in Microsoft Entra ID.
• For existing users, this phase gets users to register for phishing-resistant passwordless on their existing devices directly, or using existing MFA credentials to bootstrap phishing-resistant passwordless credentials. The end goal is the same as new users - most users should have at least one portable credential, and then local credentials on each computing device. If you're an admin who deploys phishing-resistant passwordless for existing users, then you may be able to skip ahead to the Onboarding Step 2: Bootstrapping a Portable Credential section.

Before you start, Microsoft recommends enabling passkey and other credentials for enterprise users in the tenant. If users are motivated to self-register for strong credentials, it's beneficial to allow it. At a minimum, you should enable the Passkey (FIDO2) policy so that users can register for passkeys and security keys if they prefer them.

This section focuses on phases 1-3:

Users should have at least two authentication methods registered. With another method registered, the user has a backup method available if something happens to their primary method, like when a device is lost or stolen. For example, it's a good practice for users to have passkeys registered both on their phone, and locally on their workstation in Windows Hello for Business.

Onboarding step 1: Identity verification

For remote users who haven't proven their identity, enterprise onboarding is a significant challenge. Microsoft Entra Verified ID can help customers who want high assurance ID verification. It can use attestations based on government-issued ID as a way to establish user identity trust.

In this phase, users may be directed to an identity verification partner service. They go through a proofing process determined by the organization and the verification partner service chosen by the organization. At the end of this process, users are given a Temporary Access Pass (TAP) that they can use to bootstrap their first portable credential.

Refer to the following guides to enable Microsoft Entra Verified ID onboarding and TAP issuance:

• Onboard new remote employees using ID verification
• Enable the Temporary Access Pass policy

Some organizations might choose other methods than Microsoft Entra Verified ID to onboard users and issue them their first credential. Microsoft recommends those organizations still use TAPs, or another way that lets a user onboard without a password. For example, you can provision FIDO2 security keys using Microsoft Graph API (preview).

Onboarding step 2: Bootstrap a portable credential

To bootstrap existing users to phishing-resistant passwordless credentials, first determine if your users are registered for traditional MFA already. Users with traditional MFA methods registered can be targeted with phishing-resistant passwordless registration policies. They can use their traditional MFA to register for their first portable phishing-resistant credential, and then move on to register for local credentials as needed.

For new users or users without MFA, go through a process to issue users a Temporary Access Pass (TAP). You can issue a TAP the same way you give new users their first credential, or by using Microsoft Entra Verified ID integrations. Once users have a TAP, they're ready to bootstrap their first phishing-resistant credential.

It's important for the user’s first passwordless credential to be a portable credential that can be used to authenticate on other computing devices. For example, passkeys can be used to authenticate locally on an iOS phone, but they can also be used to authenticate on a Windows PC using a cross-device authentication flow. This cross-device capability allows that portable passkey to be used to bootstrap Windows Hello for Business on the Windows PC.

It's also important that each device the user regularly works on has a locally available credential to give the user the smoothest user experience possible. Locally available credentials reduce the time needed to authenticate because users don’t need to use multiple devices, and there are fewer steps. Using the TAP from Step 1 to register a portable credential that can bootstrap these other credentials enables the user to use phishing-resistant credentials natively across the many devices they may possess.

The following table lists recommendations for different personas:

Use the following guidance to enable recommended and alternative portable credentials for the relevant user personas for your organization:

Onboarding step 3: Bootstrap local credentials on computing devices

After users have registered a portable credential, they're ready to bootstrap other credentials on each computing device they regularly use in a 1:1 relationship, which benefits their day-to-day user experience. This type of credential is common for information workers and IT pros, but not for frontline workers who share devices. Users who only share devices should only use portable credentials.

Your organization needs to determine which type of credential is preferred for each user persona at this stage. Microsoft recommends:

Use the following guidance to enable the recommended local credentials in your environment for the relevant user personas for your organization:

Persona-specific considerations

Each persona has its own challenges and considerations that commonly come up during phishing-resistant passwordless deployments. As you identify which personas you need to accommodate, you should factor these considerations into your deployment project planning. The following links have specific guidance for each persona:

• Information workers
• Frontline workers
• IT pros/DevOps workers
• Highly regulated workers

Drive usage of phishing-resistant credentials

This step covers how to make it easier for users to adopt phishing-resistant credentials. You should test your deployment strategy, plan for the rollout, and communicate the plan to end users. Then you can create reports and monitor progress before you enforce phishing-resistant credentials across your organization.

Test deployment strategy

Microsoft recommends that you test the deployment strategy created in the previous step with a set of test and pilot users. This phase should include the following steps:

• Create a list of test users and early adopters. These users should represent your different user personas, and not just IT Admins.
• Create a Microsoft Entra ID group, and add your test users to the group.
• Enable your Authentication methods policies in Microsoft Entra ID, and scope the test group to the methods that you enable.
• Measure the registration rollout for your pilot users by using the Authentication Methods Activity report.
• Create Conditional Access policies to enforce the use phishing-resistant passwordless credentials on each operating system type, and target your pilot group.
• Measure the success of the enforcement using Azure Monitor and Workbooks.
• Gather feedback from users on the success of the rollout.

Plan rollout strategy

Microsoft recommends driving usage based on which user personas are most ready for deployment. Typically, this means deploying for users in this order, but this may change depending on your organization:

1. Information workers
2. Frontline workers
3. IT pros/DevOps workers
4. Highly regulated workers

Use the following sections to create end user communications for each persona group, scope and rollout the passkeys registration feature, and user reporting and monitoring to track rollout progress.

Plan end user communications

Microsoft provides communication templates for end users. The authentication rollout material includes customizable posters and email templates to inform users about phishing-resistant passwordless authentication deployment. Use the following templates to communicate to your users so they understand the phishing-resistant passwordless deployment:

• Passwordless sign-in with Microsoft Authenticator
• Register the password reset verification method for a work or school account
• Reset your work or school password using security info
• Set up a security key as your verification method
• Sign in to your accounts using the Microsoft Authenticator app
• Sign in to your work or school account using your two-step verification method
• Work or school account sign-in blocked by tenant restrictions

Communications should be repeated multiple times to help catch as many users as possible. For example, your organization may choose to communicate the different phases and timelines with a pattern like this:

1. 60 days out from enforcement: message the value of phishing-resistant authentication methods and encourage users to proactively enroll
2. 45 days out from enforcement: repeat message
3. 30 days out from enforcement: message that in 30 days phishing-resistant enforcement will begin, encourage users to proactively enroll
4. 15 days out from enforcement: repeat message, inform them of how to contact the help desk
5. 7 days out from enforcement: repeat message, inform them of how to contact the help desk
6. 1 day out from enforcement: inform them enforcement will occur in 24 hours, inform them of how to contact the help desk

Microsoft recommends communicating to users through other channels beyond just email. Other options may include Microsoft Teams messages, break room posters, and champion programs where select employees are trained to advocate for the program to their peers.

Reporting and monitoring

Microsoft Entra ID reports (such as Authentication Methods Activity and Sign-in event details for Microsoft Entra multifactor authentication) provide technical and business insights that can help you measure and drive adoption.

From the Authentication methods activity dashboard, you can view registration and usage.

• Registration shows the number of users capable of phishing-resistant passwordless authentication, and other authentication methods. You can see graphs that show which authentication methods users registered, and recent registration for each method.
• Usage shows which authentication methods were used for sign-in.

Business and technical application owners should own and receive reports based on organization requirements.

• Track phishing-resistant passwordless credentials rollout with Authentication Methods registration activity reports.
• Track user adoption of phishing-resistant passwordless credentials with Authentication Methods sign in activity reports and sign in logs.
• Use the sign-in activity report to track the authentication methods used to sign in to the various applications. Select the user row; select Authentication Details to view authentication method and its corresponding sign-in activity.

Microsoft Entra ID adds entries to audit logs when these conditions occur:

• An administrator changes authentication methods.
• A user makes any kind of change to their credentials within Microsoft Entra ID.

Microsoft Entra ID retains most auditing data for 30 days. We recommend longer retention for auditing, trend analysis, and other business needs.

Access auditing data in the Microsoft Entra admin center or API and download into your analysis systems. If you require longer retention, export and consume logs in a Security Information and Event Management (SIEM) tool, such as Microsoft Sentinel, Splunk, or Sumo Logic.

Monitor help desk ticket volume

Your IT help desk can provide an invaluable signal on how well your deployment is progressing, so Microsoft recommends tracking your help desk ticket volume when executing a phishing-resistant passwordless deployment.

As your help desk ticket volume increases you should slow down the pace of your deployments, user communications, and enforcement actions. As the ticket volume decreases you can ramp these activities back up. Using this approach requires that you maintain flexibility in your rollout plan.

For example, you could execute your deployments and then enforcements in waves that have ranges of dates rather than specific dates:

1. June 1st-15th: Wave 1 cohort registration deployment and campaigns
2. June 16th-30th: Wave 2 cohort registration deployment and campaigns
3. July 1st-15th: Wave 3 cohort registration deployment and campaigns
4. July 16th-31st: Wave 1 cohort enforcement enabled
5. August 1st-15th: Wave 2 cohort enforcement enabled
6. August 16th-31st: Wave 3 cohort enforcement enabled

As you execute these different phases, you may need to slow down depending on the volume of help desk tickets opened and then resume when the volume has subsided. To execute on this strategy, Microsoft recommends that you create a Microsoft Entra ID security group for each wave, and add each group to your policies one at a time. This approach helps to avoid overwhelming your support teams.

Enforce phishing-resistant methods for sign-in

This section focuses on phase 4.

The final phase of a phishing-resistant passwordless deployment is enforcing the use of phishing-resistant credentials. The primary mechanism for doing this in Microsoft Entra ID is Conditional Access authentication strengths. Microsoft recommends you approach enforcement for each persona based on a user/device pair methodology. For example, an enforcement rollout could follow this pattern:

1. Information workers on Windows and iOS
2. Information workers on macOS and Android
3. IT Pros on iOS and Android
4. FLWs on iOS and Android
5. FLWs on Windows and macOS
6. IT Pros on Windows and macOS

Microsoft recommends that you build a report of all your user/device pairs by using sign-in data from your tenant. You can use querying tools like Azure Monitor and Workbooks. At minimum, try to identify all user/device pairs that match these categories.

For each user, create a list of which operating systems they regularly use for work. Map the list to the readiness for phishing-resistant sign-in enforcement for that user/device pair.

¹For each user/device pair where the device version isn't immediately ready for enforcement, determine how to address the need to enforce phishing-resistance. Consider the following options for older operating systems, virtual desktop infrastructure (VDI), and other operating systems such as Linux:

• Enforce phishing-resistance using external hardware – FIDO2 security keys
• Enforce phishing-resistance using external hardware – smart cards
• Enforce phishing-resistance using remote credentials, such as passkeys in the cross-device authentication flow
• Enforce phishing-resistance using remote credentials inside of RDP tunnels (especially for VDI)

The key task is to measure through data which users and personas are ready for enforcement on particular platforms. Begin your enforcement actions on user/device pairs that are ready for enforcement to "stop the bleeding," and reduce the amount of phishable authentication occurring in your environment.

Then move on to other scenarios where the user/device pairs require readiness efforts. Work your way through the list of user/device pairs until you enforce phishing-resistant authentication across the board.

Create a set of Microsoft Entra ID groups to roll out enforcement gradually. Reuse the groups from the previous step if you used the wave-based rollout approach.

Target each group with a specific Conditional Access policy. This approach helps you roll out your enforcement controls gradually by user/device pair.

Add each user to each group as you determine whether their device and operating system is ready, or they don’t have a device of that type. At the end of the rollout, each user should be in one of the groups.

Respond to risk for passwordless users

Microsoft Entra ID Protection helps organizations detect, investigate, and remediate identity-based risks. Microsoft Entra ID Protection provides important and useful detections for your users even after they switch to using phishing-resistant passwordless credentials. For example, some relevant detections for phishing-resistant users include:

• Activity from anonymous IP address
• Admin confirmed user compromised
• Anomalous Token
• Malicious IP address
• Microsoft Entra threat intelligence
• Suspicious browser
• Attacker in the middle
• Possible attempt to access Primary Refresh Token (PRT)
• And others: Risk detections mapped to riskEventType

Microsoft recommends that Microsoft Entra ID Protection customers take the following actions to best protect their phishing-resistant passwordless users:

1. Review the Microsoft Entra ID Protection deployment guidance: Plan an ID Protection deployment
2. Configure your risk logs to export to a SIEM
3. Investigate and act on any medium user risk
4. Configure a conditional access policy to block high risk users

After you deploy Microsoft Entra ID Protection, consider using Conditional Access token protection. As users sign in with phishing-resistant passwordless credentials, attacks and detections continue to evolve. For example, when user credentials can no longer be easily phished, attackers may move on to try to exfiltrate tokens from user devices. Token protection helps mitigate this risk by binding tokens to the hardware of the device they were issued to.

Next steps

Considerations for specific personas in a phishing-resistant passwordless authentication deployment in Microsoft Entra ID