Data at rest and data in transit are the two states that determine where information needs protection. At rest usually means stored data, and in transit means data moving across networks. Security teams should encrypt both, enforce access controls, and check whether backups, replicas and application traffic are covered consistently.
Why data state changes the security model
Security teams treat data at rest and data in transit differently because the exposure path changes. Stored data is usually defended by disk, database, object-store or backup controls, while moving data depends on network channels, session security and endpoint behavior. If you only secure one state, an attacker can often take the other path to reach the same information.
The practical issue is not just encryption. The two states often have different owners, different control points and different failure modes. At rest, the common gaps are weak storage settings, exposed backups and replica drift. In transit, the common gaps are plaintext links, weak certificate handling and application traffic that bypasses the intended secure channel.
Encryption Guide is the most direct internal reference for the control choices that matter across storage, network transport and key custody.
What security teams need to cover across storage, backups and traffic
For data at rest, the question is whether the protected copy includes everything that can leak value: primary databases, file stores, snapshots, replicas, exports and backup media. A common mistake is to encrypt the main system but leave replicas or archived copies with weaker handling, which creates a second, less visible exposure path.
For data in transit, the question is whether every path carrying sensitive information is actually protected, not just the obvious user-facing one. That includes service-to-service traffic, API calls, internal admin links and replication flows. If one application leg is unencrypted or authenticated poorly, the security posture is only as strong as that weakest leg.
Consistent coverage also matters for access control. Encryption reduces exposure, but it does not replace authorization, because teams still need to limit who can read stored data, decrypt it, or intercept traffic at the application layer. In practice, storage protection and transport protection should be verified together, not treated as separate projects.
API Security Guide is useful here because so much modern data movement happens through APIs, where broken authorization or weak transport protections can expose records even when the underlying storage is well secured.
CISA KEV Catalogue is the right external reality check when transport or storage components rely on software that is actively exploited in the wild.
How to think about encryption decisions without creating blind spots
At-rest and in-transit protection should be decided by data sensitivity, threat exposure and operational dependency, not by habit. Teams often assume that “encrypted” means “safe,” but that only holds if keys are protected, certificates are valid, logs do not leak sensitive content and backup processes inherit the same policy as the source system.
The best operational view is to trace one record through its full lifecycle. Ask where it is created, where it is stored, where it is copied, how it is transmitted, and who can recover it from a backup or replica. That reveals the places where coverage breaks down, especially in hybrid environments and distributed applications.
For teams that need to align transport protection with API and service boundaries, the OWASP API Security Top 10 helps frame the kinds of transport and access failures that turn data movement into a compromise path. The control lesson is to verify the channel, the identity of the endpoint and the authorization decision together.
Risk and Threat Considerations
When one state is protected and the other is not, attackers look for the weaker path, because stolen data is often easiest to obtain from a misconfigured backup, an exposed replica, or a traffic flow that was assumed to be internal and safe. The risk is broader than confidentiality alone, since tampered or intercepted data in transit can also undermine integrity and trust in downstream processing.
Failure mechanism: Security coverage becomes inconsistent across copies, replicas, backup sets, internal traffic and third-party connections, so the protected primary system gives a false sense of safety while another path remains readable or interceptable.
Impact: Sensitive information can be disclosed, altered or replayed, and recovery may still leave the same exposure in place if the weak copy or unprotected channel was never brought under the same control.
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 and CIS Controls v8 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 | Data stored in systems, backups and replicas needs explicit at-rest protection. |
| SC-8 — Transmission Confidentiality and Integrity | In-transit data needs protection against disclosure and tampering while moving across networks. | |
| AC-3 — Access Enforcement | Encryption alone does not replace permission checks on stored data and traffic consumers. | |
| Recommendation — Apply SC-28 to protect stored data, backups and replicas with approved encryption. Apply SC-8 to protect sensitive traffic with secure transmission controls. Enforce AC-3 so only authorized subjects can access protected data. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptography is the core control for protecting stored and transmitted information. |
| Recommendation — Implement A.8.24 to define and enforce encryption use for data at rest and in transit. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Protecting stored data, backups and transmissions is a core data protection use case. |
| Recommendation — Use CIS-3 to protect data across storage, backup and transmission paths. | ||
Practitioner Guidance
What to verify: Confirm that encryption, key handling and access control apply to the primary dataset, every backup or replica, and every service path that can move the same information. If one copy or one channel is exempt, treat that as the real control gap.
Decision rule: If the data can be copied, replicated or retransmitted, security teams should assume the exposure surface is larger than the primary system and validate the weakest path first.
Practitioner takeaway: The useful security question is not whether the data is “encrypted somewhere,” but whether every place that can store, move or restore it is governed by the same protection standard.
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?
- How should security teams decide which vulnerabilities matter when runtime data is available?
- Why do AI security audits matter for IAM and data governance teams?
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 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org