The password did not fail because it was weak

Why did the password fail?

Almost everything written about passwords for twenty years concerned how hard they were to guess. Minimum lengths, character classes, dictionaries of forbidden words, entropy calculations, the little coloured bar that turns green. All of it addressed an attacker sitting outside trying combinations, and that attacker had largely stopped being the problem well before the advice stopped being given.

The attacks that actually take accounts do not guess. They collect. A page that looks like the login screen collects what you type; a database breach somewhere else collects what you chose there and tries it here; a phone call from somebody plausible collects what you say. None of those care how long the string is, and a thirty-character passphrase entered into a convincing imitation is exactly as compromised as a short one.

Two published figures make the shape of it concrete. Roughly half of a typical person's passwords are not unique, which is what makes a breach at an unrelated service worth exploiting here. And credential stuffing — the industrial version of trying leaked pairs against everything — accounts for a median 19% of all sign-in attempts observed by single sign-on providers. That is not a fringe technique. On a busy login endpoint it is close to a fifth of the traffic.

Once the property in question is transferability rather than strength, the design response follows. Either make the credential impossible to hand over, or accept that it will occasionally be handed over and design for what happens next. Nearly all the effort of the last two decades went into a third option — making it harder to guess — which was solving a problem that had already been solved.

The standards caught up before the habits did. The body whose earlier publication popularised composition rules and periodic expiry reversed both in its 2017 revision, on the evidence that they pushed people toward predictable substitutions and written notes without measurably improving anything. Nearly a decade later those rules remain in force at a great many organisations, generally because they sit in an internal policy document nobody has a reason to reopen. It is a small illustration of a general pattern: retiring advice is harder than issuing it, and the rule outlives the reasoning by years.

Are passkeys actually being used?

More than sceptics expect and less than the headline figures imply. Industry reporting for 2026 puts something like five billion passkeys in active use, with awareness near ninety per cent and around three quarters of people having enabled one on at least one account. Roughly half say they use them regularly.

The number worth holding onto is the difference between two of those measures. Accounts that have a passkey saved and accounts where somebody actually signed in with one during the last thirty days differ by twelve to eighteen percentage points. People set them up and then continue to sign in the old way, usually because the old way is still offered and is what their fingers already know.

Adoption also varies sharply by what the account is for. Financial services sit around sixty per cent, retail near thirty-five, business software close to twenty-eight, and media and entertainment near eighteen. That ordering tracks how much the account is worth to the person holding it rather than anything technical, which suggests the constraint is motivation rather than capability.

On the employer side the picture is further along than the consumer figures suggest: around sixty-eight per cent of organisations have deployed, are piloting or are rolling out passkeys for staff sign-in. Resistance turns out to be a minor obstacle rather than a blocking one — of the organisations that named internal buy-in as a barrier, a small minority said it actually delayed the work. The larger practical obstacle is the long tail of systems that cannot accept anything but a password, and those systems tend to be the ones nobody wants to touch.

Where should you start?

With whatever is reachable from the internet, and with the accounts that can grant access to other accounts. Email first, because it is the reset path for everything else, and administrative accounts second. An organisation that protects those two categories properly and leaves the rest on passwords is in far better shape than one that has rolled something out evenly everywhere.

Then remove the fallbacks, which is the step most deployments skip. Requiring a passkey while leaving a code by message available as a backup does not deploy passkeys; it deploys the weakest option that remains enabled, because the attacker chooses which route to attempt and will not choose the hard one. The same applies to help desk procedures: an account protected by a hardware key and recoverable by phoning somebody who asks for a date of birth is protected by the date of birth.

For the systems that genuinely cannot take anything but a password — and every estate has some — the realistic measures are unique credentials from a manager, blocking known-breached passwords at the point they are set, and putting the system behind something that can enforce a modern factor at the perimeter. None of that is elegant. It is considerably better than a rotation policy.

For an individual, the order is the same and shorter: a manager so that nothing is reused, a passkey on the handful of accounts that matter most, and the recognition that the recovery path is part of the security of the account rather than a convenience attached to it.

What about the credentials nobody types?

Everything above concerns a person proving who they are. In most estates the larger population of credentials belongs to software: service accounts, integration tokens, API keys, certificates, the connection string in a configuration file. They outnumber the staff accounts, often by an order of magnitude, and almost none of the thinking that produced passkeys applies to them.

They have the properties that made passwords fail, amplified. They are long-lived, frequently permanent. They are copied into repositories, build systems, monitoring tools and somebody's local notes. They are rarely rotated, because rotating one means finding everything that uses it, and nobody knows what uses it. And they do not get offboarded when a person leaves, because they were never attached to a person in the first place.

The direction of travel is toward credentials that are issued on demand and expire in minutes rather than living in a file for years — a workload proving its identity to the platform it runs on and receiving a short-lived token, so there is nothing durable to steal. That is genuinely better and it is a migration, not a setting. Meanwhile the practical work is unglamorous: find where the long-lived keys are, and the honest way to find them is to search the places they end up rather than the places they are supposed to be.

The population of automated agents acting on behalf of people is making this sharper. A piece of software holding a standing credential with the permissions of the person who authorised it has every property that made service accounts a problem and adds one more: there is nobody to phone and ask whether that was them. Whatever conclusion an organisation reaches about human authentication, this is the question immediately behind it.