Person-centric account recovery is exposing IAM blind spots

At a glance

What this is: This is a case-study-driven analysis of account recovery, showing that traditional reset and reactivation flows are easier to abuse than primary authentication.

Why it matters: It matters because IAM teams often harden sign-in while leaving recovery paths under-governed, even though those flows can become the real takeover route for customers and support operations.

By the numbers:

• The bank said its recovery process achieved a 97-98% success rate for legitimate customers completing biometric verification.
• The revised process completes in approximately 80 seconds.

Context

Account recovery is the part of IAM that restores access when the original sign-in path no longer works. In practice, it often relies on weaker proof than the primary authentication flow, which creates a structural gap that attackers can target directly.

This article uses Raiffeisen Bank as a real-world example of what happens when recovery depends on knowledge factors, SMS-based checks, and device trust rather than verified personhood. For IAM teams, that makes recovery design a governance issue, not just a support problem.

The article’s central point is that recovery can become the easiest route into an account when organizations optimize for convenience before they define who is actually being recovered.

Key questions

Q: What breaks when account recovery relies on security questions and SMS codes?

A: Those methods break when an attacker already has enough context to impersonate the user or intercept the recovery channel. They prove possession or remembered facts, not live identity, so they can be satisfied even when the account is already under pressure. That makes recovery the easiest path to takeover when primary authentication is stronger than the reset flow.

Q: Why do weak recovery flows increase account takeover risk?

A: Weak recovery flows create a parallel access path that often bypasses the controls used at sign-in. If attackers can complete recovery through support scripts, SMS interception, or inbox compromise, they can bind a new device and seize the account without ever defeating the primary authentication flow.

Q: How can security teams tell whether recovery controls are too weak?

A: Look for repeated resets, frequent support escalation, and recovery methods that depend on information available in public sources. If an attacker could plausibly satisfy the process using social engineering or open data, the recovery flow is not offering the same assurance as the login flow.

Q: Should organisations use biometrics or help desk verification for account recovery?

A: They solve different problems. Biometrics are better when the organization needs to verify the real person remotely, while help desk verification can still play a role in escalations that require human review. The key decision is whether the recovery event creates enough fraud risk to justify live person verification before access is restored.

Technical breakdown

Why recovery flows are easier to abuse than primary sign-in

Recovery flows often sit outside the strongest authentication design because they are built to restore access, not defend the normal sign-in path. That makes them attractive to attackers who have already obtained partial customer data, social engineering leverage, or control of a phone number. Security questions, SMS OTP, and email-based reset flows all prove possession or remembered facts, but not necessarily the person requesting access. In a banking context, that difference is decisive because recovery can be the final step before account takeover and fraudulent device binding.

Practical implication: treat recovery as a privileged access path and apply stronger controls than the flows it restores.

Why device-native biometrics do not prove the right person

Device biometrics such as a fingerprint reader can confirm that someone knows a phone’s unlock code at a point in time, but they do not reliably establish live identity for recovery. That is why device-native checks can be satisfied even when the requesting user is not the legitimate account holder, especially if a device has been shared, coerced, or previously compromised. Person-centric verification changes the model by testing the individual, not the handset, and by adding liveness so the check is tied to a real person in real time rather than a cached device state.

Practical implication: separate device authentication from person verification when recovery can lead to account reactivation or new-device binding.

How liveness and document checks change the recovery trust model

A person-centric recovery flow combines identity proofing, document verification, liveness detection, and a final compliance step so the organization can bind recovery to the actual user. Liveness matters because it reduces the value of remote impersonation, replayed images, injected video, and other presentation attacks. Document checks add a second independent signal, while a post-verification token or OTP can satisfy regulatory or audit requirements without becoming the primary trust anchor. The mechanism is not about more friction. It is about moving trust from static knowledge and device possession to live personhood.

Practical implication: design recovery so each step adds a different assurance signal rather than repeating the same weak factor in another form.

Threat narrative

Attacker objective: The objective is to convert a legitimate account recovery event into unauthorized access on an attacker-controlled device and then extract funds.

