What breaks when de-provisioning is handled separately in each cloud?

Why This Matters for Security Teams

When de-provisioning is split across clouds, the organisation no longer has a single point of truth for revocation. That creates a gap between intent and enforcement: one team may believe access was removed, while a second cloud still retains a valid entitlement, cached role, federation trust, or long-lived secret. NHI Management Group’s NHI Lifecycle Management Guide treats lifecycle consistency as a core control because identity removal is only effective when it is complete, timely, and verifiable across every runtime that can still act on the principal. This is especially important for privileged operators, service accounts, CI/CD pipelines, and shared automation identities that often outlive the human request that created them. The issue is not just delayed cleanup, but divergent policy, different account models, and inconsistent revocation workflows across providers. The NIST Cybersecurity Framework 2.0 frames this as an identity governance and access control problem, not a cloud admin inconvenience. In practice, many security teams discover residual access only after an audit, an incident, or a failed offboarding review, rather than through intentional revocation testing.

Research from The 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which directly reflects the de-provisioning problem.

How It Works in Practice

The practical failure mode is fragmented lifecycle control. One cloud may deactivate an IAM user, but another may still trust a federated assertion, preserve an API token, or keep a workload role bound to an automation service. If de-provisioning is managed separately, each platform applies its own timing, schema, and revocation semantics. That means the organisation can remove a user from one console without removing the underlying NHI from all places where it can still authenticate or be authorised. A reliable model usually requires three layers working together:

• A master ownership record for the identity, so revocation starts from one authoritative source.
• Automated propagation of disable, rotate, revoke, and delete actions into every connected cloud and secret store.
• Post-action verification that confirms the identity can no longer authenticate, authorise, or retrieve secrets anywhere.

For NHIs, lifecycle guidance such as the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially relevant because service identities often have more than one control plane dependency. A federated cloud role may need token revocation, key rotation, policy removal, and secret invalidation in a specific order. If one step is missed, the access path can remain live even when the visible account appears closed. Operationally, teams should test offboarding the same way they test incident response: with evidence, timestamps, and a clear rollback path. Best practice is to centralise identity governance, then push revocation downstream through policy-as-code and automated lifecycle hooks rather than manually repeating the same action in each console. These controls tend to break down in federated, multi-account environments because the trust relationship can persist after the visible account object has been deleted.

Common Variations and Edge Cases

Tighter de-provisioning control often increases coordination overhead, requiring organisations to balance security assurance against cloud-specific operational complexity. That tradeoff is real, especially where different business units own different cloud subscriptions or where legacy workloads cannot tolerate aggressive revocation. Current guidance suggests that these exceptions should be explicitly documented rather than allowed to create silent drift. One edge case is shared operational identities. If a single service account supports multiple workloads, deleting it in one cloud may interrupt unrelated production processes while leaving other clouds exposed if the account is recreated inconsistently. Another common exception is cross-cloud federation, where the local account is removed but the upstream IdP or token issuer still grants access. In those cases, the de-provisioning step must include the federation source, not just the destination cloud. Teams also need to distinguish between disable, revoke, rotate, and delete. Disabling a console account does not necessarily invalidate active sessions or API tokens. Rotating a secret does not help if the old token remains accepted by another provider. For that reason, many programmes pair lifecycle controls with the NHI issue patterns documented in Top 10 NHI Issues so they can map residual access risk to the exact failure mode. Where cross-cloud ownership is unclear, the safest assumption is that access still exists until every trust path has been independently verified closed.

Related resources from NHI Mgmt Group

• What breaks when teams manage SaaS, cloud, and endpoint access separately?
• What breaks when vendor or device access is handled separately from workforce IAM?
• What breaks when agent access is handled only through login controls?
• What breaks when AI agents inherit over-privileged cloud roles?