Encryption at rest protects stored data from offline access, while confidential computing protects data while it is being processed. The difference is the trust problem: encryption at rest assumes the runtime is safe, whereas confidential computing tries to make the runtime itself verifiable before sensitive data is exposed.
How the trust model differs
Standard encryption at rest and confidential computing solve different parts of the trust problem. Encryption at rest protects data when it is stored, but it leaves the application runtime, memory, and platform operators inside the trust boundary. Confidential computing narrows that boundary by protecting data during processing and letting the workload prove itself before sensitive material is released.
The practical difference is not just where the ciphertext sits, but what you are asking the infrastructure to prove. With encryption at rest, the main control is that disk or database content is unreadable without the right keys. With confidential computing, the main control is that the code is executing inside a protected environment that can be attested before secrets or plaintext are exposed.
What each control protects, and what it does not
Encryption at rest is the right baseline for protecting stored datasets against offline theft, media loss, snapshot exposure, and unauthorised database access after the storage layer is bypassed. It does not, by itself, stop a privileged runtime, a compromised application server, or a malicious operator from reading data after decryption has occurred.
Confidential computing is designed for that gap. It is most useful where the processing environment itself is a concern, such as shared cloud infrastructure, sensitive analytics, or workloads that must receive data only after remote attestation and key release checks have passed. The control is strongest when paired with encrypted storage rather than treated as a substitute for it.
For a practical baseline on the storage side, NHIMG’s Encryption Guide is useful for separating disk, database, field-level, and in-use protections. For the processing side, NHIMG’s Confidential Computing Guide covers TEEs, attestation, and key release, which are the mechanisms that change the trust model. The broader Privacy-Enhancing Technologies Guide helps place both controls in the wider set of techniques used to reduce exposure while data is used.
When the difference matters in real deployments
The distinction matters whenever sensitive data must be processed in an environment you do not fully trust, or cannot fully inspect. That includes multi-tenant cloud workloads, outsourced analytics, regulated datasets, and workflows where the operator should not see the plaintext even temporarily. In those cases, encryption at rest reduces storage risk, but confidential computing addresses the stronger question of whether the runtime is worthy of trust before decryption happens.
It also matters when key custody is tied to runtime integrity. Confidential computing can make key release conditional on attestation, so the decryption step becomes dependent on the measured environment rather than on simple possession of a credential or stored secret. That changes the threat model from “protect the file when idle” to “verify the execution context before any useful data is revealed.”
Risk and Threat Considerations
The main risk is assuming encryption at rest covers processing risk. If plaintext must exist in memory, then an attacker who reaches the runtime, a hypervisor edge, an admin path, or a compromised dependency can still capture data after it is decrypted. Confidential computing reduces that exposure, but only if attestation, key release, and workload integrity are implemented correctly.
Failure mechanism: Storage encryption fails to address the moment of use, so access to a live runtime, debugging path, memory scrape, or operator-controlled environment can expose data after decryption. Confidential computing fails when attestation is skipped, misconfigured, or treated as optional, because then the workload can receive secrets without a trustworthy proof of execution.
Impact: Sensitive data can be read, copied, or exfiltrated even though “encryption” was technically present. In the worse case, organisations believe they have protected the data end to end while the processing layer remains the easiest place to steal plaintext or release keys.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | Encryption at rest is the baseline storage protection described in the question. |
| SC-12 — Cryptographic Key Establishment and Management | Confidential computing depends on controlled key release after runtime trust is established. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Attestation-based trust in a workload runtime maps to authenticating a non-human execution environment. | |
| Recommendation — Apply SC-28 to protect stored data from offline disclosure and media loss. Use SC-12 to govern key release only to trusted, verified environments. Use IA-9 to require strong machine or workload authentication before exposing sensitive data. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The comparison centers on how cryptography protects data at rest versus in use. |
| A.8.28 — Secure coding | Confidential computing relies on software that behaves correctly inside a protected runtime. | |
| Recommendation — Define when storage encryption and in-use protection are required for each data class. Build applications so secrets are only released after the runtime trust check succeeds. | ||
Practitioner Guidance
What to verify: Check whether the control objective is storage secrecy or runtime secrecy. If the concern is only lost disks, backups, or dormant datasets, standard encryption at rest is usually the correct baseline. If the concern is hostile or untrusted processing infrastructure, you need a design that includes attestation and controlled key release, not just encrypted storage.
Decision rule: Use encryption at rest by default, then add confidential computing when the data must be protected while actively processed or when the platform operator should not automatically be trusted with plaintext. Do not treat confidential computing as a replacement for storage encryption, because the two controls address different exposure windows.
Practitioner takeaway: The key judgement is whether the sensitive moment is storage or use, because that answer determines whether you need only ciphertext protection or a verifiable execution environment as well.
Related resources from NHI Mgmt Group
- What is the difference between encryption at rest and encryption in transit?
- What is the difference between end-to-end encryption and Salesforce-style at-rest and in-transit encryption for file sharing?
- What is the difference between BYOK and standard application-managed encryption keys?
- What is the difference between encryption at rest and encryption in transit under NYDFS Part 500?