Tooling advanced

NHI Security in 2026: The Category Is Consolidating Before It Learned to Detect

A detection engineer's map of the NHI vendor landscape — and why it's being acquired into platforms before it built the part that catches breaches.

· 19 min read · Gowthamaraj Rajendran

The non-human identity security category did something unusual in the last eighteen months: it raised hundreds of millions of dollars, got a Gartner-adjacent acronym, and started getting acquired — all before it shipped the one capability it was founded to deliver. Astrix took a $45M Series B and a Cisco partnership [1][2]. Oasis raised a $120M Series B in March 2026, $195M total [3]. SailPoint bought Entro for around $200M [4]. Palo Alto closed its $25B acquisition of CyberArk — the company that had just spent $1.54B on Venafi to own machine identity [5][6].

Here is the uncomfortable part for anyone writing the check. Almost every product in this category sells you governance — discovery, inventory, posture, least privilege. Very few sell you detection — the ability to catch a valid credential being used maliciously at runtime. And detection is the part that would have caught the breach that made everyone care about non-human identities in the first place.

This post is a detection engineer’s map of the landscape: what these tools actually do, which of your problems each one solves, when to pick one over another, and what no amount of budget in this category currently buys you. If you’ve read 45 to 1: Non-Human Identities Are Your Biggest Detection Blind Spot, this is the buyer’s-guide companion — the same argument, pointed at the vendor floor.

”NHI Security” Is Four Products Wearing One Label

The first thing to understand is that “NHI security” is not one product. It is a label stretched over at least four genuinely different products that solve different problems at different layers of the stack. The vendors know this. The buyers frequently don’t — which is how an organization buys “non-human identity security,” deploys it, and still has zero ability to detect the attack it was worried about.

Here are the four layers.

Layer 1 — Secrets governance. Find the API keys, tokens, and certificates sprawled across your code, CI/CD, config files, and orchestration state, then vault and rotate them. This is the credential-hygiene layer. It answers: where are my secrets, and which ones are exposed? This is where Entro lived before SailPoint acquired it [4], and it overlaps heavily with the secrets-scanning tools your AppSec team may already run.

Layer 2 — NHI posture and lifecycle (ISPM). Discover every non-human identity, classify it, map it to a human owner, and flag the risky ones — stale, over-permissioned, orphaned. This is identity posture management. It answers: what NHIs exist, who owns them, and which are dangerous? Oasis, Clutch, and the posture side of Astrix and P0 Security live here. Most of what gets marketed as “NHI security” is this layer.

Layer 3 — Workload IAM (runtime access). Instead of handing a workload a long-lived secret, broker access at the moment of the request: verify the workload, evaluate context, inject a short-lived credential or grant secretless access just in time [7]. This is a prevention layer — it shrinks the attack surface by removing standing credentials. Aembit and Teleport are here, P0’s PAM side is here, and Oasis’s “Agentic Access Management” is a move in this direction [3][8]. It answers: should this workload get this access, right now?

Layer 4 — NHI threat detection and response (ITDR). Watch how identities behave at runtime and catch abuse: a token suddenly used from a new ASN, a service account fanning out to resources it never touches, an OAuth integration querying far more than it ever has. This is the detection layer. It answers the only question that matters after a credential is already valid and already stolen: is this access being used maliciously right now? Astrix’s Non-Human ITDR, Permiso, and Token Security are among the few naming this as a first-class capability [9][10]. It is, by a wide margin, the thinnest layer in the category.

The reason this taxonomy matters: a tool that is excellent at Layer 2 tells you a service account is over-permissioned. It will not tell you that the over-permissioned account is, at this moment, being used by someone who shouldn’t have it. Those are different products. Buying the first and believing you bought the second is the single most common mistake in this market.

Use the Layer That Matches Your Actual Problem

Layers are not a maturity ladder you climb in order. They are answers to different questions, and the right starting layer depends on which question is actually keeping you up at night. A few concrete “pick this over that” calls:

Pick Layer 1 (secrets governance) first when your exposure is sprawl — keys hardcoded in repos, tokens in CI logs, plaintext secrets in Terraform state. The CSA found plaintext secrets routinely hidden in orchestration state files, and only 20% of organizations have a formal process to even offboard and revoke API keys [11]. If you don’t know where your credentials are, nothing downstream works. This is the cheapest, highest-ROI starting point for a small team.

Pick Layer 2 (posture) over Layer 1 when you already vault your secrets reasonably well but have no idea how many service accounts, OAuth grants, and workload identities exist or who owns them. If your honest answer to “how many NHIs do you have?” is a shrug — and for most orgs it is; 82% have unknown AI agents running and only 5.7% have full visibility into service accounts [11][12] — posture is where the first real risk reduction comes from. This is also the layer that directly attacks the standing-privilege problem from Identity Creep.

