The Challenge
The National Cyber Security Centre (NCSC) faced a persistent authentication issue: traditional password guidance wasn't effective. Despite warnings against weak passwords and promoting password managers and multi-factor authentication, breaches continued. The NCSC had to decide whether to reinforce password practices or accept that passwords themselves were the problem.
This wasn't a technical glitch; it was a strategic dead end. Every password policy assumes users will comply, yet breaches prove otherwise. The NCSC's move to recommend passkeys over passwords signifies more than a tech preference. It's an acknowledgment that user behavior won't change, so the authentication method must.
For IAM architects, this raises a question: if a national cybersecurity authority is shifting away from passwords, what does that mean for your enterprise authentication plans?
The Environment and Constraints
The NCSC operates uniquely. They can't enforce technology choices across the UK's digital landscape, but their guidance heavily influences enterprise security decisions. Their recommendation needed to work across consumer platforms and government systems, accommodate varying technical maturity, and align with existing standards.
Timing is key. Platforms like Apple, Google, and X already support passkeys, providing a baseline for implementation. The FIDO Alliance standards offer the technical foundation. Yet, enterprise adoption lags behind consumer platforms, with many organizations still viewing multi-factor authentication as the ultimate security measure.
The NCSC also faced the password manager paradox. They've long promoted password managers, and many enterprises have invested in these tools. Recommending passkeys now suggests that this practice is outdated.
The biggest constraint: backward compatibility. You can't just switch off password authentication across an enterprise. Legacy applications, third-party integrations, and service accounts all rely on shared secrets. The NCSC had to recommend a technology that could coexist with passwords during a multi-year transition.
The Approach Taken
The NCSC established a clear hierarchy: passkeys first, password managers second, multi-factor authentication as a minimum. This ranking reflects the phishing-resistance model that FIDO2 provides.
Passkeys differ from password-plus-MFA because the authentication credential never leaves your device. There's no shared secret on the server for an attacker to steal. When you authenticate, your device signs a challenge with a private key, and the server verifies it with a public key. Even if an attacker compromises the server, they can't use your credential elsewhere.
Contrast this with password-plus-TOTP. The password exists in plaintext at some point, and the TOTP seed is a shared secret. Both can be phished if an attacker proxies the authentication flow. You've seen this attack: a credential-stealing site intercepts the user and the real service, capturing both the password and the one-time code.
The NCSC's approach acknowledges that phishing-resistant authentication isn't just better security theater. It's a different threat model. You're not just protecting secrets in transit and at rest; you're eliminating the shared secret entirely.
Results and Metrics
The NCSC didn't publish adoption targets or timelines, but the policy shift itself is significant. A national cybersecurity authority doesn't change decades of practice lightly. This recommendation will influence procurement requirements, compliance frameworks, and security audits across UK enterprises.
The immediate result: legitimacy. When your CISO asks why you're prioritizing passkey implementation, you can point to NCSC guidance. When your application teams resist FIDO2 integration complexity, you have regulatory backing.
The longer-term result will appear in breach statistics, but that data is years away. What we can measure now is the gap between consumer platform readiness and enterprise adoption. Apple, Google, and X support passkeys. Your HR system probably doesn't. Your VPN client might not. Your privileged access management tool is still using passwords and TOTP.
That gap is your implementation roadmap.
What They Would Do Differently
The NCSC's guidance doesn't tackle the toughest enterprise problems: handling service accounts, API authentication, and user migration without creating support issues.
If the NCSC were designing this for enterprise implementation, they'd need to address the authentication inventory problem first. You can't migrate to passkeys until you know where passwords are used. This means cataloging not just user authentication, but service-to-service authentication, legacy application integration, and third-party SSO flows.
They'd also need to address recovery scenarios. Passwords have a well-known recovery path: reset via email, security questions, or admin intervention. Passkeys tied to a hardware device create a new problem. If a user loses their phone or security key, how do they regain access? The solution involves account recovery credentials, which reintroduces some of the problems passkeys solve.
A more complete recommendation would include guidance on hybrid authentication policies: which applications get passkey-only enforcement, which get passkey-preferred with password fallback, and which remain password-based during the transition.
Takeaways for Your Team
Start with your authentication inventory. You can't build a passkey migration roadmap without knowing where passwords are used. Include service accounts, API keys, and application-to-application authentication. Most enterprises find they have far more password-based authentication than expected.
Prioritize user-facing applications with high phishing risk. Your VPN, email, and privileged access tools should be first for passkey support. These are the credentials attackers target in initial access campaigns.
Don't treat this as an all-or-nothing migration. You'll run hybrid authentication for years. Build your policy framework to support passkey-preferred flows with password fallback, then tighten the policy as adoption grows.
Test your FIDO2 implementation against real attack scenarios. Passkeys resist phishing, but they don't prevent account takeover via session hijacking or malware. Your session management, device trust, and continuous authentication controls still matter.
Prepare for the service account problem. Passkeys work for human users, but your CI/CD pipelines, monitoring tools, and automation frameworks still authenticate with API keys and service account passwords. You'll need a separate strategy for non-human authentication, likely involving short-lived credentials from a secrets management platform, not passkeys.
The NCSC's recommendation isn't just about passkeys. It's about recognizing that password-based authentication has failed. Your enterprise authentication strategy needs to reflect that reality, even if your migration timeline spans years.
