How Atlas Vault Encrypts Credentials

How Atlas Vault encrypts passwords, keys and one-time codes at rest, how to protect them with your own Azure Key Vault key, and more.

Before you begin

  • Nothing to set up for the default protection: it is on in every deployment
  • To add Key Vault protection: Owner or User Access Administrator on the Key Vault, and permission to change the Atlas App Service's settings in the Azure portal

Where your secrets live

Atlas Vault keeps its data in your deployment's own Atlas database, in your Azure subscription. Each tenant's credentials sit in that tenant's database. Vault credentials are not stored as individual Key Vault secrets, and they are never sent to Atlas or to any outside service.

Your deployment also has an Azure Key Vault. Atlas uses it for its own app secrets, such as its Entra app registration and email credentials. Atlas Vault can also use a key in a Key Vault to protect its encryption keys, as described below.

What is encrypted

Each of these is encrypted on its own, with its own key:

  • Credential secrets, in the shared company vault and in My Vault.
  • Every older version kept in Secret History.
  • One-time code (TOTP) seeds.
  • Password fields on assets, and escrowed BitLocker recovery passwords.

Documents, uploaded files, templates and notes are encrypted too. Because they appear on list pages, they use one data key per tenant instead of one key per value, and that data key is itself encrypted the same way as a credential secret. Whole-word search still works without the text being stored readable.

How a secret is encrypted

Atlas encrypts each secret with AES-256-GCM before it reaches the database. GCM also detects tampering: a stored value that has been altered fails to decrypt rather than returning wrong data. What protects each secret's key depends on how your deployment is set up:

  • Default: each secret's key is derived from your deployment's master encryption key, created when Atlas was installed, using PBKDF2-SHA256 with 600,000 iterations and a fresh random salt for every secret. The master encryption key is held in the Atlas App Service's settings, not in the database.
  • With Azure Key Vault: Atlas creates a new random AES-256 key for every secret, encrypts the secret with it, then has an RSA key in your Key Vault wrap that key (RSA-OAEP-256). Only the wrapped key is stored. The secret itself is never sent to Key Vault, and the RSA key never leaves it.

A secret protected by Key Vault can only be read with both your Atlas database and access to the key in your Key Vault. Revoke Atlas's access to the key and those secrets can't be decrypted, even by someone holding a copy of the database. Secrets saved before you turned Key Vault protection on, and not changed since, are not covered by this until they move to the key (see Existing secrets and key rotation below). Documents and notes can also stay readable for up to 15 minutes after you revoke access, while Atlas still holds their key in memory.

Protect Vault secrets with an Azure Key Vault key

Key Vault protection is optional, and a standard install does not turn it on. To turn it on:

  1. In the Azure portal, open a Key Vault in the same Azure cloud as your deployment. The one Atlas installed is fine. Make sure soft-delete and purge protection are on, so the key cannot be lost by mistake.
  2. Under Objects → Keys, choose Generate/Import and create an RSA key of 3072 bits or more. On a Premium vault you can choose an HSM-protected key (RSA-HSM).
  3. Under Access control (IAM), give the Atlas App Service's managed identity the Key Vault Crypto Service Encryption User role on the key or the vault. If your vault uses access policies instead, grant the Get, Wrap Key and Unwrap Key key permissions.
  4. Open the key and copy its Key Identifier (https://<vault>.vault.azure.net/keys/<name>, or .vault.usgovcloudapi.net in GCC High). Leave the version off, so Atlas always uses the key's current version.
  5. On the Atlas App Service, open Settings → Environment variables, add VAULT_KV_KEY_ID with the key identifier as its value, and apply. Do the same on the staging slot if your deployment has one, and give that slot's managed identity the same role.

Once Key Vault protection is on, Atlas never falls back to the default method. If the key is disabled or deleted, or Atlas loses access to it, Vault secrets can't be revealed or saved until access is restored. Never delete the key, or an older version of it, while Vault secrets use it.

Existing secrets and key rotation

  • After you turn on Key Vault protection, new and changed secrets are protected by the key. Secrets saved earlier keep their existing protection and stay readable, and each one moves to the key the next time it is changed or rotated. Contact Atlas support if you need them all moved at once.
  • Rotating the Key Vault key is safe. Each secret records which key version protected it, so secrets saved before a rotation still decrypt afterwards, and new ones use the new version.
  • Keep the master encryption key in the App Service settings even with Key Vault on. Atlas still needs it to read secrets saved before Key Vault protection, and for its other encrypted settings.

What Atlas never does with a secret

  • Secrets are never stored in plain text and never written to logs or error messages.
  • Decrypted secrets are never cached. A secret is decrypted only when it is needed, such as when someone with permission chooses Reveal, Copy or Show one-time code, or a recipient opens a secure share link, and each of those is recorded in the audit log.
  • List pages, search results and exports (CSV, XLSX or PDF) never contain secrets.
  • A development-only mode that does not encrypt is refused in a production deployment.

Next steps