Zero Trust for distributed enterprises: Moving from vision to implementation

The network perimeter no longer defines the boundary of trust. As enterprises distribute workloads across cloud environments, onboard remote workforces, and integrate AI-driven automation into core operations, the implicit trust that traditional security architectures were built on has become a structural liability. Zero Trust addresses this directly: no user, device, or workload receives access by default, regardless of where the request originates.

It is built on five core principles:

• Every user, device, and workload must be authenticated and authorized before access is granted.
• Access decisions are governed by dynamic policy rather than static credentials, meaning context such as device posture, location, and behavior can change what access is permitted at any point.
• Every identity receives only the minimum privileges required to perform its function, nothing more.
• The resources that require protection must be explicitly defined before controls can be applied to them.
• Access is not a one-time decision. Continuous monitoring ensures that access remains appropriate throughout a session, not just at the point of authentication.

These principles apply equally to human users, machine identities, and AI-driven workloads. The emphasis on continuous evaluation of access, rather than one-time authentication, is what distinguishes Zero Trust from traditional access control models. This is also why its relevance has increased as enterprise environments have become more complex.

Zero Trust remains a critical security imperative

Three converging pressures have kept Zero Trust at the center of enterprise security strategy, and each has intensified in the past two years.

1) Expansion of non-human identities

Service accounts, API keys, OAuth tokens, containerized workloads, and AI agents now outnumber human identities in most distributed environments. These identities authenticate continuously, inherit permissions dynamically, and operate at speeds that make periodic governance reviews insufficient. Many of these identities retain outdated or excessive permissions from earlier deployments, which are rarely reassessed. This makes them a vulnerable and often overlooked attack surface.

2) The dominance of credential-based intrusion

Attackers no longer need to break access controls. They can inherit valid credentials through phishing, token theft, and consent abuse. Once inside the network, threat actors often generate valid logs, pass authorization checks to move through systems that have no mechanism to distinguish legitimate access from misuse. The infrastructure functions as designed, but the trust model does not.

3) Regulatory momentum

In the United States, the CISA's Executive Order 14028 requires federal civilian agencies to adopt Zero Trust architecture, with the Office of Management and Budget's accompanying memorandum M-22-09 setting specific Zero Trust security goals for federal agencies. This shift has moved the conversation from strategic intent to operational execution.

Looking further ahead, Gartner predicts that by 2028, 50% of organizations will implement a Zero Trust posture specifically for data governance, driven by the proliferation of unverified AI-generated data that organizations can no longer implicitly trust.

The structural conditions that make Zero Trust necessary are visible in the breach investigations that follow when those conditions go unaddressed. Two recent incidents illustrate that gap with precision.

Recent incidents that illustrate the cost of implicit trust

In early 2026, a campaign linked to the ShinyHunters collective targeted enterprise SSO environments. Attackers relied on voice phishing and credential harvesting rather than exploiting software vulnerabilities. Once SSO credentials and MFA codes were captured, threat actors accessed enterprise identity platforms and pivoted across federated SaaS applications, including Salesforce and Microsoft 365. The infrastructure functioned as designed throughout. Authentication attempts succeeded. Authorization checks were passed. The breach was enabled through the extension of a verified identity across connected applications without continuous reevaluation of access context at each boundary.

In August 2025, a campaign exploited stolen OAuth tokens associated with the Salesloft–Drift integration to access Salesforce environments across hundreds of organizations. The activity occurred between August 8 and August 18, 2025, and has been attributed to a threat actor tracked as UNC6395. The tokens were obtained following a prior compromise of Salesloft’s GitHub environment earlier in the year, which enabled attackers to access integration credentials. Using these tokens, attackers accessed Salesforce instances linked to the Drift integration and exfiltrated data, including AWS access keys, passwords, and Snowflake tokens. The attackers also deleted query job records after data extraction in an attempt to reduce detection, although logs remained available for investigation.

