Who should own offboarding for platform identities and secrets?

Ownership should sit with the team that governs the underlying identity, not just the application team. Pipeline identities, workload credentials, and portal access all need explicit revocation paths so access does not outlive the system or project that created it. Without lifecycle ownership, platform automation becomes permanent privilege.

Why This Matters for Security Teams

Offboarding platform identities and secrets is not just an application cleanup task. It is a lifecycle control that determines whether automation retains access after the project, service, or owner changes. If revocation is unclear, secrets continue to authenticate workloads long after the original business need has ended, creating standing privilege in systems that were supposed to be ephemeral.

This problem is especially visible in secrets sprawl and orphaned NHI estates. NHIMG research shows 91% of former employee tokens remain active after offboarding, which is a strong signal that ownership gaps are not theoretical; they are operational. The same pattern appears in NHI Lifecycle Management Guide and the Top 10 NHI Issues, where delayed revocation and unclear stewardship repeatedly turn temporary access into durable risk. The OWASP Non-Human Identity Top 10 frames this as a governance failure, not just a hygiene issue.

In practice, many security teams discover the gap only after an incident review shows a pipeline token, service principal, or portal account still live months after the system owner moved on.

How It Works in Practice

Ownership should follow the identity lifecycle, not the ticket queue. The team accountable for the underlying platform identity should define when access begins, who can approve changes, what signals trigger deprovisioning, and where revocation must be enforced. That usually means shared responsibility across platform engineering, cloud operations, IAM, and the application team, but with one named owner for lifecycle policy and one named executor for technical teardown.

For platform identities, offboarding usually needs to cover at least four paths: API credentials, workload tokens, portal or console access, and any downstream service-to-service trust that was delegated from the original identity. That is why current guidance increasingly treats secrets and identities as lifecycle-bound assets, not static configuration. The Guide to the Secret Sprawl Challenge shows how duplicated secrets make revocation harder because one forgotten copy can preserve access even after the primary credential is removed.

Operationally, teams should:

• Assign a single system-of-record owner for each platform identity and secret source.
• Require expiry, rotation, or decommission dates at creation time.
• Use JIT provisioning and short TTLs where possible so offboarding is mostly automatic.
• Revoke at the identity provider, secret store, CI/CD runner, and cloud control plane, not just in the app.
• Log and verify completion, because “disabled” is not the same as “unusable.”

For implementation patterns, the OWASP Non-Human Identity Top 10 and the lifecycle guidance in Ultimate Guide to NHIs both point toward revocation-by-design rather than manual cleanup. These controls tend to break down in multi-team environments where platform ownership is split across DevOps, security, and application squads because no single party sees the full blast radius.

Common Variations and Edge Cases

Tighter offboarding controls often increase coordination overhead, requiring organisations to balance fast delivery against complete revocation. That tradeoff is real in CI/CD, shared service accounts, and cross-environment automation where one identity may support many workloads and many owners. In those cases, the best practice is evolving toward context-specific ownership rather than a single universal rule.

One common edge case is a shared platform credential used by multiple applications. If one app is retired, security cannot simply delete the secret without checking whether other systems still depend on it. Another is vendor-managed automation, where the platform team may own the identity but the vendor controls the runtime. In those environments, offboarding requires contract-aware teardown steps and explicit confirmation that downstream trust has been removed.

Another nuance is that secret revocation alone does not fully solve access if long-lived refresh tokens, cached credentials, or runner-side copies remain active. Current guidance suggests treating these as separate lifecycle objects. Where there is no universal standard yet, teams should at least require evidence of revocation at the source of truth, in the secret store, and in any execution environment that could still replay the credential. NHIMG’s CI/CD pipeline exploitation case study shows why this matters when build systems retain powerful access long after the original job ends.

For broader control mapping, the same lifecycle discipline aligns with the shared accountability model described in 230M AWS environment compromise, where unmanaged identities and stale access paths magnified impact.

Related resources from NHI Mgmt Group

• Who should own zero-knowledge secrets governance in an enterprise?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?