In this chapter, you learned how to evaluate passwordless sign-in options for your organization and deploy the ones that best suit your needs. Some passwordless options, such as Windows Hello or FIDO2 keys, may require specialized hardware such as cameras, USB devices, or fingerprint readers, while the Microsoft Authenticator app method requires only the Microsoft Authenticator app on any supported Android or iOS-based device.

You also learned about deploying features such as self-service password reset and Azure AD password protection to further reduce administrative overhead, helping your organization comply with security policies.

In the next chapter, you’ll learn about implementing secure access in the context of Microsoft 365.

Exam Readiness Drill – Chapter Review Questions Benchmark Score: 75%

Apart from a solid understanding of key concepts, being able to think quickly under time pressure is a skill that will help you ace your certification exam. That’s why, working on these skills early on in your learning journey is key.

Chapter review questions are designed to improve your test-taking skills progressively with each chapter you learn and review your understanding of key concepts in the chapter at the same time. You’ll find these at the end of each chapter.

Before You Proceed

You need to unlock these resources before you start using them. Unlocking takes less than 10 minutes, can be done from any device, and needs to be done only once. Head over to the start of Chapter 7, Managing Security Reports and Alerts by Using the Microsoft 365 Defender Portal in this book for instructions on how to unlock them.

To open the Chapter Review Questions for this chapter, click the following link:

https://packt.link/MS102E1_Ch05. Or, you can scan the following QR code:

Figure 5.34 – QR code that opens Chapter Review Questions for logged-in users

Once you login, you’ll see a page similar to what is shown in Figure 5.35:

Figure 5.35 – Chapter Review Questions for Chapter 5

Once ready, start the following practice drills, re-attempting the quiz multiple times:

Exam Readiness Drill
For the first 3 attempts, don’t worry about the time limit.

ATTEMPT 1
The first time, aim for at least 40%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix your learning gaps.

ATTEMPT 2
The second time, aim for at least 60%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix any remaining learning gaps.

ATTEMPT 3 The third time, aim for at least 75%. Once you score 75% or more, you start working on your timing.

Tip You may take more than 3 attempts to reach 75%. That’s okay. Just review the relevant sections in the chapter till you get there.

Working On Timing

Target: Your aim is to keep the score the same while trying to answer these questions as quickly as possible. Here’s an example of how your next attempts should look like:

Table 5.4 – Sample timing practice drills on the online platform

Note
The time limits shown in the above table are just examples. Set your own time limits with each attempt based on the time limit of the quiz on the website.

With each new attempt, your score should stay above 75% while your time taken to complete should decrease. Repeat as many attempts as you want till you feel confident dealing with the time pressure.

In addition to the core options for the methods and types of multifactor authentication, Azure AD also supports a number of settings, as given in Table 5.3, to further modify the behavior of multifactor authentication. These properties are located under Azure Active Directory | Security | Multi-Factor authentication in the Azure portal:

Table 5.3 – Additional multifactor authentication settings

Investigating and Resolving Authentication Issues

Resolving authentication issues in Azure AD can be tricky due to the number of authentication methods, sign-in methods, and other configurations that may be put in place.

