Passwords were never the thing our security team lost sleep over — breach insurance and MFA covered most of that risk. They were the thing our help desk lived with, one reset ticket at a time. Here’s how 1,400 employees ended up on passkeys without a single mandatory training session.
The number that started this project wasn’t a breach. It was 412 — the average number of password-reset tickets our help desk closed every month, most of them between 8 and 9 a.m. on a Monday. Multiply that by an average handle time of six minutes and you get a team that was spending roughly the equivalent of one full-time engineer, every month, typing “click the link we just emailed you” into a chat window. That’s the number that got budget approved. The phishing statistics got the executives’ attention, but the reset-ticket number is what got the project prioritized over three other things competing for the same headcount.
Why passwords were the wrong problem to keep solving
We had MFA. We had a password manager mandate. We had rotation policies nobody liked and phishing-awareness training people mostly forgot by lunch. None of it touched the actual failure mode, which wasn’t a sophisticated attack — it was an exhausted employee, at the end of a long week, typing their password into a login page that looked close enough to the real one. Passwords are phishable by design. No amount of complexity or rotation changes that; it just changes how annoying the phishable thing is to use.
The rollout, in three phases
Phase 1 — IT team only, six weeks
We didn’t announce anything company-wide. IT and platform engineering — forty people who’d tolerate rough edges and tell us about them directly — moved to passkeys first, password still available as fallback. This surfaced the two problems that would have generated the most help-desk tickets if we’d skipped straight to a full launch: a shared kiosk workflow that assumed a typed password, and a small number of managed devices without a usable platform authenticator. Both got fixed quietly, before anyone outside IT noticed.
Phase 2 — opt-in, company-wide, twelve weeks
We turned on passkey enrollment for everyone and made it the recommended path in every login prompt, but changed nothing about the password option. Adoption climbed steadily without a single mandatory session — we found that people switched fastest right after their own reset-ticket experience, so we added a one-line nudge to the password-reset confirmation email: “tired of this? set up a passkey in under a minute.” That single email line drove more enrollments than the launch announcement did.
Phase 3 — default-on, password de-prioritized
At the six-month mark, we flipped the default: new logins prompt for a passkey first, and reaching the password field takes an extra click most people never bothered to find. We didn’t remove passwords outright — see below — but we stopped treating them as the primary path.
We didn’t sell people on security. We sold them on never typing a password on a Monday morning again. That pitch worked in a way “protect the company” never does.
Where we deliberately kept passwords
Full elimination was never the goal, and we’re suspicious of anyone who claims they’re fully passwordless. Some things still need a break-glass path.
What surprised us
The resistance we braced for — “this feels less secure, I can’t see a password” — barely showed up. What people actually complained about was device-switching: a passkey tied to a work laptop didn’t automatically help on a personal phone used for occasional approvals, and syncing behavior across platform ecosystems wasn’t as seamless as the marketing suggested. We solved most of it with clearer guidance, not more technology. The lesson we keep repeating to other teams considering this: the security case for passkeys is real, but the adoption case is about deleting a chore from someone’s Monday. Lead with that, and the security follows on its own.