If you’ve sat through identity security vendor pitches over the last few years, you’ve probably heard some version of the same promise: deploy this, and credential-based attacks stop being a problem.
Most of those pitches aren’t lying, exactly. They’re just describing the demo. Production is a different environment, one with change-control processes, risk-averse infrastructure teams, engineers who will absolutely find the path of least resistance when a tool slows them down, and budgets that don’t stretch as far as the licensing model assumes.
Quick answer: The identity security market has largely converged on four architectural patterns: kernel-level Domain Controller agents, single-vendor “walled garden” ecosystems, governance-and-certification (IGA) platforms, and traditional privileged access vaults (PAM). Each solves a real piece of the problem. Each also has a structural weakness that tends to surface only after the contract is signed, and it’s worth understanding those weaknesses before you commit budget and engineering time to one.
This is Part 2 of our series on the identity perimeter. Part 1 covered how attackers exploit identity in the first place; this post is about why the tooling built to stop them so often underdelivers.
Credential abuse remains one of the most persistent breach patterns. Verizon’s 2026 Data Breach Investigations Report found it in 39% of breaches when counted across the full attack chain. That is why Identity Threat Detection and Response (ITDR), PAM, and IGA budgets keep growing. Here is how the four most common approaches compare once they reach production:
| Approach | What it assumes | Where it breaks in production | What it can’t see |
|---|---|---|---|
| Domain Controller kernel agent | Infrastructure teams will accept kernel-mode risk on DCs | A driver conflict or bad update can crash a DC and break authentication | Okta, AWS IAM, and SaaS logins |
| Single-vendor “walled garden” | The enterprise runs on one vendor’s stack | Identities cross into other platforms and clouds | Everything outside the ecosystem, plus air-gapped and sovereign networks |
| IGA (Identity Governance and Administration) | Reviewers have the bandwidth to actually review | Certification fatigue turns reviews into rubber-stamping | How access is being used right now |
| PAM (Privileged Access Management) | Engineers always choose the sanctioned path | Friction during outages creates shadow access paths | Standing privilege between rotations |
In short: Kernel agents on Domain Controllers carry crash risk for the system every login depends on, and they can’t see identity activity outside on-prem Active Directory.
The pitch: Install a lightweight sensor directly into the kernel of your Domain Controllers for maximum visibility into every authentication event, in real time, at the source.
The reality in production: Domain Controllers are about as close to sacred ground as infrastructure gets. They authenticate everything, everywhere, constantly, which is exactly why most AD administrators treat any request to install third-party kernel-mode code on one with real suspicion, and for good reason. Kernel space doesn’t forgive mistakes. A driver conflict, a memory leak, a poorly tested update pushed during a routine patch cycle: any of these can crash a Domain Controller outright. This is the core of domain controller kernel agent risk. Security teams have watched this exact failure mode play out publicly enough times in the broader endpoint security world that “kernel agent on a DC” has become close to a non-starter in a lot of infrastructure reviews, independent of how good the detection logic behind it is.
There’s a second problem that’s less dramatic but just as limiting: a sensor sitting on your Domain Controller has no visibility into anything happening outside it. Authentication in Okta, AWS IAM, or a SaaS app’s own login flow is simply invisible to a tool that only watches on-prem AD. And the licensing tends to match the architecture’s ambition: per-seat pricing in the $5 to $10-plus range per user per month is common, which gets expensive fast for any organization managing tens of thousands of identities, MSSPs especially.
In short: Native identity protection works well inside one vendor’s ecosystem, but most enterprises run identities across many platforms, and these tools usually need cloud connectivity that air-gapped and sovereign environments can’t provide.
The pitch: If your identity and compute already live inside one major platform ecosystem, that platform’s native identity protection should be the natural, integrated choice.
The reality in production: Almost no real enterprise runs on a single vendor’s stack, no matter how large that vendor is. A walled-garden tool is genuinely strong at watching its own ecosystem, and largely blind the moment an identity touches anything outside it. Okta, Ping, AWS IAM roles, a long tail of SaaS apps with their own login flows: all of it sits outside the garden wall, which means attackers who understand this simply route around it.
There’s also a practical constraint that rules the approach out entirely for some organizations: these tools generally assume continuous outbound connectivity to the vendor’s cloud. In sovereign data environments, defense and government networks, or air-gapped industrial OT systems, that assumption doesn’t hold, and the tool doesn’t work at all.
In short: IGA governs who should have access, not how access is being used, and repeated certification campaigns tend to decay into rubber-stamping.
The pitch: Solve identity risk at the source by formalizing who has access to what, with regular manager sign-off and structured recertification campaigns.
The reality in production: IGA platforms answer an important but narrow question (what access does someone have on paper) and have essentially no visibility into how that access is actually being used in real time. They can’t tell you a credential is being actively abused right now, because runtime behavior was never what they were built to watch.
The bigger issue is human, not technical. Ask a manager to review forty employees’ full permission sets every quarter, and the first review might get genuine scrutiny. By the third or fourth cycle, it’s usually a five-minute click-through, “approve all,” because nobody has the bandwidth to meaningfully evaluate that much access, that often. The formal process keeps running. The actual risk reduction quietly stops. That is how IGA shelfware happens: the platform is live, the campaigns are running, and the control has stopped controlling anything. And getting to that point in the first place is rarely fast: 12 to 18 months of implementation is a realistic range for a full rollout, which is a long time to operate without the protection the project was funded to deliver.
In short: PAM vaults add friction exactly when engineers are under the most pressure, which creates shadow access paths, and credential rotation alone doesn’t remove standing privilege.
The pitch: Route every privileged session through a centralized vault. Administrators check out credentials, connect through a monitored jump host, and every privileged action gets logged.
The reality in production: PAM’s logic is sound, and for well-governed, low-urgency access, it works. The trouble starts at 2 a.m. during an outage, when an engineer needs to get into a system right now and the vault workflow adds friction at exactly the moment friction is least tolerable. Engineers under pressure are resourceful. They create local service accounts. They embed credentials in scripts. They find, or build, a path around the vault, and once that shadow path exists, it tends to stay in use long after the outage is resolved, because it’s faster than doing it the sanctioned way. This is the pattern behind most PAM vault problems, and a textbook case of privileged access management friction.
There’s also a subtler architectural gap: rotating a privileged credential regularly doesn’t remove the account’s standing privilege. Between rotations, the account is still a full administrator around the clock, whether anyone is using it or not, which means if it’s compromised, the attacker inherits real, immediate authority. Just-in-time access models are designed to reduce this, but adoption is uneven, and shadow paths created outside the vault remain outside its coverage either way. And because PAM tools typically operate as their own island, correlating a privileged session with what’s happening elsewhere on the network usually requires manual work the SOC doesn’t have time for.
Look past the specifics, and a pattern shows up: each of these approaches was built to solve part of the identity problem exceptionally well, in a way that assumes the rest of the environment will accommodate it. Kernel agents assume infrastructure teams will accept the risk. Walled gardens assume a single-vendor environment. IGA assumes reviewers have the bandwidth to actually review. PAM assumes engineers will always choose the sanctioned path over the fast one.
Production environments rarely make those accommodations. And every time a tool assumes friction that doesn’t materialize, that friction gets absorbed somewhere else, usually by an overworked IT team finding a workaround, which quietly reopens the exact gap the tool was bought to close.
None of this means identity security is a lost cause, or that these categories of tools are worthless: IGA, PAM, and directory-level monitoring all solve real problems within their scope. It means the industry has mostly been optimizing each piece in isolation, without asking a more basic question: what would an approach look like if it were designed from the start around zero added operational friction: no kernel risk, no single-vendor lock-in, no certification fatigue, no jump-box workaround?
That’s the question we’ll walk through in Part 3 of this series, where we get specific about the architecture behind Seceon aiSecurity UIDGuard360 and how it was built to close the gaps described here without introducing new ones of its own.
ITDR is a security category focused on detecting and responding to attacks that abuse identities and identity infrastructure, such as stolen credentials, privilege escalation, and attacks on Active Directory or identity providers. Access-management tools decide who should have access. ITDR watches how identities are actually behaving and flags activity that points to compromise.
Because Domain Controllers are foundational to enterprise authentication, and kernel-mode code, even well-tested code, carries a nonzero risk of driver conflicts, memory issues, or crashes. A single Domain Controller outage can disrupt authentication across the entire organization, which makes many infrastructure teams unwilling to accept that risk regardless of the detection benefit.
IGA platforms govern access on paper, who is entitled to what, but generally have limited visibility into how access is actually used at runtime. They’re also vulnerable to “certification fatigue,” where repeated, high-volume access reviews become a rubber-stamping exercise rather than a genuine control.
IGA governs entitlements, provisioning, and access certification: who should have access. ITDR monitors runtime behavior: how an identity is acting right now, and whether that activity indicates credential abuse. An account can hold fully legitimate access and still be compromised, which is why the two solve different problems.
Usually under time pressure. When a vault’s checkout workflow adds meaningful delay during an active incident, engineers often create workarounds (local accounts, embedded credentials, direct access) that persist after the incident ends, quietly undermining the vault’s coverage.
It can work well for an organization that genuinely operates entirely within one vendor’s ecosystem. The risk is that almost no real enterprise stays that way for long: multi-cloud footprints and third-party SaaS adoption tend to outgrow the walled garden, leaving blind spots the tool was never built to cover.
Seceon aiSecurity UIDGuard360 is an AI-driven identity security module within the Seceon Open Threat Management (OTM) platform. It discovers identity accounts agentlessly across Active Directory, Entra ID, Okta, AWS IAM, and SaaS applications, and correlates them into unified identity profiles. Working with Seceon aiITDR™, it detects and responds to identity-based threats across hybrid and multi-cloud environments.
This is Part 2 of a 3-part series on modern Identity Threat Detection & Response. Read Part 1: Why Today’s Attackers Don’t Hack In. They Log In., or continue to Part 3: The Zero-Friction Alternative.
