How Vault Enterprise derives client identity for billing—findings from testing

Vault
1

Hi Vault community,

I’ve been digging into how Vault Enterprise counts clients for billing. The official docs cover token and identity behavior well, but connecting it to billing implications takes some digging—and most teams I’ve worked with only fully understand it after an unexpected invoice.

I ran controlled, repeatable tests on Vault Enterprise 1.21.1 (Raft storage, tokens actually exercised) and wanted to share what I found. This is purely community-driven—not official HashiCorp guidance.

Key observations:

  • Vault bills by unique active clients, not token count

  • Entity-backed auth (LDAP, OIDC, userpass, AppRole with aliases) anchors to entity_id—all associated tokens count as 1 client, stable and predictable

  • Non-entity tokens (direct vault token create, orphan tokens, token auth method) derive identity from namespace + sorted policy names (deduplicated since 1.9, which was a big improvement)

  • Orphan tokens never inherit entity_id, even from entity-backed parents with sudo—the entire downstream chain stays non-entity forever

  • Batch tokens inherit entity by default (unless created with -orphan), making them safer for short-lived automation

  • A single entity-backed principal with sudo on auth/token/create can mint tokens with arbitrary policy sets—hundreds of workloads can collapse to 1 client (efficient for billing, but reduces visibility into usage diversity)

I documented the full methodology, comparison tables, remediation options, and audit queries here: https://myros.net/how-vault-enterprise-actually-counts-clients

Curious to hear from others:

  • Have you seen different behavior on versions newer than 1.21.1?

  • Any real-world surprises or mitigations you’ve implemented?

  • Corrections to anything above?

Happy to discuss more — thanks for reading.