Zero Trust, microsegmentation and network segmentation

Before you commit to a direction, this is the distinction that counts. Zero Trust is a security principle: do not trust a connection on the basis of its location, but validate every access request continuously against identity, context and risk. Network segmentation and microsegmentation are not synonyms for it and not alternatives to it. They are two methods of execution that land the principle in an existing landscape. Anyone who uses the three terms interchangeably ends up buying a product for a question that has not yet been framed as an architectural choice.

That difference is not wordplay. It decides the order in which you commit, what it touches in your landscape, and where a wrong choice stays lodged for years. A CIO who gets Zero Trust onto the agenda as a programme is in fact handed three questions at once: which principle do we adopt, with which segmentation execution, and in what phasing does that fit alongside what is already running. This piece pulls those three apart, so that the choice you make is traceable for the people who have to approve it.

What is the difference between Zero Trust and microsegmentation?

Zero Trust describes a stance towards access. The starting point is "never trust, always verify": no implicit trust based on network location, but continuous validation per request. NIST captures this in SP 800-207 as a set of principles, emphatically not as a product or an architecture you procure. Zero Trust is therefore something you decide, not something you install.

Microsegmentation is one of the ways that decision becomes reality within the network. It divides the environment into small, isolated zones and enforces which application may talk to which other application. The aim is concrete: to limit lateral movement. An attacker who gets in somewhere cannot move freely east-west through the environment, because traffic between systems is explicitly allowed or denied rather than implicitly trusted.

The confusion arises because microsegmentation is one of the most visible executions of Zero Trust. But the relationship is hierarchical, not interchangeable. Zero Trust is the quality attribute you set for your architecture. Microsegmentation is a design choice that meets that attribute for one layer of the problem: communication between application flows. Identity validation at the edge, conditional access and the continuous weighing of session risk are other executions that serve the same principle at other layers. An organisation can have microsegmentation and still not have Zero Trust, if access elsewhere still leans on location and implicit trust. And an organisation can be well advanced in Zero Trust on identity without having drawn a single segment in the network.

This is precisely why security in this context is a property of the architecture, in the same way as performance, scalability and maintainability are. You do not bolt it on with a tool. You design it in, or you do not design it in.

How does microsegmentation relate to network segmentation?

Network segmentation is the older, coarser technique. It cuts the network into zones, often with VLANs, subnets and firewall rules between those zones. Production separated from office, OT separated from IT, a DMZ between outside and inside. The granularity sits at the level of zones and segments, and traffic is checked mainly at the boundary between those zones, the north-south and zone-to-zone traffic.

Microsegmentation carries that same thinking inside the zone. Not "may this subnet talk to that subnet", but "may this specific application talk to that specific application, on this port, for this function". Control no longer sits only on the zone boundary but down to the level of the individual application flow, and precisely on the east-west traffic that classic segmentation largely leaves untouched.

The distinction can be summed up in three points:

Granularity. Network segmentation works on zones and subnets. Microsegmentation works on applications and application flows.

Traffic direction. Network segmentation primarily controls traffic that crosses zone boundaries. Microsegmentation also controls traffic between systems within the same zone.

Enforcement point. Network segmentation relies on network equipment and firewalls at the boundary. Microsegmentation shifts the enforcement point to the application itself or to a layer immediately around it.

Neither is "better". They answer different questions. Network segmentation is often the first step and remains the foundation: without sensible zoning, microsegmentation is a roof without footings. Microsegmentation is what you add when the dominant risk is lateral spread within a zone, and when the blast radius of an incident after initial access has to be contained.

When does microsegmentation fit, and when does it not?

The honest question is not whether microsegmentation is good. The question is whether your landscape is ready for it, and whether the dominant risk justifies it.

Microsegmentation fits when lateral spread is your greatest exposure. A flat server environment where ransomware, after gaining an initial foothold, spreads on unhindered is the textbook case. Likewise, in an environment with sensitive systems that must stay strictly separated while they run physically in the same data centre or the same cloud tenant, microsegmentation delivers something a zone firewall cannot.

Microsegmentation fits less well, or not yet, in three situations that have to clear the assessment before a product comes onto the table:

The dependencies are not mapped. Enforcing microsegmentation without knowing which application talks to which breaks applications no one had modelled. Dependency mapping and an observation phase come before enforcement, not the other way round. CISA describes this phased route, observe and simulate before you enforce, as the way to keep a transition from foundering on production. Skip this phase and you trade a security gain for a run of incidents that have nothing to do with attackers.

The coarser segmentation is not yet in place. If OT and IT still run into each other, or production and test still live on the same segment, an investment in network segmentation delivers more risk reduction per euro spent than microsegmentation does first. The order is an architectural choice, not a detail.

The management does not match the scale. Microsegmentation shifts complexity; it does not make it disappear. Network complexity becomes policy complexity: a set of explicit rules that someone has to maintain as applications change. An organisation without the capacity to keep that policy plane alive buys a snapshot that expires within a year. That is a legitimate reason to phase the execution differently, not to let go of Zero Trust as a principle.

That last point is where many programmes get stuck. The architectural choice holds up on paper. The execution runs around it because the policy plane became no one's fixed task. The difference between a Zero Trust design and a Zero Trust reality rarely sits in the design. It sits in who maintains it after the advisory report has been delivered.

What the three terms together mean for an architectural choice

Lay the three side by side and the choice becomes workable. Zero Trust is the standard you set for your landscape. Network segmentation and microsegmentation are two executions that meet that standard at different layers and with different granularity. The question at an architecture table is therefore not "do we buy Zero Trust", because that is not a purchase. The question is: given our dominant risk and the state of our landscape, which execution first, in what order, and what shifts to which management function as a result.

That question is deliberately not one for a vendor to answer. A party that sells a microsegmentation product has an interest in the conclusion that microsegmentation is the answer. That need not be ill-intentioned to be steering. The diagnosis therefore belongs before the tool: first establish which risk justifies the execution and what phasing your landscape can carry, then weigh which means fits, and choose that means transparently, including what it asks back in management. A choice reached in that order is defensible to a board and durable in a multi-year programme. A choice reached in the reverse order is a product with an architecture story built around it.

For the internal decision line behind this, that means something practical. The CIO making this assessment must be able to have the risk reasoning tested by the CISO, and to substantiate the choice so that the executive board can approve it without fully grasping the technology. The principle-execution distinction is exactly what makes that conversation carriable: it lets you explain why you adopt a standard independently of which tool you use for it, and why the order of execution was a deliberate choice and not an accident.

The logical next step

If Zero Trust is on your programme as a direction, the first step is not a product selection and not a pilot. It is separating the three questions that still arrive as one: which principle, which execution, in what order given this landscape and this dominant risk. Anyone who has those three clear before a vendor is at the table keeps governance over a choice that stays lodged in the architecture for years. Anyone who skips them lets the market set the order.

A sound next step is to make that separation together with someone who does the assessment on the merits without having to sell a product, alongside your own architecture and programme people rather than over their heads. Then the outcome stays yours, and it stays explainable to the link who has to approve it.