Skip to content
◆Service

Secure Architecture & Zero Trust

Security architecture for enterprise, cloud, and operational-technology environments, designed around Zero Trust.

Zero Trust replaces the hard edge with authorisation at every layer, using identity as the control plane. A request from inside the network earns no more trust than one from outside, which is what stops a single compromised endpoint reaching everything.

The perimeter stopped being the control boundary some time ago, but a great many networks are still built as though it were: hard at the edge, flat and trusting inside, so a single compromised laptop can reach the finance system, the domain controllers, and the backups. Zero Trust is the correction to that, and it is a design principle rather than a product. Identity becomes the control plane, every request is authorised on its merits, and the network stops being a proxy for trust.

In practice that means designing around identity and segmentation first: strong authentication, least privilege that is actually enforced rather than aspirational, policy enforcement points where traffic crosses a boundary that matters, and segmentation that assumes something inside is already compromised. Across Azure, GCP and AWS the primitives differ but the design intent does not, and hybrid estates need patterns that work consistently in both directions rather than two disconnected models.

Operational technology and critical infrastructure change the constraints rather than the principles. Availability outranks confidentiality, the equipment may predate the concept of authentication, and you cannot patch on a Tuesday because the plant does not stop. That calls for compensating design, IEC 62443-aligned zoning, and rigorous separation of IT and OT, work I have done where the consequence of getting it wrong is physical rather than financial.

You might need this if

  • A cloud migration is underway with no agreed target architecture
  • The internal network is flat enough that one compromised endpoint reaches nearly everything
  • IT and OT networks were joined for convenience and never properly separated
  • Zero Trust was purchased as a product and nothing about the architecture changed
  • Every project makes its own security decisions because there are no reference patterns

Who it's for

Organisations modernising onto cloud, securing OT and critical infrastructure, or adopting a Zero Trust strategy.

How the engagement runs

  1. 01

    Current state and target architecture

    Understand what exists, including the parts that are undocumented, and agree a target architecture with explicit trade-offs rather than an idealised diagram nobody can build.

  2. 02

    Identity and segmentation design

    Identity as the control plane, authorisation per request, and segmentation designed on the assumption that something inside the boundary is already compromised.

  3. 03

    Reference patterns and decision records

    Architecture decision records and reusable patterns your engineers can build from, so the design outlives the engagement instead of being reinterpreted per project.

  4. 04

    Assurance through delivery

    Stay involved while it is built, because architecture erodes during delivery under schedule pressure. Review the implementation against the intent and adjust where reality argues back.

What's delivered

  • Reference architecture for cloud (Azure, GCP, AWS) and hybrid estates
  • Zero Trust design using the Forrester model across identity, segmentation, and policy
  • DevSecOps integration so security ships with the pipeline
  • OT and critical-infrastructure segmentation and resilience
  • Architecture decision records your engineers can build from

Proof point

Collaborated on the security architecture for one of New Zealand's most significant infrastructure projects, critical national infrastructure with no margin for error.

Common questions

Is Zero Trust just a vendor slogan?
The marketing certainly is. The underlying model, set out in Forrester's work and NIST SP 800-207, is sound and predates the product category: authorise every request on identity and context rather than on network position. No single product delivers it, and anyone selling you one is selling a component.
Do we have to rip out our VPN?
Not immediately, and not necessarily at all. The problem with a traditional VPN is that it usually grants broad network access once connected. That can often be narrowed substantially with what you already own, which is a far cheaper first step than replacing remote access wholesale.
How does any of this apply to OT?
The principles hold, the implementation differs sharply. Availability and safety take precedence, much of the equipment cannot authenticate or be patched on a normal cycle, and the answer is usually zoning, conduits, and monitoring rather than agents on endpoints. IEC 62443 is the reference point rather than a general IT framework.
Can this be done incrementally?
It has to be. A wholesale re-architecture is neither affordable nor safe for most organisations. The usual sequence is identity first, then segmenting the highest-consequence systems, then working outward as projects create natural opportunities.

Other services

Get in touch

Let's talk about your security programme

Considering a vCISO, a security strategy and architecture, a SOC uplift, an AI assurance review, or a secure web build? Tell me where you are and where you need to get to.

Discuss an engagementaspera@antan.co.nzLinkedIn (opens in a new tab)