What happens when banks require memorised passwords instead of supporting password managers?

Why Banks Push Customers Into Password Reuse

When a bank requires a memorised password, it is forcing customers to optimise for human recall rather than for account security. That usually drives reuse across services, predictable password patterns, or unsafe storage habits. In practice, the weakest link is rarely the bank alone, it is the broader credential footprint created when one password must survive in memory across many accounts.

The security problem is not simply “bad passwords.” It is the collision between a bank’s access model and how people actually manage credentials at scale. A password manager changes that model by letting a customer use a unique, long password without relying on memory, which reduces the chance that a compromise in one service cascades into banking access. Supporting password managers also aligns better with modern authentication guidance and with stronger credential hygiene in general. Password Security and Password Manager Guide

Memorisation also creates a hidden usability tax. If the login flow makes strong credentials harder to use, customers tend to simplify their behaviour elsewhere, for example by writing passwords down, saving them in notes, or reusing an old password that is already exposed. That means the bank may preserve a legacy control, but the real-world effect is often weaker overall account protection rather than stronger security.

How the Risk Spreads Beyond the Banking Account

The main consequence of forcing memorised passwords is that the bank account becomes one node in a much larger exposure graph. Reused credentials can be tested elsewhere after a breach, and a weak or recycled password can also be guessed or cracked more easily than a unique generated secret. Once one password is shared across services, a breach in an unrelated site can become a path into banking.

This is why password managers are more than a convenience feature. They let users keep strong, unique passwords without creating an unworkable memory burden, which reduces credential reuse and lowers the odds that one compromised service opens several others. The risk is not theoretical, because password manager failures and password reuse both have obvious blast-radius effects. LastPass breach 2022

There is also a secondary operational risk for the bank itself. If customers cannot manage strong passwords, support teams see more resets, more lockouts, and more recovery requests, which increases friction and can create pressure to weaken other controls. In other words, a memorised-password policy often shifts risk rather than removing it.

What a Better Authentication Stance Looks Like

A better approach is to make strong authentication usable enough that customers do not need to choose between security and memory. For many banking flows, that means allowing password managers, supporting passkeys or phishing-resistant options where available, and treating the password as one part of the control set rather than the only line of defence. The bank should also ensure its login and recovery journeys do not break autofill or password-manager use, because the control only helps if it fits the actual customer workflow.

That design choice also changes how you evaluate account compromise. If a customer is required to memorise credentials, you should expect a higher rate of reused secrets and weaker password discipline. If password managers are supported, the expected baseline shifts toward unique secrets and lower cross-service reuse, so any sign of compromise points more strongly to session theft, phishing, or other attack paths rather than ordinary memory-driven reuse. NIST SP 800-63 Digital Identity Guidelines

Risk and Threat Considerations

Forcing memorised passwords increases exposure to credential stuffing, reuse-based compromise, and unsafe storage workarounds. The risk compounds because one weak password habit can affect many accounts, not just the banking login.

Failure mechanism: Users cannot reliably remember unique strong passwords, so they reuse old ones, choose guessable variants, or store them insecurely, which expands the attack surface across services.

Impact: A compromise in one service can be replayed against banking, and the bank inherits the downstream blast radius of weaker customer credential behaviour.

Practitioner Guidance

What to verify: Check whether the bank’s login, recovery, and device trust flows work cleanly with password managers and modern browsers. If autofill is broken or discouraged, customers will route around the control with weaker habits.

Decision rule: If the account can be protected with a unique password plus a stronger second factor or phishing-resistant option, do not force memorisation as the main usability strategy. Make the secure path the easy path.

Common mistake: Treating password memorisation as a security control when it is really a usability constraint. The observable sign of success is not “customers can recall passwords,” but that they can use unique credentials without resorting to reuse or unsafe storage.

Practitioner takeaway: Bank authentication policy should reduce the need for human memory, because security improves when users can maintain unique credentials without compensating through reuse, notes, or other unsafe shortcuts.

Related resources from NHI Mgmt Group

• What happens when attackers gain access through valid credentials instead of stealing passwords directly?
• What happens when organisations treat password security as a once-a-year awareness exercise instead of an ongoing practice?
• What happens when organisations rely on passwords alone instead of layered account security?
• What happens when organisations rely on manual password review instead of automated blocking?