Pick Layer 3 (workload IAM) over Layer 2 when you’re early enough or greenfield enough to prevent the sprawl instead of cataloging it. If you’re standing up new AI agents or a new platform, brokering secretless just-in-time access from day one is strictly better than discovering a mess later and governing it. The catch: it’s an architectural commitment, not a scanner you point at production. You can’t retrofit it across a legacy estate over a weekend.

Pick Layer 4 (detection) when — and only when — you can operate it. ITDR for non-human identities is the layer that catches the live compromise. It is also the one most likely to become shelfware, because it produces alerts that a human or an automation has to triage, and most teams that buy it have no one to run it. More on this below, because it’s the crux of the whole buy-versus-build question.

The practical reality is that most mature programs end up running two or three of these layers, often from different vendors, because no single product is genuinely best-in-class across all four — despite what every “unified platform” slide claims.

What the Whole Category Does Well: Inventory and Least Privilege

Credit where it’s due, because the governance layers are genuinely useful and I don’t want the detection critique to read as dismissal.

The best tools in Layers 1 and 2 do something your SIEM and your CSPM do not: they build an identity-centric graph. Clutch’s “Identity Lineage” tracks an NHI’s access, origin, ownership, storage, and usage in one view [8]. P0’s “Access DNA” maintains a continuously updated inventory of human, non-human, and AI identities and their effective permissions [13]. Oasis discovers, classifies, and governs machine identities across the environment to cut exposure from unmanaged credentials [3]. This is real work, and doing it by hand across a cloud estate is miserable. If your problem is “I have no inventory and no ownership,” these tools solve a problem you genuinely cannot brute-force.

But notice what this layer is: it is posture management. It reduces the conditions that let abuse succeed — stale roles, dormant accounts, overbroad entitlements — which is exactly the definition of ISPM (identity security posture management), the cousin of CSPM [14]. And here’s the trap the marketing sets: much of what’s sold as “NHI security” is functionally CIEM — cloud infrastructure entitlement management — with a new label [15]. CIEM is a slice of Layer 2. It’s valuable. It is not detection. You can buy a tool that perfectly manages your cloud entitlements and still have no idea when one of those entitlements is being abused.

The Cloud Security Alliance said this part out loud in April 2026, in a post titled — and I am not editorializing the title — “We Are Fixing the Wrong Problem in Non-Human Identity Security” [16]. When the standards body that runs the category’s flagship survey publishes that headline, the governance-heavy tilt of the market is not a contrarian take anymore. It’s the consensus catching up.

The Hole in the Middle: Nobody Is Watching Runtime

Here is the gap, stated plainly. Posture management (ISPM) reduces the chance of abuse. Detection (ITDR) catches abuse in progress. The category has poured its funding into the former and mostly skipped the latter — and the attack everyone cites as the reason NHI security matters was a runtime attack that no amount of posture would have stopped.

Go back to Salesloft Drift, which I walked through in detail in OAuth Abuse in SaaS. Attackers stole valid OAuth refresh tokens and used them to reach into hundreds of organizations’ Salesforce data. Every token was legitimate. Every permission was one the customer had granted. A perfect posture score would have shown green: the Drift integration was supposed to have that access. What gave it away was behavior — a trusted integration suddenly querying far more, far faster, and exfiltrating. That is a Layer 4 detection problem, and Layer 4 is precisely the layer the category underbuilt.

The asymmetry shows up in the maturity data. Organizations have reached some level of competence with human-user ITDR, but for non-human identities most lack the fundamentals — a solid inventory, let alone the ability to detect an NHI compromise effectively [9]. Only 12% of organizations are confident they can prevent NHI-based attacks at all [11]. And the structural reason your existing stack won’t cover the gap: SIEMs and XDRs don’t map NHI relationships, permissions, or abnormal usage, so even when the telemetry is technically present, nothing is correlating it into “this principal is behaving unlike itself” [9].

This is the same shape as Stage 1 of The Detection Funnel: the gap is not that detection is impossible, it’s that almost nobody has built and operated it. The difference here is that the vendors aren’t closing the gap for you either — they’re selling you the inventory and calling it security.

The Category Is Consolidating Before It Matured

Now layer the market structure on top, because it changes how you should buy.

