What is the difference between data at rest, data in motion, and data in use?

Data at rest is stored and not moving, such as files, databases, and backups. Data in motion is traveling across a network, such as email, uploads, and API calls. Data in use is actively open on a screen or in memory, where encryption is off and protection shifts to access control, monitoring, and intent-aware detection.

How the Three States Differ in Practice

The useful distinction is less about the file name and more about the protection problem. data at rest is primarily a storage and retention question, data in motion is a transport and interception question, and data in use is a runtime exposure question where confidentiality depends more on who can access the process, memory, or interface than on ciphertext alone.

That is why the same dataset can require different controls at different moments. Strong encryption can protect stored and transmitted data, but once information is actively being processed, the practical focus shifts to access restriction, session control, endpoint hardening, and monitoring for misuse.

In many environments the boundary between the three states is not clean. A record can be copied from a database to an application cache, sent through an API, rendered in a browser, and logged elsewhere, so practitioners need to think in terms of where the data is exposed, not just where it nominally lives.

Which Controls Matter at Each Stage

At rest, the main objective is to reduce the blast radius of storage compromise. That usually means encryption, sound key management, backup protection, and restrictive access to the storage system itself.

In motion, the main objective is to protect the channel and the session. Transport security, message integrity, mutual trust where appropriate, and strict endpoint validation matter because the data is exposed to network interception, man-in-the-middle risk, and misdirected transmission.

In use, the practical challenge is that the data must be readable to the system that is processing it. That creates a control problem rather than a cryptographic problem, so the best protections are least privilege, segmentation, strong authentication, auditability, and controls that detect suspicious use rather than assuming encryption alone will save the record.

For API-driven systems, this distinction is especially visible because the same payload may be safe in transit but still fail at the access-control layer. The OWASP API Security Top 10 helps practitioners keep that separation clear by focusing attention on broken authentication, broken authorization, and improper resource exposure in the service layer: OWASP API Security Top 10.

Why the Distinction Changes Security Decisions

The main mistake is treating encryption as a universal answer. Encryption is strongest when data can remain protected while stored or transported, but it offers limited help once a user, application, or automated process must actively work on the data.

That difference changes implementation priorities. If the risk is disk theft or backup exposure, storage controls dominate. If the risk is interception or tampering during transfer, transmission controls dominate. If the risk is insider misuse, malicious scripting, or compromised application access, runtime controls dominate.

It also changes where detection value comes from. Storage events, network flows, and runtime access logs tell different stories, so teams should not expect one monitoring layer to cover all three states equally well. Data in use is usually the hardest state to observe cleanly because legitimate processing and malicious access can look similar without context-aware monitoring.

Risk and Threat Considerations

The biggest security risk is assuming one control layer protects all three states equally. Attackers often choose the weakest point in the lifecycle, such as exfiltrating data from a running application, stealing session material during transfer, or copying sensitive records from poorly protected backups.

Failure mechanism: Encryption, transport protection, and access controls each protect a different exposure window, so a gap in any one layer can still lead to disclosure, tampering, or unauthorized use even when the other two states are well protected.

Impact: Exposure in use is often the most damaging because the data is already decrypted for legitimate processing, which can widen the blast radius from a single record to whole sessions, queries, or workflows.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API5 — Broken Function Level Authorization	API access during transit and use depends on correct authorization decisions.
Recommendation — Enforce function-level authorization on every API action before sensitive data is processed.
NIST SP 800-53 Rev 5	SC-13 — Cryptographic Protection	Encryption at rest and in motion is central to differentiating data-state protections.
	AC-6 — Least Privilege	Data in use relies on limiting who can access readable data at runtime.
	AU-2 — Event Logging	Runtime exposure is best detected through logs that show access and usage patterns.
Recommendation — Apply cryptographic protection to stored and transmitted data according to sensitivity. Restrict runtime access to the minimum privileges needed for the task. Log data access and processing events that indicate misuse or abnormal activity.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Stored and transmitted data depend on cryptographic controls for confidentiality.
Recommendation — Use cryptography to protect data at rest and data in motion.

Practitioner Guidance

What to verify: Map controls to the state the data is actually in, not to the system name. A database may be encrypted at rest, yet still expose sensitive values through application memory, logs, exports, or overly broad API access.

Decision rule: If the primary concern is theft of stored media, prioritize encryption and key protection; if it is interception, prioritize secure transport; if it is misuse after legitimate access, prioritize authorization, monitoring, and containment of the runtime environment.

Practitioner takeaway: The most reliable posture comes from layered controls matched to the exposure state, because no single measure protects data equally well while it is stored, moving, and actively being processed.