diff --git a/_posts/2026-05-25-enforced-trust-zones-microsegmentation.md b/_posts/2026-05-25-enforced-trust-zones-microsegmentation.md
new file mode 100644
index 0000000..1a312ee
--- /dev/null
+++ b/_posts/2026-05-25-enforced-trust-zones-microsegmentation.md
@@ -0,0 +1,159 @@
+---
+title: "Enforced Trust Zones: Microsegmentation for When Identity Is Not Enough"
+description: "Identity-based Zero Trust verifies who is talking. It does not stop a compromised host from talking to everything. Network-segmented trust zones, NACLs at every boundary, and protocol break at an edge control zone are the defense-in-depth layer that contains lateral movement when an identity is already inside."
+date: 2026-05-25 12:00:00 +0000
+categories: [Security, Zero Trust]
+tags: [zero-trust, microsegmentation, network-segmentation, trust-zones, security, networking]
+image:
+ path: /assets/img/posts/enforced-trust-zones/hero.svg
+ alt: "A flat network where one compromised host reaches everything, contrasted with segmented trust zones whose boundaries are guarded by NACLs and an edge control zone that breaks and re-originates traffic"
+---
+
+There is a sentence I hear in almost every security review, and it makes me nervous every time: **"we moved to Zero Trust, so the network does not matter anymore."** The idea is seductive. If every call is authenticated and authorized on identity, why care which subnet a packet came from? I made a version of this argument myself, on stage at [RSAC 2026](/2026/03/30/rsac-2026-beyond-zero-trust.html). And then I spent the back half of that talk walking it back, because the room kept asking the same uncomfortable question: what happens after one host is already compromised?
+
+This post is the technical companion to the network-segmentation half of that talk. The earlier writing on building a Zero Trust enforcement point with a [reverse proxy](/2025/08/03/zero-trust-with-reverse-proxy.html) and the [control plane that backs it](/2025/10/20/zero-trust-control-plane-and-sessions.html) was about who is allowed to talk to what. This one is about the layer underneath: the network itself refusing to carry traffic it was never asked to carry, so that an attacker who wins one box does not inherit the whole estate.
+
+## The Flat Network Is the Silent Failure Mode
+
+Start with the architecture almost everyone actually runs, whatever the slide deck says. One large network. Every host can reach every other host on every port that a firewall did not explicitly close. Identity is checked at the application layer, which feels like enough.
+
+It is not enough, and the reason is the gap between **authentication** and **reachability**. Identity tells you who is making a request. It says nothing about whether two machines should be able to exchange a single packet in the first place. On a flat network, reachability is total by default, and identity is the only thing standing between an attacker and the rest of your fleet.
+
+So picture the failure. A single host falls: a vulnerable dependency, a phished credential, a misconfigured service. On a flat network, that host can now scan every other host, knock on every open port, and pivot. The attacker does not need to beat your identity layer everywhere at once. They need one foothold, and then the network itself hands them the map.
+
+
+
+
+ lateral movement on a flat network
+
+
# attacker owns one web host: 10.0.4.17
+# every other host is one hop away, because nothing forbids it
+
+attacker@web-01 $ nmap -sS 10.0.0.0/16 -p 22,3306,6379,5432
+Nmap scan report for db-primary.internal (10.0.9.3)
+ 3306/tcp open mysql # reachable. should it be?
+Nmap scan report for cache-01.internal (10.0.9.8)
+ 6379/tcp open redis # no auth, no segmentation, no limit
+Nmap scan report for secrets.internal (10.0.2.5)
+ 22/tcp open ssh
+
+# identity was never the thing keeping these apart. nothing was.
+
+
+This is the part identity-based Zero Trust does not address, and the part its loudest advocates sometimes wave away. A stolen identity is a real threat, but so is a workload that was never compromised at the identity layer at all, just reachable. Microsegmentation is the answer to reachability, and reachability is a network property.
+
+## Trust Zones: L2/L3 Isolation as the Baseline
+
+The fix is to stop treating the network as one space. You carve it into **trust zones**, where a zone is a group of workloads that share a security posture and a blast-radius budget. The web tier is one zone. The data tier is another. Admin and management planes are their own zones. The principle is simple: a compromise in one zone should not automatically become a compromise in another.
+
+Crucially, a trust zone is not a tag or a label that lives only in policy. It is enforced at L2 and L3. Each zone gets its own **dedicated VLAN** and a **unique, non-overlapping subnet**. That isolation is what makes the boundary real rather than aspirational. Two workloads in different zones are not on the same broadcast domain, and traffic between their subnets has to be routed, which means it has to pass a point where you can inspect and deny it.
+
+
+
+
+ trust-zone layout
+
+
zone: edge-control vlan: 10 subnet: 10.10.0.0/24
+zone: web vlan: 20 subnet: 10.20.0.0/22
+zone: app vlan: 30 subnet: 10.30.0.0/22
+zone: data vlan: 40 subnet: 10.40.0.0/24
+zone: management vlan: 50 subnet: 10.50.0.0/24
+
+# separate VLAN + unique subnet per zone:
+# no shared broadcast domain, every cross-zone hop is routed,
+# and every routed hop is a place you get to say "no".
+
+
+The mental model I keep is this: **identity decides who you are, segmentation decides where you can even knock.** A flat network lets everyone knock on every door and relies on the locks. Trust zones take most of the doors away.
+
+## Default-Deny at Every Boundary: NACLs and Host Firewalls
+
+A zone boundary is only worth something if it denies by default. The rule is that **cross-domain access is denied unless explicitly allowed**, and it is enforced in two places, on purpose.
+
+The first is the network boundary: a **NACL** (network access control list) at every zone edge. The NACL is stateless and coarse, evaluated at the subnet boundary, and it encodes the few flows that are supposed to exist between zones. Web may reach app on one port. App may reach data on one port. Everything else, including the lateral scan from the flat-network example, is dropped before it ever reaches a host.
+
+
+
+
+ NACL at the data-zone boundary
+
+
# data zone (10.40.0.0/24): explicit allow, then deny all
+100 allow src=10.30.0.0/22 dst=10.40.0.0/24 proto=tcp port=5432
+110 allow src=10.10.0.0/24 dst=10.40.0.0/24 proto=tcp port=5432# via edge control only
+900 deny src=0.0.0.0/0 dst=10.40.0.0/24 proto=all # default deny
+
+# the web zone (10.20.0.0/22) is not in any allow line.
+# a compromised web host simply cannot reach the database.
+
+
+The second is the **host-level firewall** on every workload, which scopes inbound traffic to exactly the ports that host serves and the sources it expects. This is deliberate redundancy. The NACL guards the boundary between zones; the host firewall guards the host even against its own zone neighbors. If an attacker lands on one app server, a tight host firewall keeps them from freely pivoting to the app server next to it. Two independent layers have to fail before lateral movement succeeds, which is the whole point of defense in depth.
+
+The honest tradeoff: default-deny at this granularity generates real operational work. Every legitimate new flow is a deliberate allow rule, reviewed and recorded. That friction is not a bug. It is the system forcing you to know, and to justify, every path that exists. A flat network has zero friction precisely because it has zero answers to "who is allowed to reach this."
+
+## Protected Lateral Movement: Protocol Break at the Edge Control Zone
+
+Default-deny raises an obvious question: real systems do need some cross-zone traffic. A web request genuinely has to reach data eventually. If you simply punch a NACL hole from web straight to data, you have quietly rebuilt a piece of the flat network: a direct path an attacker can ride.
+
+The answer in the talk was the one I care most about here: **do not let zones talk directly. Route protected flows through an edge control zone, and break the protocol there.** The edge control zone is a thin, hardened, heavily monitored zone whose entire job is to be the only place where two other zones meet. And it does not forward packets. It **terminates** the incoming connection and **re-originates** a brand new one toward the destination.
+
+That distinction, protocol break versus packet passthrough, is the load-bearing idea. A passthrough device forwards the attacker's bytes, framing, and any protocol-level tricks straight through. A protocol break terminates the session, parses it back up to the application layer, applies policy against a fully reconstructed request, and then opens a separate, clean connection it originates itself. The attacker's TCP session dies at the edge. Nothing they crafted at the transport or framing layer survives the gap.
+
+
+
+
+ protocol break vs passthrough
+
+
passthrough (bad):
+ web-host ===== one TCP session, packets forwarded =====> database
+ attacker framing + payload reaches the DB untouched
+
+protocol break (good):
+ web-host --- TCP session A ---> [ EDGE CONTROL ZONE ]
+ 1. terminate session A
+ 2. parse + authorize request
+ 3. re-originate session B
+ --- TCP session B (new) ---> database
+
+# two separate sessions. session A never touches the database.
+# the edge re-originates; the source IP the DB sees is the edge.
+
+
+This is the same enforcement-point pattern from the [reverse-proxy Zero Trust post](/2025/08/03/zero-trust-with-reverse-proxy.html), turned sideways: instead of standing only at the perimeter facing the internet, the enforcement point also stands between internal zones. Every protected cross-zone flow is mediated, terminated, inspected, and re-originated by something you control and watch closely.
+
+## Policy Enforcement Lives at the Zone Edge
+
+Putting the edge control zone in the path gives you a natural, single place to enforce policy on cross-zone traffic. Because the edge terminates and reconstructs each request, it can apply full policy: identity of the caller, sensitivity of the destination, the specific operation requested, and live risk signals. This is exactly where network segmentation and identity-based Zero Trust meet. The network got the packet to a place it is allowed to be; the policy engine at that place decides whether the actual request is allowed to proceed.
+
+
+
+
+ zone-edge policy decision
+
+
on cross_zone_request(req):
+ allow_zone = nacl_permits(req.src_zone, req.dst_zone) # network layer
+ allow_ident = identity_authorized(req.caller, req.action) # identity layer
+ allow_risk = risk_score(req.session) < THRESHOLD # live signal
+
+ if allow_zone and allow_ident and allow_risk:
+ return re_originate(req) # new clean session to dst
+ return deny(req) # default deny wins ties
+
+# segmentation and identity are AND-ed, not OR-ed.
+# both must say yes. either can say no.
+
+
+The boolean AND in that snippet is the entire thesis. Network segmentation and identity are not competing models where you pick one. They are independent layers that both have to agree, and either of which can refuse. That is what "defense in depth" actually means when you stop using it as a slogan.
+
+## Segmentation Complements Identity, It Does Not Replace It
+
+So let me retract the sentence I started with, carefully. The network does still matter, and "we did Zero Trust" is not a reason to flatten it. But the inverse error is just as real: segmentation alone, without strong identity, gives you rigid zones that trust anything already inside them, which is how the breaches of the perimeter era happened. Neither layer is sufficient. Each covers the other's blind spot.
+
+Identity-based Zero Trust answers "is this caller who they claim to be, and are they allowed to do this." Network segmentation answers "should these two machines be able to exchange a packet at all, and if a host is compromised, how far can it reach." The first contains stolen credentials. The second contains compromised hosts. An attacker has to defeat both, in sequence, at every boundary, and you have given yourself a place to see them try. That is the layered posture I argued for at RSAC, and it is the one I keep coming back to: continuous validation of identity over time, as in the [control-plane post](/2025/10/20/zero-trust-control-plane-and-sessions.html), riding on top of a network that was never flat to begin with.
+
+
Identity tells you who is knocking. Segmentation decides whether there is a door there at all. Zero Trust needs both, because an attacker only needs one of them to be missing.
+
+---
+
+*This is the network-segmentation companion to my [RSAC 2026 talk write-up](/2026/03/30/rsac-2026-beyond-zero-trust.html), and it builds on my two-part series on Zero Trust with a [reverse proxy](/2025/08/03/zero-trust-with-reverse-proxy.html) and the [control plane and sessions](/2025/10/20/zero-trust-control-plane-and-sessions.html) behind it.*
+
+*Building trust zones, wiring up an edge control zone, or arguing about whether the network still matters? I am on [LinkedIn](https://www.linkedin.com/in/singhsanjay12) or reachable by [email](mailto:hello@singh-sanjay.com).*
diff --git a/assets/img/posts/enforced-trust-zones/hero.svg b/assets/img/posts/enforced-trust-zones/hero.svg
new file mode 100644
index 0000000..6979c09
--- /dev/null
+++ b/assets/img/posts/enforced-trust-zones/hero.svg
@@ -0,0 +1,105 @@
+