Security categories fail all the time. Most of them quietly disappear into the Gartner graveyard with a deprecation notice and a vague successor category nobody asked for. We mourn them briefly, update the slide deck, and move on.
ISPM and ITDR are more interesting than that. They diagnosed real problems in enterprise identity security. In many cases they were technically correct. But many of these technologies couldn't solve the underlying issue, and that distinction matters if you're trying to understand where identity security actually goes from here.
To get there, you have to look at how identity actually works inside large enterprises, not how it appears in architecture diagrams, which are famously optimistic documents.
The Problem They Were Trying to Solve Was Real
By the mid-2010s, most enterprise IAM programs had become deeply fragmented. A typical large company had an Active Directory team, a PAM team, an IGA team, a cloud platform group managing IAM as an afterthought, and SaaS access scattered across helpdesk tickets and application admins who may or may not still work there. Each system managed its own slice of identity. None of them had a complete picture of the environment. None of them particularly wanted one either, because a complete picture tends to come with a complete list of problems.
More importantly, none of the teams operating those systems were incentivized to build one. Budgets, ownership, and tooling were aligned to specific platforms, not to the overall identity estate. Nobody's annual review said "understands the full picture."
Then Identity Security Posture Management (ISPM) showed up. The pitch was simple: connect to your identity systems and we'll show you where things are misconfigured. Stale accounts, dormant admin rights, orphaned service accounts, shadow administrators buried somewhere in Active Directory, OAuth grants floating around SaaS platforms that nobody remembers approving. For a lot of organizations, the posture dashboard was the first time anyone had seen those issues across systems at once. That was genuinely useful, even if what followed was a governance meeting and a very long to-do list nobody owned.
ITDR came from a different angle. Security teams had been feeding authentication logs into SIEMs for years. The problem was context. Knowing that someone logged in at 3 AM isn't that interesting, people work odd hours unfortunately. But knowing that a privileged administrator authenticated to a production database at 3 AM, using credentials that were exposed in a Kerberoasting attack two weeks earlier, and that this deviates sharply from their normal behavior? That's something a SOC can actually act on.
So why didn't these categories scale, at least not in the way identity teams needed them to across the hybrid infrastructure visibility that enterprises needed them to play in?
A Quick Caveat on "Scale"
Before going further, it's worth being precise about what "didn't scale" actually means here. ITDR was successfully utilzed when it became a feature of endpoint and XDR platforms sold to SOC teams and CISOs who were already buying those platforms anyway. It succeeded as an add-on capability for security operations, not as a standalone discipline owned by identity teams. Vendors didn't have to convince IAM engineers to rethink their architecture. Instead, they gave the SOC more signal inside a console they already lived in.
ISPM never had that kind of host platform to attach to, and ITDR as a standalone identity-first capability, the version that was supposed to change how IAM programs operate, largely stalled. The SOC got a better alert. The identity team got a dashboard nobody fully owned. Those are very different outcomes.
Nobody Actually Owned the Outcome
A security tool without clear operational ownership rarely becomes part of day-to-day operations. It becomes a reporting dashboard. Someone buys it, it generates findings, those findings get presented in governance meetings, and then everyone nods and agrees that this is indeed a lot of findings.
ISPM runs into this immediately. The tool might detect a stale admin account in Active Directory, but fixing that belongs to the AD team. It might find excessive permissions in Salesforce, which belongs to a completely different team. It might flag a shadow admin in Azure AD, and now you're dealing with the cloud platform group, who have their own priorities and their own quarterly roadmap and their own opinion about whose problem this really is. The posture platform can aggregate findings across all of these. What it cannot do is aggregate the authority to fix them.
In practice the findings follow a familiar lifecycle. The dashboard fills up. A governance committee reviews it. A consulting partner prioritizes remediation. Fixes roll out slowly over quarterly change windows. Nothing is technically broken in this process. It's just slow. And when remediation moves slowly, posture scores move slowly, and renewal conversations become uncomfortable for everyone except the consulting firm.
ITDR has an even stranger ownership problem. The tool lives somewhere between identity engineering and security operations, two teams that historically don't overlap much and don't always agree on whose job it is to care. The SOC knows how to run detections and investigate incidents. The identity team understands service accounts, privilege models, and how authentication systems actually behave. ITDR requires both skill sets simultaneously. Most enterprises do not have a team that naturally sits at that intersection, which means the alerts land in a queue where neither side feels fully responsible for responding. Technically the platform is deployed. Technically everyone is very busy.
Then You Run Into the Denominator Problem
This one is less visible, but more fundamental. Most large organizations do not have a complete inventory of privileged identities. Not a reliable one. And before anyone sends me an angry email: yes, I know your organization has a CMDB. I'm sorry.
Metrics like "coverage of privileged accounts" are usually calculated from snapshots taken across disconnected systems. The data is exported on schedules, reconciled by hand when it conflicts, and updated just slowly enough to guarantee drift. Any metric built on top of that data inherits the same error.
The real identity estate includes cloud roles created directly in infrastructure consoles, service accounts in SaaS platforms nobody integrated, automation credentials sitting inside CI/CD pipelines, local administrator privileges granted during system imaging and never revisited, and service principals operating on short-lived tokens that expire before the next data sync. A posture tool can only assess the identities it knows about. Everything outside that perimeter is invisible, and in most Fortune 500 environments, the invisible portion is not small.
ITDR inherits the same blind spot. Detection logic works on the identities it can see. Credentials that were never catalogued never receive a behavioral baseline. An attacker who understands enterprise identity architecture knows this. The most dangerous credential in the environment is often the one nobody is monitoring, because nobody realized it existed. This is not a hypothetical. It's a recurring theme in breach post-mortems that people read, nod along to, and then fail to structurally address.
This is fundamentally a data problem. You can improve detection logic. You can tune posture algorithms. None of that fixes the underlying issue if the input data is incomplete. More sophisticated analytics on top of incomplete data just produces more sophisticated wrong answers, delivered with greater confidence.
The Consulting Incentive Problem
There's also a quieter structural issue that doesn't get talked about much, probably because a meaningful portion of the identity industry's conference circuit is sponsored by the same firms involved.
In organizations large enough to consider dedicated identity security tooling, identity programs are often heavily supported by consulting firms. These firms do genuinely important work but their incentives are aligned with services engagements that scale with the complexity of the environment.
When a posture tool identifies thousands of identity issues inside a large enterprise, it creates the conditions for a multi-year remediation program. The tool generates findings. The consulting engagement clears them. From the consulting firm's perspective, this is a very good outcome. From the platform vendor's perspective, the value of the tool is now embedded inside the services engagement it enabled rather than inside the platform itself. From the customer's perspective, they are now in year three of a project that was originally scoped for eighteen months.
There's also a simpler version of the same dynamic. Before ISPM tools existed, consulting firms were already delivering identity maturity assessments: a team would spend several weeks reviewing systems and produce a long report full of findings. ISPM automated that process. The problem is that most enterprises didn't need faster findings. They needed faster remediation. If the backlog was already measured in quarters or years, generating findings faster didn't materially change the outcome. It just meant the pile got bigger, faster.
What Would Have Needed to Exist First
Both ISPM and ITDR assumed something about enterprise identity infrastructure that was rarely true. They assumed the underlying identity data was already complete and reliable. It wasn't.
Most identity programs were operating on partial inventories assembled from disconnected systems. Posture and detection were layered on top of that foundation. And if the foundation is incomplete, everything built on top of it inherits the same blind spots, which is a polite way of saying the math doesn't work.
The sequence actually needs to run the other way. First you build a continuously updated picture of the identity estate, every account, every entitlement, every service principal, across every connected system. Then you build controls on top of that. Once the data layer is accurate, posture insights become a natural output. Detection signals improve because every identity has a behavioral baseline. Access reviews and governance decisions operate on the same ground truth instead of competing spreadsheet exports from three different teams who all have different numbers and are each convinced they're right.
The capabilities ISPM and ITDR promised start to make sense once the underlying identity data is trustworthy. Before that point, they're trying to solve an infrastructure problem with analytics.
The Diagnosis Was Right
ISPM and ITDR correctly identified two real problems: ungoverned configuration surfaces, and invisible attack paths created by fragmented identity infrastructure. Those problems absolutely exist. What these categories couldn't provide was the ground truth needed to actually solve them.
They were tools designed to analyze identity environments that most organizations still didn't fully understand.
Until that foundation exists, a continuous, accurate, unified view of the identity estate, posture dashboards and identity detections are navigating with an incomplete map. And incomplete maps are a dangerous thing to rely on, especially when the attackers already know where the blank spaces are.