Microsoft Pulled Password Support From Its Authenticator

What Happened

In August, Microsoft removed password support from its authenticator app, keeping passkey functionality intact. This wasn't a bug or a gradual phase-out, it was a deliberate decision. Users who relied on the app for password-based multi-factor authentication had to switch to passkeys or other methods.

Amazon took a different approach, implementing persistent prompts to encourage users to create passkeys without removing existing password options. Both moves indicate an industry shift away from password-based authentication, driven by standards from the FIDO Alliance developed years ago.

Timeline

Years ago: FIDO Alliance develops and publishes the FIDO2 standard, forming the technical foundation for passkeys.

August: Microsoft removes password support from its authenticator app, while passkey support remains fully functional.

Ongoing: Amazon implements recurring prompts for users who haven't created passkeys, maintaining password support alongside the new method.

Which Controls Failed or Were Missing

This isn't a traditional incident, no breach occurred, and no credentials were stolen. However, the industry-wide push highlights the longstanding failure of passwords as a control mechanism.

Weak credential storage. Passwords are stored in databases. Even when hashed with bcrypt or Argon2, they're targets. A compromised database allows attackers to attempt offline cracking. Passkeys eliminate this risk entirely, the private key never leaves your device, and the public key stored on the server is useless without it.

Phishing susceptibility. Passwords can be entered into fake login pages. Even trained users fall for sophisticated attacks that mimic legitimate sites. FIDO2-based passkeys use origin binding, ensuring the cryptographic challenge-response only works on the legitimate domain. You can't accidentally "give" your passkey to an attacker because there's nothing to give.

Credential reuse across services. Password managers help, but users still reuse passwords across accounts. A breach at a forum site can become a vector into corporate systems. Passkeys are domain-specific by design, the key pair for your corporate SSO can't be used elsewhere.

Missing phishing-resistant MFA. Many organizations use Two-Factor Authentication with SMS codes or TOTP-based authenticators. These meet compliance checkboxes but don't satisfy the FIDO2 standard for phishing-resistant authentication. An attacker with a phished password and a real-time proxy can intercept the Time-Based One-Time Password during the same session. Passkeys close this gap.

What the Relevant Standard Requires

FIDO2 defines the technical requirements for passwordless and phishing-resistant authentication. It combines two specifications: WebAuthn (the W3C standard for browser-based authentication) and CTAP2 (Client to Authenticator Protocol, handling communication between the browser and the authenticator).

The standard requires:

• Public key cryptography. Authentication must use asymmetric key pairs. The private key stays on the user's device. The relying party stores only the public key.

• Origin binding. The authentication must bind to the requesting domain, preventing phishing. A passkey for login.yourcompany.com won't respond to a challenge from login-yourcompany.phishing-site.com.

• User verification. The authenticator must verify the user through biometrics or a device PIN before signing the challenge. This combines "something you have" (the device) with "something you are" or "something you know."

• Attestation support. Organizations can verify that the authenticator meets security requirements before allowing registration. This is crucial in enterprise environments where weak authenticators aren't acceptable.

NIST Special Publication 800-63B (Digital Identity Guidelines) classifies FIDO2-based authentication as AAL3 (Authenticator Assurance Level 3), the highest level. Password plus TOTP reaches AAL2 at best. If your compliance framework or Zero Trust architecture requires phishing-resistant authentication, FIDO2 is the technical answer.

Lessons and Action Items for Your Team

Map your authentication surface. List every application, service, and interface that currently accepts passwords. Prioritize based on access to sensitive data or privileged functions. Your VPN portal and cloud admin consoles should move to passkeys before your internal wiki.

Identify FIDO2-compatible services. Check if your identity provider supports passkey registration and authentication. Azure AD, Okta, and Google Workspace all support FIDO2. Legacy applications relying on LDAP bind or Kerberos may need a federation bridge or a longer migration timeline.

Plan for device loss scenarios. Users will lose phones. Your account recovery process must handle passkey replacement without reverting to weaker authentication. Options include pre-registered backup authenticators, secure account recovery codes stored offline, or helpdesk verification with strong identity proofing.

Test cross-platform passkey sync. Apple, Google, and Microsoft now sync passkeys across devices within their ecosystems. Understand how this works in your environment. A passkey created on an iPhone can be used on a Mac, but not on a Windows laptop unless you use a cross-platform password manager that supports passkey storage.

Update your identity governance workflows. Certification campaigns that ask managers to review "passwords" need to shift to reviewing registered authenticators. Your Identity Governance and Administration (IGA) system should track which users have registered passkeys, which are still on legacy authentication, and where gaps exist.

Don't wait for a mandate. Microsoft didn't remove password support because of a breach, they did it because the risk profile of passwords no longer justifies their convenience. You can make the same calculation. Start with a pilot group (IT staff, security team) and expand based on what you learn.

Prepare for the hybrid period. You'll run passkeys and passwords in parallel for months or years. Ensure your monitoring can distinguish authentication methods in your logs. If an admin account authenticates with a password when it should only use a passkey, that's an anomaly worth investigating.

The password isn't disappearing next quarter, but the direction is clear. Organizations that treat this as a compliance exercise will lag behind those that see it as a fundamental improvement in authentication assurance.