The point at which an identity system is no longer treated as a supported production control and must be replaced or retired. In practice, the risk is not the label itself but the leftover trust relationships, audit dependencies, and access paths that continue to rely on it.
Expanded Definition
Identity platform end of life is the operational point where an IAM, directory, federation, or credential orchestration platform can no longer be treated as a supported production control. For NHI security, the concern is not only decommissioning software, but also removing every workload trust path, token issuer dependency, audit trail integration, and automation hook that still assumes the platform is authoritative.
Usage in the industry is still evolving because some teams describe this as product retirement, while others treat it as a lifecycle control tied to migration, reassignment, and revocation. In practice, it should be read alongside NIST Cybersecurity Framework 2.0 because unsupported identity infrastructure directly affects access control, logging, recovery, and supplier risk. NHI Management Group treats this as a governance event, not a procurement event, because the hidden failure mode is stale trust that survives after the platform is no longer maintained.
The most common misapplication is assuming the platform is safely retired when the license expires, which occurs when service accounts, API keys, or federation metadata still point to it.
Examples and Use Cases
Implementing identity platform end of life rigorously often introduces migration overhead and short-term access risk, requiring organisations to weigh continuity of authentication against the cost of retiring trust paths cleanly.
- An enterprise replaces a legacy SSO platform but leaves machine-to-machine tokens valid until they fail, so workloads continue authenticating through a deprecated issuer.
- A SaaS provider migrates directories yet misses embedded certificate validation in a CI/CD pipeline, leaving build systems dependent on the old platform.
- A regulated firm retires an identity vendor only after re-pointing all audit exports and event collectors, because downstream monitoring still depends on the former control plane.
- During a post-incident review, analysts map orphaned service accounts to a sunsetted identity broker and discover access persisted well past the intended retirement date.
These scenarios match patterns seen in Top 10 NHI Issues and the 52 NHI Breaches Analysis, where the failure is usually not the planned migration itself but the overlooked dependency graph. The control question is whether every NHI, secret, federation trust, and audit feed has been re-homed before the platform is treated as dead. This also aligns with NIST Cybersecurity Framework 2.0 because recovery and access continuity must be validated, not assumed.
Why It Matters in NHI Security
Identity platforms often sit at the center of workload authentication, secret distribution, and privileged automation, so end of life becomes a security issue when retired systems are still trusted by agents, applications, or pipeline jobs. NHI Management Group notes that 91.6% of secrets remain valid five days after notification in incident contexts, which underscores how slowly credential dependencies disappear even when teams believe a system has been cleaned up.
That persistence matters because platform retirement can expose hidden service accounts, stale tokens, and undocumented federation links that were never subject to current controls. When those paths remain active, the business inherits unsupported cryptography, broken revocation processes, and audit gaps that become visible only during incident response or compliance review. The operational lesson is that decommissioning must include credential invalidation, trust map teardown, and evidence that no NHI still depends on the old authority. Organisations typically encounter the real consequence only after a failed login, a broken pipeline, or an unexpected access event, at which point identity platform end of life becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Covers identity and access protections that must be removed or migrated at platform retirement. |
| NIST CSF 2.0 | DE.CM-8 | Monitoring must confirm legacy identity dependencies stop working after decommissioning. |
| OWASP Non-Human Identity Top 10 | NHI-09 | Lifecycle and decommissioning failures leave stale NHI trust and access behind. |
Treat platform end of life as an NHI offboarding exercise and remove every dependent secret and token.
