Complete a passwordless authentication deployment

A majority of cyberattacks begin with a username and password stolen from someone in an organization.

Organizations try to counter the threat by requiring users to use:

  • Long passwords
  • Complex passwords
  • Frequent password changes
  • Multi-factor authentication (MFA)

Microsoft’s research shows that these efforts annoy users and drive up support costs. For more information, see Your Pa$$word doesn’t matter.

Deploying passwordless authentication provides the following benefits:

  • Increased security. Reduce the risk of phishing and password spray attacks by removing passwords as an attack surface.
  • Better user experience. Give users a convenient way to access data from anywhere, and provide easy access to Outlook, OneDrive, office, and more while mobile.
  • Robust insights. Gain insights into users passwordless activity with robust logging and auditing.

The password is replaced with something you have plus something you are or something you know. For example, in Windows Hello for Business a biometric gesture, like a face or fingerprint, or a device-specific PIN that isn't transmitted over a network.

Microsoft offers three passwordless authentication options that cover many scenarios. These methods can be used in tandem.

  • Windows Hello for Business is best for users on their dedicated Windows computers.
  • Security key sign in with FIDO2 Security keys is especially useful for users who sign in to shared machines like kiosks, situations where use of phones is restricted, and for highly privileged identities.
  • Phone sign in with the Microsoft Authenticator app is useful for providing a passwordless option to users with mobile devices. It turns any iOS or Android phone into a strong, passwordless credential by allowing users to sign into any platform or browser. Users sign in by getting a notification to their phone, matching a number displayed on the screen to the one on their phone and then using their biometric data or PIN to confirm.

Compare passwordless authentication methods

Microsoft’s passwordless authentication methods enable different scenarios. Consider your organizational needs, prerequisites, and the capabilities of each authentication method to select your passwordless authentication strategy. We recommend that every organization that uses Windows 10 devices use Windows Hello for Business. Then, add either phone sign in (with the Microsoft Authenticator app) or security keys for additional scenarios.

Passwordless authentication scenarios

Scenario Phone authentication Security keys Windows Hello for Business
Computer sign in:
From assigned Windows 10 device
No Yes
With biometric, PIN
with biometric recognition and or PIN
Computer sign in:
From shared Windows 10 device
No Yes
With biometric, PIN
Web app sign in:
‎ from a user-dedicated computer
Yes Yes
Provided single sign-on to apps is enabled by computer sign in
Provided single sign-on to apps is enabled by computer sign in
Web app sign in:
from a mobile or non-windows device
Yes No No
Computer sign in:
Non-Windows computer
No No No

Technical considerations for the Microsoft Authenticator app

AD FS Integration - When a user enables the Microsoft Authenticator passwordless credential, authentication for that user defaults to sending a notification for approval. Users in a hybrid tenant are prevented from being directed to ADFS for sign in unless they select “Use your password instead.” This process also bypasses any on-premises Conditional Access policies, and Pass-through authentication flows. However, if a login_hint is specified, the user will be forwarded to ADFS and bypass the option to use the passwordless credential.

Azure MFA server - End users enabled for MFA through an organization’s on-premises Azure MFA server can still create and use a single passwordless phone sign in credential. If the user attempts to upgrade multiple installations (5+) of the Microsoft Authenticator with the credential, this change may result in an error.

Device Registration - To use the Authenticator app for passwordless authentication, the device must be registered in the Azure AD tenant and can't be a shared device. A device can only be registered in a single tenant. This limit means that only one work or school account is supported for phone sign in using the Authenticator app.


Organizations must meet the following prerequisites before beginning a passwordless deployment.

Prerequisite Authenticator app FIDO2 Security Keys
Combined registration for Azure MFA and self-service password reset (SSPR) is enabled (preview feature)
Users are able to perform Azure MFA
Users have registered for Azure MFA and SSPR
Users have registered their mobile devices to Azure Active Directory
Windows 10 version 1809 or higher using a supported browser like Microsoft Edge or Mozilla Firefox
(version 67 or higher).
Microsoft recommends version 1903 or higher for native support.
Compatible FIDO2 security keys. Ensure that you’re using a Microsoft-tested and verified FIDO2 security device, or other compatible FIDO2 security device.

Prerequisites for Windows Hello for Business

The prerequisites for Windows Hello are highly dependent on whether you’re deploying in an on-premises, hybrid, or cloud-only configuration. For more information, see the full listing of prerequisites for Windows Hello for Business.

Azure Multi-Factor Authentication

Users register their passwordless method as a part of the Azure MFA registration flow. Multi-factor authentication with a username and password along with another registered method can be used as a fallback in case they can't use their phone or security key in some scenarios.

Security key lifecycle

