Passkeys vs. passwords 2026: NIST 800-63-4 and the real-world rollout

2026 is the year passkeys jumped from 'cool but who actually uses them?' to 'why do you still have passwords?' The FIDO Alliance reports over 1 billion activated passkeys in June 2026, 48 % of top-100 sites support the tech, and Google says: a 99.9 % lower compromise rate than passwords. At the same time NIST in SP 800-63-4 has mandated phishing-resistant authentication for AAL2. I have run two passkey migrations for clients in the past two months — what passkeys can do, where they still stumble, and why password tools stay relevant.

What passkeys actually are, technically

At its core a passkey is an asymmetric cryptographic key pair generated and stored in a secure hardware module on your device (Apple Secure Enclave, Windows TPM, Android StrongBox). The private key never leaves the device. On every sign-in the server sends a challenge, your device signs it with the private key, the server verifies the signature with the corresponding public key it received during initial onboarding.

The decisive difference from passwords: the secret (the private key) is never transmitted. Even if the server gets hacked and the entire database leaks, the public keys are useless to the attacker — they cannot produce signatures from them. That is a paradigm-level security gain. Passwords always had to be cached server-side (even as hashes); passkeys don't.

Phishing resistance comes from a second property: the passkey is bound to the domain (Relying Party ID) it was created for. If an attacker spins up a fake site at calcsi-login.com, your device signs nothing, because the domain doesn't match the registered one. There is no 'trap to fall into' — the cryptography simply makes authentication against the wrong domain impossible.

NIST SP 800-63-4: what the new US standard mandates

NIST's 'SP 800-63-4: Digital Identity Guidelines' has been the leading US standard for identity authentication since its final release in 2025. Anyone working for US federal agencies has to comply — and in their slipstream large corporations follow because 800-63-4 is increasingly referenced in private contracts. For Authenticator Assurance Level 2 (AAL2), 800-63-4 demands phishing-resistant authentication. For AAL3, it is mandatory.

Three more important changes compared to the predecessor SP 800-63-3: (1) no more forced periodic password rotation — only on suspected compromise. This took years; the old rule 'change password every 90 days' objectively worsened security, because users adopted variation schemes. (2) Length over composition — 8 characters mandatory, 15+ recommended, composition rules ('1 uppercase, 1 special character') explicitly discouraged. (3) Screening against breached password lists is mandatory — accounts get checked against HaveIBeenPwned and similar at creation.

The EU world has no direct 1:1 equivalent, but the NIS-2 directive and the EU Cyber Resilience Act move in the same direction: phishing-resistant MFA for critical infrastructure mandatory from 2026. Anyone running a BSI-compliant system in Germany can cite the NIST guidelines as best practice — auditors increasingly use them as a benchmark.

What actually happens in 2026 — adoption reality

The sober reality: 48 % of top-100 sites support passkeys. But: support doesn't mean default. On most sites you still have to actively add a passkey in account settings — the signup flow for new users continues to go through password + email. Google, Microsoft, Apple and PayPal are leading the charge to actively retire passwords. With smaller SaaS providers, the password stays the primary method and the passkey is an optional add-on.

Concretely, in the migrations I did in 2026: about 15-25 % of users activate a passkey within the first 3 months when actively prompted. Without prompts, under 5 %. Meaning: the password is going to stay in the stack for the foreseeable future (5+ years), alongside the passkey. As a developer in 2026 you plan for both paths.

Where passkeys still stumble: the 'set up on device A, later log in on device B' problem. Apple and Google have largely solved it via iCloud Keychain and Google Password Manager — keys sync between devices in the same cloud account. But: cross-platform (use an Apple-issued key on a Windows PC) remains awkward. WebAuthn hybrid via QR code works but is too fiddly for many users. Security keys (YubiKey 5) remain the most robust cross-platform solution.

Where passwords stay relevant

First: many services won't get passkey support in the next 5 years. Government portals, small SaaS, international providers from regions with different security maturity. A 25-character unique password per service in a password manager is still the pragmatic default in 2026.

Second: recovery. If your phone falls in water and the iCloud login fails, you need a backup path — usually a password. That is the biggest argument against a passkey-only service: many users fear getting locked out. In practice I find recovery via email codes plus backup codes (10 one-time codes to print) is a solid compromise.

Third: WordPress, wikis, self-hosted tools. The WordPress community has had a passkey plugin since 2024, but adoption is small. Anyone running their own WordPress install will be entering through the standard login form for the foreseeable future — with a strong password and two-factor authentication. Our WordPress Password Hash Generator stays important in recovery scenarios: it lets you write a new admin hash directly into the database without going through email reset.

Practical migration: what I recommend to clients in 2026

Step 1 is always: inventory. Which services has your team used? Which support passkeys, which don't? A simple CSV export from your password manager (1Password, Bitwarden, Dashlane) is the starting point. Then per service: passkey-capable? On the yes answers: activate, keep the old password as backup. On the no answers: a strong unique password + MFA (ideally with a YubiKey, otherwise TOTP).

