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.

Expanded Definition

Data in use refers to information that is actively being read, transformed, computed on, or written by a user, application, or workload. In NHI and IAM practice, the term matters because protection must follow the identity performing the action, not just the file or packet. That makes it distinct from data at rest and data in transit, where controls can rely more heavily on storage or transport boundaries. For live workloads, governance usually depends on runtime identity assurance, session context, and tool-level authorization, which is why the security model often aligns with NIST Cybersecurity Framework 2.0 and identity-centric monitoring. Usage in the industry is still evolving across confidential computing, tokenized access, and agentic workflows, so definitions vary across vendors when they describe where protection begins and ends.

The most common misapplication is treating data in use as if encryption alone solves the problem, which occurs when runtime access is assumed safe once the storage layer is protected.

Examples and Use Cases

Implementing protection for data in use rigorously often introduces performance and operational overhead, requiring organisations to weigh stronger runtime controls against latency, integration effort, and user friction.

• A service account decrypts customer records inside an application process, where access logs and identity context matter more than the database location.
• An AI agent calls tools to summarize sensitive tickets, making the prompt, output, and delegated permissions part of the live protection problem.
• A CI/CD job expands a secret, queries an internal API, and rewrites configuration, which turns a short-lived execution window into a high-value data-in-use event.
• A security team reviews whether ephemeral credentials are sufficient for a workload that handles regulated records only during processing.
• Investigators trace a breach path where an NHI was over-privileged and the damage happened during runtime, not at storage. See the Ultimate Guide to NHIs — Key Research and Survey Results for the scale of NHI exposure, and compare implementation expectations with the NIST Cybersecurity Framework 2.0.

Across these scenarios, the security question is not just “where is the data?” but “which identity is acting, under what authority, and with what tools?”

Why It Matters in NHI Security

Data in use is where privilege becomes operational, so mistakes here tend to expose the real blast radius of a compromised NHI. NHI Management Group research shows that 97% of NHIs carry excessive privileges, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That combination makes runtime access the moment when weak governance turns into actual misuse, especially when secrets are stored outside approved controls or rotation is inconsistent. The same risk pattern is visible in the broader research set: Ultimate Guide to NHIs — Key Research and Survey Results highlights how frequently organisations struggle with visibility, revocation, and secret hygiene. For practitioners, the implication is clear: if an NHI can reach live data, it must be governed with Zero Trust assumptions, continuous verification, and tightly scoped authorization.

Organisations typically encounter the operational impact only after a credential is abused during an active workload, at which point data in use controls become unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams use data context during a ransomware incident?
• How should security teams use sensitive data discovery to reduce AI risk?
• Who is accountable when an AI agent accesses sensitive data it was not meant to use?
• What breaks when staff use consumer AI with patient data?