Who is accountable when a support workflow adds an attacker-controlled MFA device?

Why This Matters for Security Teams

A support workflow that adds an attacker-controlled MFA device is not a routine help desk error. It is an identity control failure that can convert a single social-engineering call into full account takeover, persistence, and lateral movement. The accountability question matters because support teams often act inside incomplete process boundaries, while IAM and security governance own the rules that should have prevented the change. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, a reminder that weak identity controls compound quickly once trust is misplaced.

Attackers target MFA enrollment because it is often treated as a low-friction support action rather than a high-risk identity mutation. Current guidance from CISA cyber threat advisories consistently shows that identity-centric intrusions rely on procedural gaps, not just technical flaws. The real issue is whether the organisation required strong proof, dual approval, and post-change review before allowing a device swap or reset. In practice, many security teams encounter takeover only after the attacker has already enrolled a device and locked the legitimate user out.

How It Works in Practice

Accountability should be assigned across the control chain, not pinned on the individual analyst who clicked the button. The service desk executes the action, IAM defines what actions are permitted, and security governance sets the approval standard, evidence requirements, and exception handling. For high-risk changes such as MFA device replacement, best practice is evolving toward step-up verification, out-of-band confirmation, and explicit approval for any change that could defeat existing authentication assurance.

Practically, a defensible workflow includes:

• Strong identity proofing before any reset or device enrollment.
• Role separation so the same person cannot request, approve, and execute the change.
• Justification tied to an authenticated user session, incident ticket, or known outage.
• Time-bounded approvals with logging that preserves who authorised what and when.
• Automated alerts for risky patterns, such as a new MFA factor followed by password reset or mailbox rule creation.

This aligns with the direction in the OWASP NHI Top 10 and with the operational reality described in Ultimate Guide to NHIs, where poor visibility and weak lifecycle controls create repeatable compromise paths. Organisations also need clear exception review so support actions can be audited after the fact, not merely recorded. These controls tend to break down in high-volume service desks with informal identity recovery practices because speed pressure overrides verification discipline.

Common Variations and Edge Cases

Tighter identity recovery controls often increase help desk friction, so organisations must balance user convenience against the risk of account takeover. That tradeoff becomes more acute in executive support, emergency access, and remote work scenarios where staff claim device loss or travel-related lockout.

There is no universal standard for this yet, but current guidance suggests that the highest-risk cases should use the strongest proofing, not the fastest path. For privileged users, contractors, and shared operational accounts, a support-approved MFA change should usually trigger additional review because the blast radius is higher. The same logic applies when the request originates from a compromised inbox, a recently changed phone number, or a device that has not been previously trusted. The 52 NHI Breaches Analysis is useful here because it shows how identity failures often chain together, rather than appearing as isolated mistakes. For a threat perspective on attacker tradecraft, see Anthropic’s first AI-orchestrated cyber espionage campaign report and the MITRE ATLAS adversarial AI threat matrix, both of which reinforce that identity abuse is often the front door to broader compromise.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised workflow exposes cloud and repository credentials?
• Who is accountable when temporary access is misused in a delegated workflow?
• Who is accountable when a device still has access after administrators believe it has been revoked?
• Who is accountable when MFA exceptions become permanent?