The standalone NHI category is being absorbed into platforms in real time, and fast. SailPoint bought Entro [4]. Palo Alto bought CyberArk for $25B, after CyberArk had bought Venafi and Zilla to assemble a machine-identity portfolio [5][6]. Astrix is partnered into Cisco’s stack [2]. And the identity providers you already own are shipping NHI and agent identity natively: Microsoft launched Entra Agent ID in 2025 to assign managed identities to AI agents [17], and Okta shipped Okta for AI Agents in April 2026 to fold agents into the same policy, logging, and revocation controls as human users [18].

Read that together and the trajectory is obvious: in eighteen months, a meaningful share of what you’d buy from a standalone NHI startup today will be a feature inside your IdP or your platform vendor. That doesn’t make the startups wrong — they’re ahead on capability, and the platforms will be twelve to eighteen months behind on the detection layer specifically, because detection is always the last thing to mature. But it does mean you’re making a bet about who’s going to own this capability, and the bet has real switching costs attached.

So how do you buy into a category that’s being acquired out from under you?

So Do You Buy or Build?

Start with the strongest argument against my whole thesis, because it deserves a real answer: maybe governance-first is correct, and the detection critique is premature. You cannot detect anomalies on identities you haven’t inventoried. You cannot baseline what you can’t see. And every credential you eliminate with Layer 3 secretless access is a credential you never have to detect the theft of. By this logic, the category is building in the right order — inventory, then posture, then access control, and detection comes last because it should.

That argument is half right, and the half it gets right matters. If you have no inventory, buying an ITDR product is putting a smoke detector in a house you haven’t mapped. Governance genuinely comes first for a team starting from zero. But the half it gets wrong is the dangerous half: posture is not a substitute for detection, it’s a prerequisite for it. “We did the inventory” is not the same as “we’d catch the breach,” and a green posture dashboard during a Drift-style attack is exactly how you convince yourself you’re covered while you’re being robbed. Governance-first is a sequencing argument. It is not an excuse to stop before Layer 4.

So the answer is a mix, and the canonical build-versus-buy principle tells you how to split it: build what differentiates you, buy the plumbing [19]. If a capability is on your competitive surface you build it regardless of what the spreadsheet says; if it’s undifferentiated infrastructure you buy it regardless of how cheap building looks. For a detection program, inventory and posture are plumbing — every org needs the same asset graph and there’s no edge in hand-rolling your own. The detections that fire on your identities, baselined against their normal, are the differentiated capability. That’s the part worth owning.

The spreadsheet lies in both directions, so don’t let “we’ll just build it” or “we’ll just buy it” win on a napkin number. Naive build estimates come in low almost every time, and maintenance — not the initial build — is 60–80% of a tool’s lifetime cost [19]. On the buy side, hidden integration and training routinely add 150–200% on top of the license fee over a few years [20]. Neither path is cheap. The real question is not whether you spend but where the spend lands: in engineering you control, or in license and integration tax you don’t.

With that framing, four variables locate your org on the line — roughly in order of weight:

  1. Talent — the deciding variable. Can you actually operate and maintain the thing, built or bought? A detection product generates alerts someone has to work; a home-built pipeline needs someone to keep it alive. With well over half of organizations reporting significant security skills shortages [21], this is the constraint that overrides the rest — buying Layer 4 you can’t staff is the same shelfware as building it and walking away.
  2. Use case — do you actually need it yet. Be honest about whether the capability solves a problem you have or one you imagine you’ll have. The prevention-shaped problems (sprawl, over-permissioning) are real for almost everyone. The detection-shaped problem becomes real the moment you have crown-jewel NHIs — and not much before. Buying ITDR before you have an inventory is a smoke detector in an unmapped house.
  3. Existing telemetry. Do you already collect what detection runs on — CloudTrail, Entra and Okta sign-in and audit logs, SaaS audit APIs, OAuth consent events? If you do, the build path for Layer 4 is far shorter than any vendor pitch admits, because the hard part was always the data, not the rules.
  4. Budget, measured honestly. Not the sticker price — the five-year TCO including the maintenance and integration tax above. A small team almost always comes out ahead buying the commodity layers, because the opportunity cost of scarce engineers building an asset graph is the detections they didn’t write.

The most common landing spot — and the right one for most mid-size programs — is hybrid: buy a core platform for the commodity layers, then build your differentiated detection on top [19]. Three worked examples of how those variables resolve:

  • Mid-size cloud-native SaaS, two detection engineers, decent SIEM, tight budget. Buy Layer 1 to kill secret sprawl fast — highest ROI per dollar — and build Layer 4 on the SIEM telemetry you already pay for, using per-identity baselines. Don’t buy an ITDR platform two people can’t run.
  • Large regulated enterprise, mature SOC, already runs Okta/CyberArk/Entra, wants consolidation. Buy Layers 2–3 from the platform you already own, accept it’s somewhat behind a startup, and keep runtime detection in-house — the platform’s ITDR will be the last piece to mature, and your SOC can carry it in the meantime.
  • AI-forward startup shipping agents with real tool access, eng-heavy, no detection team. Buy Layer 3 (workload IAM) and make secretless, just-in-time access the default before the sprawl exists. Prevention beats detection you have nobody to operate. Build nothing yet; you don’t have the team.

