I Spent a Decade Building a Password Company. Here's Why I'd Tell You to Kill Yours

I founded a CIAM platform in 2013 and scaled it to over a billion user identities. For a decade, my technical life revolved around making passwords work: hashing them properly, rotating them sensibly, recovering them safely, layering on MFA when the basic primitive was not enough, building bot defenses to keep credential stuffers out, monitoring breach corpora to know when our users' credentials had leaked from somewhere else.

I am as proud of that engineering as anything I have built. And I would tell you, today, to kill yours.

This is not a marketing post. There is no upsell at the bottom. It is the conclusion I reached the hard way, and it is the conclusion every CISO I respect has reached too. We were defending the wrong castle.

The thing nobody told me on day one

When you start in identity, you spend the first six months learning that passwords are bad. You learn about rainbow tables, you learn about Argon2, you learn the difference between salting and peppering. You absorb the cybersecurity orthodoxy: the password is a flawed primitive, but with enough engineering, you can make it survive.

What no one tells you on day one is the second half of that lesson. The engineering keeps escalating. Forever.

Hashes need salts. Salts need peppers. Peppers need HSMs. The HSM strategy needs key rotation. Key rotation needs an operational team. The team needs runbooks. The runbooks need audits. And every additional control adds attack surface somewhere else.

Meanwhile, the user is typing the same password they used on a forum that got breached three years ago.

What a billion users taught me

When you operate authentication for a billion identities, you stop talking about edge cases. Every edge case happens to you, every day, thousands of times.

You learn that the rate of credential reuse across services is brutal. North of 60 percent of breached credentials work on a second site. We watched it in our logs.

You learn that account recovery is where attackers actually win. Not at the login screen. At the "I forgot my password" screen, where a security question becomes a social engineering attack.

You learn that SMS OTP fails in production well before NIST formally downgrades it. SIM swap attacks, telco vulnerabilities, regional carriers that route OTPs through systems no one audits.

You learn that the cost of fraud and support and engineering and compliance, summed across the whole stack, dwarfs any line item in the buy-versus-build spreadsheet. The password is not free. The password is the most expensive thing in your identity stack. You just do not see the line item.

And the worst part: every layer you add (MFA, KBA, adaptive risk, device fingerprinting) is paying down complexity interest on a primitive that should not exist anymore.

The moment the math flipped

For me, the moment was watching a passkey deployment. The support volume for "I forgot my password" dropped roughly 80 percent within a quarter. The account takeover rate on those accounts went to effectively zero. The flow was faster than the password flow. Users preferred it. Engineering had less to maintain.

That was the moment I understood what we had been doing wrong for a decade. We had been adding controls to a broken primitive when we should have been replacing the primitive.

Every credential breach that hits the news is downstream of this same mistake. The credentials in those dumps exist because the system requires them to exist. Replace the requirement and the dump becomes worthless. There is nothing to phish if there is nothing to type.

What I would tell my younger self

If I could send one message back to the day I started designing the auth stack, it would be this: do not optimize the password. Plan the migration off it.

Specifically:

Build passkey support as a first-class citizen, not a "feature flag for later." The infrastructure to manage WebAuthn credentials, attestations, account recovery for passkey accounts, multi-device sync, is the work. Start it on day one.

Treat MFA as a bridge, not a destination. Every dollar you spend hardening SMS or TOTP is a dollar you will throw away in 24 months. Skip the bridge if you can. Go to phishing-resistant directly.

Design recovery flows for a passwordless world from the start. Recovery is where attackers attack. If your recovery flow falls back to email or SMS, you have not gone passwordless. You have just hidden the password.

Measure the right thing. Login success rate matters less than fraud rate per successful login. Account takeover rate matters more than complexity score. You will not get the right behavior from your team unless you measure the right things.

The honest part

I am not anti-password because I read a paper. I am anti-password because I built and operated a password system at a scale where the failure modes were not theoretical. Every one of them happened. Many of them happened weekly.

A founder building today has an advantage I did not have in 2013: passkeys are real, browser support is broad, the platforms have shipped credential sync, and the user mental model is no longer alien.

You can launch a product in 2026 that has never had a password field, and a user can sign up in five seconds with biometrics, and the credential lives in a key store the user cannot read out and the attacker cannot type into your login form.

That is what I would build today. That is what I am building today, in the parts of the GrackerAI stack that touch identity, we have passwordless auth for our customers.

The decade taught me a lot. The biggest lesson was the one I did not want to learn. We were brilliant defenders of a primitive that should not have existed.

What is keeping you on it?

---

FAQ

Are passkeys really ready for production today?

Yes, with caveats. Browser support is broad, OS support is broad, and the major platforms now sync passkeys across a user's devices. The remaining hard problems are recovery flows when a user loses all devices, and enterprise lifecycle management, both of which are tractable.

Is going passwordless realistic for a B2C product with millions of users?

Yes, but not as a big-bang migration. The realistic path is to add passkey as an option, prefer it on subsequent logins, then require it for new accounts. Existing password users migrate over months, not weeks.

What about users without modern devices?

This concern is shrinking faster than most teams plan for. Passkey support is now standard on every device shipped in the last several years. For the long tail, magic links and one-time codes are reasonable fallbacks, with the understanding that they are not phishing-resistant.

Does this mean MFA was a waste?

No. MFA was the right interim step for a generation of products. The mistake is treating MFA as a destination rather than a bridge. The same engineering effort, applied to a passkey rollout, gets a better outcome.

What is the single highest-ROI move for a team still on passwords today?

Add passkey as an authentication option, default it for users who have enrolled one, and run that experiment for a quarter. The data will tell you the rest.

---

About the author

Deepak Gupta is a serial entrepreneur and cybersecurity researcher, who founded and scaled a CIAM platform to 1B+ users. He writes about AI, cybersecurity, and B2B growth at guptadeepak.com.