How to secure data at rest, in use, and in motion

At a glance

What this is: This article explains how to secure data in each state, with the central finding that protection must change with the data's context.

Why it matters: It matters because IAM, PAM, and security teams need to align access, encryption, and monitoring to where the data is stored, processed, or transmitted.

Context

Data at rest, in use, and in motion are not interchangeable protection problems. Each state changes the control surface: storage, processing, and transmission expose data to different threats and require different safeguards.

For identity and access teams, the practical question is not whether encryption exists, but whether access control, key handling, and monitoring are matched to the data state. A programme that treats all three states the same will miss where exposure actually occurs.

Key questions

Q: How should security teams build a data security platform that covers data in use, at rest, and in motion?

A: Security teams should design data security around the full lifecycle, not isolated tools. That means unified visibility across endpoints, SaaS, cloud databases, warehouses, email, and on-prem systems, plus controls that correlate metadata, access permissions, and lineage. The goal is to classify data in context, then apply consistent policy as it moves, so teams can reduce blind spots and avoid duplicated controls.

Q: What are the best practices for protecting sensitive data across its lifecycle?

A: Use layered controls that match the data's state, keep key management separate from storage permissions, and restrict who or what can access decrypted data during processing. The goal is not a single perfect control, but a governance model that follows the data as it changes form.

Q: When does encryption fail to protect sensitive data?

A: Encryption stops being sufficient the moment data must be decrypted for processing or exposed to a system that can read it in memory. At that point, access scope, process isolation, and monitoring become the controls that determine whether the data remains protected.

Q: What is the difference between protecting data at rest and protecting data in motion?

A: 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.

Technical breakdown

Data at rest vs data in motion: why the control surface changes

Data at rest lives in storage systems such as databases, file shares, and backups, where the dominant risks are unauthorized access and offline exfiltration. Data in motion is exposed while moving across networks and APIs, so interception, tampering, and session abuse matter more. The control model changes because the trust boundary changes: storage protection leans on encryption, access control, and retention discipline, while transmission protection leans on secure channels and certificate handling. In practice, the same dataset can require different safeguards in the same workflow depending on whether it is being stored or transferred.

Practical implication: map controls to the data state, not to the dataset alone.

Why data in use needs different protection than encrypted data

Data in use is the state where information is being processed in memory, which means encryption at rest or in transit no longer fully protects it. Once data is decrypted for an application, the exposure window shifts to runtime access, privileged processes, and any system that can read memory or intercept outputs. That is why control design has to move beyond storage encryption and into application permissions, process isolation, and monitoring of sensitive operations. The governance problem is not whether encryption works, but where its protection ends.

Practical implication: treat runtime access as a distinct governance layer, not a by-product of encryption.

How encryption, access control, and monitoring work together

Encryption reduces readability, access control limits who or what can reach the data, and monitoring reveals when those controls are being bypassed or misused. None of the three is sufficient on its own. Encryption without access control still leaves excessive insiders or NHIs with too much reach. Access control without monitoring can hide misuse until after exfiltration. Monitoring without cryptographic protection still leaves plaintext exposure. The article's core message is that these controls need to be sequenced and aligned to the lifecycle of the data, not deployed as isolated tools.

Practical implication: design data protection as a layered state-based control model.

NHI Mgmt Group analysis

State-specific data governance is the real control model, not blanket encryption. The article reinforces a basic but often ignored truth: data protection breaks when organisations treat rest, use, and motion as one problem. Each state has a different trust boundary, so the control that works in storage may add little during processing or transit. Practitioners should stop describing data security as an encryption issue and start describing it as a state-aware governance issue.

Data in use is the blind spot most programmes under-handle. Encryption can protect stored and transmitted data, but it does not fully govern information once it is decrypted for processing. That shifts risk to runtime permissions, memory exposure, and privileged application paths. The practical consequence is that many security programmes overestimate coverage because they count encrypted data rather than protected data.

Identity controls are inseparable from data-state controls. If a service account, API token, or privileged process can reach plaintext at the wrong moment, the protective value of encryption drops sharply. This is where NHI governance and data protection converge: access scope, credential lifecycle, and runtime authorization all determine whether the data-state model actually holds. Practitioners should evaluate data protection and identity control together, not as separate workstreams.

Monitoring only works when it is tied to the state transition that creates exposure. Logging stored-data access is not enough if the real risk appears when data is decrypted, transformed, or transmitted to another system. The article points toward a broader governance pattern: observe the moments when protection changes, not just the assets themselves. That is the difference between visibility and meaningful control.

Data-state protection is becoming a baseline expectation for identity programmes. As organisations move more workflows into cloud platforms and distributed applications, the boundary between data security and access governance keeps narrowing. The strongest programmes will treat encryption, authorization, and telemetry as a single control plane around data state. Practitioners should build policy around where data is, what is happening to it, and who or what can act on it.

What this signals

State-aware control design is now the minimum viable model for data protection. Teams that still talk about encryption as a single safeguard will continue to miss the handoff between storage, processing, and transport. The real governance task is to make sure the right control follows the data at each transition.

Runtime exposure is where most programme assumptions break. Once data is decrypted, the question becomes who or what can see it, move it, or copy it. That pushes identity governance into the centre of data protection, because access scope determines whether encrypted information stays protected once it is active.

For practitioners

• Map controls to each data state Inventory where sensitive data sits at rest, where it is processed in use, and where it moves in transit, then assign distinct controls to each state instead of relying on one encryption policy.
• Tighten runtime access to plaintext Review which users, service accounts, and workloads can reach decrypted data during processing, and remove standing access that is broader than the process actually requires.
• Separate key management from data storage Treat encryption keys as a governed asset with its own access, rotation, and recovery rules so compromise of storage does not automatically expose the protected content.
• Align monitoring to exposure moments Focus detections on decryption events, sensitive read operations, and unusual transfers, because those are the points where state changes create the highest risk.

Key takeaways

• Data protection fails when teams apply the same safeguard to every state of data instead of matching controls to rest, use, and motion.
• The article's core lesson is that encryption helps, but runtime access and monitoring decide whether sensitive data remains exposed after decryption.
• Practitioners should govern data protection as a layered state model, with identity controls and key management tied to where the data is and what is happening to it.

Key terms

• Data at rest: Data at rest is information stored on disks, databases, backups, or object storage when it is not actively moving through a network or application flow. Protection usually relies on encryption, access restrictions, and strong key handling so stored information is not readable if the storage layer is exposed.
• Data In Use: Data in use is information being actively accessed, processed, or modified by a user, application, or workload. It is the hardest state to govern because policy must follow live identity behaviour, not just storage location or network transit.
• Data-in-Motion: Data-in-motion is sensitive information while it is being transferred between systems, identities, or applications. For SaaS and AI programmes, the main concern is not only where data is stored, but which identities can move it, transform it, or expose it during transit.
• Key Management: Key management is the controlled lifecycle of cryptographic keys, from generation and storage through rotation, use, and retirement. In enterprise environments it is the governance layer that determines whether keys remain trustworthy across users, workloads, devices, and applications.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.