Integration is the Architecture: Zero Trust at National Scale

How do you bring Zero Trust to an organization that is older than the concept of a “computer”?

Architecting the transition felt like changing the engines on a plane mid-flight - while that plane was carrying the entire population of a nation. A user base the size of Switzerland, the country’s third-largest employer, legacy systems that predate Zero Trust itself, a massive hybrid multicloud footprint, established partner integrations. The “recipe for disaster” was already written. We decided to rewrite it. Here is the architecture behind our Zero Trust transformation.

I call this a consensus architecture: access decisions emerging from multiple independent signal sources, each contributing to a unified risk assessment. Some signals shift the risk profile moderately; others explode it - a compromised device, anomalous behavior, a failed posture check. The architecture evaluates all inputs continuously; access is granted when aggregate risk falls within acceptable bounds, denied when it doesn’t. No single system makes that determination alone. We’ve moved away from the idea of a single point of enforcement. Instead, all entity types flow through a unified policy model where multiple components act as sensors and enforcers.

---

1. The Consensus Question

Signals align - but whose signals? From how many sources? This is where most Zero Trust architectures fail before they begin.

At this scale, we studied two conventional approaches:

1. Single-vendor consolidation collapses trust boundaries. One system authenticates, evaluates, and enforces - optimized for employees, insufficient for everything else. Siloed capabilities break against multidimensional entities. Integrations depend on brittle partnerships that break when roadmaps diverge. Zero Trust demands consensus: independent sources that must agree. No agreement, no access.
2. Traditional multi-vendor fragmentation is the most expensive way to fail. Twenty consoles, twenty policy languages, twenty audit trails. Operational costs compound while blind spots multiply - gaps emerge faster than integration can close them. Attackers find the cracks. Compliance becomes archaeology. Complexity wins.

Our approach: We chose neither. For North-South, we found a middle way: two platforms tightly integrated, plus a third component of our own making: a policy enforcement point at the last hop, ensuring access decisions remain ours regardless of upstream platform availability. They signal, evaluate, and enforce together. Consolidation’s simplicity without collapsed boundaries. Multi-vendor independence without the chaos.

This is our specific instance of Zero Trust. Your business may rest on different foundations and serve a different purpose, but the goal remains the same: access is only granted when the signals align.

Now here’s the real question: which platforms excel at their domains, and how do we integrate them so the gaps disappear?

Zero Trust must be built, not bought. And built through integration, not fragmentation.

---

2. Building the Consensus

Analyst reports won’t answer that question. They rank individual capabilities, not integration potential. Building consensus requires vendors whose platforms interoperate by design.

Cloudflare and Microsoft integrate natively - standard protocols, out-of-the-box interoperability. The integration exists because both vendors built their platforms to interoperate, not because a partnership team negotiated a connector.

• Microsoft secures corporate identity, managed endpoints, and SaaS access.
• Cloudflare secures the network edge, data in transit and analyzes traffic behavior.

Where capabilities between platforms overlap, we adopted what best maps to our requirements, estate, and scope. The boundary is intentional, not accidental.

Most security vendors are networking tools or identity tools. Cloudflare is an edge computing platform with programmability at its core. This transforms it from a security platform into an integration platform - one that can consume signals from any source with an API, not just the vendors it partners with.

This is programmatic integration. Whatever is missing natively can be added programmatically. If a partnership fails and an integration disappears, we compensate by building a programmatic replacement. This de-risks the architecture - flexibility, adaptability, composability. And because it’s code, it’s versioned, auditable, and recoverable.

But where does this integration execute, and who makes the final call? That requires understanding the architecture’s functional domains.

---

3. Control Plane and Data Plane

Zero Trust enforcement requires two fundamentally different functional domains.

The control plane is calculated asynchronously. Identity decisions, device compliance, risk assessment, posture baselines. This is where the question gets asked: should this entity have access? The data plane is evaluated synchronously. Real-time packet inspection, edge decisions, threat response, enforcement at the point of connection. This is where the decision gets enforced.