Step 2 is escalation for privileged accounts. Admins, finance, HR — anyone with access to payment systems, personnel data or customer databases. Here a YubiKey 5 (EUR 50-70) plus at least one backup YubiKey is mandatory. Anyone working in an organisation under NIS-2 or comparable compliance frameworks has to do this anyway.

Step 3 is the hardest: user education. 'Passkey' is a buzzword for most employees. A 20-minute demo using a Microsoft login is usually enough to convey the value. Important: not a mandate, but an incentive. A passkey gives you a 5-second login. A 25-character password plus TOTP gives you 30 seconds. The convenience advantage drives adoption better than any 'security' speech.

A concrete plan for your 2026 security audit

A short checklist I run through for every project:

• Check password strength. Use the Password Generator to create at least 20 characters per account. Don't enforce composition rules — length beats complexity.
• Check the hash algorithm for stored passwords. Argon2id (better) or bcrypt with cost ≥12 are state-of-the-art. MD5 and SHA-1 are forbidden. PBKDF2 is acceptable but no longer recommended.
• Check passkey support in your frontend. Add the WebAuthn API, use conditional UI for browser-native passkey prompts. Apple and Google publish standard snippets in their documentation.
• Test the recovery mechanism. Generate backup codes and validate against a real test account. Have a colleague try to lock themselves out and recover.
• Enable audit logs. Every login attempt should land in an audit log with IP, user agent and timestamp. Alerts to admins on anomalies.

Sounds like a lot, but for a small-to-mid stack it is doable in 2 days. The biggest gain isn't in pure tech, it is in discipline: set up properly once, the mechanisms don't need to be reinvented daily.

My takeaway for 2026

Passkeys are not a password replacement — they are an add-on that actively eliminates the phishing attack surface. Anyone offering both in parallel and nudging users toward the passkey gains security without friction. Anyone still on the 90-day password rotation cycle should kill it immediately — NIST has been saying so since 2017, now it is explicit in the 2025 update.

Personal note: I have been using passkeys on my most important accounts since May 2024, the first one was a Google account. Login time dropped from 12 seconds to 2 seconds, zero successful phishing attempts in over two years. My password manager is still there, its contents are slowly shrinking. In three years — I think — it will primarily be a backup archive for me, not a primary tool.

Frequently asked questions

Are passkeys still secure if my phone gets stolen?

Yes, provided your phone has a device PIN or biometrics. The passkey is stored in the secure element and can't be used without successful user verification (Face ID, Touch ID, PIN). A thief can power on the phone, but sees the lock screen — without that step, the passkey doesn't work either. Important: cloud backup of your passkeys (iCloud Keychain) should be protected with a separate passphrase.

What happens if I switch from iOS to Android?

Passkeys stored in iCloud Keychain currently cannot be directly exported to Google Password Manager. You have to re-register the passkey at each service. 1Password, Bitwarden and Dashlane can sync cross-platform — anyone using an OS-independent password manager has a much easier switch. The FIDO Alliance is working on a passkey-export standard, but that will take until 2027 at least.

Do I still need a YubiKey if I have phone passkeys?

For high-privilege accounts (banking, crypto custody, admin consoles): yes. A YubiKey is phishing-resistant AND cloud-independent. With iCloud-synced passkeys, ultimately the trust sits with Apple — Apple has never been compromised, but that is a single point of trust. For ordinary online banking, email, social media, phone passkeys are entirely sufficient.

Can my employer see which passkeys I use?

On a personal device: no. On a company-managed device (MDM): they see that passkeys exist, but not for which services. On Apple, passkey storage in the personal iCloud Keychain is isolated; Apple Business Manager has no access. On Windows with Entra ID it can differ — configuration determines whether private passkeys live in the same profile or separately.

Are passkeys safe against quantum computers?

Today's passkeys use elliptic curves (ES256, ES384) or RSA-2048 — both would be broken by a sufficiently large quantum computer. A post-quantum-safe variant is in the FIDO spec pipeline but not yet in production. Practically: quantum computers that solve the problem are still 5-15 years away; migration to post-quantum crypto is a platform-wide effort that Microsoft, Apple and Google are progressing in parallel.

How can I as a web developer start with passkey login in 2026?

Three steps: (1) integrate the WebAuthn API in the frontend (vanilla JS or a library like SimpleWebAuthn). (2) Server-side, generate the challenge, store the public-key material, verify signatures. (3) Use conditional UI so the browser automatically suggests available passkeys. Auth0, Clerk, Stytch and Supabase all offer passkey-as-a-service — if you don't want a custom stack, you can integrate in 2 hours. Pure OSS options: SimpleWebAuthn (JS/TS) or webauthn-py (Python).