Integration is the Architecture: The Floor Under Zero Trust

Part 3 of a series. Part 1 covered North-South - the boundary. Part 2 went inside, to East-West - the interior. This part goes underneath both, to the layer that connects them: Network as a Service. Unlike Part 2, this one is not vendor-neutral - it is the Swiss Post stack, named. Co-authored with Fabio D’Avino, a brilliant network engineer and the Technical Product Owner of Swiss Post’s Zero Trust program.

If you have read Part 1 and Part 2, this is review - skip ahead. If you have not, here is the map. North-South is traffic between your organization and the outside world - users, customers, partners, attackers - all of it arriving at the boundary, the line where your estate meets the internet. A Zero Trust architecture guards that line with a Zero Trust Edge: a global cloud platform - Cloudflare, in our case - that every external connection passes through to be verified and inspected before it reaches anything you run.

East-West is the other half: traffic between systems you own - server to server, service to service, workload to workload - once something is already inside. Its discipline is microsegmentation: deciding what may talk to what, so one compromised system cannot roam the rest.

Two posts in, I have described a lot of deciding - identity, posture, policy, consensus, the whole architecture of saying yes and no.

At the boundary, you could leave the story there: the edge that decides is the edge that delivers - every packet it polices, it also carries. Inside, it depends which world you picked in Part 2. World One decides and never carries: the agent enforces on the host, and the network underneath does the moving. World Two carries everything it decides on - reachability, enforcement, and connectivity unified in one overlay - but that overlay is stitched from tunnels, and tunnels do not float. Every door into the corridor is itself a flow, riding a network underneath.

No underlay, no overlay. No floor, no traffic.

Underneath every East-West decision is a more boring question that rarely makes it onto a keynote slide: can these two systems actually reach each other - privately, predictably, across a large campus, two datacenters, and two clouds that have never met? That is the connective layer. In most enterprises it is a tangle no one designed - MPLS here, a site-to-site VPN there, a direct cloud link someone stood up for one project in 2019. It did not get architected. It accumulated.

At Swiss Post, we stopped owning it. We consume it as a service.

1. The Layer Under the Layers

Let me start with what this layer actually is.

Zero Trust is the strategy - technologically, a least-privilege access model that assumes breach. Across this series, its enforcement has one shape: a unified policy fabric - one policy intent, spanning every architectural component, boundary and interior alike. Network as a Service (NaaS) is the private transport that policy fabric rides on between the estate’s locations - campus, datacenters, clouds. The policy fabric decides; the NaaS carries.

Here is the symmetry it took me a while to see. The Zero Trust Edge does three things at the North-South boundary at once: it connects, it inspects, and it controls access - one platform, the whole job - riding a global backbone the vendor brings with it. Buy the edge, and the network comes in the box.

Inside, the network rarely comes in the box. Pick either world - the agent on every host, or the overlay and its corridor of tunnels - and what you have bought is enforcement. The network is sold separately: someone still has to bring the underlay that either carries the interior’s packets outright, or carries the corridor they travel through - and run it site to site and into both clouds.

NaaS is the consumption model for exactly that missing layer. SD-WAN is a technology; NaaS is a business model. You stop buying hardware and circuits and standing up a backbone, and you consume connectivity the way you already consume compute: on demand, managed, subscribed. Purists will object that a managed WAN under contract is not true NaaS by NIST’s cloud definition - no self-service, no elastic pooling. Fair. I am using the word the way the business and the architecture do: connectivity you consume instead of own. And the symmetry closes: NaaS plus microsegmentation is, for the interior, what the Zero Trust Edge is for the boundary.

Enforcement is policy: who may talk. The underlay is physics: whether they can. Policy without physics is just expensive opinion.

2. One Network, Campus to Cloud

Here is how it is actually built - and yes, the names.

One of the first diagrams I drew, three years ago, and the one worth drawing first. The details have moved on since; at the architectural level it still stands. What follows is the same drawing, zoomed in - and the reason to get this layer right early is that everything built on top of it inherits whatever you get wrong.

Inside each location, the network is Swiss Post’s own - the switches in the datacenter halls, the cabling on the campus floors. The NaaS picks up where the buildings end: everything between locations runs on Cisco SD-WAN, the former Viptela, delivered and managed by Sunrise. Sunrise runs the controllers, the controllers program the edge routers, and the encrypted tunnels between sites assemble themselves - no per-tunnel hand-cranking, and no negotiation between them either. The controllers decide which sites hear about each other at all, and the keys travel with that decision - two sites that policy says should not talk get neither the route nor the key.

The shape of the network is not cabled in. It is a decision about who gets a key.

And the WAN does not care what it rides: MPLS, broadband internet, or 5G - blended and sized per site, so a flagship campus carries MPLS and internet side by side while a small remote location rides 5G alone.

Branches and campus sites: the same design at every location, sized to what each one needs.

Branch, campus, datacenter: one network. Which leaves the clouds - and a decision about how to bring them in.

The obvious answer is the internet - and the internet as a backbone is not the villain here. It is already in the blend wherever it makes sense, and running your entire WAN through the Zero Trust Edge is a legitimate, modern choice - if you can accept the single point of failure it creates.

We cannot. The NaaS’s second job - the one the next section is about - is to hold if the edge does not.

