TL;DR: A bank account access failure after Pope Leo XIV’s elevation shows how knowledge-based identity verification breaks when names, addresses and life circumstances change, according to Prove Identity. Static checks protect systems on paper, but they create friction, abandonment and weak fraud resistance in real-world identity journeys.
At a glance
What this is: Prove Identity argues that static identity verification fails when real-world personal details change, using Pope Leo XIV’s bank access problem as a vivid example.
Why it matters: For IAM, fraud and identity verification teams, the lesson is that identity assurance must cope with life events, not just stored facts, or legitimate users will be blocked while attackers still slip through.
By the numbers:
- 1 in 4 users abandon account access due to verification failures.
- ~35 min average hold time for identity-related customer service calls.
- $29B annual cost of identity fraud.
Context
Identity verification fails when it treats a person as a fixed record instead of a changing relationship between data, devices and real-world activity. That failure shows up most sharply in consumer banking and account recovery, where knowledge-based questions and stale profile data create both friction and weak assurance.
The article’s papal example is unusual, but the underlying governance problem is ordinary: systems often assume names, addresses and other biographical facts remain stable long enough to serve as reliable proof. In practice, identity changes are normal, and verification models that cannot absorb them push legitimate users into failure states while leaving fraudsters room to exploit static answers.
Key questions
Q: What breaks when banks rely on static PII for identity verification?
A: Static PII breaks when the same personal data can be stolen, bought, or assembled from breaches and used to pass checks that were designed to prove uniqueness. It also fails when fraud models score risk using the same compromised attributes. Banks need layered verification that includes behavioural signals, device intelligence, and document authenticity.
Q: Why do static identity checks create both friction and fraud risk?
A: Static checks fail when legitimate users change names, addresses or roles, so they generate unnecessary support calls and abandonment. At the same time, the same questions are often weak against attackers who can find answers in breached data or public records. The control creates inconvenience without delivering durable assurance.
Q: How should organisations verify identity when personal details change over time?
A: They should move away from static knowledge checks and use a layered model that combines device context, behavioural history, account relationships and lifecycle-aware recovery rules. The goal is to verify the person, not just recall old data. This approach reduces false failures for legitimate users while giving attackers fewer easy questions to answer.
Q: How do teams know if their verification flow is too brittle?
A: Watch for high abandonment, repeated support calls, escalating manual reviews and users who fail only because their life circumstances changed. Those signals show the system is overdependent on static data and underusing current context. A resilient flow should accept normal life changes without turning every exception into a manual exception case.
Technical breakdown
Why knowledge-based identity verification breaks
Knowledge-based identity verification depends on facts that are easy to store but hard to keep current. Questions such as past addresses, maiden names or first pets were once treated as proof because they were presumed private and stable. In modern life, both assumptions fail. Data brokers, breaches and social media make answers discoverable, while marriage, relocation, immigration and title changes make the data itself outdated. The mechanism is therefore fragile in two directions: it excludes legitimate users whose details have changed and it overtrusts information that attackers can often reconstruct.
Practical implication: Treat static challenge questions as a weak fallback, not a primary identity proofing control.
How dynamic identity signals improve assurance
Dynamic identity verification uses signals that evolve with the person, such as device history, account tenure, carrier relationships and observed behavioural patterns. The point is not simply to add more data, but to anchor trust in relationships that are harder to fake and more likely to persist across life changes. This approach shifts the problem from memorising biographical trivia to evaluating continuity of identity over time. For identity programmes, that changes the architecture from one-off challenge events to an ongoing trust model that can survive name changes, address moves and new account contexts.
Practical implication: Build verification flows around continuously refreshed signals rather than isolated question-and-answer checks.
What unified authentication changes in the verification flow
Unified authentication treats identity assurance as a continuous layer across account opening, recovery and payment approval. Instead of forcing each event to restart the trust decision from zero, it reuses the same evolving identity intelligence across the journey. That matters because many failures happen when the system loses context between stages and falls back to weaker methods. In governance terms, the control objective is continuity of trust, not repeated proof by trivia. That is especially relevant where user populations are mobile, multilingual or likely to experience life-event-driven identity changes.
Practical implication: Preserve identity context across journeys so recovery and reauthentication do not collapse into brittle step-up checks.
NHI Mgmt Group analysis
Static identity is a governance liability, not just a user-experience problem. When verification assumes biographical data remains fixed, the control fails precisely at the moments users most need account continuity. That creates both exclusion for legitimate users and a larger attack surface for adversaries who can often infer the same data from breaches or open sources. The practitioner takeaway is that static knowledge checks should no longer be treated as sufficient proof of identity.
Continuous identity assurance is becoming the more durable model for consumer access. The real shift is from proving that someone once knew a fact to proving that their identity relationship remains consistent across time, devices and transactions. This matters for fraud teams and IAM architects because it aligns assurance with how people actually live, move and change. The practical conclusion is to favour signals that age well and to retire controls that depend on frozen personal details.
Identity verification and fraud prevention are converging on the same control problem. A system that is easy for legitimate users to outgrow is also easier for attackers to game through static data exposure. That makes the boundary between convenience and security much narrower than legacy programmes assume. The practitioner conclusion is to design verification flows that reduce abandonment without accepting stale facts as the basis of trust.
Verification friction is an operating cost, not a minor nuisance. Every failed reset, abandoned call and prolonged queue reveals a control that is misaligned with real identity behaviour. Organisations should treat those failures as evidence of architectural drift between policy and lived identity patterns. The practitioner conclusion is to measure verification success by resilience to life changes, not by how often users can answer old questions.
What this signals
Static identity verification creates governance debt because it treats change as an exception instead of the normal case. When proofing logic cannot absorb marriage, relocation, name changes or cross-border movement, teams end up compensating with manual review and support escalation. The better design principle is continuity of trust, with proofing signals that remain meaningful as a person’s life changes.
Dynamic identity signals shift the control point from memory to relationship. That matters for financial services, telecom and any programme that needs to recognise the same customer across multiple journeys without re-litigating identity each time. The practical implication is that IAM and fraud teams should align around current signals, not stale biographical challenge data.
For practitioners
- Replace security questions with dynamic proofing Use continuously updated signals such as device history, account tenure and carrier relationships for account recovery and step-up verification. Reserve static questions only as a last-resort fallback and track how often they still decide access.
- Map identity journeys for life-event failure points Review onboarding, recovery and payment authorisation flows for name changes, address changes, relocation and other common life events that break traditional verification. Identify where users are forced to restart from zero and redesign those steps.
- Reduce abandonment in recovery workflows Measure where users drop out during identity-related support calls and recovery flows, then simplify the path before adding more questions. Long queues and repeated challenge loops are signals that the control model is failing legitimate users.
- Treat fraud resistance and user continuity as one design problem Align fraud controls with IAM recovery so the same assurance model supports both security and accessibility. If fraud teams and identity teams use different proofing standards, attackers will look for the gap and legitimate users will feel the friction.
Key takeaways
- Static identity checks fail when the real world changes faster than the record they were built on.
- The article shows that bad verification hurts both security and usability, which makes it a governance problem as much as a fraud problem.
- Identity programmes should move toward continuously updated proofing signals that survive life events and reduce avoidable abandonment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63A — Enrollment and Identity Proofing | The article is fundamentally about proofing users when static data no longer represents them. |
| SP 800-63B — Authentication | The article’s verification flow depends on authentication factors that remain usable across life changes. | |
| Recommendation — Use SP 800-63A to strengthen identity proofing around current evidence, not stale biographical trivia. Apply SP 800-63B to prefer stronger authenticators over knowledge-based recovery questions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Verification failures directly affect who can regain access to accounts and services. |
| Recommendation — Align access recovery with PR.AA-05 so authorisation decisions use current identity assurance. | ||
| GDPR | Art.5 — Principles relating to processing of personal data | The topic concerns processing personal data that can become inaccurate or stale over time. |
| Recommendation — Keep identity data accurate and up to date under Art.5 by limiting reliance on obsolete attributes. | ||
Key terms
- Knowledge-based authentication: A verification method that asks a person to prove identity by answering facts such as past addresses, account details, or other shared information. It is operationally convenient but weak against social engineering, breach data, and impersonation, which is why it performs poorly in high-risk support flows.
- Dynamic identity signals: Identity evidence that changes with the person and the context, such as device history, account behaviour and relationship signals. These signals are harder to fake than static biographical data because they reflect continuity over time rather than a frozen record.
- Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.
- Continuous authentication: A model where access is re-evaluated after the initial login instead of being trusted for the full session. It uses live signals such as posture, telemetry, and policy to detect when a session should be stepped up, constrained, or revoked.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity governance to operational decisions across access, assurance and lifecycle control.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org