Vault enterprise HSM security details

This page provides information to help ensure that a Vault HSM deployment is performed as securely as possible.

PKCS#11 authentication

PKCS#11 authentication occurs via a slot number and PIN. In practice, because the PIN is not required to be numeric (and some HSMs require more complex PINs), this behaves like a username and password.

Like a username and password, these values should be protected. If they are stored in Vault's configuration file, read access to the file should be tightly controlled to appropriate users. (Vault's configuration file should always have tight write controls.) Rather than storing these values into Vault's configuration file, they can also be supplied via the environment; see the Configuration page for more details.

The attack surface of stolen PKCS#11 credentials depends highly on the individual HSM, but generally speaking, it should be assumed that if an attacker can see these credentials and has access to a machine on which Vault is running, the attacker will be able to access the HSM key protecting Vault's root key. Therefore, it is extremely important that access to the machine on which Vault is running is also tightly controlled.

Recovery key shares protection

Recovery key shares should be protected in the same way as your organization would protect key shares for the cryptographic barrier. As a quorum of recovery key shares can be used with the generate-root feature to generate a new root token, and root tokens can do anything within Vault, PGP encryption should always be used to protect the returned recovery key shares and the recovery share holders should be highly trusted individuals.