Convergence of ITDR, PAM and IGA. Which of the three is standing there when the attack lands?

But how is the work split up? Privileged Access Management (PAM) and Identity Governance & Administration (IGA) handle prevention: they decide who holds privilege and when they're allowed to use it. Identity Threat Detection and Response (ITDR) job is different. It watches, and it tells you when something's already gone wrong. Bolt all three into one console and underneath it, you still have three separate jobs.

We found out where that division breaks by paying strangers to attack us.

We ran a managed bug bounty through Bugcrowd against a moderately hardened Active Directory. Attacks were submitted by people paid for results rather than completing a checklist. DCSync, LSASS process dumping, and NTDS.dit access block bypass were among them. We found that 100% of attacks performed by standard users and IT administrator accounts were detected and prevented.

But in cases where a hacker started holding valid domain admin credentials, the attacks succeeded, because the requests coming from that account were the requests a domain admin makes. That case belongs to PAM. Figuring out which accounts hold hidden power in the first place belongs to IGA.

We stopped everything on that list while it was still being attempted, not after the fact. That distinction matters more than it sounds like it should. An attack stopped mid-attempt never becomes an incident anyone has to investigate; it never lands your company name in breach headlines.

Some of it can be taken back: restore a group membership, reset a password, strip a delegation, and you're mostly back to where you started.

But with some attacks it stops working. Take Certificate Services for example. A template that lets the requester supply their own subject alternative name will issue a certificate naming whoever asked as somebody else. Enroll, name a privileged account, and you walk away with a credential that authenticates as it.

None of the usual fixes touch that. Reset the password and the certificate still works. Fix the template and you've only stopped the next attacker, not the one already holding a valid credential. Roll back the directory and you still haven't touched it, because the privilege was never in the directory. It's sitting in a certificate store, valid until it expires or somebody revokes that specific certificate by hand.

At that point, an alert just tells you where to start digging. Blocking the enrollment is the only thing that reliably ends it.

Netwrix PingCastle and 1Secure assess identity security posture, map findings to MITRE ATT&CK, and rank them by risk, so remediation starts with what would actually hurt. At the protocol layer, patented threat prevention blocks NTDS.dit reads, LSASS dumps, and unauthorized replication requests right at the domain controller, before they succeed. Netwrix Threat Manager detects and responds to threats that can't be blocked. And when something does get through, automated AD forest recovery and granular rollback across AD, Entra ID, and Okta bring things back, down to the specific object that changed.

If you want to see it against your own directory, we can arrange that. Contact us for a demo.