Neither is a vendor domain. Both require multiple systems to reach consensus. Secondary systems contribute additional signals to the control plane, enriching the policy decision without becoming enforcement points themselves.

In this model, neither vendor makes the final call alone.

Microsoft enforces at the identity, device and data layer - authorization, compliance, threat response, risk scoring, out-of-band Data Loss Prevention. For corporate entity flows, it is used twice: once to validate the identity to Cloudflare, and again to validate identity to our dedicated policy enforcement point.

Cloudflare enforces at the network edge - traffic inspection, threat blocking, behavioral analysis, inline Data Loss Prevention. All external traffic flows through its global fabric before reaching any destination. Because it is programmable at the edge, it becomes the integration layer that ties all signals together.

Both act as sensors. Both act as enforcers. If the edge is compromised, the identity layer stops the movement. If identity is compromised, the edge holds the line.

How Consensus Works

These domains operate across two spatial dimensions. External traffic - North-South - is bidirectional with entities outside our direct control: customers, partners, employees, suppliers, external systems, the open internet. Internal traffic - East-West - flows within infrastructure: service-to-service, APIs, systems communicating with each other.

The final access decision is not made by any single system. Device compliant? Yes. Identity context shows correct organizational scope? Yes. But the behavioral pattern is anomalous and Data Loss Prevention signals a data classification risk. Access denied - not because any single signal failed, but because the aggregate across all inputs signals risk. This happens in milliseconds under normal conditions, continuously, at the edge.

This is architectural consensus: all control plane inputs inform one unified policy; all data plane enforcement points must align. Not one system doing everything, but multiple systems contributing their best capability to consensus.

They enforce in layers. A workplace device egresses through Cloudflare at the edge. Traffic is inspected inline, Data Loss Prevention policies enforced. That same traffic reaches Microsoft for out-of-band inspection on its way to a SaaS destination. Inline and out-of-band. Two different enforcement layers. Defense in depth. Every enforcement point can act independently - if a policy violation is detected mid-session, access is revoked immediately. All decisions feed back into the control plane for the next evaluation cycle.

One policy model. One intent layer. Multiple decision inputs. Multiple enforcement actions.

---

4. Five Entity Types, One Fabric

Zero Trust fails between components, not within them.

Every platform’s capabilities work within its domain. The failures happen in the gaps - the handoffs, the transitions, the entities that don’t fit neatly into one vendor’s model. Most Zero Trust conversations stop at employees. That’s where most architectures miss the point entirely.

We designed for five entity types, and we designed for the gaps between them:

• Employees - corporate users on managed or BYOD devices. Trust anchored in corporate identity, device compliance and behavioral patterns. The most signal-rich entity type.
• Customers - end users of public applications, authenticated or anonymous. Trust derived from behavioral patterns and reputation when identity is absent.
• Partners - B2B integrations with verified identity. Trust anchored in identity with conditional boundaries based on contractual scope.
• Suppliers - third parties needing access to internal systems. Trust combines verified identity with session-level controls and enhanced monitoring.
• Services - APIs and machine-to-machine traffic. Trust established through cryptographic identity with continuous validation of request patterns.

They have different identity sources, different posture signals, different enforcement points. But the policy framework evaluating them is identical.

Here is the breakthrough: customers get the same architectural rigor as employees. When a customer accesses a public application, the policy decision considers bot score, threat score, and behavioral baselines - the same continuous verification as an employee. The customer doesn’t have a managed device, but they do have an evolving risk profile. When you don’t have device compliance data, you don’t have nothing. You have the entire Cloudflare application security stack providing equivalent posture signals.

The signals are different. The policy framework is identical.

---

5. The Connectivity Fabric

Every entity type needs a path. The five entity types map onto three connectivity patterns based on device management and traffic type. Here is how traffic actually moves based on who - or what - is connecting.

Managed devices establish always-on tunnels to the edge, contributing continuous telemetry about device health, user context, and activity. Traffic flows through layered inspection - DNS filtering, network-layer examination, and application-layer enforcement. Data Loss Prevention applies inline and out-of-band. Device compliance, threat indicators, and user risk scores feed continuously into policy evaluation.

