Safeguarding Microsoft Entra ID with passwordless authentication methods – Part 4: Enablement

This is part 4 of 4 part series. If you haven’t read previous parts of the blog series, I suggest reading them first: go to part 1

Not all authentication methods are created equal. Microsoft Digital Defense report from 2023 lists multi-factor authentication as one of five key protection controls against cyber attacks. As leaks like recent Okta and LastPass breaches are becoming more and more common, authenticating with password alone seems absurd to me. Even if it’s a really good one. I would take authentication safeguarding a step further by removing weak authentication methods altogether. This is the third part of series. Let’s start!

Setting the goal

We’ve covered many aspects of passwordless authentication in our preceding posts. In this post we will outline how to enable passwordless authentication methods in our organization, what options do we have for enforcing it and couple of tips to enhance authentication security.

How to enable passwordless authentication?

To enable passwordless authentication in Microsoft Entra portal go to Protection > Authentication methods > Policies

Notice that these settings here will enable the use of these passwordless authentication methods, but it will not mean that they are immediately enforced upon users. In order to use FIDO2 passkeys or Microsoft Authenticator Phone Sign-in the user must register their passkey or phone and go through initial setup. Certificate-based authentication (CBA) is a different type of service and it requires existence of Public Key Infrastructure. CBA needs to be enabled and configured by administrator.

FIDO2 security key

• Switch on Enable. Target all users or specific groups. We can also exclude specific groups (but not users). Once completed we go to Configure tab.

• Keep Allow self-service set up so that user can register passkeys in MySecurityInfo page themselves.
• Enforce attestation setting will enforce the passkey metadata to be published and verified with the FIDO Alliance Metadata Service (MDS). FIDO keeps a database of certified passkey vendors and their passkey device models, the certification level of devices and also found security issues. If our industry requires a certain certification level we have to turn this on. Recommendation is to turn this on as it will only be beneficial.
• We don’t want to turn on Enforce key restrictions unless we want to restrict the usage of passkeys to specific passkeys. If we would turn this on, we could choose to either allow or block specific keys using their Authenticator Attestation GUID (AAGuid). AAGUID is a 128-bit identifier that tells the key type, make and model.
  • To find the AAGUID of a key that has been already registered, we go to Security Info page and expand the Security key row.
• That’s it! Users can now register passkeys at https://aka.ms/mysecurityinfo and start using them during their login.

Microsoft Authenticator Phone Sign-in

We need to enable Microsoft Authenticator app method if that is not already done.

• Switch on Enable. Recommendation is to target all users, but we can narrow the scope to specific users or groups if we like. Same exclusions are available as what we went through with Security key setup.
• Authentication mode defines if users are able to use push notification (Push), phone sign-in (Passwordless) or both (Any). We will leave the mode to Any.

• From Configure view number matching has been enforced by Microsoft to all users. I recommend to enable application name and geographic location also for better context.
• Allow use of Microsoft Authenticator OTP allows users to use the six-digit one-time passcodes from Authenticator app. In my tenant I have completed the authentication method migration and decided to opt-out of this option as no one was using it. If you have it enabled in the legacy methods controls, and you haven’t completed the migration, you should enable this.

• Microsoft Authenticator on companion applications aka Microsoft Authenticator Lite is a feature of Outlook mobile app. If our users are using Authenticator app we don’t need to enable this. User having Microsoft Authenticator app cannot enable Authenticator Lite on Outlook mobile on same device.

First prerequisite for using the phone sign-in is that the mobile device must be registered with the tenant. Here’s how to do it.

• We open Microsoft Authenticator app and go to menu and open Settings

• We select Device Registration

• This view shows our current registrations. To add a new one we select + on the top right corner

• Fill in email address and click Register device

We have now registered our mobile device with our tenant and our device is now visible in Entra ID devices.

To enable phone sign-in we still have to enable it.

• From Microsoft Authenticator app choose our account
• We choose Enable phone sign-in

• When our device is ready for phone sign-in we should see two green checkmarks. Select Continue

• We will be asked to complete a sign-in, and if our tenant requires MFA to register devices we’re asked to complete that also.
• Once we’re done we go back to our account view in Microsoft Authenticator app and we should now see Disable phone sign-in, hence meaning that the phone sign-in is enabled.

