Vault

What the vault holds#

Each entry relates a typed token to the original value it replaced, together with its data class and scope. That mapping is the single piece of information that can turn PHONE_8f3a back into a phone number — which makes the vault, deliberately, the most sensitive asset in the system. The design question is not whether such a mapping exists (reversibility requires it) but where it lives and who can use it. In Salus it lives on your infrastructure, and using it requires your keys and your policy's authorization.

Protection layers#

• Encryption at rest. Vault contents are envelope-encrypted: data keys encrypt the entries, and those data keys are wrapped by keys in customer custody. With the enterprise HSM/KMS option, wrapping keys are held in your HSM or key-management service and never leave it.
• Encryption in transit. Traffic between engine components and the vault is TLS-protected inside your environment.
• Access control. No human workflow reads the vault directly; the engine resolves mappings during restoration, and administrative access is role-restricted. Salus vendor personnel have no default access path.
• Audit. Every restoration — every event that turns a token back into a value — is recorded in the token-only audit stream to your SIEM.
• Retention. How long mappings live is governed by customer policy — per scope and data class — rather than fixed by the product.

Separation is the point#

The pseudonymization discussion in Tokenization vs. Pseudonymization turns on "additional information kept separately." The vault is that additional information, and its separation is architectural: the external provider operates on the other side of the boundary with no route to it. Deployment choices — on-premises, private cloud, air-gapped — never move the vault outside the customer-controlled environment; they only change what surrounds it, as covered in Deployment Options.