What breaks when payment environments keep passwords or OTPs as fallback authentication?

Why fallback passwords and OTPs break a payment control already weakened by passkeys

fallback authentication reintroduces the same reusable secret model that passkeys are meant to replace. If a payment environment still allows a password, SMS OTP, or weak reset path as an alternate route, attackers can target the weakest branch instead of the strongest one. That means the real control boundary is the whole login and recovery flow, not the primary factor alone.

In practice, fallback also creates a policy exception that users, support teams, and integrators can exploit under pressure. A control that depends on “use passkeys unless something goes wrong” is only as strong as the exception handling, which is why payment-sector authentication guidance increasingly treats recovery and fallback as part of the authentication design rather than a separate convenience layer. See the NIST SP 800-63 Digital Identity Guidelines for the wider expectation that authenticator strength and phishing resistance matter at the assurance level, not just in the nominal login path.

For payment systems, the practical question is whether the fallback can still be phished, replayed, stuffed, or reset through social engineering. If yes, the environment still has a reusable secret path that can satisfy the attacker without defeating the stronger factor. The issue is not whether passkeys exist, but whether they are mandatory enough to eliminate the legacy path as an operationally usable alternative.

What attacker paths remain when passwords or OTPs are kept as fallback

Passwords, SMS OTPs, and other fallback secrets preserve multiple attack paths. Credential stuffing works when the same password is reused elsewhere. Phishing works when users can be pushed to reveal the backup secret. OTP relay works when the attacker can intercept or forward the one-time code in real time. And if help desk recovery can override the stronger factor, the control can fail without the attacker ever needing to break the passkey itself.

That is why fallback is often the true bypass, not an edge case. The user may believe they are protected by modern authentication, but the attacker only needs one accepted alternative to land in the account and then move into payment workflows, stored cards, refunds, or merchant administration. The MFA Guide is useful here because it shows how fatigue, relay, and legacy factors keep a weaker path alive even when a stronger method has been added.

Payment environments are especially sensitive because access often maps directly to money movement, card data, or account changes. A weak fallback does not just raise login risk, it expands the blast radius of a compromise into fraud, unauthorized payment action, and possible regulatory exposure. That is why the control fails at the point where the weakest accepted factor remains usable, not at the point where the preferred factor was deployed.

Why payment teams should treat recovery, reset, and exception paths as part of the control

A secure payment authentication design has to cover enrollment, primary sign-in, recovery, and support escalation as one system. If any one of those steps still accepts a reusable password, a shared OTP, or an easily social-engineered reset, then the attacker will concentrate there. The control should therefore be judged on the weakest allowed path, not on the strongest factor in the normal flow.

That also means operational teams need to decide which fallback paths are truly temporary and which are standing exceptions. If a fallback is required for business continuity, it should be tightly bounded, highly monitored, and removed as soon as the user can complete a phishing-resistant method again. The Passwordless and Passkeys Guide is a useful companion because it focuses on rollout and recovery discipline, which is where many implementations lose their security advantage.

Where payments are in scope, the control objective is not just “add passkeys”, it is “remove the reusable-secret escape hatch.” If a password reset or OTP fallback remains available for routine use, the environment still tolerates the very account takeover patterns PCI DSS 4.0 is trying to suppress. A good implementation makes fallback rare, observable, and procedurally expensive, not normal and user-friendly.

Practitioner Guidance

What to verify: Verify whether the fallback path can authenticate without the phishing-resistant factor, and whether support staff can bypass it during resets or recovery. If either is true, the control is not complete even if passkeys are deployed.

Decision rule: If the fallback is a reusable secret or a real-time code that can be relayed, treat it as an attack path that must be retired, not just documented. If it must remain, limit it to tightly controlled exception handling with strong monitoring and a defined expiry.

What good looks like: The preferred sign-in method is the only routine route into payment systems, while recovery is rare, logged, and reviewed. Users do not rely on passwords or OTPs for normal access, and help desk staff cannot casually restore those methods without challenge.

Practitioner takeaway: The security gain from passkeys is only real when the fallback is removed or made materially harder to abuse; otherwise the weakest acceptable path still defines the control.

Related resources from NHI Mgmt Group

• What breaks when payment organisations rely on passwords or PINs alone for customer payment authentication?
• What breaks when organisations keep passwords in the authentication stack but hide them from users?
• Why is OAuth token management critical in cloud environments?
• How should security teams authenticate AI agents in enterprise environments?