Hardware binding
How SCSA Vault derives keys from silicon instead of storing them.
SCSA Vault never stores a decryption key. It derives the key from a live measurement of the hardware at open time. Change the hardware, and the key never materializes.
CPU binding (tiered)
Vault picks the strongest binding your machine supports and falls back cleanly:
- Confidential compute — Intel TDX trust-domain measurement or AMD SEV-SNP launch measurement, verified against the vendor attestation service. Main memory is encrypted by the CPU.
- TPM2 — keys sealed to platform configuration registers when a TEE is not available.
- Machine fingerprint — a derived hardware identity as the baseline tier.
GPU binding
On NVIDIA GPUs, the key derives from an attestation measurement of the die — its UUID, VBIOS, driver, and Confidential Computing flags at load time. Sealing to an attested GPU means the file opens only on that exact hardware, and (for the weights product) decryption can happen directly in VRAM.
Second factor
A passphrase can be layered on top of any binding. It is combined with the hardware-derived key, so both the correct machine and the passphrase are required. The passphrase never replaces the hardware requirement.
Because keys are derived, not stored, there is no key file to exfiltrate. The trade-off is that a sealed file is intentionally tied to its hardware — plan recovery accordingly (see the FAQ).