How should security teams price identity platforms when non-human identities drive most activity?

Why This Matters for Security Teams

Pricing identity platforms by named user seat makes sense for human workforce tools, but it distorts value and risk when non-human identities dominate activity. Service accounts, bots, and agents often generate far more access events than employees, and they do so around the clock. A better model prices the work the platform actually performs: policy evaluations, tool invocations, credential issuance, and privileged access decisions. That also aligns security and finance around measurable consumption rather than an artificial seat count.

This matters because NHI sprawl is not theoretical. NHI Mgmt Group reports that NHIs outnumber human identities by 25x to 50x in modern enterprises, while only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. When identity volume and activity are dominated by machines, seat-based pricing can understate control-plane load, hide overuse, and mask governance gaps. Current guidance from NIST Cybersecurity Framework 2.0 still points teams toward asset visibility, access control, and continuous monitoring, which are closer to operational consumption than to user counts. In practice, many security teams discover this mismatch only after audit friction or runaway machine activity has already exposed it.

How It Works in Practice

The simplest way to model pricing is to separate the identity platform into metered activities. First, count access events: token requests, API authorisations, and session starts. Second, count policy actions: approvals, denials, step-up challenges, and JIT credential issuance. Third, count tool invocations where agents or automation call downstream systems through controlled identity paths. That framing fits both PAM and broader NHI governance because the platform is doing more than storing identities; it is making runtime decisions and issuing short-lived access.

A practical approach is to build three internal cost buckets. One covers identity inventory and discovery, including service accounts and secrets locations. One covers enforcement, such as RBAC evaluation, ZSP checks, and workflow approvals. One covers privileged execution, including JIT issuance and revocation. That gives finance a usage lens and gives security a way to prove control-plane load. It also supports better conversations about where to invest in automation versus where to limit blast radius. NHI Mgmt Group research in the Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames. Those risks are easier to price when the platform is metered by the actions that reduce them.

For agentic environments, the pricing model should also reflect intent-based authorisation and workload identity. Agents do not follow fixed human-like access patterns, so static role assumptions break down. Best practice is evolving toward runtime policy evaluation, short-lived secrets, and workload identity proof through mechanisms such as SPIFFE or OIDC-backed assertions. That aligns with the control direction in NIST Cybersecurity Framework 2.0 and keeps the pricing unit tied to actual system behaviour. These controls tend to break down when legacy applications reuse one shared secret across many jobs because the platform cannot reliably attribute or meter each action.

Common Variations and Edge Cases

Tighter consumption pricing often increases reporting overhead, so organisations have to balance billing accuracy against operational complexity. That tradeoff is especially visible where one workflow fans out into many downstream calls, or where an agent chain triggers multiple tools per business task. There is no universal standard for this yet, but current guidance suggests using a blended model: price the platform partly by monitored identities and partly by the protected actions it enables.

Some environments need exceptions. High-volume CI/CD pipelines may justify lower per-action rates if they use strong workload identity and automatic revocation. Regulated environments may also need separate rates for privileged actions, since those events carry higher control costs than ordinary token validation. In breach-driven environments, the question is not just cost but containment: the 52 NHI Breaches Analysis and the Top 10 NHI Issues both show that visibility and rotation failures drive much of the risk. Security teams should therefore avoid pricing models that reward idle inventory but penalise control-plane usage. Where vendors only support seat counts, that usually signals a mismatch between product packaging and the machine-driven reality of the environment.

Related resources from NHI Mgmt Group

• How should security teams handle identity lifecycle gaps for non-human identities?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?