Security keys enable access to your resources, and you should plan the management of those physical devices.

  1. Key distribution: Plan how you’ll provision keys to your organization. You may have a centralized provisioning process or allow end users to purchase FIDO 2.0-compatible keys.
  2. Key activation: End users must self-activate the security key. End users register their security keys at and enable the second factor (PIN or biometric) at first use.
  3. Disabling a key: While security key functionality is in the preview stage, there's no way for an administrator to remove a key from a user account. The user must remove it. If a key is lost or stolen:
    1. Remove the user from any group enabled for passwordless authentication.
    2. Verify they've removed the key as an authentication method.
    3. Issue a new key.
  4. Key replacement: Users can enable two security keys at the same time. When replacing a security key, ensure the user has also removed the key being replaced.

Enable Windows 10 support

Enabling Windows 10 sign in using FIDO2 security keys requires enabling the credential provider functionality in Windows 10. Enable it in one of two ways:

Register security keys

Users must register their security key on each of their Azure Active Directory Joined Windows 10 machines.

For more information, see User registration and management of FIDO2 security keys.

Licensing for passwordless authentication

There's no additional cost for passwordless authentication, although some prerequisites may require a premium subscription. See detailed feature and licensing information in the Azure Active Directory licensing page.

Develop a plan

Consider your business needs and the use cases for each authentication method. Then select the method that best fits your needs.

Use cases

The following table outlines the use cases to be implemented during this project.

Area Description
Access Passwordless sign in is available from a corporate or personal device within or outside the corporate network.
Auditing Usage data is available to administrators to audit in near real time.
Usage data is downloaded into corporate systems at least every 29 days, or SIEM tool is used.
Governance Lifecycle of user assignments to appropriate authentication method and associated groups is defined and monitored.
Security Access to appropriate authentication method is controlled via user and group assignments.
Only authorized users can use passwordless sign in.
Performance Access assignment propagation timelines are documented and monitored.
Sign in times is measured for ease of use.
User Experience Users are aware of mobile compatibility.
Users can configure the Authenticator app passwordless sign in.
Support Users are aware of how to find support for passwordless sign in issues.

Engage the right stakeholders

When technology projects fail, it's typically because of mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, ensure that you’re engaging the right stakeholders and that stakeholder roles in the project are well understood.

Organization communications

Communication is critical to the success of any new service. Proactively communicate how users' experience will change, when it will change, and how to gain support if they experience issues.

Your communications to end users will need to include:

Microsoft provides MFA communication templates, Self-Service Password Reset (SSPR) communication templates, and end-user documentation to help draft your communications. You can send users to to register directly by selecting the Security Info links on that page.

Testing passwordless

At each stage of your deployment, ensure that you’re testing that results are as expected.

Testing the Microsoft Authenticator app

The following are sample test cases for passwordless authentication with the Microsoft Authenticator app

Scenario Expected results
User can register Microsoft Authenticator app User can register app from
User can enable phone sign in Phone sign in configured for work account
User can access an app with phone sign in User goes through phone sign in flow and reaches designated application.
Test rolling back phone sign in registration by turning off Microsoft Authenticator passwordless sign in within the Authentication methods screen in the Azure Active Directory portal Previously enabled users unable to use passwordless sign in from Microsoft Authenticator.
Removing phone sign in from Microsoft Authenticator app Work account no longer available on Microsoft Authenticator

Testing security keys

The following are sample test cases for passwordless authentication with security keys.

Passwordless FIDO sign in to Azure Active Directory Joined Windows 10 devices

Scenario Expected results
The user can register FIDO2 device (1809) User can register FIDO2 device using at Settings > Accounts > sign in options > Security Key
The user can reset FIDO2 device (1809) User can reset FIDO2 device using manufacturer software
The user can sign in with FIDO2 device (1809) User can select Security Key from sign in window, and successfully sign in.
The user can register FIDO2 device (1903) User can register FIDO2 device at Settings > Accounts > sign in options > Security Key
The user can reset FIDO2 device (1903) User can reset FIDO2 device at Settings > Accounts > sign in options > Security Key
The user can sign in with FIDO2 device (1903) User can select Security Key from sign in window, and successfully sign in.

Passwordless FIDO sign in to Azure AD web apps

Scenario Expected results
The user can register FIDO2 device at using Microsoft Edge Registration should succeed
The user can register FIDO2 device at using Firefox Registration should succeed
The user can sign in to OneDrive online using FIDO2 device using Microsoft Edge Sign in should succeed
The user can sign in to OneDrive online using FIDO2 device using Firefox Sign in should succeed
Test rolling back FIDO2 device registration by turning off FIDO2 Security Keys within the Authentication methods blade in the Azure Active Directory portal Users will be prompted to sign in using their security key, it will successfully log them in and an error will be displayed: “Your company policy requires that you use a different method to sign in”. Users should then be able to select a different method and successfully sign in. Close the window and sign in again to verify they do not see the same error message.

