Who should be accountable for fraudulent password resets?

Accountability should sit with the identity and access team, the service desk owner, and any third-party support provider that can complete recovery. If a reset can grant access to a regulated or privileged account, the organisation needs a clear owner for proofing standards, audit trails, and exception handling.

Why This Matters for Security Teams

Fraudulent password resets are not just help desk mistakes. They are identity assurance failures that can convert social engineering into account takeover, privilege escalation, or access to regulated data. Current guidance suggests treating every reset path as a control point, not a convenience workflow, because the person approving recovery is effectively extending trust on behalf of the organisation.

This is especially important when a reset can unlock privileged or high-risk accounts. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that identity proofing, access enforcement, and auditability must be tied together, while NHI Management Group’s Ultimate Guide to NHIs shows how weak recovery processes become dangerous once credentials or service identities are involved. If a third party can trigger recovery, that vendor becomes part of the control boundary and must be governed accordingly.

In practice, many security teams discover accountability gaps only after a fraudulent reset has already been used to bypass MFA or reach a privileged session, rather than through intentional control testing.

How It Works in Practice

Accountability should be split across the teams that own the control, execute the workflow, and approve exceptions. The identity and access team should define the reset standard, proofing requirements, and assurance levels. The service desk owner should run the process day to day, including escalation paths, logging, and agent training. Any third-party provider that performs recovery must be contractually bound to the same evidence, retention, and escalation rules.

Good practice starts with a clear reset policy that distinguishes low-risk self-service resets from high-risk assisted resets. The higher the impact of the account, the more the process should require step-up verification, supervisor approval, and immutable audit trails. For privileged users, many organisations now align recovery with zero standing privilege principles so that a reset does not automatically restore broad access.

• Define who can request, approve, and execute each reset path.
• Record proofing steps, timestamps, and any exceptions in tamper-evident logs.
• Require re-verification when the account is privileged, regulated, or externally supported.
• Review vendor-administered resets as part of access governance and incident response.

Operationally, the ownership model should map to control evidence. That means the identity team owns standards, the service desk owns execution quality, and the business system owner owns the risk of the account being recovered. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involve compromised non-human identities, which is a useful reminder that recovery paths often become the easiest route into a wider environment when credentials are not tightly controlled.

These controls tend to break down in outsourced support models where vendors can complete resets without direct visibility into the downstream privilege attached to the account.

Common Variations and Edge Cases

Tighter reset controls often increase help desk friction, so organisations have to balance user recovery speed against the damage a fraudulent reset can cause. That tradeoff becomes sharper when the account belongs to an executive, privileged administrator, contractor, or service account owner.

There is no universal standard for this yet, but current guidance suggests using higher assurance for resets that can unlock privileged or regulated access, while allowing simpler flows for low-risk accounts. Where the account supports automation or a non-human workflow, password reset may not be the right recovery mechanism at all; key rotation, token re-issuance, or workload identity recovery may be safer.

Fraud patterns also vary by environment. In call-centre-heavy enterprises, attackers often exploit weak proofing and inconsistent agent discretion. In cloud-first environments, resets can be just one step before session hijacking, token theft, or tool abuse. The control owner should therefore be the party best positioned to measure proofing quality, investigate exceptions, and revoke access when recovery is abused.

For organisations modernising their identity stack, the practical question is not only who approves resets, but who can prove the approval was legitimate. That is the real accountability test.

Related resources from NHI Mgmt Group

• How should security teams handle password resets and recovery workflows in a zero trust programme?
• Who is accountable when access governance relies on parallel local processes?
• Who is accountable when a deepfake scam succeeds through a support workflow?
• Who is accountable when a verification flow can be redirected by an impostor?