What happens when banks and other institutions keep using identifiers as proof of identity?

The result is a growing fraud problem and a steady expansion of sensitive data that should not have to be secret. People are forced to protect identifiers that were never meant to function as credentials, while victims absorb the cleanup burden after misuse. The system also becomes brittle, because changing a compromised identifier is often far harder than changing a password.

When identifiers are treated as proof of identity

The failure starts when a number, email address, account number, or similar identifier is used as if it were a credential. In practice, that turns a stable reference into a reusable access secret. Banks and other institutions then create a system where the identifier itself becomes attractive to attackers, because compromise is easier, reuse is common, and the identifier may appear in many legitimate business processes.

This also distorts the security model. An identifier is meant to name an account or person, not prove control over that account or person. Once the two roles are merged, the organisation loses a clean boundary between public-facing information and authentication material.

Why misuse spreads beyond fraud alone

When identifiers stand in for identity proof, the control problem compounds across onboarding, support, payments, and dispute handling. Each business process that accepts the identifier as sufficient proof reinforces the same weak assumption, so fraud pressure does not stay isolated. It tends to expand into credential reset abuse, account takeover, social engineering, and “prove who you are” workflows that leak more data than they should.

Institutions also end up storing and exposing more sensitive data than the business truly needs. If the identifier can be used to authenticate, then it must be protected like a secret, even when it was never designed for that role. That creates unnecessary data sensitivity, broadens the attack surface, and increases the number of systems that must safeguard the same value.

Why this makes identity systems brittle

The brittleness comes from poor revocation and poor recovery. If a password is compromised, it can be replaced. If an identifier is compromised and continues to function as proof, the institution may be forced to change customer-facing records, cross-system references, and downstream integrations just to restore trust. That is operationally expensive and often incomplete.

The result is a system that is harder to rotate, harder to contain, and harder to explain after misuse. It also encourages compensating controls that accumulate over time, such as extra challenge questions or manual reviews, which often fail under scale or are themselves vulnerable to social engineering.

Risk and Threat Considerations

Using identifiers as proof of identity creates a durable fraud path because identifiers are easy to observe, share, and reuse. Once they are accepted as authenticators, an attacker does not need to defeat a real authentication factor, only to obtain or guess a value that the institution has made overly powerful.

Failure mechanism: the organisation collapses identifier, account reference, and authentication factor into one object, so compromise of a widely exposed identifier becomes enough to impersonate the holder or trigger account recovery abuse.

Impact: fraud scales across channels, recovery workflows become high risk, and the institution inherits a larger population of sensitive values that must be protected like secrets even though they were never meant to serve that role.

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 surface, NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the technical controls, and GDPR defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Identifiers used as proof are an authentication-design failure.
	IA-5 — Authenticator Management	Compromised identifiers create lifecycle and recovery problems similar to weak authenticators.
Recommendation — Require a real authentication factor, not an identifier alone, for user verification. Manage lifecycle, rotation, and revocation for values that function as authenticators.
NIST SP 800-63	Digital Identity Guidelines	The topic is about separating identifiers from authenticators in identity proofing.
Recommendation — Use assurance and authenticators that do not rely on predictable identifiers as proof.
CIS Controls v8	5 — Account Management	The issue affects account verification, lifecycle, and misuse of account identifiers.
Recommendation — Harden account verification and ensure identifiers are never treated as sufficient proof.
GDPR	A.5.1 — EU General Data Protection Regulation	The answer concerns unnecessary accumulation and protection of sensitive personal data.
Recommendation — Minimise identifier exposure and limit collection to what is needed for the stated purpose.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	When identifiers are used like credentials, they become sensitive values that should not be exposed.
	NHI-05 — Overprivileged NHI	The design gives identifiers more authority than they should have.
Recommendation — Treat any identifier that can authenticate access as secret material and restrict its exposure. Remove authentication authority from identifiers and keep privilege tied to real credentials.

Practitioner Guidance

What to verify: confirm that no identifier is accepted as a standalone proof step in login, reset, dispute, or servicing flows. If a value can be publicly observed, customer-shared, or reused across products, it should be treated as an identifier, not as an authenticator.

What to prioritise: separate naming from verification. The practical test is whether compromise of the value would let someone act as the customer without a second, stronger check. If yes, the design is mixing identity reference with identity proof.

Practitioner takeaway: the key judgement is to keep identifiers searchable and usable for operations, but never powerful enough to stand alone as evidence of identity.