We have now enabled phone sign-in!

Certificate-based Authentication

CBA relies on existing PKI which is outside the scope of this blog. We will settle for outlining the high-level steps to enable CBA:

1. Configure the certification authorities in Microsoft Entra portal by going to Protection > Security Center > Certificate authorities and uploading at least root and one intermediate certificates
2. Enable CBA on the tenant by going to Protection > Authentication methods > Policies and enable Certificate-based authentication
3. Configure authentication binding policy and username binding policy from the same view but switching to Configure tab
4. Test your configuration

The work for setting up CBA is not trivial and requires understanding and experience of certificates. Once CBA has been enabled and configured users should be able to choose Use certificate or smart card during login and then choosing the certificate to complete the authentication.

Windows Hello for Business

As this post is already quite long I decided to make a dedicated post for Windows Hello for Business deployment. Once that has been published, I will add a link to the post here.

How to enforce passwordless authentication?

There is no way to remove user’s password, but we now have Conditional Access and Authentication Strengths. With Authentication Strengths we can limit the authentications methods we allow users to use when logging in to specific apps or from untrusted locations for example. First we need to enable passwordless methods and allow users to start registering those methods. Passwordless methods will satisfy both first and second factors. We’ll achieve this by creating conditional access policy and configuring it with authentication strength which requires users to use passwordless methods.

Authentication security enhancing tips for organizations not yet ready for passwordless

Tip 1 – Disable legacy MFA & SSPR policies

Have you migrated your legacy MFA and SSPR policy setting to unified authentication methods policies? If not, you should plan to do that soon. Deprecation date is not your worst enemy here, but clarity of operational management and user experience is. To start planning read my blog post about the migration and Microsoft guide. By migrating, you’ll give yourself an opportunity to dump some of the weaker authentication methods and adopt better ones, all the while making the management easier with single pane of glass for controls.

Tip 2 – Adopt system-preferred multi-factor authentication

If our organization is not ready for passwordless-only, but we would like to ensure that our users are using those more secure multi-factor authentication methods we should enable system-preferred multi-factor authentication. System-preferred MFA will make sure that the user is prompted with the most secure method they have registered. This helps users to get accustomed to the more secure methods rather then the weaker ones. I recommend starting with a pilot group and monitoring the user experience and feedback, before enabling it organization wide.

The order of methods from most secure to least secure is:

1. Temporary Access Pass
2. FIDO2 security key
3. Microsoft Authenticator notifications
4. Time-based one-time password (TOTP) (Includes hardware or software TOTP from Microsoft Authenticator, Authenticator Lite, or third-party applications)
5. Telephony (Voice and SMS)
6. Certificate-based authentication (CBA)

Microsoft has put CBA on the bottom of the list because of known issues with system-preferred multi-factor authentication.

Tip 3 – Users resisting company appointed authenticator apps on personal devices

There is a lot of talk on the forums about some users not wanting to install anything work-related on their personal mobile devices, which unfortunately keeps voice and SMS authentication methods still relevant. It is an issue that is very hard to overcome. Microsoft Authenticator, while not being phishing-resistant yet, has become a standard of some kind for strong second factor authentication. Purchasing a separate work mobile for those users might quickly become a large expense item as those also need to be managed properly since they are company owned. Passkeys have less maintenance overhead are more portable then mobile devices and in most cases they are cheaper as well. You should consider this option for users who are resisting Authenticator app. In some rare cases I’ve seen a user resisting the Microsoft Authenticator app, but being okay to use 3^rd party authenticator. If this is the case maybe they are okay with using the Outlook mobile app with Authenticator Lite feature?

This issue is of course work culture related, as there may be parts of the world where the employee does not get a say if they WANT to use company appointed authenticator application. I’m believer that we should be able to respect users that want to keep their personal devices clean from work related data and access and provide other options.

Summary

In this post we went through how to enable and enforce authentication methods. This is the final part of the Safeguarding Microsoft Entra ID with passwordless authentication methods blog series.

While writing this series, Microsoft Authenticator Passkeys was published in public preview. This will be one of the upcoming topics I will address.

Stay secure!