Zero Trust Does Not Abolish Network Segmentation

“We are doing zero trust, so we can flatten the network.”

No. Say the rest of it out loud first, because it becomes a migration programme with a very large outage window.

Zero trust does not abolish network segmentation.

Zero trust says a network location doesn’t certify a request as legitimate.

Network segmentation says a compromised thing should not have a path to every other thing.

Those aren’t competing conclusions.

They are the same assumed-compromise premise, applied at different enforcement points.

NIST SP 800-207, published in August 2020, requires access to an individual resource to be granted on a per-session basis.

And says authentication and authorization to one resource do not automatically grant access to another.

That is access policy.

It does not say every workload that reaches one resource should be able to reach every service in your estate while the policy engine sorts out its feelings.

Your network is viewed as compromised because a network position cannot reliably distinguish a legitimate requester from a compromised device sitting beside one.

Fine.

Now follow that logic all the way through.

If a workload is compromised, its reachable paths are part of your incident.

A PEP can deny a request to a protected resource.

It cannot make an unrelated database, administrative plane or control service disappear from a route table it is still allowed to reach.

Flattening your network because you have a policy engine is like removing the fire doors because the building has badge readers.

The badge reader is useful.

The fire door is still doing a different job.

1. “But Every Request Is Authenticated.”

Authenticated to what, and authorized for which resource?

NIST’s third tenet is deliberately narrow.

Access is evaluated before it is granted, per session, and authorization to one resource does not automatically grant access to another.

Your policy engine’s trust algorithm decides your request.

The PEP is the boundary through which you evaluate a resource before granting access.

That is a resource-access control path.

It should sit close to the resource it protects.

NIST’s network-planning assumptions say no resource is inherently trusted, and every asset must have its posture evaluated via a PEP before a request is granted.

A PEP at the edge of a large internal network still leaves a large internal network behind it.

Segmentation asks an earlier, different question.

May this source zone initiate a connection to that destination zone, on this named service, at all?

A firewall or network policy can refuse the path before a request ever reaches a resource-level PEP.

It doesn’t need to know whether the caller holds a valid credential to decide that a development workload has no business opening a connection toward an unrelated administrative service.

Authentication identifies a claimant. A PEP applies a resource decision. Segmentation limits the set of resources and protocols that can become your next reachable problem.

If your identity check is your only boundary, a compromised identity gets to knock on every door.

That isn’t zero trust.

That is a very polite flat network.

2. “But the Service Mesh Encrypts East-West Traffic.”

Good.

Encrypt east-west traffic.

TLS protects the connection two endpoints establish.

It protects data in transit and, where the implementation supplies it, supports peer identity.

It does not decide whether an application service should be able to initiate a connection to every other service merely because both ends can speak TLS.

The difference is visible in the mechanisms.

A stateful inspection firewall evaluates a connection against a state table keyed on the classic 5-tuple: source address, destination address, source port, destination port, connection state.

An application-proxy gateway makes two separate connections.

Client to proxy, proxy to destination, and can decrypt, inspect and re-encrypt TLS-protected payloads between them.

Neither mechanism becomes redundant because the payload is encrypted.

They operate on the path and the connection differently.

Encryption answers whether a connection is protected.

Authorization answers whether a principal may use a resource.

Segmentation answers whether the connection should be possible between these zones in the first place.

Nobody argues that “the storage volume is encrypted, so every application may mount it.”

Add encrypted service-to-service traffic to that sentence and suddenly the route table is treated as a civil liberty.

The defensible pattern is boring on purpose.

Require service identity and authorization at the PEP or proxy.

Then require an explicit network path to that point.

An encrypted connection that should never have been allowed to start is still an unnecessary lateral-movement path.

It is simply a private one.

3. “But Microsegmentation Is Hard to Operate.”

Yes.

Because your estate has dependencies, and the dependencies need to be known.

That isn’t an argument for default-allow.

It is an argument for doing your inventory and change work an actual security boundary requires.

NIST SP 800-41 Rev.

1 says all inbound and outbound traffic not expressly permitted by firewall policy should be blocked, because you do not need it.

