Accountability sits with both operations and security governance. Service desk teams need clear approval rules, while identity and security leaders must define the minimum verification standard, review exceptions, and audit compliance. If a reset leads to compromise, the failure is usually procedural, not technical, because the control boundary was too loose.
Why This Matters for Security Teams
An unsafe MFA reset is not a narrow help desk mistake. It is a control failure that can turn identity proofing into an attacker entry point, especially when the reset process is treated as an operational convenience instead of a governed security decision. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access control, identification, and authentication must be implemented as defined controls, not informal judgment calls.
NHI Management Group research shows why this matters in practice: in the Ultimate Guide to Non-Human Identities, 80% of identity breaches involved compromised non-human identities, and 79% of organisations reported secrets leaks with tangible damage. Those figures are about NHIs, but the lesson transfers directly to human support workflows: once identity recovery becomes loose, attackers target the weakest verification path, not the strongest login factor.
The accountability question matters because the help desk typically executes the reset, while security and identity leadership define the standard that makes the reset safe. In practice, many security teams encounter compromise only after a rushed exception has already been approved, rather than through intentional review of the reset process.
How It Works in Practice
Accountability should be split by function, but never diluted. The service desk is accountable for following the approved playbook, collecting the required evidence, and refusing resets that do not meet the minimum standard. Identity governance and security leadership are accountable for defining that standard, approving exception handling, and ensuring the process is auditable. That division maps cleanly to control design in NIST SP 800-53 Rev 5 Security and Privacy Controls, where procedures, approvals, and auditability are explicit requirements.
A defensible MFA reset process usually includes:
- Identity verification steps that are stronger than knowledge-based questions alone.
- Two-person approval or supervisor review for higher-risk accounts.
- Recorded evidence of the reset request, approval, and execution.
- Clear rules for when resets are denied, escalated, or delayed.
- Post-event logging so security can review patterns and exceptions.
For high-value users, the bar should be higher than a standard support ticket. NHI Management Group’s Microsoft Midnight Blizzard breach research is a reminder that identity processes are frequently abused when recovery paths are easier to manipulate than primary authentication. Current guidance suggests treating MFA reset as an identity assurance event, not a password help request.
This guidance breaks down in environments that still rely on shared inboxes, informal manager approvals, or outsourced service desks without strong evidence capture, because those conditions make it impossible to prove who actually accepted the risk.
Common Variations and Edge Cases
Tighter reset controls often increase support friction, requiring organisations to balance recovery speed against compromise resistance. That tradeoff is real, especially for executives, remote users, and high-turnover environments where legitimate users are more likely to lose device access or factors.
Best practice is evolving, but a few patterns are already clear. For privileged users, resets should usually require stronger proof than for standard employees, because the business impact of a takeover is far greater. For emergency scenarios, organisations may allow temporary access restoration, but only with time-bound approval and mandatory follow-up review. For outsourced or global service desks, the risk is less about intent and more about inconsistency: if agents interpret policy differently, the reset standard becomes unpredictable.
There is also a governance issue when business leaders pressure service desks to “make it happen.” That is where accountability must stay visible. Operations owns execution, security owns the rule set, and leadership owns the risk acceptance when exceptions are granted. The Ultimate Guide to Non-Human Identities is relevant here because it shows how weak lifecycle controls and poor visibility create long-lived exposure; the same pattern appears when reset exceptions are never reviewed. In practice, the failure is usually not the reset itself, but the absence of enforced escalation when the request does not meet policy.
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 CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Addresses identity verification before access changes. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Covers insecure credential recovery and reset paths. |
| NIST SP 800-63 | IAL2 | Defines stronger identity proofing for account recovery. |
| NIST AI RMF | Supports accountable governance for risky identity decisions. | |
| NIST Zero Trust (SP 800-207) | SP 5 | Supports continuous verification before privilege restoration. |
Assign owners for recovery policy, exception review, and post-incident accountability.
