To make Zero Trust real in 2026, security must extend the "assume breach" mindset beyond the login screen to data at rest and machine identities within the cloud workspace to minimize the blast radius of inevitable compromises.
The phrase "assume breach" has been a staple of the security lexicon for over a decade. For most CISOs, it’s no longer a radical philosophy but a foundational expectation. We’ve spent the last several years re-architecting our networks, deploying ZTNA to kill the VPN, and hardening the identity perimeter.
But as we settle into 2026, there is a visible disconnect in how we apply this mindset. While we "assume breach" at the network and session layer, we often revert to "assume safety" the moment a user successfully authenticates into the cloud workspace.
We protect the front door with high-assurance MFA, but once an attacker—or a rogue integration—slips past that door, they find themselves in an environment of staggering openness. In Google Workspace, specifically, the default state is often one of high transparency and historical persistence. If a compromise occurs today, the "blast radius" isn't just what the user is doing now; it’s everything they’ve ever done, every sensitive email they’ve ever sent, and every third-party app they’ve ever authorized.
To make Zero Trust meaningful in 2026, we have to extend "assume breach" from the point of entry to the data at rest and the invisible web of machine identities living within our productivity suites.
The identity is the perimeter, but the perimeter is porous
We have leaned heavily on Identity and Access Management (IAM) as the "new perimeter." The logic is sound: if you control the identity, you control the keys to the kingdom.
However, the reality of 2026 is that identities are compromised in ways that bypass even the most robust "gatekeeper" controls. Adversary-in-the-Middle (AiTM) attacks and session hijacking have become commoditized. When an attacker replays a valid session token, they don't just "look" like a legitimate user to Google; for all intents and purposes, they are that user.
For a CISO, the risk here is binary. Either you have controls that function after the login, or you are entirely dependent on a front-door defense that you already know is fallible. A pragmatic approach acknowledges that while Google Workspace offers excellent native security, its primary job is to facilitate collaboration, not to act as a focused security platform.
Severing the link to historical data
One of the most significant oversights in modern Zero Trust implementations is the treatment of data at rest. In a typical Google Workspace environment, an executive’s mailbox is a treasure trove of ten years' worth of M&A documents, legal strategy, and sensitive HR discussions.
If that account is compromised today, the attacker doesn't just get access to today's emails. They get a decade of context.
A pragmatic application of "assume breach" requires us to proactively identify and secure this sensitive data before the incident occurs. This isn't about traditional DLP—which is often too noisy and restrictive to be useful—but about "de-risking" the mailbox. By finding sensitive content and adding a layer of verification (like a step-up MFA challenge) before that specific data can be accessed, we effectively sever the attacker's path to the "crown jewels" without interrupting the user's daily workflow.
The rise of the machine: managing the shadow integration layer
We talk a lot about human identities, but in 2026, the real expansion of the attack surface is in machine identities and OAuth grants.
The supply chain is the new watering hole, and attackers have shifted their focus to the invisible connections we’ve allowed into our environments. When a user clicks "Allow" on a seemingly innocent productivity tool, they may be granting that application the right to read their entire inbox or modify files in Drive.
These permissions often persist indefinitely. They don't expire when a password is changed. They don't care if you have Titan Keys.
Most security teams lack visibility into the true reach of these integrations. To address this, a comprehensive Zero Trust strategy must:
- Inventory the Reach: Understand not just which apps are connected, but exactly what data they can touch.
- Monitor Behavior: Detect when an integration starts behaving outside of its expected scope—much like we saw in the Drift/Salesloft incidents.
- Enforce Least Privilege for Apps: Just as we do for users, we must restrict the permissions of machine identities to the absolute minimum required for their function.
Redefining the blast radius
For a CISO, "risk" is a function of the likelihood of an event and the magnitude of its impact. We have spent billions trying to reduce the likelihood of a breach. It is time we spent an equal amount of effort reducing the impact.
Reducing the blast radius means that when the inevitable "Assume Breach" scenario becomes a reality, the attacker finds themselves in a room with no doors and empty cabinets. They may have the identity, but they don't have the data. They may have the session, but they don't have the permissions.
The path forward
The goal isn't to build a wall that can never be breached: that’s a fantasy. The goal is to build an environment that is resilient by design.
By augmenting the native capabilities of the Cloud Workspace with deep, data-centric protections and identity-aware visibility, we move from a reactive posture to a proactive one. We stop worrying about "if" they get in and start ensuring that it doesn't matter "when" they do.
