What happens when organisations keep relying on passwords for customer or citizen access?

They create more friction for users, more support burden for the business, and more opportunities for insecure behaviour. People forget passwords, abandon transactions, recycle credentials, and share access informally. Over time, that combination weakens security and disrupts commerce, especially when the service needs both low friction and strong identity assurance.

Why Password Reliance Breaks Down for Customer and Citizen Access

Passwords are a poor fit for high-volume external access because they place too much burden on the user and too much recovery work on the service desk. As transaction volume grows, the organisation absorbs more failed logins, reset requests, abandonment, and credential reuse. The result is not just inconvenience, but a weaker access model that is harder to support and easier to abuse.

For customer and citizen journeys, the failure is structural: a password is both a friction point and a control that users routinely work around. That matters most where the service needs low friction at scale, because every extra step raises drop-off and every weak workaround reduces assurance.

When organisations want stronger assurance without adding more friction, they typically move toward passwordless sign-in, phishing-resistant authenticators, or step-up checks for higher-risk actions rather than treating the password as the primary gate.

How Password Habits Create Security and Service Problems

Repeated password use encourages the behaviours defenders dislike most: reuse across sites, informal sharing, and predictable recovery patterns. Those habits make account takeover easier when credentials are exposed elsewhere, and they also increase the chance that legitimate users will bypass controls when access is urgent.

Customer identity journeys make this worse because account recovery becomes part of the attack surface. If recovery is too permissive, attackers can take over the account through reset abuse; if it is too strict, real users lose access and support queues grow. The business ends up paying for both sides of the control failure.

In practice, this is why CIAM programmes tend to focus on authentication strength, recovery design, and risk-based step-up rather than password complexity rules alone. A password policy can look strict on paper while still leaving the service exposed to reuse, phishing, and support-driven bypasses.

What Changes When Passwords Are the Default for External Access

At customer scale, passwords affect conversion, service cost, and trust at the same time. A login that is easy to forget or easy to fail reduces completed transactions, and a recovery flow that is too cumbersome pushes users toward weaker behaviour such as reusing a known password or asking support to intervene.

That trade-off is especially sharp for public-sector services and consumer platforms, where access must work reliably for large populations with uneven technical ability. The service still needs to know who is at the door, but the method must be both usable and resistant to casual abuse.

The most effective response is to treat authentication as a journey, not a one-time password event. Stronger assurance should be applied where risk increases, while routine access should remain as low-friction as possible so legitimate users do not create their own exceptions.

Risk and Threat Considerations

Passwords become a security liability when they are the main control for large external populations, because the same weaknesses that hurt usability also create predictable attack paths. Reuse, weak recovery, phishing, credential stuffing, and support-mediated bypass can all turn ordinary login friction into account compromise.

Failure mechanism: Users respond to password friction by reusing credentials, storing them unsafely, sharing access, or relying on weak recovery flows, while attackers exploit reused or phished secrets and the recovery process itself.

Impact: The organisation sees more account takeover risk, more help-desk load, lower completion rates, and less confidence that the person logging in is the real account holder.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	Passwords are the core external-authentication weakness described here.
Recommendation — Adopt stronger authentication methods and reduce password reliance for external access.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Password handling, resets, reuse and recovery directly affect authenticator lifecycle risk.
Recommendation — Enforce controlled authenticator lifecycle rules and tighten reset and recovery handling.
OWASP ASVS	V6 — Authentication	The question is about customer authentication friction and assurance in the login flow.
Recommendation — Verify stronger authentication requirements and reduce dependence on passwords alone.
CIS Controls v8	CIS-6 — Access Control Management	External access control weakens when passwords drive reuse and informal sharing.
Recommendation — Centralise access control decisions and remove avoidable password-driven exceptions.
NIST CSF 2.0	PR.AA-05 — Authenticator Management	Authenticator management is central to reducing password friction and takeover risk.
Recommendation — Manage authenticators to improve assurance while lowering password dependence.

Practitioner Guidance

What to prioritise: Replace password-only thinking with a journey-level view of sign-in, recovery, and step-up assurance. The most important question is not whether the password meets a policy, but whether the whole access flow can keep friction low without making compromise or recovery abuse easy.

What to verify: Check whether password resets, fallback channels, and support scripts can be used to bypass stronger authentication. If they can, the organisation has merely moved the weakest point away from the login box.

Decision rule: If the service supports high-volume customer or citizen access, treat passwords as a legacy compatibility layer and give priority to phishing-resistant methods, risk-based step-up, and tightly governed recovery.

Practitioner takeaway: The real problem is not that passwords are inconvenient, it is that inconvenience pushes users and support teams toward behaviours that quietly weaken both assurance and operational resilience.