Encryption at rest and in transit are solved and universally deployed. The remaining gap is data in use: while your process is actually working on it, the plaintext sits in memory, visible in principle to the hypervisor, the host operating system, and anyone with sufficient access to the infrastructure underneath you. For most workloads that is an acceptable risk. For some customers it is the reason the contract does not get signed.
Confidential computing closes that gap with hardware: memory is encrypted with keys the CPU holds and the host cannot extract, so a workload runs inside an enclave that the platform operator cannot read into. It has moved from research curiosity to something you can select from a dropdown, which makes it worth understanding precisely rather than dismissing or over-promising.
Attestation is the part that matters
Memory encryption alone would be nearly useless, because you would have no way to know your workload is actually running in a protected environment. Attestation is the real mechanism: the hardware produces a signed report describing exactly what is running — the measurement of the image, its configuration, the firmware version — and a relying party verifies that report before releasing anything of value.
That inverts the usual trust flow in a genuinely useful way. Instead of trusting an operator's assurance that data is handled correctly, a customer's key management service can refuse to release the decryption key unless the attestation matches an approved measurement. The control is cryptographic and automatic rather than contractual and audited annually.
# The enclave proves what it is; the key service decides whether to unlock.
report = tee.get_attestation_report(nonce=challenge)
key = customer_kms.release_key(
attestation=report,
policy={
# Only this exact image, built by our release pipeline, gets the key.
'image_measurement': 'sha384:9f2c...',
'firmware_min_version': '1.4.0',
'debug_disabled': True, # a debuggable enclave is not an enclave
'nonce': challenge, # freshness: no replayed reports
},
)
# Plaintext exists only inside encrypted memory, under a key the host never sees.
with tee.sealed(key) as session:
result = session.run(pipeline, encrypted_dataset)An honest cost assessment
The performance overhead for general workloads is now modest — low single-digit percentages for many, higher for memory-bandwidth-bound work and meaningfully higher where enclave boundary crossings are frequent. That is rarely the blocker. The operational cost is: debugging is deliberately constrained, because the properties you want depend on the host being unable to inspect the process. Your usual observability tooling either does not work or must be redesigned to emit only what you have explicitly decided is safe to leave the boundary.
- Verify attestation somewhere the operator cannot influence — ideally the customer's key service, not yours.
- Pin the measurement and treat changing it as a release event with its own approval, or the guarantee is decorative.
- Design the observability story first; retrofitting it into an enclave is painful and tends to erode the boundary.
- Remember it protects against the infrastructure layer, not against your own application bugs — an injection flaw inside the enclave leaks data just as well.
- Confirm the attestation policy is actually enforced in production. An unverified report is a document, not a control.
Hardware encryption without verified attestation is a locked room where nobody checked which building it is in.
Where I have seen it genuinely earn its cost: multi-party analytics where two organisations want a joint result without either seeing the other's raw data, regulated processing in a jurisdiction where the customer cannot accept operator access, and AI inference over sensitive documents where the model provider must not retain or observe the input. Outside those, it is a meaningful engineering cost for a risk most threat models already accept — and saying so plainly is more useful to a customer than selling them an enclave they do not need.