The future is now

It has been quite apparent for a while in the industry that authentication is shifting towards passwordless solutions. This is good. Passwords should fade into the history books, having served their purpose dutifully for decades. Passwords and multi-factor authentication simply aren’t fit for purpose anymore in a modern threat landscape. Passkeys (and synced passkeys) have been available for some time, and are finally becoming common, in some cases the default for most modern, user-facing services.

So if the current status quo is insecure by design, and the technological solutions already exist, why haven’t we all gotten rid of our passwords? Good question. If I had the answers I would probably be working as a psychologist and not writing this at 10 in the evening.

What I do believe I have an answer to, however, is how we should make the right choices moving into the passwordless future.

Why passwordless is only a piece of the puzzle

Passwordless authentication through Microsoft Authenticator push notifications is fantastic from an end user perspective. You use a workflow that most people by now have ingrained into their daily routine, and eliminate the cumbersome, annoying part: remembering that pesky password you set (and forgot) 3 months ago when your company required you to complete your annual password rotation.

This sounds amazing, what is not to like? Well, the main problem is that AiTM phishing attacks are hot and trendy. No one cares about your password anymore, they want that yummy session token sitting in your browser. Passwordless (non-passkey) authentication does not protect against this type of attack. Push notification authentication is vulnerable because the adversary proxy completes the full authentication flow on your behalf and captures the resulting session cookie. No password needed (although the password is a nice bonus catch).

Two birds, one stone

If you intend to move to passwordless authentication in the near future (as you should), I would strongly recommend doing this by rolling out (and enforcing) phishing-resistant authentication methods such as device-bound passkeys and/or FIDO2 security keys. You’re already doing the heavy lifting by informing-, teaching- and changing the authentication flow for your end users. Might as well get them on the correct authentication method right-away. No double work, less user frustration, and increased security posture right away. I would dare to say you’re killing more than two birds at once (poor birds…).

For non-privileged accounts you can also consider allowing synced passkeys for a more convenient end user experience.

You’re halfway there, no need to live on a prayer

If you are mainly running Windows 11 in your environment, did you know that most (if not all) of your end users are already using phishing-resistant authentication through device-bound passkeys? If you have rolled out Windows Hello for Business, this is a phishing-resistant, device-bound authentication method.

This means you’re already halfway to running phishing-resistant authentication across the board. Your end users would only need another authentication method in the following scenarios:

• When enrolling a new machine (if you enforce this through Conditional Access)
• When adding a new authentication method or running SSPR (the latter you won’t need after passwordless is fully implemented)
• When accessing work apps from their phone

If that is the case for your team or organization, increasing your tenant security massively is a relatively straight forward job:

1. Plan and run a registration campaign for your end users to register a passkey through the Microsoft Authenticator app on their phone: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-registration-campaign
2. Create Conditional Access policies in Entra ID that enforce phishing-resistant authentication and set them to report-only mode (make sure you have break-glass accounts excluded from all CA policies before touching Conditional Access)
3. Monitor user adoption and use the Conditional Access logs from the policies you set in report-only mode to verify that your users would not get blocked
4. Roll out gradually by creating CA policies that enforce the settings, tied to an Entra ID security group where you add users in bulk (remember to switch the policy back to all users and remove the group once the rollout is complete)