ForgeRock is PingAM and PingIDM now. Your upgrade plan should say so.
ForgeRock deployments still need upgrading, they just go by PingAM, PingIDM and PingDS now. We plan each move against Ping's LTS and STS rules, so you don't land on a version whose support runs out early.
PingAM, PingIDM, PingDS (renamed since early 2024)
Long-Term Support
PingAM 7.5
Short-Term Support
PingAM 8.0
release watch
ForgeRock products renamed
PingAM 7.5 is LTS, 8.0 is STS05 Dec 2025
connects with
in short·15-second read
ForgeRock is now part of Ping Identity.
Access Management is PingAM and Identity Management is PingIDM. Cohash upgrades and supports these deployments from 7.x to 8.x, including custom nodes, scripts and connectors. We plan each upgrade against Ping's End of Life policy, where PingAM 7.5 is a Long-Term Support version and 8.0 is Short-Term Support, and we configure PingAM 8.1 support for AI agents.
you probably need this if
AM or IDM is on 7.x and the team can't decide between 8.0 now or waiting for the next LTS.
Custom Java authentication nodes break on every upgrade and get rewritten under deadline.
IDM reconciliation fails overnight, and nobody finds out until a new hire can't sign in.
05 Dec 2025PingAM 7.5 is LTS, 8.0 is STS From February 2026, ForgeRock-origin products fall under Ping's single End of Life policy, which is built around LTS releases. source ↗
18 Jun 2026STS and LTS lifecycle rules An STS version gets one year of maintenance after the next version ships, then one year of End of Maintenance. There's no Extended Limited Support for it. LTS versions get at least three years. source ↗
today · Oct 22, 2026
no date yetForgeRock products renamedThe renames took effect in early 2024. ForgeRock Access Management is PingAM now, and ForgeRock Identity Management is PingIDM.source ↗
no date yetPingAM 8.1 AI agentsAI agents as OAuth 2.0 identities using delegated token exchange. 8.1.1 adds DCR script methods for agent attributes when AM is integrated with PingIDM.source ↗
the story · forgerock (ping) estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your ForgeRock (Ping) estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · forgerock (ping) estate3 open
openAM or IDM is on 7.x and the team can't decide between 8.0 now or waiting for the next LTS.
recurringCustom Java authentication nodes break on every upgrade and get rewritten under deadline.
blockedIDM reconciliation fails overnight, and nobody finds out until a new hire can't sign in.
exposure
Upgrades to PingAM and PingIDM 8.xChoosing LTS or STSJourneys and custom nodesPingIDM sync and provisioningAI agents in PingAMTakeovers and health checks
startrehearsehandover
Deployment review
Version decision
Code and config changes
Rehearsal and cut-over
Agents and handover
we are here
ready to hand over
We get AM onto a version with a known end-of-life date and put the forty nodes in source…
The assistant changes bookings using its own narrow token.
Version plan choosing LTS or STS per product, with support end dates
Custom node and script inventory checked against Ping's removed-feature lists
chapter 01 · where it hurts
Why teams reach out
AM or IDM is on 7.x and the team can't decide between 8.0 now or waiting for the next LTS.
Custom Java authentication nodes break on every upgrade and get rewritten under deadline.
IDM reconciliation fails overnight, and nobody finds out until a new hire can't sign in.
chapter 02 · what we change
How we solve it
Upgrades to PingAM and PingIDM 8.x
Choosing LTS or STS
Journeys and custom nodes
PingIDM sync and provisioning
AI agents in PingAM
Takeovers and health checks
chapter 03 · how it runs
Our approach
Deployment review
Version decision
Code and config changes
Rehearsal and cut-over
Agents and handover
chapter 04 · where you end up
What changes
We get AM onto a version with a known end-of-life date and put the forty nodes in source control, with tests.
The assistant changes bookings using its own narrow token.
Version plan choosing LTS or STS per product, with support end dates
Custom node and script inventory checked against Ping's removed-feature lists
what we do
Our ForgeRock (Ping) work
6 kinds of ForgeRock (Ping) work, each run by engineers who have done it on live tenants.
Custom authentication nodes, scripts and PingIDM mappings reviewed against Ping's incompatible-changes and removed-features lists, then rehearsed on a copy of production.
A version plan that weighs new features against support length, so you upgrade fewer times without falling out of maintenance.
Authentication journeys simplified where they've sprawled, custom Java nodes reviewed, and scripted decision nodes retested after each upgrade.
Mappings, reconciliation schedules and connectors tuned, with live sync and reconciliation jobs monitored so failures surface the same day.
PingAM 8.1 AI agent clients set up as OAuth 2.0 identities that act for users through delegated token exchange, with agent attributes managed through PingIDM.
A review of an existing deployment's custom code, pipeline and configuration, with a ranked list of fixes before any upgrade work starts.
capability 01 / 06in production
Upgrades to PingAM and PingIDM 8.x
Custom authentication nodes, scripts and PingIDM mappings reviewed against Ping's incompatible-changes and removed-features lists, then rehearsed on a copy of production.
PingAM 8.1 AI agent clients set up as OAuth 2.0 identities that act for users through delegated token exchange, with agent attributes managed through PingIDM.
We pieced these together from ForgeRock (Ping) situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
AM 6.5 with forty custom Java nodes and a sync that fails on weekends
composite · not a client story
Beforethe situation
An access management deployment still runs ForgeRock AM 6.5 with about forty custom Java authentication nodes. The IDM sync from HR fails silently on weekends, and the team can't decide between landing on 7.5 or going straight to 8.x.
What we dothe work
We inventory the nodes and scripts, check each against Ping's incompatible-changes and removed-features lists, and rebuild the ones that break. The target version comes from Ping's End of Life policy: 7.5 for a long stay, 8.x only if you will keep moving through releases.
Afterwhere you end up
We get AM onto a version with a known end-of-life date and put the forty nodes in source control, with tests. If the HR sync fails on a Saturday, somebody hears about it that day.
case file 02
A customer portal that wants an AI assistant to act for signed-in users
composite · not a client story
Beforethe situation
There's a self-service portal backed by a consumer-facing PingAM deployment. Product wants an AI assistant that changes bookings for users, and the current plan has the agent reuse the user's session cookie.
What we dothe work
We move to PingAM 8.1, register the assistant as an AI agent client and use delegated token exchange, so it gets its own narrower token on the user's behalf. Agent attributes live in PingIDM. Before committing we check how long 8.1 is supported in Ping's EOL tracker.
Afterwhere you end up
The assistant changes bookings using its own narrow token. The user's session cookie stays in the browser. For every change, the audit log shows which agent made it and for which user.
We don't start a step until the last one has produced something you can check.
step 01
Deployment review
We read your AM trees and the custom nodes hanging off them, the IDM mappings and connectors, DS topology and the deployment pipeline. Whatever has to be fixed before upgrade work can start goes at the top.
step 02
Version decision
We weigh staying on PingAM 7.5 LTS against moving to 8.x STS. Ping's End of Life dates go into that, along with the features you'd actually use.
step 03
Code and config changes
Every custom node and script goes up against Ping's incompatible-changes and removed-features lists, and so do the IDM mappings. Then we fix them and test in your pipeline.
step 04
Rehearsal and cut-over
The upgrade runs on a copy of production, DS data included. In production we check sign-in, reconciliation and live sync before sign-off.
step 05
Agents and handover
If you need them, we set up PingAM 8.1 AI agent clients for delegated token exchange. After that, your team takes over the runbooks and monitoring.
ai on forgerock (ping)
Where AI fits on ForgeRock (Ping), and where it needs guardrails.
ForgeRock products ship as PingAM and PingIDM now. PingAM 8.1 treats AI agents as OAuth 2.0 identities that act for users through delegated token exchange. That's only in 8.x, and 8.x follows Ping's Short-Term Support rules. So if you move for agent support, we'd plan on moving through releases from then on.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
ForgeRock (Ping)does the work
Ping doesn't document an MCP server for PingAM or PingIDM. So agents go through PingAM's OAuth 2.0 endpoints, each with a dedicated agent client and delegated tokens on narrow scopes. Writes through PingIDM REST should run under a scoped service account. We log them, and a person approves them.
AI agents in PingAM 8.1
In PingAM 8.1, an AI agent is registered as an OAuth 2.0 identity and gets its own tokens on a user's behalf, through delegated token exchange. For us that's the setup for every assistant. None of them reuses a user's session cookie.
Agent attributes through PingIDM
When AM is integrated with PingIDM, PingAM 8.1.1 adds dynamic client registration script methods for agent attributes. We'd put agent ownership and attributes in PingIDM. That puts agents on the same lifecycle as every other identity.
AI help with custom node upgrades
Most ForgeRock upgrades break on the custom Java nodes and scripts. An AI coding assistant can check each one against Ping's incompatible-changes list and draft the fixes and tests. Engineers then review them and run them in your pipeline.
How PingAM, PingIDM and PingDS fit together after ForgeRock
PingIDM reconciles people from HR and Active Directory and keeps the PingDS identity store current. PingAM reads that store to sign users in, issue OIDC and SAML responses to apps, and hand delegated tokens to AI assistants.
01 · Sources
HR systemWorkday · SAP → PingIDM · reconciliation
Active DirectoryLDAP connector → PingIDM · LDAP sync
02 · Identity management
PingIDMmappings · recon · live sync → PingDS · sync identity store
03 · Directory and access
PingDSidentity and config stores
PingAMauth trees · OAuth 2.0 · sessions → PingDS · user lookup→ Web and mobile apps · OIDC · SAML→ AI assistant · delegated token→ Internal APIs · access tokens
04 · Apps and agents
Web and mobile appsOIDC · SAML
AI assistantdelegated token exchange
Internal APIsOAuth 2.0 access tokens
Read the diagram as text
HR system → PingIDM: reconciliation
Active Directory → PingIDM: LDAP sync
PingIDM → PingDS: sync identity store
PingAM → PingDS: user lookup
PingAM → Web and mobile apps: OIDC · SAML
PingAM → AI assistant: delegated token
PingAM → Internal APIs: access tokens
use cases
Typical ForgeRock (Ping) projects
The work teams usually bring us, and the platforms ForgeRock (Ping) has to talk to while we do it.
FOR-01You're on AM or IDM 7.x and unsure whether to go to 8.0 or wait
common request
FOR-02Custom nodes and scripts turn every upgrade into a rewrite
common request
FOR-03Support renewals now come from Ping and the terms look different
common request
FOR-04Chatbots or internal assistants need delegated tokens from PingAM
common request
FOR-05You're weighing self-managed PingAM against a hosted Ping service
common request
These are working documents, written against your configuration, so your team can run them without us.
plan01
Version plan choosing LTS or STS per product, with support end dates
yours to keep
inventory02
Custom node and script inventory checked against Ping's removed-feature lists
yours to keep
tests03
Upgrade rehearsal log from a copy of production, with timings
yours to keep
inventory04
Map of authentication journeys showing which can be merged or retired
yours to keep
document05
PingIDM reconciliation monitoring with same-day failure alerts
yours to keep
talent and delivery · forgerock (ping)
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
ForgeRock to Advanced Identity Cloud migration lead
PingDS directory administrator
due diligence · forgerock (ping)
Questions to ask any partner, including us.
Put these to anyone bidding on your ForgeRock (Ping) work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which version should we land on, given Ping's LTS and STS rules?
PingAM 7.5 is Long-Term Support and 8.0 is Short-Term Support. STS versions reach End of Life two years after the next version ships, so parking on one brings the next upgrade sooner than many teams expect.
Q2
How will you test our custom nodes against Ping's removed-features list before the upgrade?
Custom Java nodes and scripted decisions are where ForgeRock upgrades fail. Each one needs testing on the target version, ideally in a pipeline, and not after cutover.
Q3
What happens if we need to stay longer than the LTS window allows?
Extended Limited Support is a paid year, LTS versions only, covering Severity 1 and security fixes with no new features. It buys time to finish the upgrade. It won't do the upgrade for you.
Q4
Is Ping's EOL tracker the source for the support dates in your plan?
Per-version dates live in Ping's tracker. Plans built from memory or an old partner deck miss the changes Ping made when it unified the ForgeRock and Ping policies.
Q5
How will an AI agent get tokens in PingAM without borrowing a user's session?
In PingAM 8.1 an AI agent is an OAuth 2.0 identity that uses delegated token exchange. Reuse the session cookie instead and the agent disappears from the logs. It also gets every right the user has.
01Is ForgeRock still supported?
It is, though the names are Ping Identity's now. Look for PingAM (Access Management), PingIDM (Identity Management) and PingDS (Directory Services). Ping's End of Life policy governs support. Ping's EOL tracker has the dates per version.
02Should we upgrade to PingAM 8.0 or stay on 7.5?
PingAM 7.5 is Long-Term Support, so it has the longer runway. 8.0 is Short-Term Support and hits End of Life two years after the next version ships. If you want 8.x features, like the AI agent support that arrived in 8.1, plan on moving through releases as they come. Parking on an STS version doesn't work for long.
03What happens when an LTS version reaches End of Support?
If your subscription is current you can buy a single year of Extended Limited Support. Severity 1 fixes are covered, and so are critical or high security fixes where Ping thinks they're reasonable. New features and new OS support aren't. Once the year's up, the version is End of Life.
04Can you take over a ForgeRock deployment another partner built?
Yes. We start with a review of custom nodes, scripts, mappings and the deployment pipeline, then agree what to keep, fix and simplify.
05How long does a ForgeRock upgrade take?
It depends on the number of custom nodes, scripts and PingIDM mappings, and how many versions you are crossing. A lightly customized deployment moves faster than one with dozens of custom Java nodes. We estimate after reviewing your custom code against Ping's change lists.
services
Related services
Projects on ForgeRock (Ping) usually end up touching one of these, so they're worth a look.
