Notifications
Clear all
Topic starter
22/06/2026 4:55 pm
TL;DR: Phishing-resistant authentication fails when recovery falls back to weaker controls, and this playbook argues for warm-path, cold-path, and assisted recovery with stronger proofing and dual control, according to Scramble ID. The decisive security boundary is not login but recovery, where KBA, OTP, and helpdesk overrides collapse phishing resistance.
NHIMG editorial — based on content published by Scramble ID: Recovery and Fallback Playbook
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- 17 minutes., edentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when passwordless recovery falls back to KBA?
A: Phishing resistance breaks because the attacker no longer needs to defeat the primary authenticator.
Q: Why do support-led recovery flows create so much risk?
A: Support-led recovery creates risk because it concentrates trust decisions in a human conversation that attackers can manipulate with urgency, authority, and partial identity data.
Q: How can security teams tell whether recovery is actually strong enough?
A: Measure recovery like a control, not a convenience feature.
Practitioner guidance
- Remove KBA from all recovery paths Retire security questions from both primary authentication and fallback recovery.
- Separate helpdesk routing from trust decisions Train support agents to initiate the recovery workflow without approving identity on the call.
- Define warm-path and cold-path recovery tiers Give users with multiple enrolled devices a fast warm-path, but require supervised proofing for users with no enrolled device.
What's in the full article
Scramble ID's full report covers the operational detail this post intentionally leaves for the source:
- Step-by-step recovery flow design for warm-path, cold-path, and assisted recovery
- Identity proofing requirements for higher-assurance recovery contexts
- Decision-tree logic for elevated users, repeated failures, and cooldown handling
- Logging and review fields for recovery events, including proofing evidence and approver identity
👉 Read Scramble ID's recovery and fallback playbook for passwordless IAM →
Recovery fallback in passwordless IAM: are your controls strong enough?
Explore further
22/06/2026 5:06 pm
Recovery is an identity governance control, not an edge-case support feature. The article shows that passwordless deployments fail when recovery is treated as a convenience layer instead of a governed trust boundary. That changes the programme question from whether primary authentication is phishing-resistant to whether the recovery path preserves the same assurance under stress. Practitioners should treat recovery events as high-risk identity transactions, not routine service tickets.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should approve recovery for privileged accounts?
A: Privileged recovery should require dual control, not a single support agent or manager. For high-risk accounts, proofing should establish identity and two distinct approvers should authorise activation. That keeps restoration separate from routine helpdesk support and reduces the chance that one compromised conversation restores broad access.
👉 Read our full editorial: Recovery fallback is the real attack surface in passwordless IAM
