Protected at rest, in transit, in use.
Encryption at rest with customer-managed keys, TLS 1.3 in transit, and confidential computing — AMD SEV-SNP, Intel TDX — to protect the most sensitive operations even while data is being processed.
1. Three states of data, one gap
Data exists in three states, and a serious confidentiality posture has to cover all three. At rest — on disk, in a database, in a backup. In transit — moving across a network. In use — loaded into memory and being processed. The first two are well-trodden; the third is where most platforms quietly leave a gap. Plaintext in RAM is readable by a privileged host, a compromised hypervisor, a malicious co-tenant on shared infrastructure, or anyone with a memory dump. “Confidential by default” means the gap is closed too.
2. At rest: customer-managed keys
Encryption at rest is table stakes; who holds the key is the control that matters. B5 Secure uses customer-managed keys (CMK) over platform-managed defaults, with an envelope-encryption hierarchy: data-encryption keys (DEKs) encrypt the data and are themselves wrapped by a key-encryption key (KEK) that lives in the Managed HSM. Rotating the KEK re-wraps the DEKs without re-encrypting petabytes; revoking it renders the data cryptographically inaccessible immediately. Because the KEK never leaves the validated boundary, “encrypted at rest” means the keys are out of reach even from the operator of the storage.
3. In transit: TLS 1.3 and PQ hybrid
Every connection is TLS 1.3 with forward secrecy — legacy renegotiation, static-RSA key exchange, and the downgrade-prone constructions of TLS 1.2 are simply not offered. Service-to-service traffic adds mutual TLS so both ends authenticate. Under the 2026 profile the key exchange becomes hybrid post-quantum — an X25519 + ML-KEM (FIPS 203) construction — so a recorded session is protected against “harvest-now, decrypt-later” even if the classical curve falls later. Hybrid, not pure-PQC, is deliberate: it keeps the classical guarantee intact while adding the quantum-resistant one, so a flaw in the new primitive never weakens the connection below today’s baseline.
4. In use: confidential computing
The in-use gap is closed with a Trusted Execution Environment (TEE) — a hardware-enforced enclave whose memory is encrypted by the CPU and inaccessible to the host OS, the hypervisor, other tenants, and the cloud operator. B5 Secure targets VM-level confidential computing so existing services run inside the boundary with minimal change:
- AMD SEV-SNP — Secure Encrypted Virtualization with Secure Nested Paging: per-VM memory encryption plus integrity protection that defeats the malicious-hypervisor remapping and replay attacks SEV alone did not;
- Intel TDX — Trust Domain Extensions: hardware-isolated trust domains with encrypted, integrity-protected memory and a measured launch.
The threat model is explicit and unusual: the infrastructure operator is outside the trust boundary. That is precisely the assurance a financial counterparty wants before sensitive computation runs on infrastructure it does not own.
5. Attestation before secrets
A TEE is only worth its memory encryption if you can prove a workload is genuinely running inside a genuine enclave before you trust it with anything. Remote attestation provides that: the hardware produces a signed quote — chained to the silicon vendor’s roots — measuring the enclave’s identity and launch state. B5 Secure verifies the attestation first, then releases keys and secrets to the workload only after the quote checks out. No valid attestation, no secrets — the same fail-closed discipline the pipeline applies everywhere.
Attestation turns “the enclave protects this data” from an assumption into a checked precondition. Secret release is gated on a fresh, verified quote — so a workload that isn’t the workload you measured never receives the keys.
6. Crypto-agile by design
None of these primitives is hard-wired. B5 Secure resolves its hash, signature, and key-exchange algorithms through a provider it can swap — the property the industry calls crypto-agility, and the single most important defense against the day an algorithm is deprecated. The algorithm becomes configuration, not a recompile:
// Crypto-agile by design — primitives resolved, not hard-coded
services.AddB5SecurityKit(o => {
o.Signing.Algorithm = HmacAlg.HmacSha384; // SHA-2/SHA-3 family
o.Keys.Source = KeySource.AzureManagedHsm; // FIPS 140-3 L3
// PQC in transit is a host setting — configure the hybrid X25519MLKEM768
// group at the host (Kestrel + SymCrypt / OpenSSL 3.5+), not in B5.
o.Signing.PqcOption = Pqc.MlDsa65; // FIPS 204 signatures
o.Data.AtRest = AtRest.CustomerManagedKey; // envelope, KEK in HSM
});Migration becomes a configuration change negotiated side by side with the legacy primitive, not a forklift. That is what lets the at-rest, in-transit, and in-use layers all move onto post-quantum footing on the CNSA 2.0 timeline without rewriting the application.
7. What each layer defeats
The three layers are defense in depth, each defeating a distinct adversary so a single failure is not catastrophic: customer-managed keys at rest defeat the operator and the stolen-disk attacker; TLS 1.3 with PQ-hybrid key exchange defeats the network eavesdropper, today and against a future quantum adversary holding recorded traffic; and confidential computing with attestation defeats the privileged host and the malicious co-tenant. The result maps onto the controls auditors test — SOC 2 CC6.1 and CC6.7, PCI DSS Requirements 3 and 4, and the encryption expectations of GDPR Article 32 — and it does so by construction, on by default, rather than as an option a customer has to remember to enable.