A floor that hangs from the thing it is meant to catch is not a floor.

So into the clouds, we go private, on fiber - and this is where the carrier earns its keep. Sunrise delivers the NNI: a Network-to-Network Interface, the carrier-to-carrier handoff where a backbone and the cloud’s own routers meet in the same facility. The carrier builds that interconnect once, at high capacity, then carves it into customer circuits. Over that fiber:

• Into AWS: a Direct Connect connection, straight into the landing zone.
• Into Azure: an ExpressRoute circuit, on a redundant pair of Microsoft’s own routers.

Private, dedicated, off the public internet.

Where the private fiber meets the clouds - and, in blue, the second path into each landing zone that does not ride it.

The move that keeps those circuits from being two more links in the pile: they are stitched into the NaaS directly, and the routes follow both ways - the NaaS learns the way into the clouds, the clouds learn the way back. A cloud becomes just another site on the private WAN: no virtual appliance inside it, no tunnel stretched over the top. The whole East-West estate - campus, datacenters, AWS, Azure - one network, reasoned about in one place.

Stitched in, Direct Connect and ExpressRoute stop being cloud projects. They become part of the same floor plan.

One boundary worth drawing: everything above is the East-West story - workload to workload, inside the estate. The clouds’ North-South face does not ride the NaaS at all: the Zero Trust Edge builds its own tunnels into the landing zones over the internet, and that is the path the outside world takes to reach what runs there. Two planes, two paths into the same cloud - by design.

Datacenters treated as sites on the same network, not as a world of their own.

3. Designed for Failure

Now the part that turns a connectivity story into a Zero Trust one.

In Part 1 I wrote that we do not design for a world where technology never fails - we design for a business that survives when it does. That sentence has a bill attached, and this is where it comes due.

Ask the uncomfortable question: what happens to your most critical services should the Zero Trust Edge go dark? If every path of any consequence runs through the edge, then an edge outage is not a security event - it is a business outage. You spent years removing single points of failure from the network and quietly rebuilt one at the policy plane.

And it is a different failure from the one the NaaS eats for breakfast. A dead MPLS link or a flaky internet circuit, SD-WAN shrugs off - it reroutes over 5G before anyone files a ticket. That is link resilience, and it is the easy half. The failure that matters here is a storey up: the enforcement plane itself going dark.

Zero Trust has to be designed for failure, and designing for failure means an independent plane. The NaaS is that plane: private, carrier-operated, sharing none of the edge’s runtime fate.

So should the edge go dark, a defined set of critical services can fall back to the NaaS - a direct private path site to site, or a local internet breakout for the flows that must reach the world. Not a security vacuum and not a hole left open, but a break-glass: scoped, governed, opened when you need it and shut when you do not. The bar the design holds it to - still under active discussion as of this writing - is that the fallback polices its own traffic. One policy intent, even in fallback.

You do not get to choose whether the edge ever fails. You only get to choose whether that day is designed.

The break-glass exit, scoped to what has to keep running. Nothing leaves this way day to day - that path goes through the edge.

And the dependency runs both ways - the part I find elegant: the NaaS that catches the edge also leans on it. The SD-WAN edge routers interconnect with the Zero Trust Edge directly, and that handoff is the entire campus’s internet breakout: day to day, every outbound request leaves through the edge’s Secure Web Gateway. The edge is the interior’s door to the world.

Now flip the failure: should the fiber into the clouds degrade - a Direct Connect connection, an ExpressRoute circuit - the campus reaches the landing zones through that same interconnect and the edge’s own tunnels.

Remember the two paths into the same cloud? This is why. North-South falls back on the NaaS; East-West falls back on the edge. Each one catches the other.

Drawing the edge is easy. Architecting the floor you land on should it fail is the hard part.

An edge you cannot fail past is not resilience. It is a single point of failure with a good security story.

4. Why a Service, and Not a Build

So why consume all of this from Sunrise instead of building it?

Because owning it is somebody else’s core competency. The NNIs into AWS and Azure, the accreditations behind them, the round-the-clock operation of a national backbone, the meet-me facilities where the clouds’ routers physically live - that is a telecommunications company’s entire reason to exist. It is not Swiss Post’s. Renting it turns a capital project and a permanent operations burden into a service with a number next to it.

The real reason is the division of labor. The carrier owns the hard, boring, always-on plumbing. We own the policy and the intent. Sunrise guarantees the roads exist and stay up; Swiss Post decides who is allowed to drive on them and inspects them at the gates. That split is the whole integration thesis of this series in one sentence - the underlay is consumed, the enforcement is ours, and the value lives in how cleanly the two compose.

We do not want to own the roads. We want to own who drives on them - and a guarantee they are still there tomorrow.

The Bottom Line

So what does it come down to?

North-South is the door. East-West is the hallways. NaaS is the floor they are both standing on - and, on the worst day, the net beneath them. The series keeps arriving at the same place from different directions: the edge, the segmentation, and the network underneath are not three products you buy and bolt together. They are one system, integrated - or they are three islands doing an impression of an architecture.

Network as a Service is the least glamorous layer in the stack and the most load-bearing. It connects everything you are trying to protect, and it is the reason critical services keep breathing even if your cleverest control plane does not. Designed for failure is not a feature you add at the end. It is the floor you build first.