Passwordless authentication has spent five years as a conference demonstration. This year it acquired a delivery date. In May, Apple, Google and Microsoft jointly committed to shipping synchronised passkey support across their platforms; Apple's implementation is in beta now and arrives with the autumn operating system releases; and the American federal zero trust directive issued in January already requires agencies to move to phishing-resistant authentication rather than multi-factor authentication in general. That last distinction is the one that matters. The conversation has quietly shifted from "do you have MFA" to "can your MFA be phished", and this year has supplied the evidence for why. The intrusions that embarrassed large technology companies in the first quarter did not break cryptography. They rang the help desk, bought a session cookie, or pushed approval prompts at a tired employee until one was accepted.
Three different things share one name
Passwordless sign-in replaces password entry with an application approval or a code. Convenient, popular, and still phishable, because a human is being asked to approve something they cannot verify. Phishing-resistant authentication binds the credential cryptographically to the site it was registered with, so a convincing replica domain receives nothing usable. Hardware security keys and platform authenticators built into laptops and phones fall in this category. Password-free with a password underneath is the most common state in practice: users no longer type a password, but one still exists, is still valid, and can still be used by anyone who obtains it. Organisations frequently believe they have bought the second and have actually deployed the third.
| Path | What changes | What still needs review |
|---|---|---|
| Passwordless sign-in | A code or approval replaces typed password entry | The approval or code may still be phishable |
| Phishing-resistant authentication | A credential binds cryptographically to its registered service | Recovery, sessions and support-desk changes remain risks |
| Password underneath | Users stop typing a password | A retained valid password may still open an old path |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Passwordless does not remove the password. It moves it to the recovery process
This is the architectural point that pilots keep missing. A cryptographic credential bound to a device is extremely strong until the device is lost, replaced, or the employee is new — and then somebody has to issue a replacement. Whatever that process is, it is now the true strength of your authentication. If a support agent can enrol a new authenticator after a phone call, you have built a very sophisticated front door with a manual override. Get three things right before rollout, not after: Bootstrap. How does a new joiner receive a first credential, especially remotely? Time-limited enrolment passes issued by a verified manager, in-person enrolment on the first day, or identity proofing against a document — pick one deliberately. Replacement. Require a second registered authenticator for everyone, so the ordinary case of a broken phone never touches the help desk. The cost of a second key is trivially less than the cost of a weak reset path. Emergency. Define what happens when both are gone, who authorises it, and what evidence is required — and make that path deliberately slow, because attackers need it to be fast.
What works in production
Use platform authenticators — the fingerprint or face recognition already built into laptops and phones — for the general population. They cost nothing, users already understand them, and enrolment is quick. Use hardware keys for administrators, finance approvers, executives and anyone with access to the identity console. Two keys each, one kept off-site. Protect the identity provider itself first. It is the single account that unlocks everything else, and it is routinely the last system anyone hardens. And plan to run both worlds for eighteen to twenty-four months. Coexistence is not failure; pretending you can switch in a quarter is.
Enrolment is not adoption. Count authentications, not accounts
The standard programme metric — percentage of users enrolled — is close to meaningless, because an enrolled user who still signs in with a password every morning has changed nothing. Measure the proportion of successful authentications that were phishing-resistant, broken down by application and by privilege level. That number starts embarrassingly low even in programmes reporting ninety per cent enrolment, and it is the only figure that tracks actual risk reduction. A second metric worth watching: legacy authentication attempts. Until those reach zero and stay there, the old path remains open.
The three blockers nobody costs
Legacy applications that cannot federate. Each needs a decision — front it with a gateway, replace it, or accept a documented exception with compensating controls and an owner. Shared and deskless workers who have no assigned device and often no corporate account at all. Contractors and third parties, who frequently hold significant access and sit entirely outside the device management that platform authenticators assume. A rollout plan that does not name all three by week two will stall at roughly sixty per cent and stay there.
Practical Guidance for Passwordless Rollout Planning
- Classify your current factors into phishable and phishing-resistant before claiming any coverage.
- Harden the identity provider first, with hardware keys for every administrator.
- Register two authenticators per user so that replacement is self-service by default.
- Rewrite the recovery and enrolment process before rollout; it becomes your weakest link the day you finish.
- Report phishing-resistant authentications as a percentage of all authentications, not enrolment counts.
- Inventory legacy authentication and set a shutdown date with named exception owners.
- Plan shared-device and contractor populations explicitly, with a different design rather than a delayed one.
- Retire text-message codes last, not first — removing them before alternatives are universal produces lockouts and shadow workarounds.
The Regional Angle
Three regional conditions change the shape of this programme, and the first is an advantage almost nobody exploits. Government digital identity here is well ahead of enterprise identity. Residents already authenticate to national and municipal services using a national digital identity tied to biometric enrolment and a government-issued credential, and they do it routinely, on their own phones, without training. The familiar change-management objection — that users will resist biometric authentication or find it intrusive — is empirically false in this market, and any project plan budgeting heavily for user resistance is budgeting for a problem the population solved years ago. There is a further question worth asking rather than assuming: for workforce scenarios that require high assurance, federating to or verifying against the national identity is technically available and increasingly accepted, which is a capability most European or American programmes simply do not have. The second is the deskless majority. Construction, logistics, hospitality, facilities management and retail employ enormous regional workforces who have no corporate laptop, frequently no corporate account, and often share a terminal login across an entire shift. Passwordless design assumes one person and one device, and that assumption does not survive contact with a warehouse. The workable pattern is a badge tapped at a shared terminal with a personal code, credentials bound to the badge rather than the machine, and enrolment handled at induction alongside the identity card. The prize here is larger than removing passwords: it is removing shared accounts, which is the control failure that makes attribution impossible in exactly the operations where safety and inventory matter most. The third is device churn. This is a heavily bring-your-own-device market with an unusually mobile workforce, and phones are replaced, numbers are changed, and staff depart the country on short notice with far greater frequency than global rollout templates assume. Synchronised passkeys stored in a personal cloud account are convenient and will arrive this autumn whether you plan for them or not — but a workforce credential that lives in an employee's personal account, travels with them when they leave, and is recoverable by them alone is a governance question your leavers process has never had to answer. Decide now which populations use company-controlled authenticators and which may use personal synchronised credentials, and write the difference into the joiners and leavers procedure rather than discovering it at the first contested exit.
The objection worth taking seriously
The strongest objection is that this is a vendor programme wearing security clothing. A typical estate runs hundreds of applications, a large share of which will never support modern authentication, so passwords persist regardless. Hardware keys cost money and get lost. And the same service desk that used to reset passwords will now reset authenticators, meaning a year of effort has relocated the weakness rather than removed it. Ordinary multi-factor authentication, actually enforced everywhere with no exceptions, would stop the overwhelming majority of real attacks at a fraction of the cost and disruption. That last sentence is the strongest argument in security this year, and organisations with enforcement gaps should absolutely fix those before buying anything. But push-based approval is being defeated in production right now, not theoretically, which means "properly enforced MFA" is a target that moved in the first quarter of this year. The value is also far more concentrated than the objection assumes: administrators, finance approvers and the identity console itself represent a small fraction of accounts and most of the achievable risk reduction — a quarter of focused work, not a multi-year transformation. And the help-desk point is not a reason to skip the programme; it is a reason to fix recovery, which is required whether or not a single password is ever removed.
Common Questions
Are text-message codes still acceptable?
As a fallback for low-risk populations, for now. Not for administrators, not for finance approvers, and not as the recovery path for anything privileged.
What do hardware keys actually cost?
Two keys per privileged user, plus shipping and a small loss rate. Compare that against a year of password reset tickets before deciding it is expensive.
Can we start without replacing our identity platform?
Usually yes. Most current platforms already support phishing-resistant authenticators; the work is policy, enrolment and legacy shutdown rather than procurement.
What should we expect over the next twelve months?
Expect synchronised passkeys to ship in consumer operating systems this autumn, which will create internal demand before your policy is ready. Expect auditors and insurers to begin distinguishing phishing-resistant authentication from multi-factor authentication generally, and to price the difference. Expect text-message codes to be formally deprecated in more standards and frameworks. Expect the enterprise question about credentials synchronised through personal cloud accounts to stay unresolved well into next year. And expect attackers to move further toward stolen session tokens and support-desk manipulation, because when the front door hardens, the attack relocates to whichever step is still performed by a person under time pressure.
Passwordless Rollout Planning — we separate what is phishing-resistant from what merely feels modern, fix the recovery path before it becomes your weakest control, and sequence the rollout around the accounts that actually matter.