Passwordless is a five year project, not a five month project, and the companies that are treating it like a five month project are the ones whose roadmaps have slipped twice and will slip a third time. The reason it is a five year project is that passwordless is not a feature you ship. Passwordless is a migration you manage, and the migration is measured in credential rotations, in customer support tickets, in browser compatibility, in enterprise SSO integrations, and in the long tail of legacy systems that nobody has time to update.
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 dedicated 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, the cross device sync works for the major password managers. The technical side becomes the easy side.
The developer experience is also good. The WebAuthn libraries for the major languages are mature, the documentation is solid, and the integration patterns are well established. The developer who wants to add passkey support to a new application can do it in a week. The developer who wants to add passkey support to a ten year old application that has accumulated twelve years of password handling edge cases is in for a longer project.
What the migration actually looks like
The hard side runs as the migration. The hard side becomes the customer who has 200 passwords in their password manager, half of which they have not used in three years, and the migration tool that does not know which of the 200 to migrate and which to leave alone. The hard side stands as the enterprise SSO integration that needs to talk to a 12 year old LDAP server that nobody wants to touch. The hard side amounts to the legacy system that requires a password, the API that requires a password, the database that has a password column, the report that runs on a cron job with a service account password stored in plaintext in a config file. The hard side runs as the long tail.
The migration sits as the work that takes the five years. The migration sits as the work that has to be scoped, prioritised, and funded as a programme rather than a project. The migration is what the engineering team has to commit to, the migration is what the product team has to commit to, and the migration is what the customer support team has to commit to, because the migration is going to generate the support tickets the support team has to handle for the next five years.
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 sits as the high confidence path, the path where the user is in the flow, the path where the support cost serves as the lowest. The next surfaces are the ones the user logs into every day (the email, the bank, the primary work application), and the surfaces where the user has the highest motivation to switch (the account that gets the phishing attempts, the account that the user is worried about).
Run the migration in waves. The first wave serves as the new accounts. The new accounts do not have a password to migrate. The new accounts get the passkey from day one. The second wave stands as the high value accounts (the admin accounts, the accounts with the privileged access). The high value accounts get the passkey as a second factor first, and the high value accounts get the passkey as the only factor after the second factor has been in place for a quarter. The third wave runs as the long tail. The long tail counts as the migration that takes the rest of the five years, and the long tail stands as the migration the engineering team has to plan for.
Keep the password as a fallback for as long as the user needs the fallback. The user who cannot use the passkey (the user on the unsupported browser, the user on the unsupported device, the user in the restricted environment) needs the password as a fallback, and the user who needs the fallback runs as the user the migration has to support. The password counts as the legacy, and the legacy serves as the thing the migration has to support until the migration is done.
What to do this quarter
Pick one surface. Add the passkey support. Watch the support tickets. The first surface is going to teach the engineering team what the support cost is going to be, and the first surface is going to teach the engineering team where the integration gaps are. The first surface counts as the surface the engineering team should be working on, and the first surface sits as the surface the migration is going to start with.
The passwordless migration is a five year project. The five year project starts with the first surface. The first surface is what the engineering team should be shipping this quarter, and the first surface is what the migration is going to be measured on.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
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.
