Data at rest is stored on disks or databases, data in transit moves across networks, and data in use is actively processed in memory. The first two are usually protected with encryption and transport controls, but data in use is the hardest state to defend because it must be decrypted for computation. That is why enclaves matter for sensitive analytics.
How the three data states differ in a security plan
Security planning treats these states as different exposure surfaces. Data at rest is usually a storage problem, data in transit is a network problem, and data in use is a runtime problem. The distinction matters because the right control changes with the state: encryption, transport protection, access enforcement, key management, and trusted execution do not solve the same part of the lifecycle.
That is why a single “encrypt everything” policy is incomplete. The same record may need disk encryption when stored, TLS when moving, and stronger runtime protections when it is decrypted for computation. The practical question is not only where the data sits, but what can observe, intercept, or modify it at that moment.
For planners, the state model is useful because it maps cleanly to different control boundaries. Storage controls reduce theft from lost media or exposed databases, network controls reduce interception and tampering in motion, and in-memory protections reduce exposure during processing, when confidentiality is hardest to preserve without constraining computation.
What each state means operationally
Data at rest is information retained on disks, object stores, backups, archives, databases, or file systems. It is the easiest state to inventory and the most common place to apply default encryption, access controls, backup protection, and key lifecycle management. Its main security question is who can open the stored copy and under what conditions.
Data in transit is information moving between endpoints, whether across internal networks, the internet, service-to-service calls, or user sessions. Here the control focus shifts to confidentiality, integrity, and endpoint validation. Transport encryption protects against interception, but it also depends on correct certificate handling, protocol configuration, and trust decisions at both ends.
Data in use is information actively processed by software, usually in memory, where applications must decrypt or materialize it to perform work. This is the hardest state to protect because the system must briefly expose the plaintext to CPU, memory, or execution context. That is why sensitive analytics, delegated processing, and confidential workloads often look to enclaves, hardened runtimes, or other isolation mechanisms.
Why the distinction changes control choice
The main planning mistake is assuming one control covers all three states equally. A strong storage encryption program can still leave sensitive data exposed once a service decrypts it. Likewise, a secure transport layer does not help if an application logs plaintext, caches it unprotected, or hands it to a component with broader access than intended.
State-based planning also helps separate confidentiality from trust. Data at rest usually asks about access control and key custody. Data in transit asks about authenticated endpoints and tamper resistance. Data in use asks about execution boundaries, memory exposure, and whether the computing environment itself is trusted enough to handle sensitive content.
When the workload is highly sensitive, the “in use” state often becomes the design driver. If the system can only protect stored and transmitted data, but not the plaintext during processing, then the residual risk may still be unacceptable. That is where architecture choices such as isolated compute, data minimization, or offloading sensitive steps become part of security planning rather than later hardening.
Risk and Threat Considerations
The security exposure changes as data moves between states, and attackers often target the weakest transition rather than the strongest static control. A system can be well protected on disk and in transit, yet still leak through memory scraping, unsafe logging, misrouted access, or a compromised execution environment.
Failure mechanism: Defenders overestimate storage or transport protections and under-protect the runtime path where plaintext exists long enough to be observed, copied, or misused.
Impact: Sensitive information can be disclosed, altered, or exfiltrated even when encryption is present, because the compromise occurs after decryption or before re-encryption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Protects sensitive runtime and storage paths where plaintext may exist. |
| Recommendation — Harden deployment settings so sensitive data is not exposed in runtime or storage misconfigurations. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | Supports encryption for data at rest and in transit. |
| AC-4 — Information Flow Enforcement | Controls how sensitive data moves between systems and trust boundaries. | |
| SC-39 — Process Isolation | Addresses protection of data while it is being processed in memory. | |
| Recommendation — Apply cryptographic protection to stored and transmitted data. Enforce approved information flows for sensitive data paths. Isolate sensitive workloads so plaintext exposure is constrained during execution. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Network Segmentation | Segmentation reduces exposure for data in transit between trust zones. |
| Recommendation — Segment network paths to reduce interception and lateral exposure. | ||
Practitioner Guidance
What to prioritise: Classify the data by all three states before selecting controls. If the data is sensitive enough to matter, define what protects storage, what protects movement, and what prevents unauthorized observation during processing.
What to verify: Confirm that encryption is paired with key control, that transport protection is actually enforced between the right endpoints, and that runtime exposure is constrained by the smallest feasible trust boundary. If the processing step cannot tolerate plaintext exposure, treat that as an architecture issue, not just a configuration issue.
Decision rule: If the main risk is loss or theft of stored media, focus on rest-state controls; if the main risk is interception or tampering over the network, focus on transit-state controls; if the main risk is sensitive computation, prioritize runtime isolation and reduce the amount of data that ever reaches memory in the clear.
Practitioner takeaway: The state with the highest residual risk is usually data in use, so good security planning treats encryption as necessary but not sufficient and designs for the moment plaintext must exist.
Related resources from NHI Mgmt Group
- What is the difference between quantum computing and classical computing for security planning?
- What is the difference between data security and data protection in practice?
- What is the difference between data-in-use encryption and traditional database encryption?
- What is the difference between shifting security left and treating data protection as a separate downstream review step?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
