HashiTalks 2025 Learn about unique use cases, homelab setups, and best practices at scale at our 24-hour virtual knowledge sharing event. Register
Vault
Vault Home

License FAQ

This FAQ section is for license changes and updates introduced for Vault Enterprise.

Q: what is the product behavior change introduced by the licensing changes?

Per the feature deprecation plans, Vault will no longer support licenses in storage. An auto-loaded license must be used instead. If you are using stored licenses, you must migrate to auto-loaded licenses prior to upgrading to Vault 1.11

Vault 1.12 will also introduce different termination behavior for evaluation licenses versus non-evaluation licenses. An evaluation license will include a 30-day trial period after which a running Vault server will terminate. Vault servers using a non-evaluation license will not terminate.

Q: how do the license termination changes affect upgrades?

Vault 1.12 will introduce changes to the license termination behavior. Upgrades when using expired licenses will now be limited. Vault will not startup if the build date of the binary is after the expiration date of a license. License expiration date and binary build date compatibility can be verified using the Check for Autoloaded License check performed by the vault operator diagnose command. The build date of a binary can also be found using the vault version command.

A user can expect the following to occur based on the following scenarios:

Evaluation or non-evaluation license is valid: Vault will start normally

Evaluation or non-evaluation license is expired, binary build date before license expiry date: Vault will start normally

Evaluation or non-evaluation license is expired, binary build date after license expiry date: Vault will not start

Evaluation license is terminated: Vault will not start independent of the binary's build date

Non-evaluation license is terminated, binary build date before license expiry date: Vault will start normally

Non-evaluation license is terminated, binary build date after license expiry date: Vault will not start

The Vault support team can issue you a temporary evaluation license to allow for security upgrades if your license has expired.

Q: will these license changes impact HCP Vault Dedicated?

No, these changes will not impact HCP Vault Dedicated.

Q: do these license changes impact all Vault customers/licenses?

Customer/licensesImpacted?
ENT binaries (evaluation or non-evaluation downloaded from releases.hashicorp.com)Yes
Business-Source (BSL)No

Q: what is the product behavior change introduced by the licensing changes?

With Vault 1.11, the use of an auto-loaded license is required for Vault to start successfully.

Q: how will Vault behave at startup when a license expires or terminates?

When a license expires, Vault continues to function until the license terminates. This behavior exists today and remains unchanged in Vault 1.11. The grace period, defined as the time between license expiration and license termination, is one day for evaluation licenses (as of 1.8), and ten years for non-evaluation licenses. Customers must provide a valid license before the grace period expires. This license is required to be auto-loaded. When license terminates (upon grace period expiry), Vault will seal itself and customers will need a valid license in order to successfully bring-up Vault. If a valid license was not installed after license expiry, customers will need to provide one, and this license will need to be auto-loaded.

Vault 1.12 changes the license expiration and termination behavior. Evaluation licenses include a 30-day trial period after which a running Vault server will terminate. Non-evaluation licenses, however, will no longer terminate. When a non-evaluation license expires, Vault will continue to function but upgrades will be limited. The build date of the upgrade binary must be before the expiration date of the license. Vault will not start when attempting to use an expired license and binary with a build date after the license expiration date. Attempting to reload an expired license will result in an error if the build date of the running Vault server is after the license expiration date.

License expiration date and binary build date compatibility can be verified using the Check for Autoloaded License check performed by the vault operator diagnose command. The build date of a binary can also be found using the vault version command.

Q: what is the impact on evaluation licenses due to this change?

As of Vault 1.8, any Vault cluster deployed must have a valid auto-loaded license.

Vault 1.12 introduces expiration and termination behavior changes for non-evaluation licenses. Evaluation licenses will continue to have a 1-day grace period upon license expiry after which they will terminate. Vault will seal itself and shutdown once an evaluation license terminates.

Q: are there any changes to existing methods for manual license loading (API or CLI)?

The /sys/license and /sys/license/signed endpoints have been removed as of Vault 1.11. With that said, it is no longer possible to provide a license via the /sys/license endpoint. License auto-loading must be used instead. The /sys/config/reload/license endpoint can be used to reload an auto-loaded license provided as a path via an environment variable or configuration.

Q: is there a grace period when evaluation licenses expire?

Evaluation licenses have a 1-day grace period. The grace period is the time until the license expires. Upon expiration, Vault will seal and will require a valid license to unseal and function properly.

Q: are the license files locked to a specific cluster?

The changes to licenses apply to all nodes in a cluster. The license files are not locked to a cluster, but are independently applied to the appropriate clusters.

Q: will a EULA check happen every time a Vault restarts?

Yes, starting with Vault 1.8, ENT binaries will be subjected to a EULA check. The release of Vault 1.8 introduces the EULA check for evaluation licenses (non-evaluation licenses are evaluated with a EULA check during contractual agreement) . Although the agreement to a EULA occurs only once (when the user receives their license), Vault will check for the presence of a valid license every time a node is restarted.

