A 90-Day Rollout Plan
You do not need a two-year identity program to fix login. Most of the gains land in one quarter if you sequence the work so each phase pays for the next.
The plan below has three 30-day phases and a gate between each one. A gate is a measurable condition, not a meeting. If the gate is not met, you hold the phase and fix what blocked it, because skipping a gate is how passkey launches end up with high enrollment and flat usage.
Who owns what
Login touches four teams. Name one owner per team on day 1, and give them a shared dashboard and a 30-minute weekly review.
| Role | Owns | Accountable for |
|---|---|---|
| Product | Login and signup experience, enrollment copy, guest paths | Sign-in success, time to sign in, abandonment at the door |
| Security | Risk policy, step-up rules, recovery controls | Account takeover rate, fallback policy |
| Engineering | Instrumentation, vendor integration, rollout flags | Funnel data quality, release safety |
| Support | Help content, scripted recovery process, ticket tagging | Login-related tickets, recovery abuse reports |
One person should own the whole program. In my experience, product is the right home for that role, because the metrics that decide success are experience metrics with a security guardrail.
Days 1 to 30: measure and remove the obvious pain
Phase 1 costs little and needs no new vendor. It creates the baseline you will need to prove anything later.
Week by week
| Week | Work | Owner |
|---|---|---|
| 1 | Name owners. Instrument the login funnel. Start tagging login-related support tickets. | Product, Engineering, Support |
| 2 | Run the scorecard and three-person test from Chapter 12. Remove composition rules and scheduled expiry. Add breached-password screening. | Product, Security |
| 3 | Allow paste and password manager autofill everywhere. Fix error messages so they never reveal whether an account exists. | Engineering, Security |
| 4 | Make guest checkout or guest trial the most prominent path, with account creation after the first success. Review the baseline. | Product |
What to do
- Instrument the login funnel. Track first-attempt sign-in success, time to sign in, reset requests, MFA prompts per active user, and drop-off at the login and signup steps. Chapter 12 defines each metric with a formula.
- Run the scorecard and the three-person test on a new phone. Record the score; you will run it again on day 90.
- Remove password composition rules and scheduled expiry. Add breached-password screening. Chapter 3 covers what NIST SP 800-63B Revision 4 requires here.
- Turn on autofill support and allow paste everywhere.
- Make the guest path prominent. Offer account creation after the first purchase or trial success, as Chapter 7 describes.
- Fix error messages so they never reveal whether an account exists.
Deliverables
- A funnel dashboard with a baseline for every metric in Chapter 12
- A completed scorecard with the day-1 score
- Three-person test results, with every prompt and timing logged
- Updated password policy, live in production
- A tagged support-ticket view for login and recovery issues
Gate to phase 2: a working funnel dashboard and a baseline for every metric in Chapter 12. Without a baseline, phase 2 cannot prove it worked.
Days 31 to 60: launch passkeys the right way
Phase 2 is where most of the experience gain comes from. It is also where most rollouts stall, usually because passkeys are launched into a settings page instead of into the sign-in flow.
Week by week
| Week | Work | Owner |
|---|---|---|
| 5 | Finalize vendor using Chapter 9 and Chapter 10, or enable passkeys in your current platform. | Product, Security, Engineering |
| 6 | Ship identifier-first login with passkey autofill behind a feature flag. Release to internal users. | Engineering |
| 7 | Add enrollment prompts after sign-in, after reset, and after cross-device sign-in. Publish help content. Release to 10% of users. | Product, Support, Engineering |
| 8 | Add trusted-device memory. Stop MFA prompts on known devices. Expand rollout to 100% if metrics hold. | Security, Engineering |
What to do
- Pick your vendor, or turn on passkeys in your current platform.
- Ship identifier-first login with passkey autofill. Autofill (conditional UI) offers a saved passkey inside the username field, so returning users sign in with one tap.
- Add passkey enrollment at three moments: after sign-in, after password reset, and after cross-device sign-in. Enable conditional create where browsers support it, using Chrome's guide.
- Add trusted-device memory of 30 days or more, and stop prompting MFA on known devices.
- Publish a short help article and an in-product tooltip explaining what a passkey is, in plain words.
Deliverables
- Passkey sign-in and autofill live on web and mobile
- Enrollment prompts live at all three moments, with "not now" handling
- Trusted-device policy documented and live
- Help article and tooltip published; support trained on passkey questions
- Weekly report of passkey share of successful sign-ins, by platform
Gate to phase 3: passkey share of successful sign-ins rising week over week, and sign-in success flat or up.
Days 61 to 90: move friction to where risk lives
Phase 3 spends the friction you removed. Prompts move from every visit to the moments when an account takeover turns into a loss.
Week by week
| Week | Work | Owner |
|---|---|---|
| 9 | Implement step-up with a passkey for email changes, payout changes, and new factors. | Security, Engineering |
| 10 | Retire push approvals without number matching. Move SMS to fallback and recovery only. | Security |
| 11 | Harden recovery: two pre-registered methods, cool-down periods, notifications, scripted support process. | Security, Support |
| 12 | Review account takeover alongside friction metrics. Rerun the scorecard and three-person test. | Product, Security |
| 13 | Write the quarter review and set next-quarter targets. | Program owner |
What to do
- Implement the friction map in Chapter 8: step-up with a passkey for email changes, payout changes, new factors, and recovery.
- Retire push approvals without number matching. CISA's number matching fact sheet explains why. Move SMS to fallback and recovery only.
- Harden recovery. Require two pre-registered methods, add cool-down periods for high-value changes, notify users of every recovery event, and give support a scripted process.
- Review account takeover rates alongside the friction metrics.
Deliverables
- Step-up policy live for every action on the friction map
- Push and SMS policy changes live
- Recovery runbook for support, with an audit trail on every override
- Day-90 scorecard and three-person test, compared with day 1
- A one-page quarter review for leadership
Gate to the next quarter: account takeover flat or down while every friction metric improves. That result is the proof that security and experience were never a trade-off.
Risks and mitigations
Most rollout risks are predictable. Write this table into your plan on day 1 and review it in the weekly meeting.
| Risk | Early signal | Mitigation | Owner |
|---|---|---|---|
| No reliable baseline | Funnel numbers disagree across tools | Hold phase 2 until one dashboard is trusted | Engineering |
| High enrollment, flat usage | Passkey share of sign-ins lags enrollment | Add autofill; move passkey to the primary option | Product |
| Passkey failures on one platform | Failure rate spikes on one OS or browser | Segment by platform; fall back to email code there | Engineering |
| Users confused by "passkey" | Help-article views and tickets rise | Rewrite copy in plain words; add a tooltip | Product, Support |
| Recovery becomes the attack path | Recovery requests rise faster than users | Cool-downs, notifications, scripted support | Security, Support |
| Support bypasses factors | Overrides without a ticket trail | Require a verified process; audit every override | Support |
| SMS removal locks users out | Recovery tickets from users without passkeys | Keep SMS for recovery until passkey share is high | Security |
| Vendor or relying party mistake | Passkeys registered against a vendor domain | Register on your own domain from the first pilot | Engineering |
| Account takeover rises | ATO rate up week over week | Pause the latest change; tighten step-up first | Security |
Never change your relying party domain after customers enroll passkeys. Passkeys are bound to that domain, and moving it invalidates every one of them.
After day 90
Keep raising passkey share of sign-ins. Once it is high and stable, offer users a way to remove their password entirely, and start with your highest-value accounts. A passkey that sits next to a password still leaves the password for attackers and reset tickets.
Then run the quarter again. Each cycle should raise passkey share, lower MFA prompts per active user, and hold account takeover flat or down. I covered the longer-term version of this program in how to choose and roll out passwordless authentication.
Key takeaways
- Sequence the quarter so each phase pays for the next: measure, launch passkeys, then move friction to risk.
- Gates are measurable conditions; hold a phase when its gate is not met.
- Name one owner each in product, security, engineering, and support, with one program owner.
- Launch passkeys into the sign-in flow with autofill and enrollment moments, not into a settings page.
- Account takeover is the guardrail metric for every change you make.
Do this next week:
- Name the four owners and the program owner, and book a weekly 30-minute review.
- Copy the week-by-week tables into your project tracker with real dates.
- Start tagging login and recovery tickets in your support tool so phase 1 has a baseline.