Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Account recovery and biometrics: what IAM teams need to change


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 5324
Topic starter  

TL;DR: Account recovery remains a weak point because attackers target security questions, SMS recovery, and email-based reset flows that assume compromised accounts are not already in play, according to iProov’s Raiffeisen Bank case study. Person-centric biometric verification shifts recovery from device trust to presence and identity, making remote recovery harder to abuse.

NHIMG editorial — based on content published by iProov: account recovery processes and the Raiffeisen Bank biometric recovery case study

By the numbers:

Questions worth separating out

Q: How should security teams secure account recovery without forcing branch visits?

A: Use layered identity proofing that verifies the person, not just the device or channel.

Q: Why do SMS-based recovery flows remain risky in modern IAM programmes?

A: SMS recovery assumes the phone number and message channel are trustworthy, but attackers can intercept or redirect those signals through SIM swapping and social engineering.

Q: What do teams get wrong about biometric account recovery?

A: Teams often assume biometrics automatically prove the right person is present, but that is only true when liveness and anti-spoofing controls are built into the flow.

Practitioner guidance

  • Review recovery as a privileged identity path Map every account reactivation, reset, and device-binding flow as a separate control surface with its own approval, logging, and fraud review steps.
  • Replace knowledge-based recovery with stronger proofing Remove or de-emphasise security questions and SMS-only resets where the attacker can research answers or intercept the channel, and require stronger identity evidence instead.
  • Add liveness to remote recovery journeys Use liveness detection and document checks when the process must confirm a real person is present, especially for remote device activation or account reactivation.

What's in the full article

iProov's full article covers the operational detail this post intentionally leaves for the source:

  • The full Raiffeisen case study with the original recovery workflow and the specific breakpoints criminals exploited.
  • Implementation detail on the five-step reactivation flow, including document verification and biometric verification token handling.
  • Operational results on branch visit reduction, monthly reactivation volumes, and customer success rates for legitimate recovery.
  • The vendor's explanation of how Dynamic Liveness and Flashmark support remote recovery assurance in practice.

👉 Read iProov's analysis of secure account recovery and biometric verification →

Account recovery and biometrics: what IAM teams need to change?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 1 month ago
Posts: 4523
 

Account recovery is now part of the attack surface, not a back-office convenience. This case shows that criminals do not need to break the primary login if the reset path is easier to manipulate. Security questions, SMS OTP, and email-based recovery all assume that compromise has not already reached the user, device, or communications channel. Practitioners should treat recovery as a governed identity flow with its own assurance threshold, because the weakest recovery path defines the real account boundary.

A few things that frame the scale:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
  • Only 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.

A question worth separating out:

Q: Who is accountable when a recovery process is abused for account takeover?

A: Accountability usually sits with the identity, fraud, and customer operations teams together, because recovery is a shared control boundary. Security owns assurance thresholds, fraud teams monitor abuse patterns, and operations must support a process that does not force unsafe shortcuts. Recovery governance should be documented as a control, not treated as a support exception.

👉 Read our full editorial: Person-centric account recovery is exposing IAM blind spots



   
ReplyQuote
Share: