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

At a glance

What this is: This is a practitioner guide to securing data in different states, with the key finding that protection must match whether data is stored, processed, or transmitted.

Why it matters: It matters because IAM, NHI, and autonomous programmes all depend on state-aware controls for secrets, keys, access, and monitoring rather than one-size-fits-all encryption.

👉 Read Netwrix's guide on securing data at rest, in use, and in motion

Context

Data security is not one problem. Data at rest, data in use, and data in motion each create different exposure patterns, which means the same safeguard does not work equally well across storage, processing, and transmission.

For IAM and NHI teams, the missing layer is often governance around the identities and keys that protect data rather than the data itself. Secrets, certificates, and encryption keys are the control plane for protection, and weak lifecycle handling turns a technical safeguard into a recurring risk.

That is why state-specific control design matters. A team can encrypt storage and still leave data exposed through over-permissioned service accounts, weak key handling, or unmonitored transfers, which is the typical failure mode in mixed identity environments.

Key questions

Q: How should teams secure data at rest without relying on encryption alone?

A: Teams should pair encryption at rest with strict key custody, access reviews, and rotation controls. If the identities that can unlock data are over-permissioned or poorly governed, storage encryption only reduces the impact of theft, not the risk of misuse. The real control is who can decrypt, not only what is encrypted.

Q: Why do data in motion controls still fail in well-defended environments?

A: Data in motion controls fail when organisations assume the network path is trustworthy. Transport encryption protects confidentiality on the wire, but it does not stop compromised endpoints, stolen session tokens, or over-broad workload permissions. Teams need identity verification and session monitoring, not just TLS.

Q: How do organisations reduce exposure for data in use?

A: They reduce exposure by limiting which workloads, services, and users can decrypt data during processing, then logging those interactions. Data in use is hardest to protect because it must be available to applications, so runtime least privilege and isolation matter more than static encryption claims.

Q: What is the difference between protecting data and governing the identities that access it?

A: Protecting data focuses on encryption, masking, and transport safeguards. Governing identities focuses on who or what can use those controls, including service accounts, API keys, and certificates. In practice, the second determines whether the first holds up under real operational pressure.

Technical breakdown

Data at rest protection and key governance

Data at rest is information stored on disk, in databases, backups, or object storage. Encryption at rest reduces exposure if media is lost or accessed improperly, but the real control boundary is key governance. If encryption keys, service account tokens, or vault access are overexposed, stored data remains recoverable. For identity teams, this makes access scope, rotation, and segregation of duties part of the storage protection model, not separate administrative tasks. Practical implication: treat key custody and access review as part of the data-at-rest control stack.

Practical implication: align storage encryption with key custody, access reviews, and rotation so at-rest protection is not defeated by identity sprawl.

Data in motion protection across network paths and sessions

Data in motion is information moving between systems, users, APIs, or workloads. Transport encryption such as TLS protects confidentiality in transit, but it does not solve endpoint trust, session abuse, or interception inside trusted networks. In modern environments, the key question is whether the identities establishing the session are tightly bound to the workload or user that should be communicating. This is where Zero Trust thinking matters: trust should be continuously verified rather than assumed because traffic is inside the perimeter. Practical implication: authenticate endpoints and protect session boundaries, not just the wire.

Practical implication: verify identities and session boundaries for every transfer path instead of relying on network location as a trust signal.

Data in use and the limits of encryption alone

Data in use is information being processed in memory, queried by applications, or handled by analytic pipelines. It is the hardest state to protect because encryption is usually removed or temporarily relaxed for processing. That creates a reliance on runtime access controls, isolation, and auditability. For NHI-heavy systems, the challenge is not only who can read the data but which workload or agent can reach it during execution. The result is a control problem, not just a cryptography problem. Practical implication: pair processing controls with least privilege, workload identity, and monitoring for sensitive operations.

Practical implication: govern runtime access and workload identity wherever data must be decrypted for processing.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

State-specific protection is the only defensible model for modern data security. Data at rest, in use, and in motion fail for different reasons, so treating encryption as a universal answer creates blind spots. The article is directionally correct in separating the three states, but the deeper governance point is that identity controls and cryptographic controls must be designed together. Practitioners should map each data state to its own access, monitoring, and key-handling model.

