26 August 2026

 

Anyone who has approved a workplace login through the Microsoft Authenticator app has probably encountered Microsoft Entra ID, even if they have never heard the name.

Entra ID is the identity and access management system behind many Microsoft 365 accounts and other workplace applications. It helps organisations determine who may access Outlook, Teams and corporate systems, and whether a user must enter a password, approve an Authenticator notification or use another form of verification.

Microsoft is now making passkeys the default phishing resistant credential for Entra ID. From 1 September 2026, users who have SMS or voice authentication enabled will be automatically enabled and prompted to register a passkey when signing in with multifactor authentication.

The company plans to stop providing SMS and voice authentication itself on 1 February 2027. Organisations with regulatory, technical or operational reasons to retain these methods will be able to obtain them through third party telecom providers in the Microsoft Security Store.

For employees, the transition may look like little more than a new instruction on a familiar Microsoft sign in screen. Instead of entering a password or copying a code from a text message, they may sign in using Microsoft Authenticator, Windows, their phone’s credential manager or a physical security key.

One distinction is important. Approving a conventional push notification in Microsoft Authenticator is not necessarily the same as using a passkey. The app supports several authentication methods. A passkey stored in Authenticator is a cryptographic credential bound to that particular device and cannot be synchronised to another one.

Behind this apparently small change is a fundamentally different way of proving identity. Passwords depend on secrets that people must remember and websites must recognise. Passkeys use public key cryptography and a trusted device.

Microsoft is far from alone. Google supports passkeys through Android, Chrome and Google Password Manager, while Apple synchronises them across devices through iCloud Keychain. Passkeys are based on open standards from the FIDO Alliance and World Wide Web Consortium, allowing websites, operating systems, browsers and credential managers to use the same underlying approach.

 

How do passkeys work?

 

A passkey replaces a password with a pair of cryptographic keys.

When someone creates a passkey, their device or credential manager generates two mathematically connected keys. The public key is registered with the website or online service. The private key remains under the user’s control in a credential manager, on a device or on a physical security key.

During login, the service sends the device a fresh, random challenge. After the user authorises the request, generally by unlocking the device with a fingerprint, facial recognition or local personal identification number, the private key signs that challenge. The service checks the signature using the public key it already holds.

The private key is not sent to the service. Nor does the website receive the user’s fingerprint or facial data. Biometric verification remains on the device. The FIDO Alliance's explanation of how passkeys work describes how this process proves that the user controls the correct private key without disclosing it.

Crucially, each passkey is associated with a particular website or application. A passkey created for a genuine corporate domain will not work on a lookalike phishing site. The browser and operating system check the website’s identity instead of relying on the user to notice a subtly altered address.

This is what makes passkeys phishing resistant, rather than simply more difficult to phish.

 

Are passkeys safer than passwords?

 

For the most common password based attacks, passkeys are considerably safer.

A stolen password can be replayed from another computer. A passkey instead creates a signature for a specific challenge from the service for which it was registered. Capturing one authentication exchange does not provide an attacker with a reusable credential.

Passkeys also prevent password reuse because each service receives a separate key pair. If attackers breach one company’s servers, the public keys they obtain cannot be used to access accounts elsewhere. Unlike password hashes, public keys are not secrets that can be cracked to reveal the user’s credential.

That does not mean passkeys solve every security problem. They do not protect an organisation from malware operating inside an authenticated session, stolen session cookies or an attacker who has already gained control of an unlocked device. The protection afforded to synced passkeys also depends partly on the security of the credential manager and the account controlling it.

Organisations must therefore decide which type of passkey is appropriate for different employees and systems.

Synced passkeys can follow users to authorised devices through services such as Google Password Manager or Apple’s iCloud Keychain. This makes them convenient for people replacing a phone or working across several devices.

Device bound passkeys remain on one physical device. Microsoft Authenticator passkeys, for example, cannot be restored or synchronised to a replacement phone. Physical FIDO2 security keys are also device bound, although the same security key can be used with multiple computers.

Microsoft Entra ID supports both synced and device bound passkeys. Microsoft’s guidance suggests that synced credentials can suit much of the general workforce, while administrators, highly privileged employees and users of sensitive systems may require device bound passkeys with stronger organisational control.

 

What happens if I lose my passkey?

 

Losing a device does not necessarily mean losing access to every account protected by a passkey.

A synced passkey may already be available on another authorised device. Someone who replaces a phone may regain access through the same credential manager after satisfying its security requirements. A user can also employ a passkey on a nearby phone to sign into another device, generally by scanning a QR code and confirming the request. Cross device authentication normally uses Bluetooth to verify that the devices are physically close.

An account can also have multiple passkeys. An employee might register credentials on a managed laptop and phone, with a physical security key stored as a backup. Losing one device would then be inconvenient, but would not require full account recovery.

The difficult case arises when none of the registered authenticators remains available. The service must decide how the person can prove ownership of the account and register a replacement credential.

Account recovery options can include saved recovery codes, another registered authenticator, verified recovery contacts or renewed identity verification. US National Institute of Standards and Technology guidance on account recovery recommends stronger combinations of recovery methods for higher assurance accounts and requires users to be notified when recovery occurs.

In Microsoft managed workplaces, an administrator can issue a time limited Temporary Access Pass. This allows a verified employee to sign in and register a replacement passkey without reverting the account to a permanent password.

The Temporary Access Pass is only as secure as the process used to identify the person requesting it, however. If a helpdesk agent can be persuaded to issue one to an impostor, the attacker may be able to register a new passkey and take control of the account.

Many online services still offer recovery through email links, SMS codes, passwords or customer support. These methods may be easier to operate, but they can also reintroduce the vulnerabilities that passkeys were intended to remove.

 

Why account recovery can undermine passkey security

 

Account recovery is attractive to attackers because it is designed for exceptional circumstances.

A locked out employee may have lost a phone, damaged a laptop or be travelling without a corporate device. Support staff are expected to restore access quickly, often with limited information.

An attacker can exploit that pressure by impersonating an employee and asking a helpdesk worker to reset the account or permit a new authenticator to be registered. Publicly available personal information, compromised company data and AI generated messages can make the request more convincing.

SMS recovery presents different risks. Telephone numbers can be taken over through SIM swapping fraud, while one time codes can be disclosed during social engineering or entered into phishing sites. Email recovery is only as secure as the email account receiving the link.

The FIDO Alliance therefore treats account recovery as part of authentication security, rather than as a separate administrative process. Its passkey deployment framework says that merely offering passkeys alongside phishable login and recovery methods does not provide comprehensive phishing resistance.

Full protection requires phishable routes to be removed from both regular authentication and account recovery.

 

Passkey versus password is not the whole comparison

 

Organisations cannot always eliminate every legacy authentication method immediately. Older applications may not support passkeys, contractors may use unmanaged devices and employees need workable procedures when hardware is lost or damaged.

A staged migration is therefore realistic, but it should not be mistaken for a completed passwordless system. Security teams must map every route through which access can be obtained or restored: passwords, SMS, email, recovery codes, new device registration, helpdesk resets and administrator intervention.

High risk accounts may justify device bound passkeys, separately stored backup security keys and stronger identity checks before a replacement authenticator can be registered. Recovery attempts should be logged, while successful recovery and registration of new authenticators should generate immediate notifications.

Passkeys solve an important problem. They remove reusable secrets from the login exchange and take responsibility for recognising phishing sites away from users.

But an account is not truly passwordless if a password is still waiting behind the “I can’t sign in” link. The disappearance of the password box is the visible part of the transition. Securing every route that can bring it back will be the more difficult work.