Both incidents reflect a consistent pattern. Modern intrusions do not announce themselves through authentication failures. They surface through behavioral drift across systems that have no mechanism to evaluate whether the access pattern still aligns with legitimate business activity.

What makes these incidents particularly instructive is that both organizations operated environments with significant distributed complexity, federated identity systems, and interconnected applications. That complexity is not unique to them. It is the default state of most enterprises today, and it is precisely what makes Zero Trust both harder to implement and more consequential to delay.

Distributed environments create specific implementation challenges

Distributed enterprises face a compounding problem. The architectural characteristics that make their environments flexible are the same ones that make Zero Trust enforcement difficult to apply uniformly.

Identity in a distributed environment does not reside in a single system. A user might authenticate through an on-premises directory, access cloud workloads through a federated identity provider, interact with SaaS applications under separate OAuth grants, and trigger automated workflows running under service principal identities in a cloud tenant. These are not isolated domains. They form a connected attack surface where compromise in one area can traverse into another through legitimate trust relationships.

The security stack mirrors this fragmentation. Network monitoring tools, endpoint detection platforms, identity providers, and SIEM systems each operate with partial visibility. A network anomaly detected after a user has already authenticated does not reach the identity layer in time to restrict access. A behavioral deviation flagged by a UEBA system might not be correlated with entitlement data showing that the same identity holds dormant administrative privileges. Each tool captures a portion of the picture. No single tool assembles it.

This is where lateral movement becomes difficult to detect. It is not a single event that crosses a defined boundary. It is a pattern that develops across identity planes, trust relationships, and privilege boundaries over time. Detecting it requires correlation across governance data, behavioral telemetry, and access events, capabilities that siloed tools evaluated independently cannot provide.

Distributed enterprises also typically lack the foundational inventories that Zero Trust enforcement requires: a current record of every application, every identity with access to it, and what that access actually permits. These gaps are not incidental. They are the starting conditions that any implementation plan must account for honestly.

The scale of the challenge is real. But scale is not the same as impossibility. The practical question is not whether to implement Zero Trust across the full environment immediately, but where to apply it first to generate meaningful security improvement without requiring a complete architectural overhaul as a precondition.

Establishing a practical starting point for Zero Trust implementation

The assumption that Zero Trust requires a complete architectural rebuild before it delivers security value is one of the primary reasons programs stall at the planning stage. A more accurate framing is that Zero Trust is an architecture built incrementally, with each phase reducing implicit trust across a defined scope before expanding to the next.

The starting point is scope, not comprehensiveness.

1) Prioritize critical applications over the full catalog

Most organizations do not have a complete, current record of every application in their environment. Requiring that comprehensive inventory before starting to apply Zero Trust controls often means an indefinite delay. What most organizations have is clarity on their most critical systems, those included in business impact analyses, disaster recovery plans, or identified by operational teams as highest-value assets. Web-based applications that support modern authentication protocols and integrate with identity providers without significant rearchitecting make them practical early candidates. Applications scheduled for refresh can be rebuilt with Zero Trust controls embedded rather than retrofitted.

2) Define policies that are executable

The goal is for organizations to have a central policy engine that can ingest signals from enforcement points across a distributed environment. While sound, this objective is operationally out of reach for most organizations. A more productive goal is to determine what minimum inputs allow meaningful access enforcement now. Here, identity is the key. The objective can be accomplished by requiring the confirmed identification of every user, device, and workload before granting access to reduce risks immediately. Beginning with MFA, device posture signals, and authenticated workload identities for automated processes can be layered onto this foundation over time as the policy matures.

3) Use existing enforcement infrastructure before procuring new tools

Next-generation firewalls already deployed in the environment can enforce identity-based access policies rather than the alternative of relying solely on port and protocol rules. ZTNA solutions already operational in parts of the network create enforcement points that can be extended with context-aware policies without additional procurement. Identity-aware proxies for web-based applications can verify access before users reach application workloads. These are not temporary measures. They represent a practical entry point into Zero Trust enforcement using investments already in place.

