Encryption in use is a security concept for protecting data while it is being processed, not just when it is stored or transmitted. It usually relies on specialised hardware or confidential computing techniques so applications can work on data with reduced exposure to operators, memory inspection, or certain cloud-side attacks.
How encryption in use works
Encryption in use protects data while it is being processed, which is the hardest state to secure because applications must briefly handle plaintext somewhere. The core idea is to narrow that exposure window through trusted execution, hardware-backed isolation, or cryptographic techniques that let computation happen with less direct visibility into the data.
That makes the term broader than “data encryption” in the storage or transport sense. It is really about limiting who or what can inspect working data during execution, including cloud operators, hypervisors, memory scrapers, and other parties that should not see the cleartext.
Where encryption in use fits in the data protection model
Most organisations already understand encryption at rest and in transit. Encryption in use completes that picture by addressing the moment when data is actively loaded, transformed, queried, or analysed. It is often discussed under confidential computing, trusted execution environments, secure enclaves, or homomorphic approaches, depending on the level of isolation and what the workload needs to do.
The trade-off is practical, not just conceptual. Stronger protection of data in use can add deployment complexity, performance overhead, platform constraints, and application redesign effort. The right model depends on whether the workload needs full general-purpose processing, limited trusted execution, or a specialised privacy-preserving method such as homomorphic encryption.
For practitioners comparing options, Encryption Guide is the best starting point for understanding how in-use protection relates to encryption at rest, in transit, key custody, and confidential computing.
Common deployment patterns and constraints
In-use encryption is usually implemented through specialised hardware, such as secure enclaves or confidential VM support, where the platform helps isolate code and data from the surrounding environment. In other cases, it may rely on partially or fully homomorphic encryption, secure multi-party computation, or a hybrid design that keeps only the most sensitive processing inside protected boundaries.
These designs are not interchangeable. Some protect data only while it is inside a trusted execution boundary, while others try to preserve confidentiality even when computation is performed on ciphertext. That difference matters because the workload, latency tolerance, memory profile, and trust model all change what is realistically deployable.
Selection usually comes down to how much the organisation trusts the underlying host, how sensitive the processed data is, and how much application refactoring it can absorb. The concept is therefore as much an architecture choice as a cryptographic one.
When the decision includes hardware and key custody questions, the Encryption Buyer’s Guide helps frame choices such as HSM use, BYOK, HYOK, and cloud KMS trade-offs. For workloads that need to process ciphertext directly, the Homomorphic Encryption Guide explains the main techniques and where their limits usually appear.
Operational consequences for security and privacy
The value of encryption in use is that it reduces exposure in environments where storage and network protections are not enough. It can help when sensitive analytics, shared infrastructure, or regulated data processing create unacceptable plaintext exposure to platform administrators or adjacent services.
It also changes the threat model. Instead of assuming the host is fully trusted, organisations assume the host may be observable, partially compromised, or operated by a third party, and they design the workload so that sensitive data remains less exposed during processing. That is why the term appears in conversations about cloud trust boundaries, protected analytics, and privacy-preserving processing.
For teams deciding whether the technology fits a real workload, the main question is not whether encryption is “stronger” in the abstract. It is whether the chosen method meaningfully reduces the exposure that matters most for the business, without breaking the application or creating a false sense of protection.
Risk and Threat Considerations
Encryption in use is attractive because it narrows the window in which sensitive data exists in cleartext, but it does not eliminate trust assumptions. If the protection boundary is misconfigured, bypassed, or weaker than expected, processing-time data exposure can still occur through memory inspection, privileged access, side-channel abuse, or insecure integration paths.
Failure mechanism: The workload leaves plaintext, keys, or derived secrets accessible outside the intended trusted boundary, or the protected boundary itself is compromised through host, firmware, or application misuse.
Impact: Attackers or privileged operators may recover sensitive data during computation, undermining confidentiality claims and potentially exposing regulated, customer, or high-value workload data.
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, NIST SP 800-57 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | Covers cryptographic protection of information during processing and storage. |
| SC-28 — Protection of Information at Rest | Supports the broader data protection model that encryption in use extends beyond storage. | |
| Recommendation — Apply SC-13 to protect sensitive data with cryptographic controls across its lifecycle. Use SC-28 to secure stored data with cryptographic protections that complement in-use controls. | ||
| NIST SP 800-57 | Key Management | Encryption in use depends on disciplined key lifecycle and protection choices. |
| Recommendation — Manage key generation, storage, rotation, and destruction to preserve in-use confidentiality. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Directly governs cryptographic control selection and operation for data protection. |
| Recommendation — Define cryptographic use and protection requirements for sensitive processing workloads. | ||
| CSA Cloud Controls Matrix | DSP — Data Security and Privacy | Addresses protecting sensitive data across storage, transport, and processing states. |
| Recommendation — Apply DSP controls to reduce exposure of sensitive data during processing and sharing. | ||
Practitioner Guidance
Why practitioners should care: Encryption in use is only useful when it matches the actual exposure you are trying to reduce. If the main risk is platform operator visibility, tenant co-residency, or cloud-side inspection, the control must be evaluated as part of the full workload trust model, not as a branding label.
What to watch for: Look for mismatches between the promised protection and the deployment reality, especially where application code, memory handling, key access, or supporting services can still reveal sensitive data outside the intended boundary.
Practitioner takeaway: Treat encryption in use as an architectural control with explicit trust assumptions, not as a universal substitute for good key management, access control, and data minimisation.
Related resources from NHI Mgmt Group
- What is the difference between symmetric and asymmetric encryption for IAM use cases?
- Why do VPNs create risk even when they use strong encryption?
- Why do password managers still need strong governance if they use end-to-end encryption?
- How do teams handle group automation in systems that use encryption keys?