A governance pattern where one party can propose or remediate a change, but another party controls whether that change is authorized to take effect. It is especially important in customer-hosted deployments, where vendor support actions must not silently become standing administrative power.
Expanded Definition
Delegated Change Authority describes a control pattern in which the party that discovers or performs a fix does not also decide when that fix becomes active. In NHI operations, that separation matters because a vendor, platform operator, or support engineer may need to prepare a configuration change, rotate a credential, or remediate an integration issue without gaining unrestricted power over the customer’s environment. The change is proposed or staged by one actor, then authorized by another according to policy, review, or approval workflow.
This pattern is closely related to least privilege and change control, but it is not the same as ordinary admin delegation. The key distinction is that authority to execute is time-bound and conditional, not silently durable. In Zero Trust language, the system should verify the request, the requester, and the scope before allowing activation, which aligns with guidance in the NIST Cybersecurity Framework 2.0. Definitions vary across vendors when support workflows, break-glass access, and delegated administration overlap, so organisations should be explicit about who can propose, who can approve, and who can trigger the final change.
The most common misapplication is treating vendor troubleshooting access as standing administrative authority, which occurs when temporary support permissions are left enabled after the incident ends.
Examples and Use Cases
Implementing delegated change authority rigorously often introduces review overhead and slower recovery, requiring organisations to weigh operational speed against the risk of silent privilege expansion.
- A cloud provider can draft a remediation for a broken service account, but the customer security team must approve activation before the new permission set is applied.
- A managed service desk can prepare a credential rotation plan for a customer-hosted deployment, while an internal approver validates the blast radius before execution.
- An automation pipeline can generate a configuration change for an API gateway, but production deployment is blocked until a separate control owner signs off.
- A support engineer can request emergency access to inspect a failing integration, yet the access token expires automatically once the incident window closes.
- Operational guidance in the Ultimate Guide to NHIs is especially relevant when third parties touch customer secrets, because approval boundaries prevent a support action from turning into persistent access.
In practice, the approval step should be auditable, reversible, and tied to the exact object being changed. The surrounding governance model should also reflect the broader access lifecycle described in the Ultimate Guide to NHIs rather than relying on informal trust.
Why It Matters in NHI Security
Delegated change authority matters because NHI compromise often happens through processes that were meant to help. If a vendor can both fix and approve its own access path, a temporary support exception can become persistent privilege, creating a hidden control plane inside the customer environment. That breaks segregation of duties, weakens incident containment, and makes post-incident review much harder.
This is especially relevant in third-party operations, where NHIs already extend beyond the direct enterprise boundary. NHIMG notes that 92% of organisations expose NHIs to third parties, which raises the odds that support workflows will cross trust boundaries. Once that happens, governance must ensure the person or automation proposing the change is not the same party deciding whether it becomes effective. The structure of NIST Cybersecurity Framework 2.0 reinforces this separation through protective access governance and change discipline. Organisaties typically encounter the need for delegated change authority only after a support action, outage, or compromise reveals that temporary remediation has quietly become standing administrative power.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Separates approval from execution to prevent standing support access and privilege creep. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed so authorization is limited and reviewable. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires verifying each request before granting execution authority. |
Require independent approval before any NHI change becomes effective, especially for vendor support actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
