In this article, we explain the token prefix changes introduced in Vault 1.10 (released March 23, 2022). While the prefix format has been updated, token functionality and policy enforcement remain the same. Note that examples recorded before Vault 1.10 may still show the older single-letter prefixes.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.

Existing tokens created before the upgrade keep their original prefixes (
S., B., R.). Only tokens generated after upgrading to Vault 1.10 receive the new three-letter prefixes.Token Prefix Changes in Vault 1.10
Vault 1.10 replaces the previous one-letter prefixes with more descriptive three-letter identifiers. The new mapping is:| Token Type | Old Prefix | New Prefix | Minimum Length |
|---|---|---|---|
| Service Token | S. | hvs. | 95 bytes |
| Batch Token | B. | hvb. | unchanged |
| Recovery Token | R. | hvr. | unchanged |
Service Tokens
Service tokens are the most common token type. In Vault 1.10, they now start withhvs. followed by at least 95 random bytes:
hvs.indicates a HashiCorp Vault Service token.- The random string that follows provides the required entropy.
Service tokens with insufficient length will be rejected. Always verify token length when automating creation.
Batch and Recovery Tokens

hvb.marks a Batch token used for one-time API operations.hvr.marks a Recovery token used for root recovery workflows.
Summary
When working with Vault 1.10 or later, newly generated tokens will use:hvs.→ Service tokenhvb.→ Batch tokenhvr.→ Recovery token
vault token create, vault token revoke, or policy checks—remain unchanged under the new prefix scheme.