What Happened
In August, Microsoft removed password support from its authenticator app while keeping passkey functionality. This wasn't a gradual shift. Microsoft eliminated a credential type that millions relied on, forcing a transition to FIDO2 passkeys or other authentication methods.
Amazon took a different approach, encouraging users to register passkeys through persistent prompts. Both moves indicate an industry shift away from password-based authentication, but Microsoft's action marks the first major platform to make this transition mandatory for a core product.
Timeline
Pre-August 2024: Microsoft Authenticator supported both password storage and FIDO2 passkey generation. Users could store website credentials alongside multi-factor authentication tokens.
August 2024: Microsoft updated the authenticator, removing password vault functionality. Existing stored passwords became inaccessible. The app retained support for FIDO2 passkeys, Time-Based One-Time Passwords, and push notification approval flows.
Post-August 2024: Amazon began prompting users to register passkeys during login flows and account management sessions.
Which Controls Failed or Were Missing
This wasn't a breach. No controls failed. Instead, it highlights three weaknesses in password-based authentication:
Weak credential binding: Passwords aren't tied to a device or user context. A stolen password can be used from any network, device, or location, offering no proof of legitimate possession.
Phishable authentication factors: Users enter passwords into web forms that attackers can replicate. There's no cryptographic method to verify the legitimacy of the service. Password managers help but don't eliminate this vulnerability.
Credential reuse across trust boundaries: Users often reuse passwords across services. A breach at one service can compromise others. Password rotation policies don't solve this, as users tend to make predictable modifications.
What the Relevant Standard Requires
FIDO2 addresses these issues with public-key cryptography tied to the authentication origin and user device.
Origin binding: The authenticator generates a key pair linked to the domain. The private key stays on the user's device. During authentication, the relying party sends a challenge, which the authenticator signs with the private key. This proves possession of the private key and that the user is authenticating to the correct domain. Phishing sites can't replicate this exchange.
User verification: FIDO2 requires local user verification before signing the challenge, using biometrics, a device PIN, or a hardware security key. This happens on the user's device, not over the network. An intercepted signed challenge can't be reused without compromising the user's device and biometric data or PIN.
Attestation: During passkey registration, the authenticator can provide cryptographic proof of its make and model. Organizations can require specific authenticator types, blocking software-only implementations if needed. This isn't mandatory but is available for high-assurance scenarios.
FIDO2 doesn't prevent all attacks. An attacker with physical access to an unlocked device can authenticate. However, it eliminates attacks like credential stuffing, password spray attacks, phishing, and remote compromise through stolen credentials.
Lessons and Action Items for Your Team
Map your authentication surface: Inventory every application that still accepts passwords, including internal tools, vendor portals, service accounts, and legacy systems. Document whether each system supports FIDO2, WebAuthn, or any phishing-resistant method.
Identify your constraint path: One application will block your migration. It might be an old ERP system or a vendor portal that only supports outdated protocols. If it can't support FIDO2, implement compensating controls like network segmentation or privileged access management.
Start with high-value targets: Protect your cloud administration consoles first. Azure, AWS, and Google Cloud support FIDO2 security keys. Require them for identities with standing privileges. Then move to your identity provider. If you use Okta, Entra ID, or Ping Identity, enforce FIDO2 for administrative access. A compromised IDP administrator can issue tokens for any federated service.
Handle the device loss scenario: Users will lose devices. Your passkey implementation must support recovery without reverting to passwords. Options include multiple registered passkeys per user, account recovery through a high-assurance channel, or backup codes stored securely. Document your recovery process before disabling passwords.
Communicate the threat model change: Users know not to click phishing links, but they might not understand "your authentication is cryptographically bound to the correct domain." Explain what attacks you're preventing when rolling out passkeys. Show them a phishing site and demonstrate that their passkey won't work on it. This builds trust and reduces support tickets.
Microsoft's authenticator change isn't just a cautionary tale. It's a catalyst. Your organization will face the same transition, whether you initiate it or a vendor forces it. The question isn't whether to adopt FIDO2. It's whether you'll control the timeline and scope or react to external pressure without complete planning.