1. Attackers begin with social engineering, impersonating bank staff or police to persuade customers to hand over internet banking access and recovery details.
2. They then use the compromised recovery process to activate mobile banking on an attacker-controlled device, turning the recovery flow into a device-binding abuse path.
3. Once the new device is bound, the attacker gains direct account access and can steal funds or continue fraudulent activity through the compromised banking session.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Account recovery is a privileged access path, not a customer-service afterthought. When organizations harden primary login but leave recovery flows dependent on security questions, SMS codes, or inbox access, they create a secondary control plane that attackers can target first. The governance error is treating recovery as an operational convenience layer rather than as a high-risk identity decision point. Practitioners should classify recovery as part of the access lifecycle and govern it accordingly.

Person-centric verification is the right control model when recovery can trigger new trust relationships. The core issue is not whether a customer can complete a flow, but whether the flow proves the actual person who should regain control. Device-centric checks can validate possession, while recovery needs assurance of live presence plus identity. That distinction matters because recovery often leads directly to device re-binding, a new privilege boundary that deserves stronger proof than a forgotten-password reset.

Biometric recovery exposes the limits of knowledge-based and possession-based recovery assumptions. Security questions, SMS OTP, and email resets were designed for a threat model in which the attacker lacked both the customer’s context and the recovery channel. That assumption fails when criminals already know enough to impersonate support, control a number, or intercept messages. The implication is that recovery governance must stop assuming the recovery channel is independent of compromise.

Operational scale is part of the security argument, not separate from it. The article shows that high-volume recovery creates support pressure, customer frustration, and incentives to weaken controls in the name of usability. The smarter model is to make secure recovery self-serviceable at scale without reducing the assurance standard. Practitioners should judge recovery controls by both takeover resistance and the support burden they displace.

What this signals

Recovery governance now belongs in the same risk conversation as sign-in policy. Many programmes still assume that the hardest part of IAM is authentication, but recovery often creates the most exploitable exception path. Teams should review whether their reset and reactivation processes can be used by an impersonator without ever touching the primary login controls.

Person-centric recovery changes the control objective from access restoration to identity revalidation. That shift matters because a recovery transaction often creates a new device trust relationship and a new fraud opportunity at the same moment. IAM teams should treat that moment as a high-assurance checkpoint, not a convenience flow.

Recovery design is now a support, fraud, and identity problem at once. When organizations reduce branch visits or help desk load without changing assurance, they may simply move the abuse path into a faster channel. The programme signal to watch is whether secure recovery remains available at scale without lowering the identity standard.

For practitioners

• Redesign account recovery as a high-risk IAM journey Map every recovery step that can restore access, bind a new device, or reopen a locked account, and assign stronger assurance to those paths than to ordinary sign-in.
• Replace knowledge-based recovery with person-centric verification Remove security questions and similar static recovery checks where they remain in use, and require live person verification for remote reactivation or device transfer.
• Separate device trust from identity proofing Do not treat a trusted phone or enrolled device as proof of the rightful account holder when the recovery event creates a new trust relationship.
• Review support-assisted recovery as a fraud control surface Audit help desk and branch-assisted recovery paths for impersonation risk, escalation steps, and manual override points that attackers can exploit.
• Measure recovery success against abuse resistance Track recovery completion, abandonment, and fraud attempt rates together so a smooth user experience does not hide a weak takeover boundary.

Key takeaways

• Recovery is a common blind spot because it can be easier to abuse than the primary login flow, especially when it depends on knowledge or possession factors alone.
• The Raiffeisen Bank example shows that attackers can turn remote reactivation into device binding and account takeover when recovery is not person-centric.
• The control gap is not just weaker technology. It is the assumption that recovering an account is less sensitive than authenticating into one.

Key terms

• Account Recovery: Account recovery is the process used to restore access when a user cannot authenticate normally. In mature IAM programmes, recovery is treated as part of the trust chain because a weak reset path can bypass stronger login controls and become the easiest route to account takeover.
• Person-Centric Verification: A verification approach that confirms the actual human being rather than the device, channel, or remembered secret they are using. In identity programmes, this matters because possession of a phone or knowledge of a code does not always prove that the right person is present at the moment access is restored.
• Liveness Detection: Liveness detection is the mechanism that checks whether a biometric sample comes from a real, present person rather than a spoof such as a photo, screen, or mask. In identity programmes, it is a core defence against presentation attacks and should be tested under realistic operating conditions.
• Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.