4) Apply monitoring where exposure is highest

Deploying context-aware monitoring at established enforcement points, focused on the critical applications already identified, provides actionable signal without requiring full-environment coverage from the start. UEBA tools establish behavioral baselines for users and workloads interacting with those applications and surface deviations that warrant investigation. Next-generation SIEM platforms go beyond log aggregation to incorporate behavioral analytics and policy context, enabling real-time detection of anomalous access activity in the systems that matter most.

These four actions are the starting points for a complete Zero Trust program that ensures the architecture can be extended systematically. Once this foundation is in place and functioning, Zero Trust can extend across the full IT environment.

Core architectural requirements for a mature Zero Trust posture

Progressing from a scoped starting position to a mature Zero Trust posture requires deliberate expansion across five domains. Each one addresses a layer of implicit trust that is not covered by securing access only at the point of entry.

1) Identity governance should be extended to non-human identities

Human accounts, service accounts, machine identities, API credentials, and AI agent identities must be governed under a consistent framework: least-privilege access, regular certification cycles, and continuous behavioral monitoring. In most distributed enterprises, non-human identities already outnumber human accounts significantly. Zero Trust controls governing only human identities address a shrinking portion of the total exposure.

2) Implement workload-level network segmentation

Perimeter-based boundaries do not prevent lateral movement within a distributed environment. Micro-segmentation, which limits communication between systems to only what is necessary, prevents unnecessary connections and reduces how far an attacker can move within the environment.

. East-west traffic, movement between internal systems, has historically operated with limited inspection. Segmentation makes that movement visible and subject to access policy.

3) Enforce continuous, context-aware policy evaluation

Access decisions made at authentication time and left static for the session duration are not Zero Trust. Continuous evaluation reverifies context as session conditions change, restricts access when behavioral signals indicate anomaly, and enforces step-up authentication when risk scores rise. This is the operational distinction between strong authentication and a functioning Zero Trust posture.

4) Extent visibility to cover all traffic flows

Complete coverage requires that both external-to-internal traffic and internal lateral movement are observable, with signals correlated across identity, network, and endpoint telemetry. Identity analytics—the coordinated use of behavioral modeling, entitlement analysis, risk scoring, and cross-system correlation—binds governance and detection together to produce a unified identity risk narrative that discrete tools operating independently cannot generate.

5) Apply Zero Trust principles to data governance

Because AI agents produce outputs often indistinguishable from human-generated data, implicit trust in this data carries the same structural risk as implicit trust in internal network traffic once did. Verification of data provenance becomes a Zero Trust requirement, not a secondary data quality consideration. This is the domain where the next concentration of Zero Trust implementation will occur, and where organizations that delay now will need to catch-up.

Each of these domains builds on the previous. Identity governance without network segmentation leaves lateral movement paths open. Segmentation without continuous policy evaluation creates static controls that attackers can map and work around. Visibility without correlation produces alert volume rather than actionable intelligence. The domains are interdependent, which is why the sequencing of implementation matters as much as the implementation itself.

Zero Trust is a continuous operating model

Zero Trust does not have a completion state. Each phase of implementation creates visibility that surfaces the next gap. Each enforcement point established informs the policy refinement that follows.

The infrastructure behaves as designed while trust is being misused. Authentication succeeds. Authorization checks pass. Movement occurs within permitted relationships. What is missing is the continuous evaluation of whether that access still reflects legitimate intent, across boundaries, over time, and across an identity surface that now includes humans, machines, and AI systems operating simultaneously.

Reducing implicit trust, domain by domain, identity by identity, application by application, is what Zero Trust implementation looks like in practice. It is a phased, measurable reduction of the conditions that modern attackers rely on, applied to an environment that was built, by default, on too much assumed trust.

Related solutions