It specifically rejects default-allow as less secure in an environment where hosts, networks, protocols and applications change.

Your operational tool is a segmentation matrix.

A source-zone-by-destination-zone table recording allowed and denied paths.

The term is industry shorthand rather than a NIST or PCI SSC definition.

The underlying rule is the useful part.

An application zone may need a named database protocol to a data zone.

It does not therefore need every protocol to every data service, an administrative plane, or every other application zone.

On sequentially evaluated firewalls, NIST also says rules most likely to match traffic patterns belong at the top of the list.

That is a mechanical fact with a security consequence.

Rule order determines your rule your connection is actually judged against.

A segmentation matrix and formal change management aren’t paperwork after your architecture.

They are how operations keep the allowlist from becoming an archaeological site.

Default-allow is easy to operate, right up to the moment a compromised workload discovers that “internal” means “reachable.”

Then your operations team has a simpler diagram and a much harder incident.

4. “But the Policy Engine Will Deny Unauthorized Requests.”

It should.

That is why it exists.

NIST’s sixth tenet requires resource authentication and authorization to be dynamic and strictly enforced before access is allowed.

The fifth requires you to monitor and measure the integrity and posture of owned and associated assets.

A policy engine can use current identity, device, application, behaviour and environment inputs to grant, deny or revoke access at the PEP.

But a deny at one PEP isn’t a network-wide quarantine order.

Your policy engine and administrator are key components precisely because no communication between resources happens unless they approve and configure it.

NIST also names their concentrated importance.

Compromise or denial of service against the PE, PA or PEP can adversely affect operations.

That is a reason to protect your policy plane and keep independent boundaries.

It is not a reason to make every east-west path depend on a single broad approval.

Suppose your data-service PEP denies a request.

Good.

What about your control-plane endpoint that lacks that PEP?

What about the management service whose network rule was written as “internal CIDR,” then forgotten?

What about a reachable protocol with no reason to be exposed from the compromised zone?

Your policy engine does not reduce any of those paths by denying one request somewhere else.

A denied resource request limits a resource action. A denied network path limits a route. Your incident needs both kinds of denial.

5. “But Private Subnets Are Already Segmented.”

Private subnets are addressing and placement.

They can support segmentation.

They do not constitute it merely by existing.

Segmentation is the enforced policy that says which source zone may reach which destination zone, on which protocol, under which rule.

A private IP address changes where a packet is addressed.

It does not write an allowlist into your firewall, any more than a locked office number creates an access-control list for the building.

PCI DSS v4.0 is usefully explicit where cardholder data is in scope.

Requirement 1.2.1 requires defined configuration standards for network security controls.

Requirements 1.3.1 and 1.3.2 require inbound and outbound traffic to and from the cardholder data environment to be restricted to necessary traffic, with all other traffic specifically denied.

Requirement 1.4.4 says systems storing cardholder data are not directly accessible from untrusted networks.

The CDE example doesn’t mean every environment needs a PCI-shaped diagram.

It does settle the principle.

A high-value asset has a boundary.

Your boundary has an explicit necessary-only path policy.

Private addressing alone is not that policy.

NIST SP 800-41 likewise recommends additional internal firewalls to protect, for example, an accounting database from unauthorized internal users.

“Internal” was never the same word as “authorized.”

6. “But More Layers Make Incidents Harder to Debug.”

Undocumented layers do.

Explicit layers with logs make an incident more explainable than a flat environment whose only policy is “it worked from somewhere.”

Log allowed and denied cross-zone flows.

Keep the segmentation matrix with an owner and a stated service purpose.

NIST SP 800-41 calls for every firewall policy change to pass through formal change management, and for your policy to be documented in the system security plan and maintained frequently.

The same discipline applies to PEP policy.

A grant, deny or revoke decision should carry enough context to identify the resource, the subject and the enforcement point involved.

Stateful inspection is already an example of layers that can be understood.

The firewall keeps its 5-tuple state table.

An application proxy establishes its two separate connections.

An inline IPS can use signature-based rules, anomaly-based baselines, or stateful protocol analysis.

