5 MIN READ
Passwordless is a five year project, not a five month project, and the companies treating it like a five month project are the ones whose roadmaps have slipped twice and will slip a third time. The reason is that passwordless is not a feature you ship. It is a migration you manage, and the migration is measured in credential rotations, support tickets, browser compatibility edge cases, enterprise SSO integrations, and the long tail of legacy systems that nobody has time to touch.
What is already solved
The technical side of passwordless is mostly solved. WebAuthn, the underlying standard, is supported in every major browser, on every major platform, and on the password manager apps that have been building passkey support for the last three years. The user experience is good enough for the major use cases. The credential is bound to the origin, the phishing protection is genuine, and cross device sync works for the major password managers. None of that is the hard part.
Same story for the developer experience. WebAuthn libraries for the major languages are mature, the documentation is solid, and the integration patterns are well established. A developer adding passkey support to a new application can do it in a week. Adding it to a ten year old application that has accumulated twelve years of password handling edge cases is a different project entirely.
What the migration actually looks like
The hard part is the migration, and the migration is where the five years comes from. Picture the customer who has 200 passwords in their password manager, half of which they have not used in three years. The migration tool has to decide which of the 200 to migrate and which to leave alone, and the customer support cost of that decision lives in the security org’s budget for the next five years.
Then the enterprise SSO integration. It needs to talk to a 12 year old LDAP server that nobody wants to touch, and the LDAP server is the kind of thing that the security team and the platform team have been quietly planning to replace since the last audit. Until the replacement ships, the SSO integration has to handle both. Add the legacy system that requires a password, the API that requires a password, the database with a password column, the report that runs on a cron job with a service account password stored in plaintext in a config file. That is the long tail.
Five years is the time to scope, prioritise, and fund this as a programme rather than a project. The product lead, the engineering lead, and the support lead all have to commit, because the support tickets they will handle over the next five years are the work the migration generates. Nobody on the inside can wave the work away.
The honest way to do a passwordless migration
Start with the surfaces where the user already has a password manager and the password manager already supports passkeys. That is the high confidence path: the user is in the flow, the support cost is the lowest, and the early wins build the credibility the rest of the programme needs. From there, the next surfaces are the ones the user logs into every day, the email, the bank, the primary work application, and the ones where the user has the highest motivation to switch, the account that gets the phishing attempts, the account the user is worried about.
Run the migration in waves. New accounts first: they have no password to migrate, so they get the passkey from day one. High value accounts next, the admin accounts, the ones with privileged access. The pattern there is passkey as a second factor first, then passkey as the only factor after the second factor has been in place for a quarter. The long tail is the rest, and the long tail is what takes the remaining four and a half years. Plan for it, fund it, do not pretend it does not exist.
Keep the password as a fallback for as long as the user needs the fallback. The user on the unsupported browser, the user on the unsupported device, the user in the restricted environment where the passkey will not work, all of them need the password, and the migration has to support them. The password is the legacy, and the legacy is the thing the programme has to carry until the programme is done.
What to do this quarter
Pick one surface. Add the passkey support. Watch the support tickets. That single surface is going to teach the identity team what the real support cost is, and it is going to show where the integration gaps actually are, not the gaps the architecture diagram claimed. One surface, instrumented, is worth more than a five year plan in a slide deck.
From there, the rest is just sequencing. The migration starts with one surface, scales from there, and gets measured on the support cost per migration, not on the count of passkeys enrolled.
The bottom line
Passwordless is a five year programme, not a five month feature. The technical side is mostly solved, the migration is the work, and the work is one surface at a time.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
