Data at rest is information stored on disk, in databases, backups, or object storage; data in transit is information moving across networks between systems or users. Attackers target both through theft, interception, or unauthorised access. Defenders should encrypt both states, manage keys carefully, and verify transport security, storage controls, and backup protection.
What “Data at Rest” and “Data in Transit” Really Mean
These are the two core states of information security: stored data and moving data. The distinction matters because each state is exposed through different control failures, different attack paths, and different operational dependencies.
data at rest includes databases, file systems, backups, archives, and object storage. data in transit includes traffic moving between applications, users, services, and networks, where interception, downgrade, and man-in-the-middle risks become central if transport security is weak.
Why the Two States Need Different Protections
Information is often safer in one state than the other only if the right controls are paired to that state. Storage encryption protects a stolen disk or exposed backup, while transport encryption protects sessions and API calls from passive interception and active tampering. A strong design usually treats both as mandatory rather than interchangeable.
The same data can also move between states many times during a normal workflow, which means security has to be consistent across ingestion, processing, storage, backup, replication, and retrieval. Gaps often appear when one path is encrypted and another is left in cleartext, or when a legacy integration bypasses the main protection model.
Common Control Patterns
For data at rest, the main controls are encryption, sound key custody, secure backup handling, and access restrictions on the storage location itself. For data in transit, the main controls are secure transport protocols, certificate management, endpoint verification, and resistance to downgrade or interception.
Good practice also includes scope awareness. Some data may need field-level or application-layer protection in addition to disk or volume encryption, especially when the storage platform is shared or when administrators should not be able to read plaintext. That is why the strongest answer is usually not “encrypt everything” alone, but “encrypt appropriately for the state and trust boundary.”
Encryption Guide is the most direct reference for choosing between disk, database, field-level, envelope, and transport encryption approaches.
Where This Terminology Breaks Down in Practice
The two-state model is useful, but real systems blur the boundary. Data may be encrypted at rest yet exposed through poor access control, weak backups, overly broad decryption permissions, or insecure internal APIs. Similarly, data in transit may be protected on the network but exposed after decryption at the application boundary or in logs, caches, and observability tooling.
That means the practical question is not just whether encryption exists, but whether protection survives the full data path. The security outcome depends on key management, endpoint trust, storage permissions, and the exact places where plaintext is created, copied, or persisted.
Risk and Threat Considerations
These two states are attractive to attackers because they map to different compromise opportunities: theft of stored data, interception of live traffic, or abuse of a system that can decrypt either one. The biggest failure mode is assuming one control covers the whole lifecycle, when a weak link in transport, backup handling, or key access can still expose the data.
Failure mechanism: Attackers often target the easiest plaintext moment, such as unencrypted traffic, exposed backups, poorly protected storage, or a service that can legitimately decrypt data for processing. Once the decryption point is reached, the original at-rest or in-transit protection may no longer help.
Impact: Exposure can include customer records, credentials, tokens, regulated data, or internal business information, plus follow-on loss from fraud, disclosure, integrity compromise, and incident response overhead.
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 OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | Directly addresses protecting stored information on systems and media. |
| SC-8 — Transmission Confidentiality and Integrity | Directly addresses confidentiality and integrity of information in transit. | |
| Recommendation — Apply SC-28 to encrypt stored data and protect backups, archives, and other persisted copies. Apply SC-8 to protect data in transit with secure transport and integrity controls. | ||
| NIST SP 800-57 | Key Management | Key lifecycle and cryptoperiod choices materially determine the strength of data-at-rest and data-in-transit encryption. |
| Recommendation — Manage encryption keys through their full lifecycle and rotate them on a defined cryptoperiod. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Annex A explicitly covers cryptographic controls for protecting information in storage and transmission. |
| Recommendation — Define and enforce cryptographic controls for stored data, network traffic, and key handling. | ||
| OWASP ASVS | V12 — Secure Communication | Covers secure transport requirements for application traffic and service communication. |
| Recommendation — Verify that application traffic uses secure protocols and resists downgrade or interception. | ||
Practitioner Guidance
Why practitioners should care: Treat “at rest” and “in transit” as separate control obligations, not as a single encryption checkbox. The right implementation depends on where plaintext exists, who can decrypt it, and which system boundary is actually being trusted.
What to watch for: Misplaced confidence in storage encryption alone, cleartext between internal services, backups without equivalent protection, and key access that is broader than the data protection model requires.
Practitioner takeaway: The most reliable design protects both states, but it also narrows the decryption surface so that encryption remains meaningful when storage, transport, or backup layers are attacked.
Related resources from NHI Mgmt Group
- How should security teams choose an AES mode for protecting sensitive data at rest and in transit?
- How should security teams implement encryption across data at rest and data in transit?
- What is the difference between data encrypted at rest and data encrypted in transit for a password vault?
- What is the difference between securing mainframe data at rest and securing it in transit?