Those layers have different evidence and different failure modes.

Collapsing them into unrestricted reachability doesn’t remove complexity.

It moves complexity into your incident timeline, where it is less polite and harder to query.

Suricata’s IPS mode defaults to fail-closed on parsing errors.

That is the right instinct for a boundary.

When your control cannot fully evaluate what it was supposed to evaluate, it blocks rather than silently passing traffic.

You need not apply that exact product behaviour everywhere to take the broader lesson.

“We could not explain the path” is not a reason to leave the path open.

7. No, This Does Not Mean Every Packet Needs a Unique Subnet.

It doesn’t.

The correction isn’t that every packet needs its own subnet, every workload needs an agent, or every application must be rebuilt before it may communicate.

The point is smaller and much more useful.

Access policy and reachability policy reduce different failure paths, so design them together.

NIST itself says its tenets are an ideal goal and may not all be implemented in their purest form.

Legacy systems often rely on infrequent authorization from fixed attributes, which CISA says conflicts with adaptive trust evaluation.

An enclave gateway can protect a group of resources where individual enforcement is impossible, and the residual implicit trust zone has to be named and contained rather than marketed away.

The same restraint applies to network design.

Zones should group assets that share a meaningful trust level, value and legitimate communication pattern.

A source-zone-by-destination-zone matrix can express those boundaries without an absurd explosion of subnets.

The objective isn’t ornamental granularity.

It is that compromise of one workload does not create routes to unrelated administrative, data or control-plane services.

Some paths need to exist.

Name them.

Some systems cannot yet receive per-request evaluation.

Bound them.

Some network rules will need to change.

Review them.

Less glamorous than saying “flat network, zero trust.”

It has the minor advantage of describing a design.

8. What You Should Actually Do

Define zones by asset value and trust level. Separate administrative and control-plane services from ordinary application workloads.

Identify data services and other high-value resources.

Then list the specific source zones that genuinely need to initiate communication toward each one.

Do not start from a product diagram.

Start from the routes an incident must not inherit.

Default-deny east-west traffic. Block what is not expressly permitted.

For each exception, record source zone, destination zone, protocol or named service, owner, business purpose, and the PEP or application boundary that will evaluate the resource request.

Put likely matching rules first where your firewall evaluates sequentially, and move changes through formal change management.

Enforce identity and authorization at the resource or proxy. Keep the boundary as close to the protected resource as your deployment permits, and require an explicit network path to the PEP as well.

A PEP with a broad reachable hinterland is still a broad reachable hinterland.

Log both decisions. Cross-zone-flow logs answer whether a source reached a destination.

PEP and application logs answer whether a subject was granted a resource action.

Keep them together during investigation without pretending they are the same telemetry.

The first exposes reachability.

The second exposes authorization.

Test the blast radius. From a representative compromised workload, test that unrelated administrative, data and control-plane services cannot be reached.

Test the necessary permitted flows too, because a boundary that silently blocks production is not a durable control.

PCI DSS v4.0 Requirement 1.2.7 requires rule-set review at least every six months.

Requirement 11.4.5 requires segmentation controls to be verified through penetration testing, and 11.4.6 sets a six-month minimum cadence for service providers.

Even outside a CDE, that is a useful reminder.

Your segmentation diagram is a hypothesis until the paths are checked.

9. The Model Is Not Complicated.

Zero trust refuses to treat network location as proof a request is legitimate.

It re-evaluates access at a PEP, using current policy and current evidence.

Network segmentation refuses to treat a compromised internal workload as entitled to reach every service.

It limits the paths and protocols available after the compromise.

Identity checks cannot reduce a path that remains unnecessarily reachable. Segmentation cannot authenticate the particular principal using an allowed path.

Use a policy engine.

Use PEPs.

Encrypt east-west traffic.

Keep private addressing where it is useful.

Then keep the internal allowlist narrow, make the cross-zone paths observable, and prove that a compromised workload cannot wander into unrelated systems.

Your network does not become trustworthy because it has been flattened under a zero-trust logo.

It becomes less useful to a compromise when the next path is denied.