Because the identity workflow itself is the regulated object. When inference, screen capture, and action execution stay inside customer infrastructure, teams reduce third-party exposure and keep the automation within their own audit and change-management model. That matters most when access reviews and entitlement changes are subject to formal control.
Why customer-controlled deployment changes the identity control boundary
Customer-controlled deployment matters because identity operations are not just a software feature, they are part of the control environment. When the customer owns the runtime, the data path, and the execution boundary, the organisation can apply its own change approvals, logging, segregation, and access review rules to the automation that touches identities and entitlements.
That difference is practical, not cosmetic. If a vendor hosts the inference path, it may also sit inside the trust boundary for screens, prompts, tokens, workflow state, and approval artefacts. If the customer hosts it, those assets remain inside the same environment that already governs identity administration, so audit evidence and operational responsibility stay aligned.
Customer control also changes what can be proven. Identity teams usually need to show who changed access, when the change was approved, what inputs were used, and whether the workflow was reversible. A customer-run deployment makes that evidence easier to anchor to existing logging, retention, and incident response processes instead of relying on a third party’s implementation choices.
Why auditability and change management are the real reasons it matters
For identity operations, the core issue is whether the workflow can be treated like a regulated control, not merely an automated convenience. If access reviews, role changes, or entitlement removals are executed by a system outside the customer’s governance model, the organisation may still own the risk while losing direct control over the mechanism that performed the action.
That is especially important when the workflow has authority to create, approve, revoke, or modify access. In those cases, the deployment model determines whether the operation can be examined under the customer’s own approval chain, tested under its own release process, and rolled back under its own incident procedures. Identity Security Programme Guide is useful here because it frames identity work as an operating model, not a collection of isolated tools.
It also affects lifecycle governance. A customer-controlled model is easier to align with onboarding, recertification, privilege reduction, and offboarding because the same team can govern the workflow logic and the identity data it acts on. NHI Lifecycle Management Guide and Top 10 NHI Issues both reinforce the importance of lifecycle discipline, ownership, and visibility when automation has access to sensitive identity operations.
What changes in practice when the deployment stays inside customer infrastructure
The main operational gain is containment of trust. Customer-controlled deployment keeps screen capture, prompts, connectors, and execution logs inside the environment where identity administrators already work, which reduces third-party exposure and narrows the number of places where secrets, approvals, and decision traces can leak.
It also improves policy consistency. If the same organisation decides what counts as an approved access request, what evidence must be retained, and when an exception must be escalated, the automation can follow those rules without depending on a vendor’s default retention or support workflow. That makes it easier to preserve segregation of duties and to prevent a helpful automation layer from becoming an informal bypass around access governance.
Customer ownership is not just about privacy, it is about control over authority. When the system can act on identity data, entitlement records, or approval artefacts, the deployment model should match the organisation’s existing governance model. Ultimate Guide to NHIs, Regulatory and Audit Perspectives and Ultimate Guide to NHIs, Standards are relevant because they connect identity controls to auditability and established security expectations.
Risk and Threat Considerations
When deployment is not customer-controlled, the biggest risk is control-plane drift: the organisation may still approve identity changes, but it no longer fully controls how the automation sees data, stores traces, or executes actions. That can create weak audit evidence, hidden dependencies, and a larger blast radius if a vendor environment, integration, or account is compromised.
Failure mechanism: Sensitive identity inputs, approval context, or execution tokens can cross into a third-party runtime, where logging, retention, or access controls differ from the customer’s own policy. If that environment is abused or misconfigured, identity actions may be observed, replayed, or modified outside the intended governance boundary.
Impact: The organisation can lose confidence in entitlement changes, access review evidence, and rollback capability, which makes incident investigation and control attestation harder. Over time, that can undermine trust in the identity process itself, especially where the workflow has direct authority over privileged or high-impact access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Customer-controlled identity automation needs controlled machine-to-machine authentication. |
| AU-2 — Event Logging | Auditability of access changes depends on complete event capture inside the customer boundary. | |
| AC-6 — Least Privilege | Identity workflows that modify entitlements must be constrained to minimum necessary authority. | |
| Recommendation — Use IA-9 to authenticate automation paths that can change identity state. Log every identity action and retain evidence under customer-controlled policy. Limit workflow permissions to the smallest set needed for each identity operation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is about governing who can execute and review access changes. |
| A.8.15 — Logging | Customer-owned deployments need auditable records for identity changes and approvals. | |
| Recommendation — Apply access control rules to the automation and its supporting administration paths. Ensure identity-change logs are retained and reviewable within the customer environment. | ||
Practitioner Guidance
What to verify: Confirm that the deployment model preserves customer control over logging, retention, approval evidence, and execution authority for every identity action the workflow can perform. If any of those controls sit outside your governance boundary, treat the workflow as a higher-risk control and require explicit compensating evidence.
Decision rule: If the system can change access, not just recommend a change, the customer should be able to explain where the action was executed, where the evidence lives, and how it can be reversed. If that cannot be answered cleanly, the deployment model is too loosely governed for identity operations.
Practitioner takeaway: For identity work, customer-controlled deployment is valuable because it keeps the automation inside the same audit, approval, and accountability model as the identities it affects, which is the minimum bar for trustworthy access governance.