NCSC says passkeys first, passwords second

· Carl Heaton · Security Commentary

The NCSC has changed its advice on how to log in. At CYBERUK 2026, it recommended passkeys as the default for any service that supports them, with password plus two-step verification reduced to a fallback. Two-step verification is the code you get on your phone or via an app after typing your password. That is a meaningful shift from a regulator that has spent years telling people to turn it on.

What a passkey actually is

A passkey is a pair of cryptographic keys generated by your device. The private key stays on the device and never leaves it. Your device hands the public key to the service you are logging into. When you sign in, the service sends a challenge, your device signs it with the private key, and the service verifies the signature against the public key it already holds. You approve the sign-in with a fingerprint, face, or device PIN.

There is no password to type, no code to relay, and no shared secret sitting in a database somewhere waiting to be stolen.

What changed

Until now, the NCSC's guidance has leaned on password manager plus two-step verification. That advice is not going away, but it has been demoted. The new line, from Jonathon Ellison, Director for National Resilience, is that "adopting passkeys wherever you can is a strong step towards a safer, simpler login experience."

The accompanying technical report from Dave Chismon, NCSC CTO for Architecture, goes further. It concludes that every common form of two-step verification – SMS codes, authenticator app codes, push approvals – remains "inherently phishable," and that passkeys are at least as secure as, and generally more secure than, strong passwords paired with any of them.

Why now

The NCSC has been deliberately slow on this. Passkeys have been technically viable for a while, but the ecosystem was a mess. Inconsistent naming, patchy device support, credential managers that could not sync reliably across platforms. A national regulator cannot tell the public to switch to something that half-works.

Those gaps have narrowed. Google reports that roughly half of its UK users have a passkey registered. Apple, Google, and Microsoft all sync passkeys across their ecosystems. Password managers like 1Password and Bitwarden handle them too. The plumbing finally works well enough to recommend as a default rather than an early-adopter option.

Why passkeys are harder to phish

The core difference is architectural. A password is a shared secret. You know it, the service knows it, and anything that can trick you into typing it into the wrong box can steal it. Two-step verification helps, but an attacker who proxies a convincing fake login page can relay the code in real time and hijack the session.

Passkeys are not a shared secret. Your device holds a private key, the service holds the matching public key, and the authentication is cryptographically bound to the legitimate domain. If the domain is wrong, the passkey will not work. There is nothing for a phishing site to harvest, because your device will refuse to speak to it.

That is why the NCSC is willing to say passkeys remove this class of attack entirely. It is not a marketing claim. It is a property of how the protocol is designed.

Where your passkey lives matters

Most people will end up with synced passkeys through Apple, Google, or Microsoft. These are convenient. They copy across your devices automatically and survive a lost phone or a wiped laptop, because recovery runs through the vendor's account system. The trade-off is that your authentication is tied to that ecosystem. If you are deep into Apple and decide to move to Android, migrating your passkeys is awkward. If your Google account is locked or disputed, your recovery path is not entirely in your hands.

Hardware security keys, such as YubiKeys, are the other sensible option and often a better one for businesses. They are small USB or NFC devices that hold the passkey directly. They work across any browser, any operating system, and any ecosystem. If a laptop is dropped, reformatted, or replaced, the key in your pocket is unaffected. Staff changing machines carry the key over and carry on. The only real discipline is registering a backup key when you enrol, so a lost key is an inconvenience rather than a lockout.

For most individuals, synced passkeys are fine. For staff who move between devices, or for admin accounts where recovery flows matter, hardware keys are worth the small cost.

What to do

For individuals, turn on passkeys where your important services offer them. Google, Microsoft, Apple, PayPal, eBay, GitHub, and most major banks now support them. Keep your password manager and two-step verification in place for everything else.

For businesses, four things are worth doing in the next few months:

  • Check which of your core SaaS tools support passkeys and make them the default sign-in method where they do.
  • Decide whether staff passkeys should live in the platform (Apple, Google, Microsoft) or on hardware keys. For admin accounts and anyone who changes devices often, hardware keys are usually the right answer.
  • Update staff guidance so new joiners are set up with passkeys from day one rather than inheriting a password-first habit.
  • For services that do not yet support passkeys, make sure two-step verification is on and that anyone still using SMS codes has a path to something better.

Nothing here needs to be rushed. The NCSC is not deprecating passwords overnight. But the direction of travel is now official, and if you are planning authentication changes in the next year, this is the signal to plan around.

Further reading

The NCSC's announcement, the underlying technical blog post, and The Register's write-up which has useful context on the ecosystem issues that held the recommendation back.

← All filings