Starting Vault 1.11, when customers deploy new Vault clusters, or upgrade existing Vault clusters, a valid auto-loaded license must exist for the upgrade to be successful.

Q: what scenarios should a customer plan for due to these license changes?

  • New Cluster Deployment: When a customer deploys new clusters to Vault 1.11 or later, a valid license must exist to successfully deploy. This valid license must be on-disk (auto-loaded).

  • Eventual Migration: Vault 1.11 removes support for in-storage licenses. Migrating to an auto-loaded license is required for Vault to start successfully using version 1.11 or greater. Pre-existing license storage entries will be automatically removed from storage upon startup.

Q: what is the migration path for customers who want to migrate from their existing license-as-applied-via-the-CLI flow to the license on disk flow?

If a Vault cluster using a stored license is planned to be upgraded to Vault 1.11 or greater, the operator must migrate to using an auto-loaded license. The vault license get -signed command (or underlying /sys/license/signed endpoint) can be used to retrieve the license from storage in a running cluster. It is not necessary to remove the stored license entry. That will occur automatically upon startup in Vault 1.11 or greater. Prior to completing the recommended upgrade steps, perform the following to ensure your license is properly configured:

  1. Use the command vault license get -signed to retrieve the license from storage of your running cluster.
  2. Put the license on disk
  3. Configure license auto-loading by specifying the license_path config option or setting the VAULT_LICENSE or VAULT_LICENSE_PATH environment variable.

Q: what is the path for customers who want to downgrade/rollback from Vault 1.11 or later (auto-loaded license mandatory) to a pre-Vault 1.11 (auto-loading not mandatory, stored license supported)?

The downgrade procedure remains the same for Vault customers who are currently on Vault 1.11 or later, have a license installed via auto-loading, and would like to downgrade their cluster to a pre-1.11 version. Please refer to the upgrade procedures that remind the customers that they must take a snapshot before the upgrade. Customers will need to restore their version from the snapshot, apply the pre-1.11 enterprise binary version they wish to roll back, and bring up the clusters.

Q: is there a limited time for support of licenses that are in storage?

The support of licenses installed by alternative means often leads to difficulties providing the appropriate support. To provide the support expected by our customers, as we have announced in Vault feature deprecations and plans we are removing support for licenses in storage with Vault 1.11. This implies licensing endpoints that deal with licenses in storage will be removed, and Vault will no longer check for valid licenses in storage. This change requires that all customers have auto-loaded licenses to upgrade to 1.11(+) successfully.

Q: what are the steps to upgrade from one autoloaded license to another autoloaded license?

Follow these steps to migrate from one autoloaded license to another autoloaded license.

  1. Use the vault license inspect command to compare the new license against the output of the vault license get command. This is to ensure that you have the correct license.
  2. Backup the old license file in a safe location.
  3. Replace the old license file on each Vault server with the new one.
  4. Invoke the reload command on each individual Vault server, starting with the standbys and doing the leader last. Invoking in this manner reduces possible disruptions if something was performed incorrectly with the above steps. You can either use the reload command or send a SIGHUP.
  5. On each node, ensure that the new license is in use by using the vault license get command and/or checking the logs.

ADP licensing

This FAQ section is for the Advanced Data Protection (ADP) license changes introduced in Vault Enterprise 1.8.

Q: what are the Vault ADP module licensing changes introduced in 1.8?

As of Vault Enterprise 1.8, the functionality formerly sold as the Vault ADP module is now separated between two new modules:

ADP-KM includes:

ADP-Transform includes:

Q: how can the new ADP modules be purchased and what features are customer entitled to as part of that purchase?

ADP-KM includes:

  • This is the first Vault Enterprise module that can be purchased standalone. This means it can be purchased without the purchase of a Vault Enterprise Standard license.
  • ADP-KM still requires a Vault Enterprise binary. The Vault Enterprise Standard license is automatically included with the ADP-KM module, but customers are contractually prohibited from using any features besides those in Vault Community Edition and ADP-KM (KMSE and KMIP).

ADP-Transform includes:

  • This module cannot be purchased as a standalone. It requires a Vault Enterprise binary, and customers must purchase the base Vault Enterprise Standard license (at least) to use the corresponding Enterprise features.
  • The ADP-Transform SKU can be applied as an add-on. This workflow is similar to the consolidated ADP SKU.

Q: what is the impact to customers based on these ADP module licensing changes?

Customers need to be aware of the following as a result of these changes:

  • New customers may choose to purchase either or both of these modules. The old (consolidated) module is not available to them as an option.
  • Existing customers may continue with the consolidated Vault ADP module uninterrupted. They will only be converted to one or both new ADP modules the next time they make a change to their licensing details (i.e. contract change).
Edit this page on GitHub