Secrets and keys are the hidden control plane behind every data-state control. Encryption does not protect anything if the identities that unlock it are uncontrolled. This is where NHI governance becomes central: service accounts, API keys, vault permissions, and certificate lifecycles determine whether protections at rest and in motion actually hold. Practitioners should stop treating key management as a back-office task and treat it as part of data protection governance.

Key custody drift: The same access paths that protect data can become the easiest way to expose it when credentials outlive their intended scope. That failure mode is especially common in environments with long-lived service accounts and distributed encryption tooling. The implication is that teams need to rethink how they assign responsibility for keys, not just how they encrypt data.

Data in use is where traditional perimeter thinking breaks down fastest. Once data is decrypted for processing, the protection model depends on runtime identity, process isolation, and operational telemetry. That matters across human IAM, NHI, and autonomous workloads because each can initiate access differently, but all can expose the same sensitive asset if runtime guardrails are weak. Practitioners should place the strongest controls where processing happens, not only where data is stored.

The market is still over-indexed on encryption features and under-indexed on identity-driven enforcement. The article points to a familiar industry gap: teams buy protection for the data state but fail to govern the identities and workflows that make that protection real. That is why state-aware data security is increasingly an identity programme issue as much as a data security one. Practitioners should align IAM, NHI, and security architecture around the full data lifecycle.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs , Key Research and Survey Results.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Our Ultimate Guide to NHIs , What are Non-Human Identities explains why service accounts, API keys, and certificates are the control surface that data protection depends on.

What this signals

Key custody is becoming the practical boundary between data security and identity security. As teams move from storage-only encryption thinking to state-aware protection, the questions shift to who can unlock, move, or process the data. That makes secrets governance, workload identity, and vault discipline part of the core control stack, not adjacent hygiene.

The next phase of programme maturity is not more encryption. It is better alignment between data state, identity state, and operational state, supported by lifecycle controls for keys, service accounts, and certificates. Teams that cannot map those relationships will keep mistaking protection features for protection outcomes.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per our Ultimate Guide to NHIs , Key Research and Survey Results, the real governance problem is distribution, not just encryption strength.

For practitioners

• Map controls to each data state Define separate control requirements for data at rest, data in use, and data in motion. Assign encryption, access control, logging, and incident response ownership to each state so gaps do not get hidden behind a single security policy.
• Treat key management as identity governance Inventory who and what can access encryption keys, vaults, and certificate authorities. Review service account permissions, token scope, and rotation cadence alongside application owners so key custody is not left to infrastructure teams alone.
• Harden session and transport trust Use strong authentication for workloads and users that exchange sensitive data, then monitor transfers for unusual volume, destination drift, or unexpected privilege use. Transport encryption should protect the channel, but session trust still needs continuous verification.
• Limit runtime exposure for sensitive processing Apply least privilege to the workloads and pipelines that decrypt or process sensitive data. Where possible, shorten processing windows, isolate execution, and log access to high-value datasets so data in use cannot become a silent exposure point.

Key takeaways

• Securing data at rest, in use, and in motion requires different control patterns because each state fails differently.
• The biggest practical weakness is not encryption itself but the identities, keys, and workflows that unlock encrypted data.
• Teams that align data-state controls with IAM and NHI governance are better positioned to reduce exposure across storage, processing, and transfer.

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 motion: Data in motion is information travelling between systems, users, APIs, or workloads across a network. The main control is secure transport, but identity verification, endpoint trust, and session monitoring are equally important because encrypted traffic can still be abused by compromised or over-permissioned identities.
• Data in use: Data in use is information being processed in memory, queried by applications, or handled by runtime services. It is the hardest state to protect because the data must become available to software, which means runtime access control, isolation, and logging matter as much as encryption.
• Key governance: Key governance is the set of policies and controls that determine who can create, store, rotate, use, and revoke encryption keys and related secrets. In practice, it is a core identity problem because whoever controls the keys often controls the data they protect.

Deepen your knowledge

Data-state protection, key governance, and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment depends on service accounts, certificates, or API keys to protect sensitive data, it is a relevant next step.

This post draws on content published by Netwrix: How to secure data at rest, in use, and in motion. Read the original.