Blog

Polarising Website

Zero Trust Architecture: Principles and Implementation

Enterprise network racks and access infrastructure

Zero trust architecture (ZTA) is a way of designing systems so that no user, device, service or network is trusted by default. Every request is checked against policy, every time. The UK’s National Cyber Security Centre describes it as an approach where inherent trust in the network is removed, the network is assumed hostile, and each request is verified against an access policy. For a CTO or integration manager, the practical question is not what the idea means. It is how to apply it to an estate of APIs, event streams, legacy platforms and cloud services without stalling delivery. This guide answers that.

Polarising
Make Complex Systems More Connected
Polarising integrates AI into business processes, with governance and accountability built in from the outset.

Explore AI engineering

Key takeaways

  • Zero trust is an architecture and an operating model, not a product. It moves defence from the network perimeter to identities, assets and individual requests.
  • The integration layer (APIs, gateways, event brokers, service meshes) is where most zero trust decisions are enforced, so integration teams own a large share of the work.
  • Start with what you have: inventory identities, data flows and legacy dependencies first, then enforce in stages, beginning with the highest-risk flows.
  • The hard part is rarely the technology. Government research points to vendor integration and unsettled definitions as the main obstacles, which makes governance and ownership decisive.

Table of Contents

What zero trust architecture means

The formal definition comes from the US National Institute of Standards and Technology. NIST SP 800-207, published in August 2020, describes zero trust as an evolving set of cybersecurity paradigms that move defences from static, network-based perimeters to a focus on users, assets and resources.

The contrast with a traditional model is easy to state. In a perimeter model, once a user or device is inside the network, it can generally move around freely. The US Government Accountability Office puts it this way: zero trust authenticates and authorises every interaction instead. Its aim is to reduce the opportunities available to an attacker by restricting access and detecting attacks through monitoring of user behaviour and network activity.

Perimeter access compared with repeated verification

That is why a “zero trust network” is not a different kind of cable or firewall. It is the same infrastructure, governed by a different assumption: being connected proves nothing. Location stops being a credential.

Why integration leaders should care

Perimeters have been dissolving for years. Enterprise estates now span on-premises systems, several clouds, SaaS platforms, partner connections and remote staff. Between all of them sit integrations: APIs, message queues, file transfers, event streams. Each is a path an attacker can use if it relies on the assumption that “internal traffic is safe”.

In our experience of legacy-heavy estates, the weakest points are rarely the shiny new services. They are long-lived service accounts, shared credentials, flat networks around old middleware and integrations nobody has reviewed since the person who built them left.

The core principles of zero trust

There is no single canonical list, but the published ones agree on the substance. The OWASP Zero Trust Architecture Cheat Sheet lists these core principles: treat all resources as protected, secure all communications, grant access per session, use dynamic policies, and monitor the security posture of every asset.

The NCSC’s eight design principles are a useful UK reference for reviewing a design. In summary, they ask you to:

  1. Know your architecture, including users, devices, services and data.
  2. Know your user, service and device identities.
  3. Assess user behaviour and the health of devices and services.
  4. Use policies to authorise requests.
  5. Authenticate and authorise everywhere.
  6. Focus your monitoring on users, devices and services.
  7. Do not trust any network, including your own.
  8. Choose services designed for zero trust.

Principles one and two are the ones most programmes underestimate. You cannot write a meaningful policy for a service you do not know exists, and the NCSC itself warns that late-stage pitfalls often come from legacy services that do not support zero trust.

The components that make decisions

Most designs reduce to three roles, as set out in the OWASP cheat sheet:

  • Policy Engine: decides whether a request is allowed.
  • Policy Administrator: issues the commands that act on that decision.
  • Policy Enforcement Point: blocks or allows the connection itself.

This matters for integration teams because enforcement points are often components you already run: an API gateway, a service mesh sidecar, an event broker’s access controls, an identity-aware proxy. The architecture question becomes whether those components consult a consistent policy or each hold their own rules.

The pillars: five, seven or something else

Readers often ask for “the five pillars”. The answer depends on whose model you adopt. CISA defines five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. According to a 2024 Pacific Northwest National Laboratory report, Visibility and Analytics, Automation and Orchestration, and Governance run across all five as cross-cutting capabilities.

