What should security teams do when customers still rely on passwords?

What changes when customers are still password-dependent?

Passwords remain a transitional control, not a destination. When customers still use them, security teams need to treat password journeys as a signal source, not just a login method: reset rates, reuse, lockouts, and phishing susceptibility show where the experience is weak and where attackers have the most leverage. That is the point at which migration planning becomes measurable rather than theoretical.

Security teams should also expect different customer segments to move at different speeds. High-volume, low-friction paths usually provide the cleanest first wins, while legacy journeys, recovery-heavy flows, and shared-account patterns tend to expose the most support cost and fraud exposure. A phased approach works best when the password path is still common enough to instrument and compare against newer authentication options.

Where password use persists, the operational question is not whether to tolerate it indefinitely, but which journeys are safest to retire first. Modern password guidance from Password Security and Password Manager Guide is useful here because it frames passwords as a managed exposure with concrete controls, including blocked weak secrets, phishing resistance, and the transition toward passwordless methods.

Which password journeys should move first?

The strongest candidates for early migration are the customer flows with the highest repetition and the highest support drag. Sign-in paths with frequent resets, repeated account recovery, or high abandonment are usually the best places to start because they combine security benefit with visible business impact. If a flow is heavily used, even a modest reduction in password friction can lower both help desk load and exposure to credential phishing.

Prioritisation should also consider the blast radius of compromise. Accounts tied to payments, stored profile data, shipping addresses, rewards balances, or admin-like support privileges should move earlier than low-impact identities because password compromise in those paths is more likely to become fraud or account takeover. In practice, the first wave should target the journeys where password risk and customer pain overlap most strongly.

That sequencing is easier to defend when teams measure real usage patterns rather than assuming that all users have the same readiness. For password-dependent populations, the migration order should be based on observed friction and exposure, not on a blanket cutover date.

How should teams manage the transition without breaking customer access?

The transition should be staged so that the password path remains available while the new method proves itself. A useful pattern is to offer passwordless as the preferred route for the highest-volume flows first, then expand it after recovery, device enrollment, and support handling are stable. This reduces the risk of forcing users into repeated fallback journeys that recreate the same friction the migration was meant to remove.

Passwordless rollout also needs a recovery design. If the fallback experience is poorly designed, users will simply shift from one weak path to another, often through SMS or email-based resets that remain attractive to phishers and social engineers. Security teams should therefore treat recovery, enrollment, and exception handling as part of the migration, not as edge cases to resolve later.

Identity guidance from NIST SP 800-63 Digital Identity Guidelines supports this approach by emphasising phishing-resistant authentication and assurance-aware design. For teams that need a control catalogue view, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for authentication, access control, and auditability expectations.

Risk and Threat Considerations

As long as customers still depend on passwords, attackers keep a large and familiar attack surface. Phishing, credential stuffing, password spraying, and recovery abuse remain attractive because they scale across many accounts and often succeed against reused or weak credentials. The main security risk is not the password itself alone, but the combination of user fatigue, recovery dependence, and the fact that the same login path often protects the most valuable customer functions.

Failure mechanism: Repeated password journeys create predictable points where attackers can harvest credentials, trigger resets, or exploit support workflows, especially when customers reuse secrets or move through high-friction recovery steps.

Impact: The result can be account takeover, fraud, customer support overload, and a slower migration because the most abused password flows remain the most costly to maintain.

Practitioner Guidance

What to prioritise: Start with the journeys that combine volume, reset activity, and fraud potential, because those are the flows where passwordless migration will produce the clearest security and operational gain. Use the password path itself as a measurement source, not just a legacy constraint.

What to verify: Confirm that enrollment, recovery, and fallback are all usable before you shift traffic, otherwise users will route around the new control and land in the same risk pattern through a different door. A passwordless program is only as strong as its exception handling.

Decision rule: If a customer path has high support cost or is exposed to phishing-driven takeover, move it ahead of low-value journeys even if the technical migration is slightly harder. If the path is low-risk and low-volume, keep it in the queue rather than forcing a premature cutover.

Practitioner takeaway: The objective is not to eliminate passwords everywhere at once, but to retire the password journeys where friction and exposure are already telling you the business case is strongest.

Related resources from NHI Mgmt Group

• How should security teams prevent account takeover in environments that still rely on passwords and OTPs?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams reduce cloud identity risk when passwords and credentials are still widely shared?