Executive Summary: In modern cloud environments, protecting data-in-use (data actively processed in memory) is critical. If an adversary can read or dump your system’s memory, they can steal session tokens, encryption keys, or other credentials that let them impersonate legitimate users. In fact, infostealing malware that exfiltrates session cookies can “bypass password and 2FA controls” and give attackers access to victim accounts from their own devicescloud.google.com. Traditional defenses like encryption at rest or multi-factor authentication, while essential, offer little protection once an attacker is operating with valid in-memory credentials. To truly safeguard data-in-use, we must shift our approach from trusting the environment to trusting the session, and assume that breaches will occur. This pragmatic philosophy centers on three design principles:
-
- Ephemeral Access: Data should only be available in memory during an active, authenticated session – no lingering plaintext secrets outside of active use.
-
- Architectural Non-Escalation: No user or service should be able to escalate privileges or traverse from data they are authorized to access to data they are not. In other words, design systems so that a breach in one area can’t spread laterally.
-
- Active Containment: Implement containment mechanisms that restrict and monitor even legitimate sessions, so that if an adversary is acting as an authorized user, their actions are isolated and detected in real time.
In this post, we’ll explore each of these principles in depth, citing recent industry examples (like Google’s Device Bound Session Credentials and Microsoft’s automated account containment) and relevant research (from confidential computing to capability-based security and zero trust architectures). By the end, you’ll see how a combination of ephemeral session design, least-privilege architecture, and active containment can significantly bolster data-in-use security in the cloud.
The Cloud Data-in-Use Dilemma
Cloud CISOs and CTOs understand that while data at rest and in transit can be encrypted, data must be decrypted in memory to be used. This creates a dilemma: memory is often the weakest link, exposed to any attacker who gains a foothold on the system. If an attacker attains the ability to dump or read memory, it’s essentially game over – they can harvest whatever secrets or session credentials are loaded and use them to masquerade as legitimate users. For example, Google’s security team notes that malware which steals session cookies can allow attackers to bypass even multi-factor authentication and access cloud accounts from unauthorized devicescloud.google.com. In practice, an attacker who can inspect memory doesn’t need to break encryption or crack passwords; they simply reuse the keys and tokens that are already there.
This exact scenario has played out in the rise of session hijacking and identity-based attacks. According to industry reports, infostealer malware has exploded in prevalence – IBM observed an 84% increase in infostealer delivery in 2024 – precisely because stealing an authenticated session token (like a cloud admin cookie) is the easiest path for attackerscloud.google.com. Once inside with a valid session, intruders can often explore laterally and escalate their attack, especially in traditional network environments where anything inside the perimeter is overly trusted. As one analysis put it, attackers that got past the perimeter “were able to quickly advance on goals with lateral movement, encountering few protection protocols”paloaltonetworks.com. This underscores why “assume breach” has become a guiding principle – we design as if the adversary will gain some level of access, and our job is to minimize the damage they can do.
Leading cloud providers and researchers have been tackling this data-in-use problem from multiple angles. One approach is confidential computing, which uses hardware-based Trusted Execution Environments (enclaves) to shield data in use. For instance, Microsoft’s Azure Confidential Computing encrypts data in memory and only processes it after verifying the execution environment. This means even a cloud operator or a malicious hypervisor cannot read the enclave’s memoryazure.microsoft.comazure.microsoft.com. In the research realm, Microsoft’s prototype Haven demonstrated “shielded execution” of unmodified applications by “cordoning them off in memory from the underlying infrastructure,” effectively protecting the program’s data from a malicious OS or insider with root accesscomputerworld.com. These technologies show it is technically possible to make data-in-use opaque to would-be attackers – even if they dump memory, they see only encrypted gibberish.
However, confidential computing is not a silver bullet; it may not be practical for every workload due to performance and complexity, and it doesn’t stop an attacker who is the legitimate user (i.e. who has valid credentials to access the enclave). Thus, beyond just encryption, a pragmatic multi-layered strategy is needed. The following sections outline that strategy via the three key principles.
1. Data Only Available in Active Sessions
The first principle is limiting the exposure window of sensitive data. Simply put: data-in-use should exist only when and where it is truly needed. The moment a user’s session ends or a process no longer requires certain data, that information should be cleared from memory or rendered inaccessible. This minimizes the chance that an attacker who gains low-level access can find “warm” secrets lying around.
In practice, this means designing systems for ephemeral credentials and on-demand access. Long-lived tokens, cached keys, or plaintext data sitting idle in RAM are invitations for abuse. Instead, systems should generate session-specific, short-lived secrets that expire quickly or are bound to a particular context. Google’s recently introduced Device Bound Session Credentials (DBSC) exemplify this approach. DBSC creates an authenticated session that is cryptographically bound to the user’s device, and the browser continuously proves it still holds the private key, refreshing the session token at short intervalscloud.google.comcloud.google.com. The effect is that the session cookie is short-lived and useless if copied elsewhere. Even if malware steals the cookie from memory, it cannot be used on another device or after expiration, drastically limiting its value.
Likewise, ephemeral session design extends to application data. Applications should decrypt or fetch sensitive data into memory only for the duration of the user’s active task, and ideally in a scoped context that other parts of the system can’t directly read. Modern cloud identity systems issue time-limited access tokens (often with lifetimes of minutes) so that an attacker can’t reuse a token hours later. Some applications go further by requiring fresh re-authentication for especially sensitive operations or by using per-session encryption keys that are forgotten once the session is over.
Confidential computing provides another layer of assurance here. By running computations in isolated enclaves or confidential VMs, organizations ensure that data is only available in plaintext to the code that needs it, and not even the underlying OS or hypervisor can peek. For example, Azure’s confidential computing can keep data “encrypted and isolated in memory,” so that even a privileged administrator outside the enclave can’t access itazure.microsoft.com. In effect, the data is only “alive” in a transient secure enclave during processing. While not all applications are ready to leverage enclaves, this technology is rapidly maturing and is even being offered in managed forms (e.g., Confidential VMs on Azure and Google Cloud). The takeaway for a CISO is that ephemerality and isolation are your friends: the less time and scope in which sensitive data is exposed in memory, the less opportunity for an attacker to grab it.
2. Architectural Non-Escalation by Design
Even if an attacker manages to compromise one user’s session or one component of your system, nothing else should be put at risk. This is the core of architectural non-escalation: design your cloud architecture such that no principal (user or service) can leverage their legitimate access to reach data beyond their authority. In practice, this translates to rigorously enforced least privilege and strong segmentation at every layer.
Traditional flat network models allowed intruders who got inside the perimeter to move laterally with easepaloaltonetworks.com. Modern zero trust approaches turn that model on its head. As Google’s BeyondCorp (its pioneering zero trust architecture) showed, no network location alone grants trust – every access is tied to individual identity, device posture, and context, and every request to a resource is checked by central policy enforcement. One tenet of BeyondCorp-style zero trust is never assume an internal call is benign. Instead, each service and each user only sees what they are explicitly authorized to see, and nothing more. For example, BeyondCorp implements “continuous authorization for every interaction between a user and a resource” and even micro-segmentation for service-to-service communicationcloud.google.com. In Zero Trust terms, you “use a least-privilege strategy and strictly enforce access control” at all timespaloaltonetworks.com.
From an architectural perspective, achieving non-escalation means compartmentalizing your systems. Cloud applications should be broken into microservices or components with well-defined access scopes, rather than giant monoliths with unfettered data access. Each microservice might have its own credentials limited to just the data it needs. Compromise of one service should not automatically grant access to a different database or service. Similarly, each user account should only have permissions appropriate to its role, and high-value data should reside behind additional controls (even for internal access).
Academic research has long explored patterns for strong compartmentalization. The Capsicum capability system in FreeBSD, for instance, demonstrates how to enforce least privilege at the OS level. When a process enters Capsicum’s sandbox mode, “it loses all permissions normally associated with its user, except ‘capabilities’ (specific file descriptors or resources) it already has”en.wikipedia.org. In other words, the process can’t suddenly start accessing files or network resources that weren’t explicitly handed to it. This prevents a compromised component from escalating its reach. Such capability-based security is an illustration of architectural non-escalation: even if an attacker hijacks one process, they hit a wall – there simply aren’t ambient privileges to abuse.
Cloud providers implement similar principles through robust identity and access management (IAM) and network segmentation. For example, an enterprise might use separate cloud projects or accounts for different data domains, with tightly controlled inter-connectivity. If an attacker compromises an application in the marketing project, architectural controls prevent that breach from immediately jumping to the finance databases. Defense-in-depth mechanisms such as VPC isolation, firewall rules, and minimal IAM roles all contribute to an architecture where a single point of compromise remains contained. The goal is to minimize the blast radius of any breachlearn.microsoft.com – an approach explicitly recommended in Microsoft’s Zero Trust guidance as part of the “assume breach” mindset. Non-escalation by design turns a potentially catastrophic breach into a localized incident.
3. Containment of Adversaries Posing as Legitimate Users
The third pillar of our philosophy addresses the scenario we fear most: an adversary is in your system, using valid credentials, and thus appears as an authenticated user or process. In this case, it’s not enough to rely only on static permissions – you need dynamic containment and detection mechanisms that can identify abnormal behavior and clamp down on it in real time. Essentially, even if the attacker is technically authorized at the moment (because they’re piggybacking on a legitimate session), your systems should treat them as suspect and limit what they can do.
One aspect of containment is continuous monitoring and analytics. Recall that BeyondCorp not only shifts access to individual sessions, but also insists that organizations “continually view and inspect all traffic to identify any unauthorized activity or malicious content” inside their environmentpaloaltonetworks.com. If a user account suddenly starts downloading gigabytes of sensitive data at 3 AM, or a normally dormant service account begins probing other systems, those are red flags. By logging and inspecting internal traffic and actions, you can catch an attacker even if they have a valid login. As the Palo Alto Networks summary of BeyondCorp warns, without continuous inspection “an attacker can easily move around within the network and take whatever data they want without anyone knowing”paloaltonetworks.com. The key is to know – and to respond swiftly.
Modern cloud security tooling is increasingly geared toward this kind of active defense. For example, Microsoft’s account containment capabilities in its Defender suite can automatically respond when suspicious behavior is detected. Microsoft Defender for Identity (part of Defender XDR) will issue a “disable user” action – essentially an automatic suspension of a compromised account – to immediately stop that account’s activity if it’s deemed maliciouslearn.microsoft.com. This kills the attacker’s session and prevents further actions under that identity. In addition, Microsoft’s platform can “contain user” sessions by isolating the user’s device or blocking its interactions with other resources, thereby halting lateral movement in its trackslearn.microsoft.com. In Microsoft’s words, this capability “temporarily contains suspicious identities to help block any lateral movement” while the security team investigateslearn.microsoft.com. Such automated containment, triggered by behavioral analytics, can drastically limit the damage an attacker posing as a valid user can do – often stopping a hands-on-keyboard attack before it pivots to crown-jewel systems.
Google’s approach to containment is seen in tools like Context-Aware Access and the aforementioned DBSC. By binding sessions to devices and continuously validating them, Google Cloud makes it so that even if an attacker steals a session token, they “would be forced to act locally on the [compromised] device” to use it, where normal endpoint protection can detect themblog.chromium.org. Stolen cookies sent to a hacker on the other side of the world simply “no longer have any value”blog.chromium.org. This is a clever form of containment: it doesn’t prevent the initial theft, but it contains the attack by constraining the attacker’s reach (they can’t reuse that session elsewhere) and giving your security tools a chance to spot the intrusion on the legitimate device. More generally, strategies like risk-based authentication can step up verification or cut off access when a user’s context changes (e.g., a login from a new location mid-session), again limiting how far a stolen session can go.
Ultimately, containment is about recognizing misuse quickly and responding decisively. It complements the first two principles: whereas architectural non-escalation limits what an intruder could do, and ephemeral session design limits how long they could do it, containment mechanisms actively stop them in the act. This might involve automated playbooks that quarantine a VM or container if it behaves oddly, temporary network segmentation of a suspected account, or simply alerting a security operations center to intervene. The positive news is that today’s cloud security tools – from SIEM and UEBA solutions to XDR platforms – are increasingly adept at this kind of live response. The philosophy for CISOs is clear: don’t rely on any single control to protect data-in-use. Design multiple tripwires and circuit breakers that assume even your “trusted” users or software might turn against you.
Conclusion: Defense-in-Depth for Data-in-Use
Protecting data-in-use in cloud environments requires a shift in mindset. Rather than chasing the impossible dream of making memory completely impervious, savvy security leaders focus on limiting the value of what attackers can get and shrinking the window of opportunity. The pragmatic philosophy outlined here – ephemeral sessions, architectural non-escalation, and active containment – provides a layered defense that accepts one fundamental truth: breaches will happen. Our job is to make each breach isolated, short-lived, and non-lethal to the business.
In practice, that means building systems where a stolen token or a compromised server process does not spell disaster. A session token is tied to a device and expires quickly, so it can’t be weaponized at scalecloud.google.comblog.chromium.org. A breached microservice runs with minimal privileges, so it can’t quietly siphon your entire databaseen.wikipedia.orgpaloaltonetworks.com. And if an intruder does start behaving badly with valid credentials, your detection and response kicks in to shut them down within minuteslearn.microsoft.comlearn.microsoft.com. Each layer backs up the others.
For executive leaders, adopting this approach means investing in architecture and culture: embracing zero trust principles, refactoring overly privileged legacy systems, and deploying advanced threat detection and response tools configured to contain incidents, not just alert on them. It also means staying abreast of emerging technologies like confidential computing that can add new options for protecting data-in-useazure.microsoft.comcomputerworld.com. By weaving these ideas into your cloud strategy, you can ensure that even if attackers get in, they won’t get much. In a world where memory-dumping malware and insider threats are ever-present, such a resilient, layered stance is not just pragmatic – it’s essential for protecting the crown jewels of your organization.
Protecting data-in-use isn’t about one magic product, but about a philosophy of continuous authentication, least-privilege design, and real-time containment. Cloud providers like Google and Microsoft have already embraced this philosophy in their own security architectures (BeyondCorp, BeyondProd, account containment) and are embedding it into the platforms available to enterprisescloud.google.comlearn.microsoft.com. As a CISO or CTO, you can lead the charge by insisting on systems that fail safe – systems where an attacker with a stolen credential finds themselves in a dead-end: short on usable secrets, stuck in a tight segment, and swiftly identified by watchful eyes. This is the pragmatic path to protecting data-in-use, turning the scenario of a memory dump from a nightmare into a nuisance, and keeping your organization’s critical data securely under your control.
Citations
Cloud CISO Perspectives: Going beyond 2FA to address fast-rising, emerging threats | Google Cloud Blog
Cloud CISO Perspectives: Going beyond 2FA to address fast-rising, emerging threats | Google Cloud Blog
What is BeyondCorp? – Palo Alto Networks
Azure Confidential Computing – Protect Data In Use | Microsoft Azure
Azure Confidential Computing – Protect Data In Use | Microsoft Azure
Microsoft researchers create a secure haven in the cloud – Computerworld
Cloud CISO Perspectives: Going beyond 2FA to address fast-rising, emerging threats | Google Cloud Blog
Cloud CISO Perspectives: Going beyond 2FA to address fast-rising, emerging threats | Google Cloud Blog
Introducing BeyondCorp Enterprise | Google Cloud Blog
What is BeyondCorp? – Palo Alto Networks
Capsicum (Unix) – Wikipedia
Prevent or reduce business damage from a breach with Zero Trust | Microsoft Learn
What is BeyondCorp? – Palo Alto Networks
Automatic attack disruption in Microsoft Defender XDR – Microsoft Defender XDR | Microsoft Learn
Automatic attack disruption in Microsoft Defender XDR – Microsoft Defender XDR | Microsoft Learn
Chromium Blog: Fighting cookie theft using device bound sessions