The US Department of Defense uses seven pillars in its 2022 reference architecture, treating Visibility and Analytics and Automation and Orchestration as pillars in their own right.

The differences are mostly presentational. The same PNNL report stresses that the pillars are interdependent, and effective zero trust depends on integrating them rather than treating them as silos. Pick one model, use it as a common vocabulary between security, architecture and delivery teams, and move on.

Pillar (CISA model) What it asks in an integration context
Identity Does every user, service and process have its own verifiable identity, with no shared credentials?
Devices Is the health of the calling device or workload part of the access decision?
Networks Is traffic segmented and encrypted, and is internal traffic treated as untrusted?
Applications and workloads Are APIs and services authenticated, authorised and monitored individually?
Data Is access decided by data sensitivity, with controls that follow the data between systems?

Zero trust for APIs and microservices

This is where the topic becomes concrete for integration managers.

APIs

NIST’s guidance on microservices security (SP 800-204) says that authentication, access management, secure communication protocols and monitoring are needed, and that these can be bundled into API gateways and service meshes. In practice, a zero trust API posture means:

  • Every call is authenticated. No anonymous internal endpoints, and no trust based on source IP.
  • Authorisation is per request, based on who or what is calling, what it is asking for and the context. Tokens carry scoped claims, not blanket access. Our explainer on OpenID Connect and OAuth 2.0 covers which protocol does what.
  • Credentials are managed, rotated and never embedded. Secrets handling is a precondition, which is why we wrote about infrastructure-first secrets management for UK teams.
  • Traffic is monitored for behaviour that departs from the norm, such as a service suddenly requesting far more records than usual.

Microservices and service-to-service traffic

For cloud-native estates, NIST SP 800-204A recommends a service mesh. It says a mesh can implement authentication and authorisation uniformly for microservices-based applications without changing individual microservice code. That is a significant argument for a mesh when you have dozens of teams shipping services at different speeds.

The later NIST SP 800-207A goes further. For cloud-native microservices it calls for network-tier policies to be augmented with identity-tier policies, using API gateways, sidecar proxies and identity frameworks such as SPIFFE. NIST’s researchers make the underlying point that trust must be established in the identity of the participating entities, wherever they run, on premises or across several clouds.

If you are building or modernising these services, our approach to cloud-native application development builds identity and policy in from the first sprint, and our piece on cloud-native architecture for CTOs covers modernising legacy without a rewrite.

Where integration platforms fit

Most enterprises already own the enforcement points zero trust needs. They sit inside the integration platforms: Boomi, MuleSoft, TIBCO and Solace. We work across all four for clients, and each tends to map onto a different part of the design:

  • iPaaS and API management platforms (the Boomi and MuleSoft style) concentrate API traffic through governed gateways. That makes them natural places to enforce authentication, apply policy and log every call between systems.
  • Messaging and event platforms (the Solace and TIBCO style) carry events between systems. Here the questions are who may publish and subscribe to which topics, how those permissions are granted, and whether traffic is encrypted in transit.
  • Enterprise service and integration layers often hold the oldest connections in the estate, so they are where a zero trust review tends to find the surprises.

The design principle is the same on any of them: the platform enforces, but a central policy and identity model decides. When each platform, gateway and broker carries its own isolated rules, you rebuild the silos the PNNL report warns against. Our integration platforms practice and enterprise integration services are organised around that idea: choose the platform for the workload, but keep identity, policy and observability consistent across all of them.

And because compliance evidence is part of the job, teams that also track obligations such as the EU’s NIS2 directive can use NIS2 compliance software to keep risk, incident and supplier records in one place alongside the technical controls.

Implementing zero trust in stages

No single guide fits every organisation, but credible programmes follow a similar order. NIST’s own work shows why a staged approach is necessary. The National Cybersecurity Center of Excellence worked with 24 partners to build 19 example implementations in SP 1800-35, published in June 2025. That variety shows there is no single correct build, only designs fitted to an organisation’s resources and risks.

Stage 1: Map what exists

Inventory users, devices, services, data stores and, above all, the integrations between them. Record who owns each, what identity it uses and how it authenticates. This is NCSC principle one in practice, and it is usually the most revealing step. Expect to find undocumented interfaces and shared accounts.

Stage 2: Establish identity as the control plane

