Accountability should sit with the identity and access team, not the individual user alone. Organisations need defined recovery ownership, documented support paths, and clear rules for restoring access without bypassing authentication policy. Otherwise, every lost phone becomes an ad hoc exception.
Why This Matters for Security Teams
Device changes expose a control gap that is easy to underestimate: the user may be blocked, but the real risk sits in how recovery is authorised, logged, and bounded. If support teams improvise resets, the organisation can drift into identity proofing by convenience rather than policy. That is especially dangerous for MFA because recovery paths often become the weakest part of the identity lifecycle.
Current guidance from the OWASP Non-Human Identity Top 10 and NIST identity guidance both point to the same operational truth: authentication strength is only as good as the recovery process around it. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is a reminder that weak lifecycle discipline rarely stops at credentials alone. The same organisational habits that let secret handling drift also affect user recovery flows.
Security teams should treat device-change recovery as an accountability question, not a help desk convenience question. In practice, many security teams encounter unsafe MFA resets only after a lockout, phishing attempt, or account takeover has already forced an exception.
How It Works in Practice
Accountability should be assigned to the identity and access function, with support from service desk, HR, and risk owners where needed. The user’s role is to request recovery and complete proofing; the team responsible for identity governance must define what evidence is acceptable, who can approve it, and how the original factor is revoked and re-enrolled. That separation matters because recovery is a privileged administrative action, not a user entitlement.
A defensible process usually includes:
- Documented recovery ownership, so every reset has a named control owner.
- Step-up verification, using factors stronger than the lost device wherever possible.
- Time-bound recovery windows, so temporary access does not become permanent bypass.
- Audit logging for proofing, approval, and factor replacement events.
- Re-enrolment requirements that invalidate the old device and any stale tokens.
Where environments use privileged access or sensitive workflows, many teams now align recovery with SPIFFE-style workload identity and policy-based access patterns, because the same principle applies across human and non-human identities: identity proof should be cryptographic or procedurally strong, not informal. That operational logic is consistent with NHI Mgmt Group’s key challenges and risks analysis, which emphasizes lifecycle control and visibility as core risk reducers.
When this works well, the organisation restores access without weakening MFA policy, and the recovery event becomes a controlled identity transaction rather than a one-off exception. These controls tend to break down in distributed organisations where frontline support is incentivised to resolve tickets quickly and lacks authority to enforce proofing discipline.
Common Variations and Edge Cases
Tighter recovery controls often increase friction, requiring organisations to balance user uptime against the risk of account takeover. That tradeoff is real: not every workforce can tolerate the same recovery speed, and not every role should have the same proofing standard.
Current guidance suggests three common variants. First, high-risk roles such as finance, admins, and developers should use stronger recovery paths than general staff. Second, remote or offshore workers may need additional verification because in-person proofing is unavailable. Third, contractors and temporary staff often need shorter recovery windows because their identity lifecycle is already constrained.
There is no universal standard for this yet, but best practice is evolving toward differentiated recovery tiers based on account sensitivity, device trust, and business impact. The 52 NHI Breaches Analysis is useful here because it shows how control failures compound when identity processes are treated as isolated events instead of lifecycle management. For related IAM thinking, the OWASP guidance helps teams distinguish between acceptable recovery, temporary exception handling, and outright policy bypass.
In mature environments, the accountable team also reviews recovery trends for abuse patterns such as repeated lockouts, suspicious geography changes, or help desk pressure to override proofing. That review is especially important where legacy MFA, shared admin tools, or informal escalation paths still exist, because those conditions make recovery abuse easier and harder to detect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | 5.1.2 | Addresses authenticator lifecycle and recovery assurance for lost devices. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Recovery paths must not create weak, long-lived exceptions around identity controls. |
| NIST CSF 2.0 | PR.AA-1 | Defines authenticated access management and recovery accountability. |
Treat MFA recovery as a controlled lifecycle event with revocation, audit, and reissue steps.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
