Why do certificate-based authentication programmes still need access review and offboarding?

Why This Matters for Security Teams

Certificate-based authentication is often treated as self-managing because the cryptography is strong, but that assumption misses the governance problem: a valid certificate can still point to an identity that should no longer have access. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research both show that lifecycle control is where risk accumulates, not just at issuance. In Entro Security’s findings, 91% of former employee tokens remain active after offboarding, which is a clear warning that credential validity and business legitimacy are not the same thing. The same pattern applies to certificates, API keys, and other secrets tracked in NHI Lifecycle Management Guide.

Security teams get caught when certificates survive role changes, app decommissioning, or employee departure because no one owns the review. Access review answers whether the certificate should still exist; offboarding ensures there is no lingering entitlement path after the person or workload leaves. In practice, many teams discover this only after an audit finding, an expired account cleanup, or a suspicious certificate still functioning in production.

How It Works in Practice

A certificate is an authentication artifact, not a guarantee of ongoing authorization. That means certificate programmes need the same lifecycle controls as other NHIs: inventory, ownership, periodic review, and revocation. The practical model is simple. First, every certificate should map to a named business owner, workload owner, or service account owner. Second, the review process should confirm that the identity behind the certificate still has a valid business purpose. Third, offboarding should revoke or disable the certificate when the owner changes roles, leaves, or the workload is retired.

In mature environments, this is automated through a joiner-mover-leaver workflow and integrated with certificate lifecycle tooling. The Critical Gaps in Machine Identity Management report notes that only 38% of organisations have automated certificate lifecycle management, which helps explain why manual review remains necessary even in certificate-heavy environments. Pair that with the Ultimate Guide to NHIs for a lifecycle view, and the operating pattern becomes clear:

• Use a complete certificate inventory to identify what exists and who owns it.
• Review certificates on a fixed cadence to validate necessity, scope, and expiration.
• Revoke certificates immediately on offboarding, decommissioning, or ownership transfer.
• Prefer short-lived certificates and automated renewal where possible, but still require approval for continued use.

For machine and workload identities, this is especially important because certificates can outlive the context that justified them. When ownership is unclear, the certificate may remain technically valid long after the access should have ended. These controls tend to break down when certificate issuance is automated but ownership tracking is still spreadsheet-driven, because no one can prove which identity is still entitled to use the certificate.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, so organisations have to balance availability against revocation speed. That tradeoff matters most in high-availability systems, shared service accounts, and legacy applications that cannot tolerate frequent reissuance. Current guidance suggests that these environments still need review and offboarding, but the mechanism may need exceptions, compensating controls, or staged migration rather than immediate hard revocation.

There is no universal standard for this yet, but best practice is evolving toward continuous validation rather than annual checkbox reviews. Short-lived certificates reduce exposure, yet they do not eliminate the need to confirm whether the identity is still legitimate. The same is true for workload certificates and mutual TLS identities: if the workload is retired or repurposed, the certificate must be removed from the trust chain. This is why NHIMG’s Top 10 NHI Issues emphasizes lifecycle blind spots, and why the OWASP NHI model treats revocation and ownership as core controls rather than administrative extras.

Edge cases arise when certificates are embedded in appliances, vendor-managed services, or air-gapped systems. In those cases, offboarding may require coordinated replacement planning, but the governance requirement does not change: someone must still verify the certificate’s business justification and remove access when the justification ends.

Related resources from NHI Mgmt Group

• Why do certificate-based authentication programmes fail in practice?
• What is the difference between role-based access and API key governance for NHI security?
• When should organizations review access controls?
• Why do user access reviews matter so much in FedRAMP programmes?