Microsoft Entra makes passwordless registration easier, but what does this mean for Zero Trust?

Microsoft Entra makes passwordless registration easier, but what does this mean for Zero Trust? Let's discuss..

Microsoft recently published a message in the message center that covers details on Windows Hello for Business and macOS Platform SSO supporting standalone MFA factors. It is well established that Passwordless authentication is becoming the default approach for modern identity security. Windows Hello for Business (WHfB), passkeys, FIDO2 and macOS Platform SSO (PSSO) all provide stronger authentication while reducing our dependency on passwords. And with this new change, Microsoft has now made passwordless registration in Entra ID easier, including bringing register security information further into the conditional access model. However, this does raise an interesting question:

If passwordless authentication is strong enough to authenticate the user, do we still need MFA?

In my personal opinion, it is still necessary, but not necessarily in the way we traditionally think about MFA. Keep reading to see why..

What has changed?

Passwordless registration has historically involved a number of configuration and bootstrap steps. Organisations would typically use MFA registration, conditional access, authentication method policies and then configure WHfB, FIDO2 or other passwordless methods.

The problem has always been the bootstrap process and this is where things are going to change.

The current process involves WHfB and macOS PSSO being able to satisfy MFA requirements during primary sign-in, but users may still be required to register and use an additional passkey or authentication method for certain step-up authentication prompts, Authentication Strength policies, and sign-in frequency checks depending on how the conditional access policies are enforced.

Microsoft's newer approach makes this registration experience simpler while still allowing organisations to protect security information registration using conditional access. Users who authenticate with WHfB or macOS PSSO, will be able to satisfy supported MFA requirements without registering an additional passkey.

This is important because registering an authentication method is itself a security-sensitive operation. Think of it this way, if an attacker can register their own credential against an Entra identity, they have effectively created a new authentication path into the organisation.

Are lines getting blurry between authentication & identity verification?

Passwordless doesn't remove identity verification, but it is important to distinguish identity verification from authentication.

Passwordless authentication answers:

Can this person demonstrate control of an authorised credential?

Identity verification asks:

How did we establish that this person is legitimately entitled to that identity and credential?

Now we know that WHfB, passkeys and PSSO can provide very strong, phishing-resistant authentication, but when that credential is initially established, replaced or recovered, we still need confidence that the correct person is performing the operation.

This is where I believe MFA continues to have a role.

Not necessarily as something the user must perform on every sign-in, but as part of the process of establishing sufficient identity assurance.

With the device being an important signal, Intune compliance, Defender risk and Entra device identity can tell us a lot about the security posture of the endpoint. However, just a compliant device isn't the objective of Zero Trust.

The access decision

The ultimate objective is protecting the resource and data. A useful way of thinking about the access decision is:

User identity + Authentication strength + Device state + Risk + Context + Resource sensitivity = Access decision

This is because the same user, with the same passwordless credential, may receive different access depending on what they are trying to access.

For example, an information worker with a dedicated corporate device, the model becomes very compelling:

Identity verification → WHfB/PSSO → phishing-resistant authentication → device/risk evaluation → Conditional Access → Access

This is where passwordless works particularly well. The user doesn't need to enter a password and may not need a traditional MFA challenge every time they access corporate resources. But shared-device and frontline scenarios are different. 

WHfB is designed particularly well around the relationship between a user and their Windows device, and Microsoft supports up to 10 users enrolled on a Windows device. For scenarios with more users, Microsoft recommends considering FIDO2 security keys. This means the authentication architecture needs to reflect the relationship between the user, credential and device. In other words..

For a dedicated device, WHfB or PSSO can be an excellent fit. However, for highly shared devices, FIDO2 or shared-device capabilities may be more appropriate.

Personally, I would place emphasis on strong verification during identity and credential lifecycle events, such as:

• Initial identity and passwordless credential registration
• Registering a new device
• Replacing a lost device
• Recovering an account
• Resetting or replacing authentication methods
• Registering a new authentication method
• Accessing particularly sensitive resources where policy requires additional assurance

The important thing to note here is that the objective isn't to make users perform MFA unnecessarily, but it is to make sure that the person establishing or changing a trusted credential is actually entitled to do so.

Final thoughts

Organization should absolutely adopt Microsoft's simpler passwordless registration experience and move users towards phishing-resistant authentication. However, I wouldn't interpret passwordless as a reason to remove explicit identity verification. Instead, I would change the role of MFA. Use strong verification when establishing or changing identity credentials, and use passwordless authentication for normal authentication afterwards. Then use conditional access and other signals to make the access decision. Decisions like -

Who is the user?

How strongly have they authenticated?

What is the state and risk of the device?

What application and resource are they accessing?

How sensitive is the data?

That is a much more meaningful Zero Trust model than simply asking whether the user or device is "trusted". Passwordless should reduce passwords and unnecessary authentication friction, but it shouldn't remove the concept of explicit verification.

Until next time..