What are the key Encryption in Use best practices?

What makes encryption in use different from other encryption states?

Encryption in use protects data while it is being processed, so the hard part is not just algorithm choice but where computation happens and who can observe it. The practical goal is to reduce exposure during execution, limit access to decrypted material, and ensure the trusted boundary is actually enforced by hardware or a verifiable runtime.

That is why Confidential Computing Guide is the right starting point for many teams: encryption in use usually depends on a trusted execution environment, confidential VM, or similar isolated processing boundary. If that boundary is weak, the promise of in-use protection is mostly theoretical.

How to reduce plaintext exposure during processing

The most important best practice is to minimise the amount of plaintext that ever exists in application memory, logs, or shared runtime components. Decrypt only for the shortest possible time, keep decrypted data inside the narrowest possible process or enclave, and avoid designs that copy sensitive material across layers just to make implementation easier.

This is also where Encryption Guide helps frame the broader control objective: encryption in use is only one part of a larger data protection model that also includes key custody, envelope patterns, and deciding which data truly needs to be accessible in plaintext at all. If a workload does not need raw data, do not give it raw data.

Constrain which workloads can reach protected data, and prefer designs where keys stay outside application memory where possible. When that is not possible, treat the runtime as part of the trust boundary and assume any expansion of process privilege or debugging access can widen exposure.

What should be enforced around attestation, patching, and fallback paths?

Encryption in use depends on trust in the execution environment, so attestation is not optional window dressing. Verify that the workload, platform, and measured configuration are the ones you expect before releasing keys or sensitive data into the protected environment. If attestation fails, the safe default is to deny access rather than silently continue.

Keep the trusted execution or hardware layer patched, because the security of the whole design rests on the isolation boundary remaining sound. Cryptographic Key Management Guide is useful here because key handling, rotation, and recovery become much more operationally sensitive when the protection boundary is hardware-backed. Confidential Computing Guide also covers the attestation-and-release pattern that makes this model work in practice.

Monitor for failures that fall back to unprotected processing, because fallback mode can quietly remove the very control the architecture was built around. Recovery paths should be tested under realistic failure conditions so the team knows whether the system blocks, degrades safely, or exposes data when the protected path is unavailable.

Risk and Threat Considerations

Encryption in use creates a different risk profile from storage encryption: the main exposure is not passive data theft at rest, but compromise of the runtime boundary, keys, or fallback logic. If attestation, isolation, or patch hygiene fails, attackers may target the processing path itself to access plaintext or force the system into a weaker mode.

Failure mechanism: A workload with excessive privilege, weak attestation, stale platform software, or permissive fallback behaviour can expose decrypted data, release keys to the wrong runtime, or process sensitive data outside the protected boundary.

Impact: The consequence is usually plaintext exposure during execution, followed by broader compromise of the protected dataset, key material, or downstream systems that trusted the weakened workload.

Practitioner Guidance

What to verify: Confirm that the attestation decision is enforced before key release, and that failure cases do not silently switch to unprotected processing. Also verify that operators cannot bypass the protected path for convenience during incident response or troubleshooting.

What good looks like: The protected workload only receives the minimum data it needs, keys stay tightly controlled, and any boundary failure is visible, logged, and treated as a security event rather than a routine exception.

Practitioner takeaway: Encryption in use is only as strong as the execution boundary around it, so the real control objective is to make plaintext exposure rare, intentional, and failure-resistant.

Related resources from NHI Mgmt Group

• What are the key Endpoint Encryption best practices?
• What are the key disk encryption recovery best practices?
• What are the key PGP Encryption best practices?
• What are the key email encryption gateway best practices?