Unmanaged entities follow different paths based on what they’re accessing. Employees and suppliers on personal devices connect through isolated browser sessions for private applications, limiting exposure while maintaining access. Customers and partners reach applications directly, encountering behavioral analysis, bot score, fraud detection, and threat score - whether authenticated or accessing anonymously. Enforcement adapts to each entity’s evolving risk profile.

Machine-to-machine traffic authenticates cryptographically using certificates or tokens for APIs, or network-layer controls for infrastructure services. Enforcement varies by protocol - API-level inspection, connection-level controls, schema validation for structured payloads. Certificate health and request patterns inform ongoing access decisions. Partner and supplier systems integrate through the same patterns - API-level or network-level, with enforcement at the edge.

Different paths. Different enforcement points based on entity type, device management, and destination. Same policy fabric evaluating all flows - Cloudflare at the edge for all entity types, Microsoft at the identity layer for corporate entities, dedicated identity providers where applicable.

---

6. Designing for Failure

Here is the uncomfortable truth most architectures pretend doesn’t exist.

If Microsoft suffers a widespread outage, authentication and authorization are severely constrained. If Cloudflare is unavailable, edge connectivity and enforcement are impacted across the estate. This architecture concentrates critical dependencies in a small number of platforms. This is not a flaw. It is a trade-off, and we accept it deliberately.

In the legacy on-premises world, we suffer from frequent, localized failures. A firewall misconfiguration. A patch gone wrong. A hardware failure in one datacenter. These are micro-failures - constant, annoying, contained. This architecture trades those frequent headaches for rare, catastrophic events. When a global cloud platform fails, it impacts everyone, everywhere, simultaneously.

We accept this because global cloud platforms fail less frequently than on-premises infrastructure - but when they do, the blast radius is large.

“Total and rare” beats “partial and constant.” We do not design for a world where technology never fails. We design for a business that survives when it does.

This means Business Continuity protocols. Manual fallbacks. Break-glass procedures that let critical operations continue without the autopilot. When Cloudflare experiences degradation, Microsoft identity services still work. When Microsoft has an outage, Cloudflare’s edge continues to block threats. And between them sits the policy enforcement point we built ourselves - protecting the last hop to the application, the one that keeps working when vendor platforms don’t. The degradation is known, measurable, handled.

There is also a defensive asymmetry in this architecture. Cloudflare deploys to 300+ locations across the world simultaneously. Ein Schweizer Anbieter kritischer Infrastruktur ist geografisch winzig - why do we need to deploy across the world? Because attackers are global. A massive DDoS attack doesn’t converge on the Swiss border - it dies upstream, absorbed by an edge that spans the planet. Most of the attack traffic never touches our infrastructure.

This is resilience. Not invincibility. Resilience designed for the world we actually have.

---

7. What Coherence Delivers

This is what we have been building toward.

One policy model for all entity types instead of five parallel security frameworks. Partner integrations become configuration, not projects. Threat investigation happens across all entity types in one fabric. Compliance has one source of truth instead of five vendor consoles.

But here is what actually matters: the entire architecture gets declaratively defined in Git.

• Every policy. Every integration. Every enforcement rule. All code. All versioned. All auditable.
• No console changes - all changes are pull requests, reviewed, tested, deployed through CI/CD.
• Zero configuration drift. Compliance review becomes repository review; commit history is the compliance record.
• Signal integrations are code. Rollbacks are git reverts.
• If the entire architecture were lost, we would re-deploy from Git. Hours, not weeks.

Policy changes are treated like application code changes - same rigor, same audit trail, same rollback capability.

---

The Bottom Line

Zero Trust is not about which platform controls your security. It is about making better decisions at the enforcement point. Better decisions require better information. Better information comes from integrating signals across domains - identity, device, network, behavior. No single platform has complete visibility.

This is what consensus architecture delivers. Employees, customers, partners, suppliers, services - human and non-human, managed and unmanaged - all flowing through the same policy fabric, all evaluated by signals from multiple sources, all enforced at multiple layers. One model for everything that crosses the boundary.