Teams should separate human licensing from machine consumption and price around measurable identity actions such as access requests, entitlement changes, tool calls, and provisioning events. That approach aligns commercial usage with real operational load, avoids shelfware, and gives security and finance the same picture of what the identity programme actually does.
Why identity pricing has to follow machine activity, not human headcount
When bots and agents do most of the work, the old per-seat model stops reflecting how the identity platform is actually consumed. The real cost driver becomes identity actions, not named users. Pricing should therefore track the volume of access requests, entitlement changes, tool calls, credential events, and provisioning activity that the platform must process.
That shift matters because machine-driven environments create load spikes in authentication, policy evaluation, approvals, logging, and lifecycle automation that a simple user count never captures. If commercial terms ignore that activity, teams either underprice heavy automation or overpay for unused human seats while the platform does the work elsewhere.
For teams building out non-human identity coverage, the same principle shows up in how they think about Non-Human Identities and in the operational differences described in the Cloud Workload Identity Guide. A machine that requests access hundreds of times a day, rotates secrets, or triggers policy checks is a different commercial object from a human employee account.
What to price, and what not to bundle into seats
The cleanest pricing models separate the person who configures or oversees the system from the automated workload that uses it at scale. Human licensing can remain focused on admin, review, and governance functions. Machine consumption should be metered against the identity events that create measurable backend work, especially where automation drives repeated authentication, policy checks, approvals, or downstream provisioning.
That also means pricing should be tied to the platform’s own cost and control boundaries. If a bot generates 10,000 entitlement evaluations, the platform is doing 10,000 governance actions whether or not a human was involved. If an agent invokes tools or request flows continuously, it is consuming more than a passive account ever would. Good commercial design follows those work units instead of trying to force every actor into a human-style subscription.
Teams that want a practical taxonomy can use the same lifecycle lens found in the NHI Lifecycle Management Guide and the more general identity taxonomy in the Ultimate Guide to NHIs. Those resources reinforce a useful pricing rule: charge for the managed identity workload, not just for the name attached to it.
How to keep the model fair for security, finance, and engineering
A workable model needs one shared measurement language. Security usually cares about privilege, lifecycle, and governance load; finance cares about predictable spend; engineering cares about not turning usage into a tax on automation. The best compromise is to define metered units that are easy to observe, hard to game, and closely aligned to actual platform effort.
In practice, that means choosing a small set of billable events and making them transparent in reporting. Access requests, approval steps, entitlement updates, secret rotations, tool invocations, and provisioning events are easier to defend than vague proxies such as “active bots” or “managed agents.” Teams should also decide whether read-only checks, failed requests, and internal retries count, because those details can materially change both cost and user behaviour.
If the platform also supports agentic systems, the pricing language should stay consistent with the control model described in the Agentic AI Identity Guide. Once an agent can request access, call tools, or act under delegated authority, its consumption is no longer theoretical. Commercial terms should reflect that operational footprint from day one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Metering identity actions directly affects IAM service consumption and governance cost. |
| Recommendation — Price managed identity actions separately from human seats and align charges to IAM work volume. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token, secret and credential rotation load is a measurable cost driver in machine-heavy identity use. |
| IA-9 — Service Identification and Authentication | Bots and agents authenticate as services or workloads, which changes the operating load. | |
| Recommendation — Meter credential lifecycle handling to reflect authenticator volume and rotation work. Treat service-to-service authentication as a distinct consumption class from human access. | ||
| NIST CSF 2.0 | GV.OC-03 — Mission Context | Pricing should reflect the organisation's operational context and how identity services are actually used. |
| Recommendation — Align pricing metrics to the operational role identity automation plays in the business. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access-control operations drive the measurable work behind identity platform consumption. |
| Recommendation — Base commercial assumptions on access-control workload rather than user count alone. | ||
Practitioner Guidance
What to prioritise: Start by defining the billable identity events that are already observable in logs, workflow engines, or IAM telemetry. If you cannot measure the event cleanly, you cannot price it cleanly.
Decision rule: If a workload can create repeated auth, approval, entitlement, or provisioning actions, meter that workload separately from human licences. If it only consumes a dashboard or occasional review function, a human-style subscription may still be acceptable.
What to verify: Check that metering cannot be inflated by retries, duplicates, or noisy automation loops. The pricing model should track genuine identity work, not accidental system chatter.
Practitioner takeaway: The right model prices the strain on identity operations, not the number of people on payroll; if bots and agents generate the load, they should also define the unit economics.
Related resources from NHI Mgmt Group
- How should security teams price identity platforms when non-human identities drive most activity?
- What do security teams get wrong about Workload Identity Federation for agents?
- How should security teams implement workload identity in Azure when deploying AI platforms with AKS and Azure OpenAI?
- How should security teams govern access to identity security platforms when users, bots, and automation all interact with the same site?