Who is accountable when onboarding automation leaves stale cloud access behind?

Why This Matters for Security Teams

When onboarding automation leaves stale cloud access behind, the issue is rarely just a technical cleanup problem. It exposes gaps in ownership, entitlement lifecycle management, and offboarding assurance. For identity and cloud security teams, the real risk is that access granted for a service, integration, or agent remains valid long after the business process that justified it has changed. Guidance from OWASP Non-Human Identity Top 10 is especially relevant here because non-human credentials often outlive the workflows that created them.

Security teams often assume automation equals control, but automation can also scale mistakes. If provider registration, secret issuance, and revocation are not tied to a clear owner, stale access becomes invisible until a review, incident, or audit exposes it. That creates accountability questions across platform engineering, IAM, application teams, and cloud operations. The practical answer is that accountability sits with the function that governs the lifecycle, not with the script that executed it. In practice, many security teams encounter stale cloud access only after an audit finding or lateral movement event has already occurred, rather than through intentional lifecycle verification.

How It Works in Practice

Operationally, accountability should be defined before onboarding automation is approved. A secure process needs a named owner for each identity type, a registration workflow that records business purpose, and a revocation path that is exercised as routinely as issuance. This is where control mapping matters. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful baseline for access enforcement, auditability, and system lifecycle governance, even when the identity is non-human.

• Assign a control owner for onboarding, renewal, and deprovisioning of cloud credentials.
• Track every secret, token, certificate, and API key back to a business service or automation workflow.
• Require expiry, rotation, or event-driven revocation rather than open-ended persistence.
• Log registration and offboarding events so stale access can be detected during review.
• Test offboarding the same way onboarding is tested, including break-glass and exception handling.

For cloud and platform teams, the key distinction is between the person who deployed the automation and the function that is accountable for access outcomes. If a CI/CD pipeline, workload, or agent receives credentials, the owning team must also own the revocation logic and periodic validation that those credentials still match an approved purpose. This is especially important where service identities are reused across environments or where permissions are inherited from templates rather than reviewed individually. The control should also extend to evidence collection, so an auditor can verify who approved access, when it was last used, and what triggered removal.

These controls tend to break down when provisioning is embedded in ephemeral infrastructure pipelines with no durable service owner because there is no stable accountability point for offboarding.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance speed of onboarding against the cost of review, evidence, and revocation checks. That tradeoff is real, especially in high-change cloud environments where teams want self-service provisioning and short deployment cycles. Current guidance suggests that the answer is not to slow automation, but to make ownership and expiry explicit from the start.

There are a few common edge cases. First, if a cloud credential supports a shared platform function, accountability may sit with the platform team, but the consuming application team still owns the business justification for use. Second, if the credential supports an external partner or automated agent, the obligation to review, rotate, and remove access is stronger because the identity boundary is less visible. Third, where cloud access is tied to regulated data or financial workflows, governance may need to reference FATF Recommendations where identity assurance, traceability, and access accountability support AML and KYC obligations.

Best practice is evolving for autonomous agents and machine-issued credentials, but there is no universal standard for this yet. What is consistent is the expectation that stale access must be detected, assigned, and removed by an accountable owner. If no one can prove who approved the access, who monitors it, and who can revoke it, the onboarding process has failed regardless of how well the automation ran. For teams building these controls, OWASP Non-Human Identity Top 10 remains a practical reference point for lifecycle and secret governance.

Related resources from NHI Mgmt Group

• Who is accountable when lifecycle automation leaves access behind?
• Who is accountable when stale cloud access causes a security or audit failure?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when Jira offboarding leaves access behind?