The pattern across all three: buy the layer that’s commodity and prevention-shaped, build or own the layer that’s specific to you and detection-shaped, and extend the bought tool toward your SIEM rather than treating it as a closed box.

Which brings us to the consolidation problem, and here my position is a merge of two instincts, with the first as the priority. First: portability is the only lock-in that matters. If the tool emits its findings and raw signals into your SIEM and you own the detection logic, then an acquisition changes the logo on the invoice, not your coverage. Build it so the vendor is a data source, not a dependency, and the consolidation churn becomes someone else’s problem. This is the priority because the consolidation is happening now — you don’t have the luxury of waiting for the dust to settle. Second, and underneath it: protect yourself contractually. Acquisitions kill roadmaps, raise prices, and force migrations. Before you sign, get the boring terms — data export guarantees, price caps, exit clauses — and run a real switching-cost analysis. The contract is the seatbelt; data portability is not crashing in the first place. You want both, but if you only get one, get the portability.

What to Actually Do Monday

The NHI security category is real, useful, and worth money — for inventory, posture, and runtime access control. Buy those layers; they’re commodity and not worth your engineering time. But do it with clear eyes about what you’re getting: you are buying governance, and governance is not detection. The part that catches the Drift-shaped breach — runtime behavioral detection on your own identities, baselined against their own normal — is the thinnest layer in the market, the last one the consolidating platforms will mature, and therefore the part you should plan to own regardless of who you buy from.

So three moves. Map your problem to a layer before you take a single demo, so you don’t buy CIEM thinking it’s ITDR. Make portability a hard requirement in every contract, because the vendor you sign today may be a platform feature by the time your renewal comes up. And own your detection layer — build it on telemetry you already collect if you have the talent, or buy it but keep the signals flowing into your SIEM if you don’t. The category is consolidating before it learned to detect. The detection is the part you’ll still own either way — so own it on purpose.

Resources

  1. Astrix Security Raises $45M Series B to Redefine Identity Security for the AI Era — PR Newswire, Dec 2024.
  2. Cisco adds Astrix Security’s NHI to its growing cybersecurity stack — SDxCentral.
  3. Oasis Security raises $120M to secure nonhuman identities across AI and cloud environments — SiliconANGLE, Mar 2026.
  4. SailPoint acquires Israeli cyber startup Entro Security in $200 million deal — Calcalist (Ctech).
  5. Palo Alto Networks Completes Acquisition of CyberArk to Secure the AI Era — Palo Alto Networks, Feb 2026.
  6. CyberArk Positions Machine Identity Security as its 2026 Growth Engine — SoftwareReviews (covers Venafi/Zilla acquisitions).
  7. Non-Human Identity Management vs. Machine Identity vs. Workload IAM — Aembit.
  8. Clutch Security Raises $20M Series A to Lead the Charge in Non-Human Identity Security — Clutch Security (Identity Lineage, Universal NHI Platform).
  9. Identity Threat Detection & Response for NHIs — What Does Right Look Like? — Resilient Cyber.
  10. Non-Human ITDR for NHI Threat Detection — Astrix Security.
  11. The State of Non-Human Identity and AI Security (Survey Report) — Cloud Security Alliance / Oasis, Jan 2026.
  12. AI is flooding IAM systems with new identities — Help Net Security (82% unknown AI agents stat).
  13. P0 Security — Access DNA and unified identity control — P0 Security.
  14. What is the difference between ITDR and ISPM? — Non-Human Identity Management Group.
  15. Non-Human Identity Security vs. CIEM: Understanding the Differences — Clutch Security.
  16. We Are Fixing the Wrong Problem in Non-Human Identity Security — Cloud Security Alliance, Apr 2026.
  17. Microsoft Entra Agent ID — identities for AI agents — Microsoft, 2025.
  18. Okta announces new blueprint for the secure agentic enterprise — Okta, Apr 2026.
  19. Build vs. Buy Software Decisions and Total Cost of Ownership Analysis — SoftwareSeni (strategic differentiation, hybrid pattern, maintenance as majority of lifetime cost).
  20. A Deep Dive into Total Cost of Ownership (TCO) in Build vs. Buy — Jaspersoft (hidden integration and training costs).
  21. State of Cybersecurity 2025 — CompTIA (security skills shortage).