Protecting data at rest focuses on stored information and the controls around where it sits. Protecting data in motion focuses on how data moves between systems, who can access it, and whether those flows create exposure. Both matter, but data in motion often reveals the real attack surface because movement creates pathways that storage-only controls do not show.
What belongs to data at rest versus data in motion?
Data at rest is information stored on disks, databases, backups, endpoints, or archives. The protection problem is about where the data resides and which storage, access, and retention controls surround it. Data in motion is information actively moving between applications, users, services, and networks. The protection problem shifts to transmission paths, session handling, and exposure created by those flows.
That distinction matters because the same record can be safe in one state and exposed in another. A file encrypted on a server may still be vulnerable once an application sends it to an API, browser, queue, or partner system. The operational question is not just “is it encrypted?”, but “where does it travel, and what new access paths appear while it moves?”
Why movement usually reveals more of the attack surface
Protecting stored data is usually a control question: encryption, access restriction, retention, backup handling, and secure disposal. Protecting moving data is also a boundary question: every hop can expose metadata, headers, tokens, or content to another system, another trust zone, or another operator. That is why data in motion often shows the real integration risk more clearly than storage-only controls do.
In practice, flow analysis matters as much as cryptography. If sensitive data leaves a controlled store and crosses internal services, external APIs, mobile clients, or third-party processors, the security question becomes whether each step is authorised, logged, and limited to the minimum necessary payload. The difference is especially visible in CIS Control 3 Data Protection Guide, which ties data protection to classification, inventory, access, segmentation, encryption, and documented data flows.
Storage controls answer a narrower question than transmission controls. A strong at-rest posture can still leave weak session tokens, overexposed APIs, or unsecured partner links that make the data reachable while it is moving. For API-mediated flows, see OWASP API Security Top 10, where authentication and authorisation failures are often more important than the database encryption behind the service.
How to think about the two protections in practice
At-rest protection is about limiting what happens if storage is lost, copied, misread, or accessed directly. That usually means encrypting stored data, tightly controlling access, and reducing how long data remains stored in the first place. The main failure mode is assuming that storage security alone covers all exposure, when many incidents begin with a legitimate system moving the data somewhere else.
In-motion protection is about limiting what happens while data is being transferred, processed, or relayed. That usually means protecting transport channels, authenticating endpoints, minimising exposure in transit, and avoiding unnecessary duplication of sensitive content in logs, caches, or intermediaries. The controls are not interchangeable: at-rest encryption does not automatically protect an API call, and transport protection does not automatically secure the destination once the data arrives.
For architectures where sensitive information moves through many systems, you should also review whether the receiving platform has adequate guardrails around authentication, service accounts, and encryption handling. Nutanix AHV and Prism Security Guide is a useful example of how data-at-rest encryption, key management, roles, and API access all intersect in a real platform.
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 and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-3 — Data Protection | Covers storage, transmission, access, retention and segmentation of sensitive data. |
| Recommendation — Classify data flows, then apply encryption, segmentation and access controls to each stage. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Moving data through APIs makes authentication failures a direct transit-risk issue. |
| API1 — Broken Object Level Authorization | Data in motion often crosses object boundaries that must be authorised separately. | |
| Recommendation — Harden API authentication before exposing sensitive data in transit. Check object-level authorisation on every request that moves sensitive data. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Directly addresses protecting information while it is transmitted between systems. |
| SC-28 — Protection of Information at Rest | Directly addresses stored information and the controls around its persistence. | |
| Recommendation — Protect transmitted data with confidentiality and integrity controls on each connection. Encrypt and govern stored sensitive data wherever it resides. | ||
Practitioner Guidance
What to prioritise: Start with the flows that carry the most sensitive data, not the storage system that is easiest to inventory. If a dataset moves across multiple applications or trust boundaries, that movement usually creates the highest practical exposure.
What to verify: Confirm where the data is stored, where it is transmitted, who can read it at each hop, and whether copies appear in logs, backups, caches, queues, or exports. If you cannot map the flow, you cannot claim to have protected the data in motion.
Decision rule: If the question is “what happens if someone steals the disk?”, focus on at-rest controls. If the question is “who can see or intercept the data while it moves?”, focus on transport, endpoint, and API exposure. Most real environments need both, but the dominant risk should drive the first fix.
Practitioner takeaway: Treat data at rest as a storage control problem and data in motion as a trust-boundary problem, then design both so the weakest hop does not become the easiest way to reach the data.
Related resources from NHI Mgmt Group
- Why do traditional data in motion and data at rest models fail for AI risk?
- How should security teams choose an AES mode for protecting sensitive data at rest and in transit?
- How should security teams build a data security platform that covers data in use, at rest, and in motion?
- How should healthcare organisations protect PHI across data at rest, in motion, and in use?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org