Join our Newsletter — 33% off our NHI Course

ForgeRock End of Support

ForgeRock End of Support means the vendor has stopped providing maintenance, security fixes, and standard technical assistance for its identity platform. After this date, organizations using the software must assess migration, compensating controls, and risk acceptance because unpatched vulnerabilities and compatibility gaps can affect IAM, SSO, and identity governance.

What End of Support Means for an Identity Platform

end of support is not just a calendar date. For an identity platform, it marks the point where the vendor stops maintaining the software, which changes how confidently teams can rely on it for access, authentication, and identity governance workflows.

That matters because identity systems sit on a critical trust boundary. When support ends, the product may still run, but the organisation can no longer assume routine fixes, compatibility updates, or vendor-backed assistance will arrive when a defect or vulnerability appears.

Why End of Support Creates Security Exposure

Unsupported identity software tends to accumulate exposure in three ways: unpatched vulnerabilities remain open longer, dependent components drift out of compatibility, and operational workarounds start to replace normal vendor-supported maintenance. Top 10 Vulnerability Management Mistakes is useful here because end-of-support risk is often magnified when teams delay remediation or rely on risk acceptance without an expiry plan.

The danger is especially high for identity platforms because compromise can affect far more than one application. If the platform is a central SSO or IAM control point, a weakness there can cascade into account access, federation trust, and downstream authorization decisions across many services.

How Organisations Assess Exposure and Plan the Transition

Exposure assessment starts with inventory: where the software runs, which environments depend on it, what internet-facing entry points exist, and which adjacent systems rely on its authentication or directory functions. Teams should also review vendor advisories and lifecycle notices to confirm whether the product is in extended support, limited support, or fully unsupported status.

That review should be paired with dependency mapping, because identity products rarely stand alone. If a directory, portal, agent, connector, or federation component depends on the unsupported platform, the practical exposure is broader than the primary application footprint. Patch Tuesday Guide is relevant as a planning model for coordinated maintenance windows, even when the product itself is not Microsoft software.

Remediation, Compensating Controls, and Post-Change Review

The preferred response is migration or replacement, but when that cannot happen immediately, organisations need compensating controls that reduce the blast radius of a failure. That usually means tightening network exposure, restricting administrative access, increasing monitoring, isolating the platform from unnecessary integrations, and reducing reliance on long-lived credentials or weak trust relationships. .NET Security Guide is a helpful adjacent reference for the general principle that runtime support dates and secure dependency management affect the security posture of a platform, even when the exact product differs.

After upgrade or migration, the review should not stop at service restoration. Teams should look for signs of pre-existing compromise, verify configuration drift, and confirm that any accounts, tokens, certificates, or administrative sessions associated with the old platform are rotated or retired where appropriate.

What Practitioners Should Watch After End of Support

The most common failure mode is treating end of support as an administrative notice rather than a live security condition. Once vendor support ends, every unresolved defect becomes harder to justify, every exception becomes more expensive to defend, and every delayed migration increases the chance that the identity platform becomes the weakest part of the access stack.

Practitioners should also watch for hidden business dependency. If the platform underpins SSO, directory sync, or identity governance workflows, a delayed transition can create authentication outages, privilege review gaps, and recovery complexity that extend well beyond the original product team.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
CIS Controls v8 CIS-7 — Continuous Vulnerability Management End-of-support systems need ongoing exposure tracking and remediation prioritisation.
Recommendation — Inventory unsupported identity software and prioritise migration or compensating remediation before new exposures accumulate.
NIST CSF 2.0 PR.MA-01 — Maintenance and Repairs Unsupported platforms require disciplined maintenance planning and change coordination to reduce service and security disruption.
ID.AM-02 — Asset Inventory Knowing where the identity platform runs and what depends on it is central to end-of-support exposure assessment.
Recommendation — Plan maintenance windows and controlled transition steps for the identity platform before support ends. Map every deployment, dependency, and internet-facing instance of the identity platform.
NIST SP 800-53 Rev 5 SI-2 — Flaw Remediation Unsupported software leaves flaws unremediated, making flaw management and compensating controls critical.
CM-8 — System Component Inventory End-of-support decisions depend on knowing the exact software instances and connected components in use.
Recommendation — Replace or isolate unsupported identity software so known flaws do not remain indefinitely exploitable. Maintain a current inventory of identity platform components, versions, and connected integrations.