HashiCorp Vault User Management Guide

• Model type: custom-roles
• Description: Vault uses ACL (Access Control List) policies written in HCL or JSON. Policies define capabilities (create, read, update, delete, list, sudo, deny) on path patterns using glob matching. There are no predefined roles in OSS Vault; all access control is through custom-written policies. Vault Enterprise adds Sentinel policies for fine-grained attribute-based access control (ABAC) and role-governing policies.
• Custom roles: Yes
• Custom roles plan: All editions support custom ACL policies. Sentinel/RBAC policy enforcement is Vault Enterprise only.
• Granularity: Path-level with capability granularity. Policies can target exact paths or glob patterns (e.g., 'secret/data/team/*'). Capabilities include: create, read, update, patch, delete, list, sudo, deny. Enterprise Sentinel adds attribute-based conditions on requests, responses, and identity attributes.

1. Choose and enable an auth method: via CLI run 'vault auth enable ' (e.g., 'vault auth enable userpass') or via Vault UI navigate to Access > Auth Methods > Enable new method.
2. Create the user within the chosen auth method. For userpass: 'vault write auth/userpass/users/ password= policies='. For LDAP/OIDC/SAML, configure the auth method to map external groups/users to Vault policies.
3. Create or assign an ACL policy that defines what the user can access: 'vault policy write <policy-file.hcl>'.
4. Optionally create an Identity Entity and alias to consolidate a user's identity across multiple auth methods: 'vault write identity/entity name=' then 'vault write identity/entity-alias name= canonical_id= mount_accessor='.
5. Assign policies to the entity directly if using Identity: 'vault write identity/entity/id/ policies='.
6. For group-based access, create an Identity Group and add the entity: 'vault write identity/group name= policies= member_entity_ids='.

Required fields: Auth method type (userpass, LDAP, OIDC, SAML, GitHub, etc.), Username or external identity identifier, Password (for userpass auth method), At least one ACL policy name to attach

Watch out for:

• Vault has no built-in user directory. 'Users' only exist within the context of a specific auth method. A person using two auth methods appears as two separate entities unless explicitly linked via Identity.
• Enabling an auth method requires a token with 'sudo' capability on 'sys/auth/*' path.
• For OIDC/SAML/LDAP, users are not pre-created in Vault; they are dynamically mapped to policies at login time based on group membership or claims. No manual per-user creation is needed, but group-to-policy mappings must be configured.
• SAML auth method requires Vault Enterprise 1.15.0 or later.
• There is no SCIM provisioning support; user lifecycle must be managed via the IdP auth method configuration or manually.
• Policies must exist before being assigned; assigning a non-existent policy name does not error at write time but results in no access.

• Can delete users: Yes
• Delete/deactivate behavior: For userpass auth method, a user can be deleted with 'vault delete auth/userpass/users/'. For LDAP/OIDC/SAML, removing the user from the external IdP or group prevents future logins; no Vault-side deletion is required for the auth mapping. Identity entities and aliases can be deleted via 'vault delete identity/entity/id/'. Existing tokens issued to the user remain valid until they expire or are explicitly revoked.

1. Revoke all active tokens for the user: 'vault token revoke -accessor ' for each token, or revoke by entity: 'vault write /auth/token/revoke-accessor accessor='.
2. To prevent future logins via userpass: 'vault delete auth/userpass/users/'.
3. To prevent future logins via LDAP/OIDC/SAML: remove the user from the relevant group in the external IdP (Vault will deny login on next attempt as group mapping will not match).
4. Optionally delete the Identity entity to clean up: 'vault delete identity/entity/id/'.
5. Optionally delete entity aliases associated with the user: 'vault delete identity/entity-alias/id/'.

Watch out for:

• Deleting a userpass user or IdP group mapping does not automatically revoke existing tokens. Active tokens remain valid until TTL expiry unless explicitly revoked.
• Token revocation must be done separately and requires knowing the token accessor. Listing token accessors requires appropriate policy on 'auth/token/accessors'.
• For LDAP/OIDC users, Vault does not store a user record to delete; access is controlled by the external IdP group membership. Removing from the IdP is sufficient to block future logins but does not revoke current tokens.
• Identity entities persist after auth method user deletion unless explicitly deleted. Orphaned entities do not grant access but may cause confusion in audits.
• Vault audit logs record token accessors, not usernames directly, making it necessary to correlate accessors to users for offboarding verification.

