Exposure reduction and zero trust

The traditional security model treats the network boundary as a castle wall. Traffic originating outside is suspect; traffic originating inside is trusted. A VPN acts as the drawbridge: it lowers entirely for authenticated users, granting broad internal access once the credential check passes. The castle-and-moat analogy held when employees worked from a fixed office, all applications lived on-premises, and attackers operated externally. None of those conditions reliably hold today.

The perimeter appliance has itself become the attack surface. Verizon’s 2025 Data Breach Investigations Report records roughly an eightfold rise in the exploitation of VPN and edge devices as a route to initial access. The very box meant to enforce the boundary, the VPN concentrator or the edge gateway, is now among the first targets, because compromising it hands an attacker the broad internal access the castle-and-moat model reserves for trusted insiders. Supply chain compromises, credential theft and insider misuse arrive the same way: from inside the perimeter, or with valid credentials in hand. When the perimeter is the only control, a single breach of it grants an attacker the same implicit trust as a legitimate employee. Zero trust is the corrective posture, not a product to be purchased: it withdraws that implicit trust and forces every request to be verified on its own merits.

Zero trust is built on three core principles that collectively dismantle implicit trust:

1. Never Trust, Always Verify: every request must be authenticated and authorised at the time it is made, regardless of whether it originates inside or outside a network boundary.
2. Assume Breach: design systems as though attackers are already present, so that a successful entry does not grant unrestricted movement.
3. Least Privilege Access: grant only the minimum rights needed for the specific task, scoped to the shortest duration necessary.

Together these principles shift security from a one-time perimeter check to continuous, contextual evaluation. The SolarWinds Orion service account had far broader rights than monitoring required. Least Privilege would have limited what SUNBURST could do even after it activated.

Google's BeyondCorp initiative, launched internally in 2009 and published in 2014, is the canonical reference implementation. Rather than placing employees on a trusted corporate VPN, Google moved every application to the public internet and required per-service authorisation based on device state and user identity. By 2017, the majority of Google employees worked without a VPN. BeyondCorp demonstrated at scale that zero trust is operationally viable for large enterprises.

NIST SP 800-207 defines three logical components that together implement a zero trust access decision. The Policy Engine (PE) is the brain: it evaluates all available signals and produces a grant or deny decision. The Policy Administrator (PA) acts on that decision by issuing or revoking credentials and session tokens. Taken together, the Policy Engine and Policy Administrator form the policy decision point, the logic that decides. The Policy Enforcement Point (PEP) sits between the subject and the resource, intercepts every request, and enforces whatever the PA communicates.

A request flows as follows: a subject (a user, service, or device) makes a request; the PEP intercepts it and forwards context to the PA; the PA consults the PE; the PE evaluates the trust algorithm inputs and returns a decision; the PA instructs the PEP to allow or block. The trust algorithm draws on device posture, user identity, behavioural analytics, and request context. No single factor is sufficient on its own.

NIST SP 800-207 defines the architecture; NIST SP 1800-35, finalised in June 2025, shows it being built. The practice guide from the National Cybersecurity Center of Excellence documents 19 example zero trust implementations, assembled from commercial products supplied by 24 collaborating vendors, with every build mapped to the functions of the Cybersecurity Framework.

Publishing 19 working builds is an evidential act. It shows that zero trust is buildable from ordinary, off-the-shelf products, which answers the objection that the term is only marketing. In the same move it confirms the opposite of a sales pitch: not one of the 19 builds is “the zero trust product”. Each composes identity, device, network and data controls from several vendors into an architecture. You assemble zero trust from parts you largely already own; you do not buy it in a box.

CISA's Zero Trust Maturity Model v2.0 organises zero trust adoption across the following pillars, each assessed against four maturity stages: Traditional, Initial, Advanced, and Optimal.

1. Identity
2. Devices
3. Networks
4. Applications & Workloads
5. Data

The model provides a structured path for organisations to incrementally improve their posture rather than attempting a wholesale replacement of existing infrastructure. Most organisations assessed against CISA ZTMM sit at the Initial stage. Reaching Optimal requires mature automation, continuous monitoring, and policy-as-code. The diagram below is interactive: click each pillar to see what each stage looks like in practice.

Microsegmentation divides a network into small zones, each governed by its own access policy. Unlike traditional macro-segmentation (VLANs or a single perimeter firewall), microsegmentation controls east-west traffic between internal services as strictly as it controls north-south traffic between users and servers.

In a three-tier web application, the principle is straightforward in its intent: the payment database should be reachable only from the payment service, not from the web tier or from any monitoring agent beyond what is explicitly required. An attacker who compromises the web tier should encounter a policy boundary before they can query the payment database, even though both reside inside the corporate network.

CISA recommends beginning microsegmentation with crown-jewel assets: the highest-value, highest-risk data stores and services. Attempting full network microsegmentation in a single phase overloads operations teams and produces fragile policy sets that are difficult to maintain. Starting with the most sensitive segments first delivers the greatest risk reduction per unit of effort.

Zero trust treats the device as a first-class signal, which turns endpoint management from a housekeeping task into an exposure-reduction decision. Two choices dominate. Bring your own device (BYOD) lets staff use personal phones and laptops for work, lowering hardware cost and friction but placing corporate data on endpoints the organisation does not fully control. Mobile device management (MDM) is the counterweight: a management layer that enforces disk encryption, screen locks, patch levels and remote wipe on enrolled devices, and, for zero trust specifically, attests a device’s compliance state to the access decision.

That attestation is what makes device posture usable as a conditional-access signal. A policy engine can then refuse a request from a non-compliant or unmanaged endpoint even when the user’s credentials are perfectly valid, which is precisely the check a stolen password cannot pass on its own. The choice between personal and managed devices is therefore not a procurement preference; it sets how much of the device signal the access decision is able to trust.