Notifications
Clear all
Topic starter
08/06/2026 4:32 pm
TL;DR: Poorly designed account recovery drives customer frustration, support costs, lost revenue, and account takeover risk, according to Strivacity’s analysis of consumer sign-in behaviour. The deeper issue is that recovery flows still treat forgotten credentials as a user problem instead of an identity design problem, which leaves IAM controls exposed.
NHIMG editorial — based on content published by Strivacity: account recovery, customer friction, and security risk
By the numbers:
- On average, people manage 100 passwords and 53% rely entirely on memory to keep them straight.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams reduce account recovery risk without making sign-in harder?
A: Start by removing recovery branches that are easier to abuse than primary authentication.
Q: Why does account recovery often create more identity risk than the login screen?
A: Because recovery frequently relies on weaker trust signals such as security questions, email access, SMS, or human support.
Q: What do organisations get wrong about password reset policies?
A: They often focus on user memory instead of the design of the recovery journey.
Practitioner guidance
- Map every recovery branch to an assurance tier Document the exact assurance level for security questions, email reset links, SMS codes, device verification, and help desk intervention.
- Treat support-assisted resets as privileged workflows Require stronger verification for any human-mediated reset, log every step, and review exceptions for patterns that indicate social engineering or insider risk.
- Reduce custom username complexity Prefer usernames that users already know and avoid self-selected handles unless there is a clear business reason.
What's in the full article
Strivacity's full post covers the operational detail this post intentionally leaves for the source:
- The specific recovery-flow design choices that reduce customer abandonment without weakening assurance.
- The practical trade-offs between email, SMS, help desk, and passwordless recovery branches.
- The user-experience patterns that help reduce repeat resets and support call volume.
- The implementation details behind FIDO-based sign-in and why it changes recovery architecture.
👉 Read Strivacity's analysis of account recovery, customer friction, and account takeover risk →
Account recovery loops: what they mean for consumer IAM teams?
Explore further
08/06/2026 6:14 pm
Account recovery failure is a human identity design problem before it is a security problem. The article is right to frame recovery as an experience issue, but the governance lesson is that poor recovery design creates a second authentication plane with weaker assurance than the first. That plane is where account takeover begins, because attackers target the path of least resistance. Practitioners should therefore treat recovery as part of the identity architecture, not as support admin.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How can teams tell whether account recovery controls are working?
A: Look for repeated resets, support escalation volume, failed recovery attempts, and exceptions that bypass normal verification. Healthy recovery should be rare, consistent, and tightly governed. If customers routinely need manual help or abandon the process, the control design is failing.
👉 Read our full editorial: Account recovery failures expose the real weakness in consumer IAM