Consolidate workforce identity, add strong multi-factor authentication, and give services and workloads their own identities rather than shared secrets. NIST’s experts note that zero trust depends on a robust identity architecture, strategic micro-segmentation and device health attestation to enforce granular, risk-based access.

Stage 3: Protect the highest-risk flows first

Choose a small number of high-value paths: payment or patient data APIs, partner connections, administrative access to core platforms. Put enforcement in front of them, covering authentication, authorisation, encryption and logging. Delivering a visible result here builds the case for the rest.

Stage 4: Segment and monitor

Reduce lateral movement by segmenting networks and workloads, and feed logs from gateways, brokers and identity systems into monitoring that can spot abnormal behaviour. Without visibility, policies cannot adapt.

Stage 5: Automate and govern

Move policy into code, automate certificate and credential rotation, and review access regularly. PNNL describes governance as a pervasive requirement, ensuring consistent policies and controls and dynamic updates across enterprise workflows. Assign an owner for the policy model, not just for each tool.

A caution on sequence: do not attempt to retrofit enforcement onto legacy systems that cannot support modern authentication before understanding them. Wrap them behind a gateway or proxy, or plan their replacement. That is where AI-assisted legacy system analysis can shorten the mapping stage.

Challenges to plan for

The GAO’s 2022 spotlight is candid about the limits. It identifies the lack of a widely accepted definition, difficulty integrating technologies from different vendors, and emerging governance frameworks and technical standards without consensus on how existing standards apply. It also notes that commercial zero trust products are largely mature, but implementing the architecture is a systems problem, for example integrating diverse identity, credential and endpoint technologies.

For an executive audience, that translates into four planning risks:

  • Scope drift. Without a defined target, programmes become a rebranding of every security project. Fix a pillar model and measurable outcomes.
  • Tool sprawl. Buying a product per pillar recreates the silos. Favour consistency of policy and identity over feature checklists.
  • Legacy exceptions. Every exception is a documented risk. Track them and set retirement dates.
  • User and delivery friction. Controls that slow developers or staff get bypassed. Involve the delivery teams who run the integrations from the start.

Our perspective

We have spent over 20 years engineering integrations for finance, healthcare, telecommunications and logistics clients, and the pattern is consistent: zero trust succeeds or fails in the integration layer. Security teams write the policy, but it is the APIs, brokers and middleware that carry it out, and those are often the least documented parts of an estate.

Our view is that governance should be designed in from the start, not added after go-live. That means identity for every service, policy defined once and enforced consistently across gateways and event platforms, and logging that answers an auditor’s question without a project to reconstruct it. It also means being honest about legacy: some systems can be wrapped, some must be replaced, and the first job is to know which is which.

— Polarising Team

Taking it further with Polarising

If you are planning a zero trust programme across a complex or legacy-heavy estate, our senior nearshore teams in the UK and Portugal can help with the engineering that sits underneath it: integration architecture, API and event platform security, cloud-native services and legacy modernisation. We work in regulated, high-volume environments and can scale a team up or adjust its seniority as the programme moves between stages.

Polarising

To discuss your estate, start with our enterprise integration services, or see everything we do on our solutions overview.

FAQ

What are the five pillars of zero trust architecture?

In CISA’s model they are Identity, Devices, Networks, Applications and Workloads, and Data. Visibility and analytics, automation and orchestration, and governance run across all five. Other bodies, such as the US Department of Defense, use seven pillars, so choose one model and keep to it.

What are the core principles of zero trust?

Treat every resource as protected, secure all communications, grant access per session, make decisions with dynamic policy, and continuously monitor the posture of assets. The NCSC’s eight design principles express the same ideas in a form suited to reviewing a design.

How is a zero trust network different from a traditional network?

A traditional network trusts users and devices once they are inside the perimeter. A zero trust network treats location as irrelevant and authenticates and authorises each interaction, so a compromised account or device has far less room to move.

Does zero trust apply to APIs and microservices?

Yes, and these are among the most important places to apply it. Each call should be authenticated and authorised, traffic encrypted and activity monitored. NIST describes API gateways and service meshes as ways to deliver these controls consistently.

Can we adopt zero trust without replacing legacy systems?

Often, yes, in stages. Map the legacy systems first, then wrap them behind gateways or proxies that enforce modern authentication, and set retirement dates for those that cannot support it.

Sources