top of page
ZERO TRUST IS AN ARCHITECTURE, NOT A PRODUCT CATEGORY.
The problem
​

Zero Trust has become the most misapplied term in enterprise security. It is used to describe network segmentation projects, VPN replacements, MFA rollouts and — increasingly — whatever a vendor happens to be selling.

 

The consequence is predictable. Organisations report Zero Trust programmes at 60% completion while remaining architecturally unchanged. They have bought a ZTNA product and continue to operate implicit trust everywhere the product does not reach.

 

NIST SP 800-207 is unambiguous about what Zero Trust actually requires. Among its seven tenets: all communication is secured regardless of network location; access is granted per session; access decisions are determined by dynamic policy; and the enterprise continuously measures the integrity and security posture of all owned and associated assets.

 

Read that honestly against your environment. Most organisations that believe they are doing Zero Trust are doing improved perimeter security with better authentication. That is worth doing. It is not Zero Trust, and calling it Zero Trust means the actual work never gets scoped.

OUR APPROACH

  1. Baseline maturity honestly. Assessment across the five CISA Zero Trust Maturity Model pillars — Identity, Devices, Networks, Applications and Workloads, Data — plus the three cross-cutting capabilities of Visibility and Analytics, Automation and Orchestration, and Governance. Scored Traditional, Initial, Advanced, Optimal.

  2. Map the policy decision architecture. Where do the Policy Engine, Policy Administrator and Policy Enforcement Points sit today? In most environments the honest answer is that there is no policy engine, and enforcement is distributed across products that do not share context.

  3. Define the target architecture. Control plane and data plane separated. Enforcement points placed deliberately. Policy expressed once, enforced consistently.

  4. Scope a first wave designed to succeed. Usually third-party or privileged access — bounded, high-risk, politically defensible, and genuinely valuable. Not the whole estate.

  5. Define measurable exit criteria. If you cannot state what "done" looks like for a phase, the phase will not end.

  6. Sequence the remainder by dependency. Identity maturity gates almost everything downstream. Attempting data-layer Zero Trust before identity is coherent is how programmes stall.

ENGAGEMENTS

01. Zero Trust Readiness Assessment

Typical duration: 10-15 days

Maturity baseline across five pillars and three cross-cutting capabilities

02. Zero Trust Target Architecture & Roadmap

Typical duration: 15-25 days

Reference architecture, PE/PA/PEP placement, phased 24–36 month roadmap, business case

03. Zero Trust Pilot Design

Typical duration: 8-12 days

First-wave design with measurable exit criteria

04. ZTNA / SASE Vendor-Neutral Selection

Typical duration: 8-12 days

Requirements matrix, RFP technical annex, PoC scorecard, evaluation chairing

05. OT Zero Trust Overlay

Typical duration: 12-20 days

IEC 62443 zone and conduit model reconciled with Zero Trust principles across the Purdue reference model

FRAMEWORKS APPLIED

NIST SP 800-207 · CISA Zero Trust Maturity Model v2.0 · CSA Zero Trust guidance · NIST CSF 2.0 · IEC 62443 for OT environments

bottom of page