Auditing passwordless

Azure AD has reports that provide technical and business insights. Have your business and technical application owners assume ownership of and consume these reports based on your organization’s requirements.

The Authentication methods section within the Azure Active Directory portal is where administrators can enable and manage settings for passwordless credentials.

Azure AD adds entries to the audit logs when:

  • An admin makes changes in the Authentication methods section.
  • A user makes any kind of change to their credentials within Azure Active Directory.

The table below provides some examples of typical reporting scenarios.

Manage risk Increase productivity Governance and compliance
Report types Authentication methods- users registered for combined security registration Authentication methods – users registered for app notification Sign-ins: review who is accessing the tenant and how
Potential actions Target users not yet registered Drive adoption of Microsoft Authenticator app or security keys Revoke access or enforce additional security policies for admins

Azure AD retains most auditing data for 30 days and makes the data available via Azure Admin Portal or API for you to download into your analysis systems. If your organization requires longer retention, the logs need to be exported and consumed into a SIEM tool such as Azure Sentinel, Splunk, or Sumo Logic. Learn more about viewing your access and usage reports.

Users can register and manage their credentials by navigating to This link directs users to the end-user credential management experience that was enabled via the combined SSPR/MFA registration experience. Any registration of FIDO2 security devices or changes to authentication methods by a user are logged in the Azure Active Directory audit logs.

When users enable or disable the account on a security key, or reset the second factor for the security key on their Windows 10 machines, an entry is added to security log and are under the following event IDs: 4670, 5382.

Plan for rollback

Though passwordless authentication is a lightweight feature with minimal impact on end users, it may be necessary to roll back.

Rolling back requires the administrator to sign in to the Azure Active Directory portal, select the desired strong authentication methods, and change the enable option to ‘No’. This process will turn off the passwordless functionality for all users.

Users that have already registered FIDO2 security devices will be prompted to use the security device at their next sign in, and will then see the following error:

choose a different way to sign in

Plan to pilot

When you deploy passwordless authentication, you should first enable one or more pilot groups. You can create groups specifically for this purpose. Add the users who will participate in the pilot to the groups. Then, enable new passwordless authentication methods for the selected groups.

Groups can be synced from an on-premises directory, or from Azure AD. Once you’re happy with the results of your pilot, you can switch on the passwordless authentication for all users.

See Best practices for a pilot on the deployment plans page.

Deploy passwordless authentication

Follow the steps aligned to your chosen method below.

Required administrative roles

Azure AD Role Description
Authentication Administrator Least privileged role able to implement and manage authentication methods
User Least privileged role to configure Authenticator app on device, or to enroll security key device for web or Windows 10 sign in.

Deploy Phone sign in with the Microsoft Authenticator app

Follow the steps in the article, Enable passwordless sign-in with the Microsoft Authenticator app to enable the Microsoft Authenticator app as a passwordless authentication method in your organization.

Deploy FIDO2 security key sign in

Follow the steps in the article, Enable passwordless security key sign in for Azure AD to enable FIDO2 security keys as passwordless authentication methods in your organization.

Troubleshoot phone sign in

Scenario Solution
User cannot perform combined registration Ensure combined registration is enabled.
User cannot enable phone sign in authenticator app Ensure user is in scope for deployment
User is NOT in scope for passwordless authentication, but is presented with passwordless sign in option, which they cannot complete. This scenario occurs when the user has enabled phone sign in n the application prior to the policy being created.
To enable sign in: Add the user to the scope of users enabled for passwordless sign in.
To block sign in: have the user remove their credential form that application.

Troubleshoot security key sign in

Scenario Solution
User cannot perform combined registration Ensure combined registration is enabled.
User cannot add a security key in their security settings Ensure that security keys are enabled.
User cannot add security key in Windows 10 sign in options Ensure that security keys for Windows sign in
Error message: We detected that this browser or OS does not support FIDO2 security keys. Passwordless FIDO2 security devices can only be registered in supported browsers (Microsoft Edge, Firefox version 67) on Windows 10 version 1809 or higher.
Error message: Your company policy requires that you use a different method to sign in. Unsure security keys are enabled in the tenant.
User unable to manage my security key on Windows 10 version 1809 Version 1809 requires that you use the security key management software provided by the FIDO2 key vendor. Contact the vendor for support.
I think my FIDO2 security key may be defective—how can I test it Navigate to, enter credentials for a test account, plug in the suspect security key, click the “+” button at the top right of the screen, click create, and go through the creation process. If this scenario fails, your device may be defective.

Next steps