This FAQ section is for the license changes introduced in Vault Enterprise 1.11.

• Q: What is the product behavior change introduced by the licensing changes?
• Q: Will these license changes impact HCP Vault?
• Q: Do these license changes impact all Vault customers/licenses?
• Q: What is the product behavior change introduced by the licensing changes?
• Q: How will Vault behave at startup when a license expires or terminates?
• Q: What is the impact on evaluation licenses due to this change?
• Q: Are there any changes to existing methods for manual license loading (API or CLI)?
• Q: Is there a grace period when evaluation licenses expire?
• Q: Does this affect clients?
• Q: Are the license files locked to a specific cluster?
• Q: Will a EULA check happen every time a Vault restarts?
• Q: What scenarios should a customer plan for due to these license changes?
• 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?
• 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)?
• Q: Is there a limited time for support of licenses that are in storage?
• Q: What are the steps to upgrade from one autoloaded license to another autoloaded license?
• Q: What are the Vault ADP module licensing changes introduced in 1.8?
• Q: How can the new ADP modules be purchased and what features are customer entitled to as part of that purchase?
• Q: What is the impact to customers based on these ADP module licensing changes?

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

Q: will these license changes impact HCP Vault?

No, these changes will not impact HCP Vault.

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

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.

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.

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:

• Key Management Secrets Engine (KMSE)
• Key Management Interoperability (KMIP)
• MSSQL Transparent Data Encryption (TDE)

ADP-Transform includes:

• Transform Secrets Engine (TSE)

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 OSS 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).