Data in use

What is Data-in-Use?

Data-in-use is data actively being read, processed, or modified by a running application. It resides in RAM, CPU registers, or application buffers rather than in persistent storage or crossing a network. A database query result being rendered on screen. A document open in an editor. Customer records loaded into a CRM session. Credentials decrypted for authentication. All of it is data-in-use for as long as the application is actively working with it.

It's the third state in the data security trilogy alongside data-at-rest and data-in-motion. And it's the hardest to protect.

The reason is structural. Not because the controls don't exist, but because the protective measures that apply to the other two states are necessarily lifted the moment data enters use.

Why data-in-use is structurally different

Data-at-rest is protected by encryption. AES-256 means that even if an attacker gains physical or logical access to the storage medium, the ciphertext is unreadable without the key.

Data-in-motion is protected by transport encryption. TLS means that even if traffic is intercepted, the payload is unreadable without the session keys.

Data-in-use can't be encrypted in the traditional sense. To process data, an application must decrypt it. To display a record, the application must load it into memory in plaintext. To run a calculation, the CPU must operate on the actual values. The encryption that protects data at rest is suspended the moment processing begins.

That's not a failure of security design. It's a fundamental property of computation. You cannot add two encrypted numbers without first decrypting them. The in-use state is, by definition, the state where data is exposed to the system that's processing it.

So the security problem shifts. Instead of "prevent access to the data," it becomes "monitor and govern what happens during the access window."

Threats specific to data-in-use

Several threat vectors apply specifically to data in the in-use state that at-rest and in-transit controls cannot address.

Memory scraping: A process running on the same system can, under certain conditions, read the memory of another process. Malware that targets point-of-sale systems uses memory scraping to capture payment card data after it's been decrypted for processing but before it's written back to storage or transmitted. The data never appears unencrypted on disk or on the network. It's only visible in RAM during the processing window. That's precisely when memory scraping attacks it.

Screen capture and screen recording: An application with screen capture permissions can exfiltrate data that a user is actively viewing without touching any file or network connection in a way that DLP would recognise as a sensitive data transfer. An employee viewing a customer record, a financial report, or a confidential document can have that data captured as a screenshot by malicious software or a compromised application before any storage or network transfer occurs.

Clipboard interception: Data copied from one application to another passes through the system clipboard in plaintext. Malware monitoring clipboard activity captures sensitive data — passwords, credit card numbers, personal identifiers — at the moment of copy, before the data reaches its destination application or any transfer control that might inspect it.

Session hijacking: A valid authenticated session gives an attacker all the access that the legitimate user holds, without needing credentials. The attacker doesn't decrypt anything. They inherit the existing decrypted session. Access controls that verify identity at login don't re-verify continuously during the session, so hijacked sessions can persist and access data for extended periods.

Authorised misuse during legitimate processing windows: This is the most common and the hardest to detect. A database analyst with legitimate read access to customer records runs their normal query. But this time they export 800,000 records instead of the 200 they typically query. The data is in-use in exactly the same way it always is during legitimate work. The access was authorised. The credentials are valid. The query ran against the correct database. The difference is volume, timing, and what happened to the data after it was in-use: it was staged, compressed, and uploaded rather than reviewed and discarded.

That scenario isn't a memory scraping attack. There's no malware. The threat is the legitimate processing window itself being used for illegitimate ends.

Controls for data-in-use

Protection at the in-use state requires a different control philosophy than the other two states. Encryption isn't the answer. The controls that matter here are access governance, behavioural monitoring, and session-level activity tracking.

Least privilege at query and session level: The most effective structural control is limiting what data a session can access during active use. A customer support agent who can query individual customer records but not bulk-export the entire customer table has a smaller in-use exposure window than one with unrestricted read access. Least privilege applied at the query and export level, not just at the login level, limits the blast radius of any misuse during legitimate processing.

Behavioural anomaly detection during sessions: Monitoring what happens inside active sessions — volume of records accessed, query patterns relative to historical baseline, export behaviour, access to data categories outside the identity's normal scope — detects misuse in the in-use window. A database analyst querying 800,000 records at 11pm when their normal pattern is 200 records during business hours is an anomaly detectable during the processing session, not only after data has moved.

Emerging hardware-level protections: Trusted Execution Environments (TEEs) such as Intel SGX and AMD SEV provide hardware-isolated memory regions where data can be processed without being accessible to the host operating system or other processes on the same machine. This addresses memory scraping and hypervisor-level attacks by ensuring the processing environment itself is trusted. Adoption in enterprise data security is still maturing, but TEEs represent the most direct technical response to the fundamental in-use decryption problem.

Application-layer controls: Screen capture prevention APIs, clipboard monitoring policies, and session recording tools address some of the endpoint-level in-use threats. These are partial mitigations. They're also dependent on the endpoint being managed and the application honouring the controls, which makes them less effective against privileged users or compromised endpoints.

The in-use state and the authorised misuse problem

That's the real reason data-in-use is the hardest state. Not memory scraping. Not session hijacking. Those are real but detectable with the right tooling.

The harder problem is that most significant data loss occurs during legitimate processing windows, by authenticated users with valid access, using approved tools. Every control that permits the legitimate use also permits the illegitimate one. The data must be in-use for work to happen. It's also in-use for exfiltration to begin.

Distinguishing those two requires context: what is this identity's normal access pattern, what volume of data is typical for this role, what happened to the data after it was queried, does the sequence of access and movement match legitimate business workflow or something else. That's behavioural analysis applied at the in-use layer, not a cryptographic or network control.

That's why data-in-use security connects directly to behavioural analytics, database activity monitoring, and intent modeling. The data is accessible by design. The question is whether that access is being used as intended.