• Where to check usage: For HCP Vault: HCP Portal > Billing > Usage. For self-managed Enterprise: 'vault license get' CLI command or Vault UI > License (operator must have appropriate policy). Vault also exposes license utilization metrics via the '/sys/license/status' API endpoint.
• How to identify unused seats: Vault does not natively track 'inactive users' as a concept since users are not pre-provisioned. Token usage can be audited via Vault audit logs (file, syslog, or socket audit device). Tokens that have not been used can be identified by reviewing audit log last-use timestamps. The '/sys/auth/token/accessors' endpoint lists all token accessors for enumeration.
• Billing notes: Vault OSS and Enterprise self-managed do not bill per user/seat. HCP Vault billing is consumption-based (cluster hours + operations), not per-user. Enterprise licensing is typically per-cluster or per-node negotiated with HashiCorp/IBM. There is no concept of 'freeing a seat' by removing a user in any Vault edition.

Because Vault has no SCIM support and no built-in 'disable user' button, offboarding requires multiple manual steps across two separate systems. Removing a user from an external IdP blocks future logins but does not revoke active tokens - those must be revoked individually by token accessor.

There is no native way to list 'inactive users' since Vault does not pre-provision user records. Identifying stale access requires correlating audit log entries against token accessors, which is operationally intensive at scale.

For userpass-managed accounts, every app's user lifecycle - creation, policy updates, and deletion - must be handled via CLI or API. Administrators without CLI access have limited options in the Vault UI, and HCP Portal access does not carry over to Vault-internal policy management.

The most consistent complaint across the HashiCorp community is the dual-layer management burden: HCP Portal controls who can manage clusters, while Vault-internal policies control who can access secrets. Administrators frequently expect a single control plane and are caught off guard by the separation.

Token revocation on offboarding is a recurring pain point. Without a 'disable user' action that also terminates sessions, teams must build their own revocation workflows or accept a window of residual access until token TTLs expire.

The absence of predefined roles is also widely cited. Writing correct, least-privilege HCL policies requires Vault-specific expertise, and misconfigured policies are a common source of both over-permissioning and accidental lockouts.

Common complaints:

• Users frequently report that Vault's lack of a traditional user management UI makes onboarding non-technical administrators difficult; all user operations require CLI or API knowledge.
• The separation between HCP Portal user management and Vault-internal policy management confuses administrators who expect a single control plane.
• No SCIM support means automated user provisioning/deprovisioning must be built custom using Vault's API, which is a significant operational burden compared to SaaS tools with native SCIM.
• Token revocation on offboarding is a common pain point: administrators must know token accessors to revoke them, and there is no simple 'disable user' button that also revokes all active sessions.
• The absence of predefined roles (e.g., 'read-only', 'admin') means every deployment requires writing custom HCL policies from scratch, which increases time-to-value and risk of misconfiguration.
• SAML auth method being Enterprise-only is a recurring complaint from teams that want SAML SSO without paying for Enterprise licensing.
• Audit log correlation between token accessors and human-readable usernames requires additional tooling or log processing, making offboarding verification difficult.

Vault is the right tool if your primary need is secrets management with fine-grained, path-level access control. It is not designed to be an identity provider or a user lifecycle management system, and teams that treat it as one will carry significant operational overhead.

If your organization relies on SAML SSO, budget for Vault Enterprise - SAML auth is not available in OSS or HCP Vault Secrets free tiers. OIDC is the practical SSO path for non-Enterprise deployments.

For every app that needs automated user provisioning or deprovisioning, plan to build and maintain API-based workflows. There is no off-the-shelf SCIM connector, and the absence of one is a known, unresolved gap in Vault's feature set.

Bottom line

HashiCorp Vault delivers powerful, policy-driven secrets access control, but it offloads nearly all user lifecycle management to the operator. There is no SCIM, no predefined roles, and no single action that both blocks a user and revokes their active tokens.

Teams that need automated provisioning must build it against the Vault HTTP API or Terraform provider. The operational cost is real and scales with team size - factor it into any deployment plan.