Who is accountable when access changes are approved in one system but applied in another?

Accountability rests with the organisation that owns the workflow boundary, not with the directory or the endpoint tool alone. If approvals, provisioning, and downstream application updates are split across systems, the control owner must define who validates completion and who is responsible when access drifts out of sync.

Why This Matters for Security Teams

Access change accountability is often misunderstood because the approval event and the enforcement event are not the same control. In a split workflow, one system may record that access was approved while another system actually grants, revokes, or synchronises that access. That gap creates a governance blind spot: auditors see a valid ticket, but the environment may still be out of policy. NHI Mgmt Group’s Ultimate Guide to NHIs shows why this matters in practice, especially where service accounts, API keys, and automation paths outlive the approval they were meant to reflect.

The real risk is not just delayed provisioning. It is drift, partial completion, and silent exceptions across directories, applications, secrets stores, and downstream systems. Security teams that assign ownership only to the approval tool or only to the target platform tend to miss the boundary where controls fail. Current guidance suggests the accountable party is the organisation or control owner that defines and verifies the workflow end to end, not whichever tool happened to process one step. In practice, many security teams encounter access drift only after an incident response or audit finding has already exposed the mismatch, rather than through intentional reconciliation.

How It Works in Practice

In a healthy workflow, accountability follows the control objective, not the technical hop. The approver authorises a change, but the owner of the access process remains responsible for verifying that the requested state was actually applied in the destination system. That includes checking whether the identity store, the application, the PAM layer, or the secrets platform received the update, and whether the resulting access matches the approved scope.

This is why many maturity models now emphasise closed-loop validation. A ticket should not be considered complete until the downstream state is confirmed, ideally through automated reconciliation. For NHI-heavy environments, that means comparing the approved entitlement against the live service account, token, or key state. The OWASP Non-Human Identity Top 10 highlights how overprivilege and lifecycle failures often emerge when governance stops at approval and never verifies enforcement. The 52 NHI Breaches Analysis shows the same pattern repeatedly: an authorised change, a missed follow-up, then access that persists longer than intended.

• Define one control owner for the workflow boundary and one named verifier for downstream completion.
• Require evidence that the destination system changed, not just that the request was approved.
• Use reconciliation jobs to detect mismatches between source-of-truth approvals and applied entitlements.
• Escalate exceptions when systems fail to sync, rather than assuming eventual consistency.

Where possible, integrate approvals with provisioning APIs and event logs so that the change is traceable from request to enforcement. If the environment uses multiple identity domains, the accountable team must also define which system is authoritative when records conflict. These controls tend to break down when legacy apps, manual admin steps, or asynchronous sync jobs are involved because completion is no longer observable in one place.

Common Variations and Edge Cases

Tighter workflow control often increases operational overhead, requiring organisations to balance faster approvals against stronger completion checks. That tradeoff becomes visible in hybrid estates, third-party integrations, and multi-tenant platforms where no single team owns every hop. In those cases, there is no universal standard for this yet, but best practice is evolving toward explicit ownership of both approval and verification, with evidence retained for each handoff.

One common edge case is delegated administration. If a business unit approves access in one platform but the IAM team applies it in another, accountability still sits with the control owner who defined the process, even if implementation is delegated. Another is eventual consistency in cloud and SaaS environments, where a change may be correct but not immediately visible. In that scenario, the team must distinguish between expected propagation delay and genuine failure, then set a maximum reconciliation window.

NHIMG’s Key Challenges and Risks section is useful here because the same governance pattern applies to NHIs: the system that approves access is not automatically the system that enforces it. Organisations that do not document the boundary usually discover the gap only after access persists beyond its intended scope.

Related resources from NHI Mgmt Group

• Who is accountable when an employee retains access in one system after leaving another?
• Who is accountable when automated remediation changes a device or access state?
• Who is accountable when high-risk access is approved through a uniform process?
• When do NHI access reviews create more value than a one-time cleanup?