When should organisations choose approval workflows for customer-hosted changes?

Use approval workflows whenever a vendor-initiated action can affect production configuration, data pathing, or recovery operations in a customer-owned environment. The more regulated the workload, the more important it becomes to separate change intent from change execution, because the customer needs evidence that the action was authorized before it landed.

Why This Matters for Security Teams

Approval workflows are not just paperwork for vendor requests. They are a control boundary that separates an approved change from an executed change, which matters most when a customer-hosted environment contains regulated data, production traffic, or recovery tooling. If a vendor can modify routing, restart services, or alter backup settings without a human checkpoint, the organisation may lose evidentiary control over who authorized the change and why.

This is especially important because non-human identities often have broad and persistent reach. NHI Mgmt Group notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, which is one reason change governance and identity governance cannot be separated. The NIST Cybersecurity Framework 2.0 also reinforces the need to manage access, monitor activity, and respond to change in ways that preserve accountability.

In practice, many security teams encounter unauthorised configuration drift only after a vendor convenience shortcut has already altered production behaviour.

How It Works in Practice

For customer-hosted changes, the workflow should be tied to the risk of the action, not just the identity of the requester. A vendor engineer, automation bot, or support agent submits a change intent, and the customer or designated approver validates the scope before execution is allowed. That validation should include environment, target system, expected outcome, rollback path, and whether the change affects data flow, privileged access, or resilience controls.

Approval is most effective when it is paired with short-lived access and task-scoped authorization. For example, a ticket may approve a one-hour maintenance window, after which just-in-time privilege is issued and then revoked automatically. This is a practical way to reduce standing exposure while still allowing necessary work. Current guidance suggests that approval workflows should be logged as part of the audit trail, not as a substitute for technical enforcement. The customer should still rely on least privilege, time bounds, and execution controls that can prove the change was authorized.

• Require approval before changes to production config, routing, secrets, or recovery settings.
• Link each approval to a specific ticket, time window, and scoped action.
• Use separate identities for request, approval, and execution where possible.
• Revoke access automatically when the task ends or the window expires.

This approach aligns with broader NHI governance in the Ultimate Guide to NHIs, where offboarding, rotation, and visibility are treated as operational controls rather than afterthoughts. It also maps cleanly to NIST guidance on access control and monitoring in NIST Cybersecurity Framework 2.0. These controls tend to break down when emergency support is allowed to bypass ticketing in highly distributed environments because approvals become detached from the actual execution path.

Common Variations and Edge Cases

Tighter approval control often increases operational friction, requiring organisations to balance faster incident recovery against stronger customer assurance. That tradeoff becomes most visible during outages, patch windows, and cross-border support, where teams may want immediate action but the customer still needs proof of authorization.

Best practice is evolving, but current guidance suggests different approval tiers for different change classes. Low-risk cosmetic updates may need lightweight review, while changes that touch production data paths, backup integrity, tenancy boundaries, or regulated workloads should require explicit customer sign-off. In some environments, there is no universal standard for this yet, so the safest design is to make the approval path policy-driven and environment-specific rather than rely on a single blanket rule.

One important edge case is delegated operations by managed service providers. If the provider operates under contract but inside the customer’s environment, the approval workflow still matters because tenancy does not remove customer accountability. Another edge case is automated remediation. If a tool can self-heal by changing infrastructure, that action may need pre-approval at the policy level even if no human reviews every execution. The practical question is not whether the change is manual or automated, but whether the customer can prove it was authorized before it landed.

Related resources from NHI Mgmt Group

• When should organisations choose polling instead of webhooks for identity sync?
• When should organisations re-evaluate NHI governance for AI workflows?
• What breaks when organisations use workforce IAM for customer identity journeys?
• What should organisations do before AI systems influence customer-facing content?