Should organisations treat support resets and device enrollment as privileged actions?

Why support resets and enrollment belong in the privileged path

Support resets and device enrollment are not routine admin chores when they can restore access, bind a new device to an account, or bypass an existing control. Those actions sit on the recovery path, which is often the easiest place for an attacker to convert social engineering or a compromised channel into account takeover. Treating them as privileged means the decision, not just the login, is controlled.

The practical question is whether the workflow can change an identity’s effective authority. If a help desk action can reset MFA, clear recovery barriers, enroll a managed device, or approve a new trust relationship, it is creating an access condition with the same business effect as an elevated grant. That is why recovery steps need stronger proofing, approval, and auditability than ordinary user support.

For a broader identity governance lens, Account Recovery and Help Desk Security Guide is directly relevant because it focuses on caller verification, reset controls, and monitoring for the recovery flow itself, not just the end-state account.

What makes device enrollment especially sensitive

Device enrollment is a privilege boundary because it can establish a trusted endpoint, not merely register hardware. Once a device is enrolled, the organisation may allow stronger tokens, device-based conditional access, certificate trust, or management actions that were not available to an unmanaged endpoint. A weak enrollment process can therefore become a shortcut into the rest of the identity stack.

That sensitivity is why enrollment should be treated as an authorization event with identity implications. The workflow should be able to answer three questions: who approved the enrollment, what evidence justified it, and what controls now depend on that device being legitimate. If those answers are missing, the enrollment path is effectively a blind trust exchange.

Stryker Microsoft Intune Wiper Attack illustrates the downstream blast radius of compromised device-management credentials, because control over enrollment and device management can translate into destructive enterprise-wide impact.

How to operationalise the privileged-treatment model

Organisations should manage support resets and enrollment through the same control pattern they use for privileged access: tight approval paths, strong step-up verification, restricted operators, session and action logging, and periodic review of who can execute the workflow. The goal is not to slow legitimate support to a crawl, but to ensure the path is attributable and hard to abuse.

For practical design, separate the ability to request a reset from the ability to approve one, and separate enrollment initiation from policy override. Recovery workflows should also be time-bound where possible, because standing permission to perform high-impact support actions creates unnecessary exposure. The most common failure is allowing convenience to collapse the difference between identity proofing and simple ticket handling.

NHIMG’s Privileged Access Management Guide and Just-in-Time Access and Zero Standing Privilege Guide both support this approach by framing high-impact actions as access that should be tightly bounded, justifiable, and temporary.

Risk and Threat Considerations

Support reset and enrollment abuse is attractive because it often targets the least scrutinized part of the access lifecycle. Attackers do not need to defeat strong authentication if they can persuade or compromise a support path that reissues it, and a maliciously enrolled device can become a durable foothold for future access, persistence, and lateral movement.

Failure mechanism: Social engineering, help desk impersonation, compromised tickets, or stolen operator credentials can let an attacker reset MFA, add a trusted device, or bind a new authentication path without raising enough suspicion.

Impact: The result can be account takeover, silent bypass of strong login controls, and expanded control over enterprise systems through a trusted endpoint or recovered account.

Practitioner Guidance

What to verify: Verify that every reset or enrollment path has a distinct approval rule, a durable audit trail, and a clear owner. If the same person can request, approve, and execute the action, the workflow is not privileged in practice even if the ticketing system says it is.

Decision rule: If the action can change future access, such as restoring MFA, enrolling a device, or granting a recovery path, treat it as an elevated operation and require step-up verification and logging before the change is made. If it only answers a low-impact service question, normal support handling is enough.

Practitioner takeaway: The control boundary is the recovery path itself, not the login screen; if recovery can recreate trust, it deserves privileged treatment.

Related resources from NHI Mgmt Group

• When should organisations treat an AI agent as a privileged system?
• When should organisations treat agent access as a privileged access problem?
• When should organisations treat a pipeline compromise as a privileged access incident?
• When should organisations treat an NHI like a privileged administrator?