How to Audit Vault Tokens, Policies and Auth Methods

A Vault cluster is only as safe as the tokens it has issued, the policies attached to them and the auth methods that hand them out, and all three drift quietly after go-live. This guide is a repeatable audit for HashiCorp Vault: how to list auth methods and their TTL tuning, find root, orphan and periodic tokens through accessors, review policies for broad globs and sudo, check AppRole secret IDs and confirm that audit devices are recording. It is for Vault operators, platform teams and identity teams who need evidence that Vault itself is not the weakest machine identity in the estate. The commands and endpoints come from the Vault 1.21 documentation; check them against your version. For architecture and secrets engine design, start with the HashiCorp Vault Guide.

Key takeaways

Accessors are the inventory: Vault documents that the only way to list tokens is auth/token/accessors, which returns accessors, needs sudo, and must be tightly controlled because accessors can revoke tokens.
Two kinds of token can live forever: root tokens with a TTL of zero, and periodic tokens that keep being renewed; Vault calls periodic tokens the only way outside root for a token to have an unlimited lifetime.
Policy is most-specific-match, not union: if different patterns match, only the highest-priority match applies, so a broad glob in one policy and a narrow rule in another can behave differently from what reviewers expect.
TTL defaults are long: the system max_lease_ttl and default_lease_ttl both default to 768h (32 days), and a mount tune can raise or lower that.
Audit devices are the evidence: without an enabled audit device there is no history of who used which token, and disabling a device means its old hashes can no longer be computed.

When you need this

Periodic control review: quarterly for production clusters, or as part of an access certification that covers machine identities. See the Secrets Management Guide.
After an operator leaves: Vault's production hardening guidance warns that removing accounts in Vault or the identity provider may not immediately revoke token-based access, and recommends removing group membership, revoking active leases and deleting the user's canonical entity.
Before and after an upgrade or migration: token formats changed in Vault 1.10 (service tokens hvs., batch tokens hvb., recovery tokens hvr.), which matters for scanners looking for leaked tokens.
When a Vault token is found in a repository, log or image: you need to identify it by accessor, see what it can do and revoke it and its children. See the Git Secret Scanning Guide.
When an auth method was added in a hurry: for example a Kubernetes or JWT role for a new pipeline with wide bound claims or long TTLs.

Before you start

An audit policy, not root: write a dedicated read-only policy for the review. Listing accessors and reading sys/auth/:path/tune and sys/audit are root-protected paths, so the audit policy needs sudo on exactly those paths and nothing else. Issue the audit token with a short TTL.
Namespaces: on Vault Enterprise or HCP Vault Dedicated, repeat every step in each namespace; set VAULT_NAMESPACE or use -namespace.
Load awareness: listing all accessors on a large cluster is heavy. Vault's own documentation uses that list call to gauge the impact of a token tidy, so run it outside peak hours and allow for timeouts.
Policies in version control: Vault recommends treating configuration as code; have the repository open so you can diff what is live against what was approved.
Evidence store: save JSON output (-format=json) with a timestamp for every step.

Step-by-step

1. Inventory auth methods and their tuning

List mounts: vault auth list -detailed (API GET /v1/sys/auth). Record path, type, accessor, description and any default_lease_ttl or max_lease_ttl overrides.
For each mount, read tuning with GET /v1/sys/auth/:path/tune. A mount max TTL may be longer than the system max, and Vault respects it.
Read the server configuration for system values: default_lease_ttl and max_lease_ttl default to 768h.
List roles per method (for example vault list auth/approle/role, Kubernetes or JWT roles) and record token_ttl, token_max_ttl, token_period, token_type, token_policies and any bound CIDRs or claims.
Flag unused methods (for example userpass or token roles left from setup) and methods without a documented owner.

2. Inventory tokens through accessors

List accessors: vault list auth/token/accessors (API LIST /v1/auth/token/accessors). Vault documents this as listing accessors for all current service tokens; batch tokens are not stored and do not appear.
Look up each accessor: vault token lookup -accessor <accessor> (API POST /v1/auth/token/lookup-accessor). The response does not include the token itself.
Record the fields that matter: policies, identity_policies, path (which auth method issued it), display_name, entity_id, creation_time, expire_time, ttl, explicit_max_ttl, period, orphan, renewable and num_uses.
Classify each token using the table below.

Finding	How to recognise it in lookup output	Why it matters	Default action
Root token	`policies` includes `root`; `ttl` 0 means it never expires	Vault states root tokens can do anything and recommends revoking them once initial setup or the emergency is over	Revoke; regenerate with `vault operator generate-root` and a key holder quorum only when needed
Periodic token without explicit max TTL	`period` set, `explicit_max_ttl` 0	Never expires while renewed; Vault advises keeping the period short and not giving periodic tokens to humans	Add an explicit max TTL on the issuing role or replace with a normal TTL
Orphan token	`orphan` true	Survives revocation of the token that created it, so parent-based cleanup misses it	Confirm the creator and purpose; revoke if unexplained
Token created directly, not via login	`path` is `auth/token/create` or `auth/token/create-orphan`	Often hand-made for a script and forgotten	Move the workload to an auth method role
Long remaining life	`expire_time` far ahead, high `creation_ttl`	A leaked token stays useful for weeks	Reduce role TTLs; re-issue
Wide policy set	Many entries in `policies` or `identity_policies`	Effective access may be broader than the role name suggests	Review in step 3

3. Review policies

