Login Is a Revenue Problem Wearing a Security Badge
About this playbook
Most login screens are designed by security teams for auditors, then handed to customers. This playbook is for the people who live with the result: product leaders, CTOs, security architects, growth teams, and founders who suspect their login is costing them users.
You will get:
- The business case for fixing login, with 2025 and 2026 data
- What NIST, CISA, and the FIDO Alliance now say about passwords, passkeys, and MFA
- A risk-based model that removes friction where users live and adds it where damage happens
- A comparison of every major passwordless method
- Evaluation criteria and recommended vendors for passwordless and passkey authentication
- A 90-day rollout plan and a 20-point scorecard you can run this week
A note on numbers. Every statistic links to its source. Where I give my own benchmark or opinion, I label it as such. Vendor pricing and features change often, so verify current details with each vendor before you buy.
The 11 p.m. checkout
A shopper on a new phone at 11 p.m. has a full cart and a card in hand. Your site asks them to sign in. They type the password they think they used, get it wrong twice, and tap "Forgot password." The reset email lands in a promotions tab they never open. The cart sits there until it expires.
Nothing in your security dashboard records that as a failure. No attacker was blocked and no alert fired. Your finance team sees one fewer order and no explanation.
That shopper is not rare. Half of US adults (51%) have abandoned an online purchase because they forgot a password or could not log in. Among Gen Z, it is 72%. (HostingAdvice survey via Chain Store Age) Even among baby boomers, the group most used to passwords, the figure is 37%. (Scripps News on the HostingAdvice survey)
Baymard Institute sees the same leak from the checkout side. Returning customers who had to reset a forgotten password produced an 18.75% average checkout abandonment rate in its usability testing. That loss never shows up cleanly in a funnel report. The user simply stops coming back.
Three costs most brands never add up
Login costs show up in three different budgets, owned by three different teams. That is why nobody adds them together.
1. Lost conversions
A shopper who decided to buy and then hit a password wall is the most expensive kind of abandonment. You already paid to acquire them. You already won the argument about price and product. You lost them on a form field.
This cost hides because most analytics tools treat "sign-in page viewed, no purchase" as ordinary drop-off. It looks the same as a browser who was never going to buy. Unless you instrument first-attempt sign-in success, you cannot separate the two.
2. Support cost
Password resets and lockouts are among the most common support contacts. Each one is a ticket, a chat session, or an email loop that a human may have to touch.
Passkey deployments have reported up to an 81% drop in login-related help desk incidents. (FIDO Alliance) The 2026 edition of the same index adds a second cost line. Every participant that shared savings data reported lower SMS one-time-code costs, with annual savings ranging from about $1 million to hundreds of millions of dollars. (FIDO Passkey Index 2026)
SMS codes are a direct per-message expense. Every sign-in that falls back to a text message is a small invoice from your messaging provider.
3. Breach exposure
Stolen credentials were the top initial access vector in the 2025 Verizon Data Breach Investigations Report (DBIR), at 22% of breaches. (Verizon) The report covered 12,195 confirmed data breaches. In basic web application attacks, 88% involved stolen credentials. (Stingrai summary of Verizon DBIR 2025)
For a consumer brand, the most common version is credential stuffing. Attackers take username and password pairs leaked from another site and replay them against yours. Every customer who reused a password inherits someone else's breach. If your login is the one that lets the attacker in, the headline carries your name. (How credential stuffing works and how to stop it)
Putting a number on it: a worked example
You can estimate the size of the problem in an afternoon. The inputs below are illustrative round numbers, not benchmarks. Replace every one with your own data.
| Input | Illustrative value | Where to get yours |
|---|---|---|
| Sign-in attempts per month at checkout | 100,000 | Analytics event on the sign-in step |
| First-attempt sign-in failure rate | 15% | Failed submits divided by attempts |
| Share of failures that never complete a purchase | 30% | Sessions with a failure and no order |
| Average order value | $60 | Commerce platform |
| Password reset tickets per month | 4,000 | Help desk tags |
| Fully loaded cost per ticket | $5 | Support operations |
With those inputs, the arithmetic runs like this:
- 100,000 attempts times 15% failure gives 15,000 failed first attempts.
- 30% of those never buy, which is 4,500 lost orders.
- 4,500 orders times $60 is $270,000 in monthly revenue at risk.
- 4,000 tickets times $5 is $20,000 a month in support cost.
Add your SMS spend and an expected cost of account takeover, and you have a line item a CFO will read. The exact figure matters less than the order of magnitude. In most models I have seen, lost conversion dwarfs support cost, and both dwarf the cost of fixing the screen.
Do not claim the full revenue figure as recoverable. Some of those shoppers would have left anyway. Use the number to size the opportunity, then measure the real lift after each change in Chapter 11's rollout plan.
The false trade-off
For two decades, brands accepted a bargain: more security means more friction. Complex passwords, rotation rules, and MFA on every visit were the price of safety.
That bargain was always weaker than it looked. Each "safe" rule has a predictable side effect:
- Complexity rules produce predictable passwords. People meet the rule with the smallest possible change, such as a capital first letter and an exclamation mark at the end.
- Constant MFA prompts train users to approve requests blindly. Attackers exploit that habit with push bombing, which Chapter 6 covers.
- Every extra step pushes users toward password reuse. Reuse is exactly what credential stuffing feeds on.
- Forced resets create a fresh attack surface. A reset flow that can be talked through by a support agent is a login with fewer checks.
The result is a login that is both annoying and weak. You paid for friction and got very little security for it.
The fix is not to pick a side. Passkeys are the clearest proof. In the 2026 FIDO Passkey Index, passkey sign-ins succeeded 93% of the time, versus 78% for passwords and traditional MFA. They were 2.8 times faster. Every participant that measures phishing reported fewer successful attacks after deploying them. (FIDO Passkey Index 2026) That is one change moving both numbers in the right direction.
Who owns login decides how it feels
I spent years building a CIAM (customer identity and access management) platform that scaled to more than 1 billion users. The pattern I saw over and over: login was owned by security, measured by audits, and never designed as a product.
When security owns login alone, the success metric becomes "nothing bad happened." That metric cannot see the shopper who left at 11 p.m. When growth owns it alone, the metric becomes conversion, and controls get quietly removed until a takeover wave arrives.
The brands that broke out of this treated login as the first experience a customer has with them, not the last line of defense. They gave it a shared owner and two kinds of metrics on the same dashboard.
| Experience metrics | Security metrics |
|---|---|
| First-attempt sign-in success rate | Account takeover rate |
| Median time to sign in | Credential stuffing attempts blocked |
| Password resets per 1,000 active users | Share of sign-ins using a phishing-resistant method |
| MFA prompts per active user per month | Recovery events followed by sensitive changes |
| Drop-off at sign-in and signup steps | Fraud losses tied to account access |
If a change improves one column and damages the other, it is not done. Chapter 12 turns this table into a monthly review.
Common mistakes when making the case internally
- Leading with breach fear alone. Executives have heard it for years. Pair every risk number with a revenue or cost number.
- Quoting industry averages instead of your own funnel. A single week of your own sign-in failure data persuades more than any survey.
- Treating login as an IT project. It touches product, marketing, support, fraud, and legal. Put one accountable owner on it.
- Promising "passwordless" as a launch date. Passwords fade gradually. Promise measurable steps instead, like the passkey share of sign-ins rising each month.
How the rest of this playbook works
The short version: put friction where risk is, remove it everywhere else, and replace the password with something both safer and faster.
- Chapter 2 shows how to score risk so that friction follows it.
- Chapters 3 and 4 cover the new NIST password rules and passkeys.
- Chapters 5 to 7 compare methods, fix MFA fatigue, and redesign the screen and recovery.
- Chapter 8 combines all of it into one friction map, a policy table you can adopt.
- Chapters 9 and 10 help you choose a vendor.
- Chapters 11 and 12 give you a 90-day plan, a scorecard, and the three-person test.
If you want the background on why passwords fail at scale, my earlier ebook covers it in depth: The Case Against Passwords.
Key takeaways
- Login trouble has made 51% of US adults abandon a purchase, and 72% of Gen Z. That is revenue you already paid to acquire.
- Bad login costs land in three budgets: lost conversions, support and SMS spend, and breach exposure. Add them up in one model.
- Stolen credentials were the top initial access vector in the 2025 DBIR, so friction-heavy password rules are not buying the safety they promise.
- Passkeys break the trade-off: higher sign-in success, faster sign-in, and fewer successful phishing attacks in the same deployments.
- Give login one owner and measure experience and security on the same dashboard.
Do this next week:
- Add an analytics event for first-attempt sign-in success, and pull one week of data.
- Ask your support lead for last month's count of password reset and lockout contacts.
- Fill in the worked example above with your own numbers and share it with finance.
- Name a single owner for login who answers for both columns of the metrics table.