The first step when attempting to troubleshoot an issue is to review any available sign-in logs in the Azure portal. To locate the sign-in logs, navigate to the Azure portal (https://portal.azure. com) and then select Azure Active Directory | Sign-in logs. See Figure 5.30:

Figure 5.30 – Sign-in logs

Each authentication failure generates an individual entry. You can select an entry to see expanded details, as shown in Figure 5.31:

Figure 5.31 – Activity details

The Basic info tab displays high-level information about this particular event. The critical piece of information will typically be listed next to Failure reason, and some expanded explanation may be available in the Additional Details property. In the example shown in Figure 5.31, the reason for the failure of authentication is that the user entered an incorrect password. If the user has entered an incorrect password multiple times in a row, it may be a sign of a forgotten password or an attempted identity breach. Figure 5.32 shows the same account after it has met the smart lockout threshold:

Figure 5.32 – Sign-in detail showing locked-out account

The Location tab will show detailed information regarding the source IP address, and, if possible, resolution to a particular geographic location.

The Device info tab displays information regarding the device that was attempting a logon, such as a Windows 10 device with the Edge browser.

Note
Other browsers can also provide device information or interact with the Microsoft 365 logon process if they have the Windows Accounts extension installed. For example, Chromium-based browsers can install the Windows Accounts extension from the Chrome Web store: https://chromewebstore.google.com/detail/windows-accounts/ ppnbnpeolgkicgegkbkbjmhlideopiji.

The Authentication Details tab, shown in Figure 5.33, provides additional information regarding the authentication method, including whether the user is configured for Password Hash Sync, Federation, or Pass-through Authentication, or whether they’re using a cloud-managed identity:

Figure 5.33 – Authentication details

Finally, the last two tabs, Conditional Access and Report-only, show what policies took effect during the sign-in process. You can review these tabs for the status of Conditional Access policies, showing either what was applied or would have been applied during the logon process and how any conditions were satisfied.

Resolving an authentication issue sometimes requires examining several logs to determine the source of the error. In many cases, however, the detailed data provided on each of the tabs of an event’s activity details should provide adequate information to pinpoint the source of the error.

For most organizations, security defaults are a good choice for configuring broad baseline security policies. Security defaults make the following security changes:

• Requiring all users to register for multifactor authentication
• Requiring administrators to perform multifactor authentication upon sign-in
• Requiring users to do multifactor authentication when necessary
• Blocking basic authentication and other legacy authentication protocols
• Requiring administrators to perform multifactor authentication when accessing privileged resources, such as the Azure portal, Azure PowerShell, or the Azure CLI

Security defaults can be modified by users with the Global Administrator, Conditional Access administrator, or Security administrator roles. Security defaults can be enabled or disabled using the following process:

1. Navigate to the Azure portal (https://portal.azure.com).
2. Select Azure Active Directory.
3. Under Manage, click Properties.
4. Scroll to the bottom of the page and click Manage security defaults.
5. On the Security defaults flyout, select either Enabled or Disabled and click Save.

If you are going to configure Conditional Access policies, you should disable security defaults. If you are not going to configure Conditional Access policies, you should enable security defaults.

Further Reading
For more information on the impact of security defaults, see https://learn. microsoft.com/en-us/azure/active-directory/fundamentals/ concept-fundamentals-security-defaults.

Conditional Access

Conditional Access provides the most fine-grained control when managing the multifactor authentication requirements for your organization. Conditional Access policies can be configured from the Azure portal.

To access the Conditional Access configuration page, follow these steps:

1. Navigate to the Azure portal (https://portal.azure.com).
2. Select Azure Active Directory | Security | Conditional Access, and then choose Policies.

You can create new policies or use one of the Microsoft-provided 14 sample Conditional Access policy templates. Policies created with a template can be modified once they have been deployed to your tenant.

To configure a template-based policy, follow these steps:

1. From the Conditional Access | Policies page, as shown in Figure 5.28, select New policy from template (Preview):

Figure 5.28 – Creating a new Conditional Access policy from a template

2. Select one of the templates, such as Require multifactor authentication for all users, and click Review + create, as shown in Figure 5.29:

Figure 5.29 – Selecting a template

3. Review the settings and click Create.

Policies created through the templates cannot be modified during creation, with the exception of Enforcement mode. All template-based policies are configured in Report only mode, which can be toggled during creation. The user creating the policy is excluded from the policy to prevent accidental lockout.

After the template policies have been configured, you can edit the scope and conditions for the policy like manually created policies.

Further Reading

For more information on Conditional Access templates, see https://learn.microsoft. com/en-us/azure/active-directory/conditional-access/concept-conditional-access-policy-common.

With the exception of Windows Hello, passwordless sign-in methods (such as the Microsoft Authenticator app or FIDO2 security keys) will require users to register for multifactor authentication.

This settings area allows you to extend the custom banned password list to your on-premises infrastructure. There are two components:

• Azure AD Password Protection DC agent, which must be installed on domain controllers.
• Azure AD Password Protection proxy, which must be installed on at least one domain-joined server in the forest. As a security best practice, Microsoft recommends deploying it on a member server since it requires internet connectivity.

In this configuration, the Azure AD Password Protection proxy servers periodically retrieve the custom banned password list from Azure AD. The DC agents cache the password policy locally and validate password change requests accordingly.

If Enable password protection on Windows Server Active Directory is configured as Yes, then you can choose what mode to process password change requests. They can be processed in Audit mode (where changes or logged) or Enforced mode, where password resets are actively evaluated against the banned password list and rejected if they do not meet the requirements.

Further Reading

To view detailed steps for deploying password protection on-premises, see https://learn. microsoft.com/en-us/azure/active-directory/authentication/ concept-password-ban-bad-on-premises.

Configuring and Managing Multifactor Authentication

Configuring users for multifactor authentication can increase the security posture of your Microsoft 365 environment, in addition to protecting any apps that use Azure AD for identity and authentication. In this section, you’ll look at configuring multifactor authentication for your tenant.

Per-User Multifactor Authentication

If multifactor authentication was configured in your tenant prior to October 2019, it may have been configured using the legacy multifactor authentication scheme. Prior to newer technologies, Legacy
Azure MFA was enabled on a per-user basis by manually updating each user’s account to enforce the use of MFA.

Prior to implementing either Microsoft-managed security defaults or Conditional Access policies, you will need to disable the legacy per-user MFA. Having per-user MFA enabled while configuring a Conditional Access policy that prompts for MFA may cause unintended or unexpected MFA prompts.

Note
You should only configure one mechanism for multifactor authentication to avoid unexpected behaviors, such as users being prompted for MFA in scenarios where they previously satisfied multifactor authentication requirements or were accessing resources from trusted locations. Microsoft recommends discontinuing the use of per-user MFA and using Conditional Access policies instead.

To disable per-user multifactor authentication, follow these steps:

1. Navigate to the Microsoft 365 admin center (https://admin.microsoft.com).
2. Expand Users and select Active users.
3. Select Multi-factor authentication:

Figure 5.26 – Active users page

4. If your tenant already has Conditional Access policies, you may need to select the Legacy per-user MFA link to launch the legacy multi-factor authentication page.
5. On the multi-factor authentication page, as shown in Figure 5.27, configure the per-user MFA status to Disabled for users that have Enforced or Enabled set. You can select multiple users, but can only multi-select users that have the same MFA status type:

Figure 5.27 – Selecting users

Once per-user MFA is disabled, you can configure security defaults or Conditional Access policies.

If you have configured Azure AD Connect or Azure AD Connect Cloud sync with your organization, you can manage SSPR integration features, as shown in Figure 5.23:

Figure 5.23 – On-premises integration

It’s important to note that the Enable password write back for synced users option only modifies the behavior of Azure AD sending password reset data back to the on-premises environment, effectively stopping on-premises integration. It does not modify the on-premises Azure AD Connect configuration.

Next, you’ll look at the features of Azure AD password protection.

Implementing and Managing Azure AD Password Protection

Azure AD password protection is a set of features designed to limit the effects of common password attacks. To view the password protection configuration, navigate to Azure Active Directory | Security | Authentication methods and select Password protection. See Figure 5.24:

Figure 5.24 – Password protection

There are three groups of settings to configure:

• Custom smart lockout
• Custom banned passwords
• Password protection for Windows Server Active Directory

Let’s briefly examine each set of configurations.

Custom smart lockout

The smart lockout settings determine how Azure Active Directory handles failed login attempts. Lockout threshold is the number of times in a row a user can enter a bad password before getting locked out. By default, Lockout threshold is set to 10 in Azure Worldwide (sometimes referred to as Commercial or Public) and Azure China 21Vianet tenants, while it is set at 3 for Azure US for Government customers. Figure 5.25 depicts the error message displayed when the bad password threshold is met:

Figure 5.25 – Account lockout

Lockout duration in seconds only specifies the initial lockout duration after the lockout threshold has been reached. Each subsequent lockout increases the lockout duration. As a security mechanism, Microsoft does not publish the rate at which the duration increases.

Custom banned passwords
While Microsoft recommends moving toward passwordless authentication as a primary mechanism, passwords are still required to be configured in a number of scenarios. To help minimize using well-known, weak, or easily guessable passwords, you can choose to specify a custom list of words that you want to exclude from being used as passwords. For example, you may wish to include your organization’s name or abbreviation, products or services offered by your organization, or local sports teams.

To enable the option, slide the Enforce custom list toggle to Yes, and then add up to 1,000 banned words in the Custom banned password list text area. The list is not case-sensitive. Azure AD automatically performs common substitutions (such as 0 and o or 3 and e), so you do not need to think of all of the possible ways a word can be represented.

Enabling SSPR is a straightforward task. Like many other features in Azure AD, it can be scoped to a group of users.

To enable SSPR, follow these steps:

1. Navigate to the Azure portal (https://portal.azure.com) and select Azure Active Directory.
2. Under Manage, select Password reset.
3. On the Properties page, as shown in Figure 5.21, click Selected if you want to be able to select one or more groups to enable SSPR. Click All if you want to enable all users for SSPR:

Figure 5.21 – Enabling self-service password reset

4. Click Save.

Now that SSPR has been enabled, you can manage and configure the features.

Managing SSPR

The SSPR service has a number of configuration options, including Authentication methods, Registration settings, Notifications options, Customization portal, and On-premises integration.
Each of those options can be configured on the Password reset configuration blade of the Azure portal.

Authentication Methods
Authentication methods are used to define how a user proves their identity, such as multifactor authentication or answering security questions. The Authentication methods page lets you select which options a user can register, as well as the number of methods needed to perform a reset. See Figure 5.22:

Figure 5.22 – Authentication methods

If you choose Security questions, additional options are configurable:

• The number of questions a user must supply when they select that option
• The number of security questions they must answer to prove their identity

You can choose up to 20 security questions from a list of predefined options or create your own security questions. Administrators are unable to pre-populate or retrieve answers to end user security
questions; users must select their own questions.

Exam Tip
Using the Office phone registration option requires an Azure AD Premium license (either P1 or P2) and can be pre-populated with a phone number in Active Directory under the telephoneNumber attribute (if using Azure AD Connect to synchronize data). Other fields that can be pre-populated for SSPR include a user’s alternate email address and mobile phone number. Alternate email does not synchronize from the on-premises Active Directory and must be set using Set-AzureADUser -OtherMails, Set-MsolUser -AlternateEmailAddresses, or Set-MgUser -OtherMails.

Registration
Options on this page allow you to configure a workflow to force users to register for SSPR the first time they log in to the Microsoft 365 portal (or any other Azure AD-backed service), as well as the interval in days in which users are asked to reconfirm their details.

Notifications
The Notifications page allows you to configure options for alerting on password changes. You can select Notify users on password resets, which sends users an email when their own password is reset via SSPR. The Notify all admins when other admins reset their password setting determines whether all Global Administrators receive a notification when any Global Administrator resets their password via SSPR.

Note
SSPR can be disabled on a per-user basis. In addition, SSPR can be disabled for administrator accounts using the Update-MgPolicyAuthorizationPolicy cmdlet. For more information, see https://learn.microsoft.com/en-us/ powershell/module/microsoft.graph.identity.signins/update-mgpolicyauthorizationpolicy.

Customization
The Customization page allows you to display a custom URL or email address for support-related requests.

To enable users to sign in with FIDO2 security keys, you need to configure the authentication policy. Configuring the policy requires an account with the Global Administrator or Authentication Administrator role:

1. Navigate to the Azure portal (https://portal.azure.com).
2. Select Azure Active Directory | Security | Authentication methods and then select Policies.
3. Select Microsoft Authenticator.
4. On the Enable and Target tab of the FIDO2 security key settings page, slide the Enable toggle to On. See Figure 5.18:

Figure 5.18 – Enabling Microsoft Authenticator

5. Using the Include and Exclude tabs, specify which users the policy settings will apply to. Select the All users radio button to include all users in the policy or choose the Select groups radio button to specify which groups will be included or excluded.
6. Click Save to update the policy configuration.

The next step is to instruct users to register the security keys.

Registering Devices

Like Microsoft Authenticator-based authentication, FIDO2 authentication requires end users to register the compatible device they wish to use for authentication.

Note
In order to register a FIDO2 security key, the user must already have an Azure AD multifactor authentication method configured. If they do not have one, they must add one (such as Microsoft Authenticator or SMS). If that is not possible, an administrator can issue a Temporary Access Pass (TAP) to allow the user to complete registration. For more information on configuring a TAP, please see https://learn.microsoft.com/en-us/azure/active-directory/ authentication/howto-authentication-temporary-access-pass.

To register a FIDO2 security key, users must follow these steps:

1. Navigate to https://myprofile.microsoft.com or, from the Microsoft 365 portal, expand the profile icon and select View account:

Figure 5.19 – Accessing My account

2. Click Security Info.
3. Select Add method and click Security key.
4. Select either USB device or NFC device.
5. Ensure the key is ready and click Next.
6. In the dialog box, create and enter a PIN for the security key and then perform the required gesture (biometric/touch) to confirm.
7. Enter a Name value for the key and click Next.
8. Click Done.

After the key has been registered, users can sign in to Azure AD, Entra ID, or Microsoft 365 using their security key. At the sign-in page, after entering a username, users can select the Use Windows Hello or a security key option, which will cause the browser to issue a prompt to insert the key, as shown in Figure 5.20:

Figure 5.20 – Sign in with Windows Hello or a security key

Next, you’ll look at configuring a self-service password reset.

Implementing and Managing Self-Service Password Reset

Self-service password reset (SSPR) is a feature that allows users to change or reset passwords without administrator or service desk involvement. Self-service passwords can be configured for Azure AD cloud-only environments as well as enabling SSPR of hybrid identity through the Azure AD Connect Password Writeback feature.

To enable users to sign in with Microsoft Authenticator, you need to configure the authentication policy. The authentication policy is shared across the tenant, though different authentication methods are scoped for groups of users.

Configuring and managing the policy requires an account with the Global Administrator or Authentication Administrator role:

1. Navigate to the Azure portal (https://portal.azure.com).

Exam Tip

While the current (as of this writing) version of the exam was developed before full parity of the Entra admin center was delivered, it’s important to understand that interim exam updates may include references to the Entra admin center (https://entra.microsoft.com). Things such as menu items or configuration options are located in slightly different locations (from the left-hand menu navigation perspective), though they render the current Azure portal information in the main content window.

2. Select Azure Active Directory | Security | Authentication methods and then select Policies, as shown in Figure 5.10:

Figure 5.10 – Authentication methods

3. Select Microsoft  Authenticator.

4.    On the Enable and Target tab of the Microsoft Authenticator settingspage, slide the Enable toggle to On, as shown in Figure 5.11:

Figure 5.11 – Enabling Microsoft Authenticator

5. Using the Include and Exclude tabs, specify which users the policy settings will apply to. Select the All users radio button to include all users in the policy or choose the Select groups radio button to specify which groups will be included or excluded. Each group can have a separate Authentication mode value selected, including Any (default), Passwordless, or Push. Choosing Push as the option prevents the use of the passwordless phone sign-in credential.

6. Click Save to update the policy configuration.

After configuring the policy, users will need to register any devices to be used for passwordless authentication.

Registering Devices

Before users can log in to the service using Microsoft Authenticator, they will need to register their devices. If they’ve already registered for multifactor authentication, nothing else needs to be done.

If a user who has not registered signs in to the Microsoft 365 portal, they are greeted with aMore information required dialog as part of the sign-in process, as shown in Figure 5.12:

Figure 5.12 – More information required

During the process, they are redirected to download the Microsoft  Authenticator app, as shown in

Figure 5.13:

Figure 5.13 – Keep your account secure page

After they click Next, they are prompted to launch the Microsoft Authenticator app and add an account. Following the directions on the mobile device, they should launch a camera window that allows them to take a picture of a unique QR code, linking their device to their account, as shown in Figure 5.14:

Figure 5.14 – Registering a device

Once the device has been linked, the enrollment process will ask the user to confirm a code between the registration screen and their Microsoft Authenticator app. After completing the challenge, users should be presented with a confirmation screen, similar to the one shown in Figure 5.15:

Figure 5.15 – Authenticator registration screen

The final step for the user for full passwordless sign-in from the Microsoft Authenticator app is to configure the device itself. In Microsoft Authenticator, the user can open the app and select Enable phone sign-in, as shown in Figure 5.16:

Figure 5.16 – Microsoft Authenticator Enable phone sign-in

This will start a process to configure the device for passwordless sign-in. After configuration, the user can choose to log in with an app instead, triggering the phone authentication notification on their device. See Figure 5.17:

Figure 5.17 – Launching passwordless sign-in

The user then completes the logon challenge in the Microsoft Authenticator app to finish logging in to Microsoft 365.

Configuring FIDO2

When setting up FIDO2 -based authentication, you’ll follow a similar process as with Microsoft Authenticator—updating the authentication policy to allow the method and then instructing users to self-register their security keys.

WHFB supports cloud-only, hybrid Azure AD, and on- premises deployments. The easiest method to deploy Windows Hello is in a cloud-only model since the Microsoft 365 organization is set up for it automatically. You’ll look at that scenario in this section.

During the out-of-box experience (OOBE), users are prompted for credentials. After providing an Azure AD credential, if the Intune enrollment policy has not been configured to block WHFB, the user will be prompted to enroll with their biometric data (such as a facial scan with a compatible camera) and set a PIN.

Devices will be joined to Azure AD during the initial sign-in process and WHFB will be enabled.

If your subscription supports it, Microsoft recommends creating a WHFB policy to configure settings for your organization:

1.Navigate to the Intune admin center (https://intune.microsoft.com or https://endpoint.microsoft.com).

2. Expand Devices and, under Device enrollment, select Enroll devices, as shown in Figure 5.7:

Figure 5.7 – Enroll devices

3. Select Windows enrollment and then choose Windows Hello for Business, as shown in Figure 5.8:

Figure 5.8 – Windows Hello for Business

4. Under Assigned to, select a group (if scoping the enrollment policy to a subset of users).

5. Configure the options for Windows Hello for Business (italics options are the default settings for the enrollment policy):

• Configure Windows Hello for Business: Enabled, Disabled, Not Configured

• Use a Trusted Platform Module (TPM): Required, Preferred

• Minimum PIN length: Configure a numeric value between 4 and 127.

• Maximum PIN length: Configure a numeric value between 4 and 127.

• Lowercase letters in PIN: Not allowed, Allowed, Required

• Uppercase letters in PIN: Not allowed, Allowed, Required

• Special characters in PIN: Not allowed, Allowed, Required

• PIN expiration (days): Never, a numeric value between 1 and 730

• Remember PIN history: Never, a numeric value between 1 and 50

• Allow biometric authentication: Yes, No

• Use enhanced anti-spoofing, when available: Not configured, Yes, No

• Allow phone sign-in: Yes, No

• Use security keys for sign-in: Not configured, Enabled, Disabled

6. Click Save to update the enrollment policy.

With the policy configured, new device enrollments (for the configured user group) will receive the Windows Hello for Business setup prompt to begin enrollment, as shown in Figure 5.9:

Figure 5.9 – Windows Hello for Business enrollment

After completing enrollment, users will be able to unlock and log in to devices using supported biometrics or their PIN.

Users that are already connected to Azure AD can also trigger the Windows Hello setup wizard, by either navigating to the Account protection blade in the Windows Settings app or by pressing Win+R and entering ms-cxh://nthaad in the Run dialog box.

Next, you’ll look at configuring Microsoft  Authenticator for passwordless sign-in.

Configuring Microsoft Authenticator

The Microsoft Authenticator app provides a convenient way to sign in to any Azure AD account with a supported mobile device. Before users can sign in using the method, however, it will need to be enabled in your tenant through the authentication policy.

Physical tokens, such as the Fast Identity Online 2 (FIDO2)-based token or security key, are another passwordless option that can be used. While the Microsoft Authenticator app is a soft token, FIDO2 tokens are physical pieces of hardware that are typically either connected to the computer (in the form of a USB device) or that communicate wirelessly (via Bluetooth or NFC).

You can access the security key logon process during a browser session by selecting the Sign in with

Windows Hello or a security key option from the sign-in page, as shown in Figure 5.5:

Figure 5.5 – Passwordless authentication dialog with a FIDO2 security token

The data flow for a FIDO2-based logon follows a similar pattern as both WHFB and the Microsoft Authenticator app. For example, to log in to a device using FIDO2, this process outlined in Figure 5.6 is followed:

Figure 5.6 – FIDO2 authentication sequence

1. The user plugs in a FIDO2 security key.
2. Windows detects the security key.
3. Windows sends an authentication request to Azure AD.
4. Azure AD responds by sending a nonce back to the logon device.
5. The user authenticates to the FIDO2 key, unlocking the secure storage area containing the private key.
6. The FIDO2 key signs the nonce with the private key and sends it to Windows.
7. Windows generates a PRT request and sends it with the signed nonce to Azure AD.
8. Azure AD verifies the signed nonce with the FIDO2 device’s public key.
9. Azure AD returns the PRT to the logon device.

FIDO2, like Windows Hello, has specific requirements for supported hardware.

Supported FIDO2 Security Tokens

You can see an up-to-date list of supported FIDO2 security keys or tokens here: https:// learn.microsoft.com/en-us/azure/active-directory/authentication/ concept-authentication-passwordless#fido2-security-key-providers.

As you’ve seen from the diagrams, each of the passwordless options (Windows Hello, Microsoft Authenticator App, and FIDO2) follows a similar authentication workflow, based on public key infrastructure.

Comparison

Now that you have explored the different passwordless options available for Microsoft 365, let’s look at some information that will help you choose the appropriate solution. Table 5.1 describes some basic features and requirements for each authentication scheme.

Table 5.1 – Authentication method comparison table

It’s also important to consider the various end user scenarios that your organization utilizes to ensure you’re recommending an appropriate mechanism based on your real-world use cases. Table 5.2 describes a few example scenarios:

Table 5.2 – Passwordless logon scenarios

With that information in hand, it’s time to look at the implementation aspects.