What breaks when deprovisioning and access certification are not tightly governed?

Why This Matters for Security Teams

Deprovisioning and access certification are the control points that prove access still has a business need. When they are weak, organisations do not just accumulate clutter, they accumulate attack paths: ex-employees, dormant service accounts, stale API keys, and privileged entitlements that no longer match job function. That gap weakens least privilege, undermines audit evidence, and gives incident responders less confidence that access can be contained quickly.

This is why lifecycle governance shows up repeatedly in NIST Cybersecurity Framework 2.0 and in the OWASP Non-Human Identity Top 10. NHIMG’s Ultimate Guide to NHIs highlights that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong signal that many teams still rely on manual cleanup after access has already gone stale. In practice, many security teams discover stale access only after an audit exception or a breach review, rather than through intentional governance.

How It Works in Practice

Strong governance starts with inventory, ownership, and revocation paths. Every identity, human or non-human, should have a named owner, a business purpose, and a defined expiry or review cadence. For human access, certification should verify whether the role still requires the entitlement. For NHI access, certification should also confirm whether the workload still exists, whether the secret is still in use, and whether the token or certificate can be safely revoked without breaking production.

Current best practice is to connect joiner-mover-leaver workflows to access review evidence so that deprovisioning happens automatically when a person changes role or leaves. For NHIs, this usually means linking the identity lifecycle to secret rotation, service retirement, and policy checks at runtime. NHIMG’s NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs both emphasise that the control is not just revocation, but provable revocation.

A practical operating model typically includes:

• ownership metadata for each identity and credential
• time-bound reviews for privileged entitlements and dormant accounts
• automatic disablement for departed users and retired workloads
• secret rotation or token reissue after certification failure
• logs that show who approved, who executed, and when the change took effect

For control design, map these steps to NIST SP 800-53 Rev 5 Security and Privacy Controls and the evidence expectations in Regulatory and Audit Perspectives. These controls tend to break down when entitlements are managed in separate IAM, ticketing, and secrets systems because no single workflow can prove that access was removed everywhere it mattered.

Common Variations and Edge Cases

Tighter deprovisioning often increases operational overhead, so organisations must balance speed against the risk of breaking legitimate work. That tradeoff is especially visible in shared accounts, emergency access, and NHIs embedded in CI/CD pipelines. Guidance suggests that the stricter the environment, the more automation matters, but there is no universal standard for exact review intervals or expiry windows yet.

Edge cases usually appear when access is indirect. A user may be offboarded, yet retain access through a group, application role, or delegated admin path. Likewise, a service account may look dormant while still powering a scheduled job. This is why certification must check actual usage, not just membership lists. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis show that governance failures frequently become breach-enabling only when stale access is paired with excessive privilege.

Two patterns deserve special handling. First, break-glass access should be time-boxed and reviewed immediately after use, not left to periodic certification cycles. Second, long-lived secrets should be treated as technical debt with an owner and retirement date, because the evidence burden grows every day they remain valid. That is the practical line between manageable access and access that can no longer be defended in audit or incident response.

Related resources from NHI Mgmt Group

• What breaks when access certification does not include remediation evidence?
• Why does SAP data migration fail when access and validation are not governed tightly?
• What breaks when SAP ECC implementations are not tightly governed across modules and integrations?
• What breaks when contractor access is not tightly governed on the factory floor?