List policies: vault policy list (API GET /v1/sys/policy) and read each with vault policy read <name>.
Diff live policies against version control. Any policy that exists only in Vault is a finding.
Search for high-risk grants: sudo anywhere; any path on sys/*, auth/* or identity/*; create or update on auth/token/create; * globs near the start of a path; + wildcards in mount paths.
Read the default policy. It is attached to all tokens unless excluded, and Vault will never overwrite your changes to it, so additions made years ago persist silently.
Check list grants on sensitive paths: Vault notes that keys returned by list are not filtered by policy, so secret names reveal information.
Test effective access rather than reading alone: vault token capabilities <token> <path> uses /sys/capabilities to show what a token can do on a path. Run it for sample tokens from each role against your most sensitive paths.

4. Review AppRole secret IDs

For each role, list secret ID accessors: LIST /v1/auth/approle/role/:role_name/secret-id.
Look up each with POST /v1/auth/approle/role/:role_name/secret-id-accessor/lookup and record expiry, remaining uses and CIDR bindings.
Flag roles with bind_secret_id set to false, roles without secret_id_ttl or secret_id_num_uses, and roles without secret_id_bound_cidrs or token_bound_cidrs where the client network is known.
Destroy unexplained secret IDs with secret-id-accessor/destroy.

5. Check audit devices and lockout

List devices: vault audit list -detailed (sys/audit is root-protected). HashiCorp recommends at least two: Vault refuses requests it cannot log to at least one enabled device, so a single device is an availability risk as well as a visibility gap.
Check options: by default Vault writes an HMAC-SHA256 keyed hash of most string values. Note any device with hmac_accessor=false (accessors in clear text, useful for emergency revocation but, as Vault notes, usable for denial of service) or log_raw.
Confirm logs reach your SIEM and that the audit files have restricted permissions.
Check user lockout configuration for userpass, ldap and approle, which Vault supports for these methods.

Verify it worked

Metric	Source	Target
Live root tokens	Accessor lookups where `policies` contains `root`	Zero outside a recorded emergency
Periodic tokens without explicit max TTL	Accessor lookups	Zero, or each with an exception
Policies not in version control	Diff of `sys/policy` against repository	Zero
Policies granting `sudo`	Policy text search	Short, named list owned by the platform team
Auth mounts with max TTL above policy	`sys/auth/:path/tune`	Zero
Enabled audit devices	`vault audit list`	Two or more, both shipping to the SIEM

Then confirm detections: search the audit log for requests on auth/token/create, sys/policy/*, sys/auth/* and sys/audit/* during the review window and check that each change maps to a ticket.

Rollback and common errors

Revoking a parent token kills its children: revocation cascades down the token tree and revokes associated leases. Check for child tokens and leased dynamic credentials before revoking an application's token in production. auth/token/revoke-orphan exists but leaves children running, so use it deliberately.
Revocation has no undo: rollback means the workload logs in again. Make sure its auth method role still works before you revoke its tokens.
Tightening role TTLs breaks renewers: a token that can no longer renew must re-authenticate. Vault notes that clients should check the TTL returned by renewal and re-authenticate if it is not extending. Change one role at a time.
Editing the default policy: it applies to every token. Test changes on a non-production cluster and keep the previous text so you can write it back.
Running tidy during the audit: the token tidy operation reloads the whole token store and can balloon memory. It is not an audit step.
Using the root token to do the audit: it hides policy gaps and creates the exact finding you are trying to remove.

Hardening afterwards

Short TTLs everywhere: Vault's hardening guidance recommends short-lived credentials. Lower max_lease_ttl and role token_max_ttl to what workloads need. See the Dynamic Secrets and Ephemeral Credentials Guide.
Prefer platform auth over static secrets: Kubernetes, cloud IAM or JWT/OIDC roles bound to workload identity, with AppRole kept for cases that need it. See the Secrets Zero Problem Guide.
Simple, explicit policies: Vault recommends limiting globs, wildcards and templates. Add CI checks on policy pull requests for sudo and leading globs.
Break-glass for root: keep root generation behind vault operator generate-root with a quorum, multiple eyes on the session and immediate revocation.
Alert on the dangerous paths: stream audit logs and alert on root token use, policy writes, auth method changes and audit device changes.

Framework	Reference	What this audit evidences
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-03	Credentials managed, least-privilege access reviewed, activity monitored
NIST SP 800-53 Rev 5	IA-5, AC-2, AC-6, AU-2, AU-12	Authenticator lifetime, account review, least privilege, audit logging
CIS Controls v8.1	Controls 5, 6 and 8	Account and access management, audit log management
ISO/IEC 27001:2022 Annex A	A.5.17, A.8.2, A.8.15	Authentication information, privileged access, logging
MITRE ATT&CK	T1555, T1528, T1098	Credentials from password stores, token theft, account manipulation

Practitioner checklist

Create a short-lived audit token with a dedicated read-only policy and sudo only where required.
Export auth methods, mount tuning and role TTL settings in every namespace.
List all token accessors, look each up and classify root, periodic, orphan and directly created tokens.
Diff live policies against version control and flag sudo, sys/*, auth/* and leading globs.
Test effective access with vault token capabilities on your most sensitive paths.
Review AppRole secret ID accessors, TTLs, use limits and CIDR bindings.
Confirm at least two audit devices, their hashing options and SIEM delivery.
Revoke unexplained tokens and secret IDs after checking children and leases.
Lower TTLs, add explicit max TTLs to periodic roles and alert on root token use.
Revoke the audit token and record the next review date.

How to audit HashiCorp Vault tokens, policies and auth methods: a repeatable review