Services / Zero Trust Architecture & Identity Centric Security
Zero trust is not a product. It is not a network appliance, a vendor platform, or a compliance checkbox. It is an architectural principle: never trust, always verify. No user, device, network location, or service is trusted by default. Every access request is authenticated, authorised, and continuously validated against current context before access is granted — regardless of whether the request originates inside or outside the network perimeter. The perimeter is not the boundary of trust. Identity is.
The enterprise IT environment that perimeter security was designed to protect no longer exists. Users work from anywhere on devices the organisation may or may not manage. Applications run in public cloud, private cloud, and on-premises simultaneously. Data moves between environments continuously. The concept of a trusted internal network — the foundational assumption of firewall-based security — was outdated before remote working made it untenable, and before adversaries demonstrated that lateral movement inside an assumed-trusted network is trivially achievable once initial access is established. The SolarWinds, Colonial Pipeline, and NHS WannaCry incidents all involved adversaries exploiting implicit trust that perimeter security provided no meaningful protection against.
This service designs and specifies zero trust architecture for organisations transitioning from perimeter-based security: identity and access management architecture grounded in continuous verification, device health attestation, microsegmentation of network access, least-privilege access control applied to every resource, and the telemetry and analytics infrastructure required to enforce dynamic access policies that respond to changing context. It also addresses the implementation reality that no organisation reaches zero trust in a single programme — the roadmap must account for the legacy systems, the inherited trust relationships, and the operational dependencies that cannot be eliminated immediately, and must provide meaningful security improvement at each stage rather than deferring security benefit to a theoretical completed state.
Price Range
£32,000 – £320,000+
Architecture design, maturity assessment, roadmap, and implementation specifications. Infrastructure implementation by your engineering and security teams is additional.
Architecture design, maturity assessment, roadmap, and implementation specifications. Infrastructure implementation by your engineering and security teams is additional.
Duration
8 – 24 weeks
Architecture and roadmap phase. Full zero trust implementation is typically a 2–5 year programme; the roadmap sequences it for meaningful security improvement at each stage.
Architecture and roadmap phase. Full zero trust implementation is typically a 2–5 year programme; the roadmap sequences it for meaningful security improvement at each stage.
Standards
NCSC Zero Trust Architecture guidance · NIST SP 800-207 · CISA Zero Trust Maturity Model · UK Government Zero Trust mandate (GDS) · DORA ICT risk management · ISO 27001:2022
Vendor neutral
No commercial relationships with Microsoft, Google, Okta, Zscaler, Palo Alto, CrowdStrike, or any zero trust platform vendor. Architecture recommendations are based on fit to your environment, not on vendor relationships.
Contract
Fixed-price. 50% on signing, 50% on delivery acceptance.
Zero trust is a destination, not a product purchaseEvery major security vendor now sells products marketed as “zero trust.” Buying a zero trust network access product, a zero trust identity platform, or a zero trust edge service does not produce a zero trust architecture. These products are components that may contribute to a zero trust architecture if they are designed, integrated, and operated within a coherent architectural framework. Without the framework, the products produce a more complex perimeter-security system with zero trust branding. The architecture is what this service produces. The products are what you buy after the architecture defines what is needed.
What Zero Trust Actually Requires — The Seven Pillars
Seven architectural components. Each one represents a domain of trust that must be managed explicitly rather than assumed. Missing any one of them leaves an implicit trust relationship that an adversary will find.
The NCSC’s zero trust architecture guidance and CISA’s Zero Trust Maturity Model both describe zero trust in terms of pillars or domains that must each be addressed. Organisations that address identity but not devices have users who are continuously verified but on devices that could be compromised. Organisations that address devices but not networks have hardened endpoints communicating over paths that provide no visibility. Zero trust is a system property, not a component property — it requires all seven domains to function at an appropriate maturity level simultaneously.
Pillar 1
Identity — The Primary Security Perimeter
In a zero trust architecture, identity is the control plane. Every request for access is evaluated against the identity making it: who the user is, what groups and roles they belong to, whether they have authenticated strongly, when they last authenticated, and whether their account is behaving consistently with their baseline pattern. Identity includes not just human users but also service accounts, API clients, automated processes, and workloads — every entity that requests access to a resource has an identity that must be managed and verified.
What adequate identity management requires
Phishing-resistant MFA (FIDO2/WebAuthn) for all human users — TOTP-based MFA is increasingly inadequate against adversary-in-the-middle phishing. Passwordless authentication for modern workloads. Centralised identity governance with automated provisioning and deprovisioning. Just-in-time privileged access with time-bounded elevation rather than standing privileges. Regular access reviews and certification. Federated identity for third-party users and partners. Service identity for non-human workloads using short-lived credentials rather than long-lived service account passwords or API keys.
The most common gap found in assessments
Standing privileged access: administrators with permanent elevated privileges whose accounts are high-value targets and whose access is not time-bounded or monitored with sufficient granularity. Service accounts with static long-lived credentials that have not been rotated in months or years. Users who have accumulated role assignments across multiple identity changes without a clean review. Legacy applications that cannot support modern MFA and that retain password-only authentication as a permanent exception.
Pillar 2
Devices — Endpoint Health as an Access Condition
In a perimeter model, devices inside the network are trusted. In a zero trust model, devices must earn trust by demonstrating health: they run a supported OS version, they have current security patches, their endpoint protection is active and up to date, they are enrolled in device management, and they have not exhibited indicators of compromise. Device health is a dynamic attribute of access decisions — a device that was healthy at 9am may not be healthy at 11am after a security tool fails or a suspicious process is detected. Access decisions must reflect current device state, not the state at last login.
What device trust requires
Device inventory with authoritative records of all devices authorised to access organisational resources. MDM/UEM enrolment for managed devices with compliant configuration enforcement. Endpoint Detection and Response (EDR) deployment across all managed endpoints. Device compliance policy that gates access: a device that does not meet the compliance standard (patched, enrolled, EDR active) is denied access to protected resources regardless of the user’s identity. Conditional access policies that enforce device compliance at the identity provider level. BYOD architecture that separates organisational data from personal device storage.
The most common gap found in assessments
Unmanaged devices with full network access: contractor laptops, personal devices used for work, IoT devices, and operational technology systems that are on the network but not enrolled in device management and not subject to compliance policy. These devices have the same network-level access as managed devices because device compliance is not enforced at the network layer. An adversary who compromises an unmanaged device has network access equivalent to a managed endpoint.
Pillar 3
Networks — Microsegmentation Replacing Implicit Trust
A flat network where any authenticated user or device can communicate with any other resource is not a zero trust network regardless of how strong the authentication at the perimeter is. Once an adversary has established a foothold on a single endpoint inside a flat network, they can move laterally to any other resource without encountering additional authentication or authorisation. Microsegmentation divides the network into segments where east-west traffic between segments requires explicit authorisation — a compromised endpoint in the user VLAN cannot directly communicate with a database server in the data tier without traversing a policy enforcement point.
What network zero trust requires
Software-defined perimeter or microsegmentation that restricts east-west traffic between workloads based on identity and policy rather than network topology. Application-layer segmentation: workloads communicate on a per-port, per-protocol basis rather than having full IP-level connectivity. DNS-based and service mesh-based access control for microservices environments. ZTNA (Zero Trust Network Access) to replace VPN for remote access: users connect to specific applications rather than to the network, and their access is brokered by a policy engine that evaluates identity and device health at each connection. Encrypted communications between all workloads, including east-west internal traffic.
The most common gap found in assessments
Flat internal network with VLANs as the only segmentation: VLANs segment broadcast domains, not access control. A compromised endpoint in a VLAN can communicate with any other device in the same VLAN, can attempt connections to other VLANs where firewall rules allow it, and can access network resources that no explicit policy permits because no explicit policy denies them. The implicit allow for intra-VLAN traffic is the lateral movement path that most incident investigations find was used for propagation.
Pillar 4
Applications — Application-Level Access Control
Zero trust access to applications means that users access specific application functions with specific permissions, not that they access a network on which the application resides. The access decision is made at the application layer: this user, on this device, with this current risk score, is authorised to access this specific function of this application, and not any other function they have not been granted. Application-layer access control requires applications to understand identity context — which legacy applications do not — and provides the granularity necessary to implement least-privilege access meaningfully rather than at the coarse level of “can access the application.”
What application zero trust requires
Application integration with the identity provider for authorisation, not just authentication. Role-based and attribute-based access control implemented at the application layer rather than controlled by network location. API security: every API endpoint is an access control boundary with its own authentication and authorisation requirements. Secrets management: applications retrieve credentials from a secrets management system at runtime rather than storing them in configuration files, environment variables, or code. Legacy application proxy: for applications that cannot be modified, an application proxy enforces identity-based access control in front of the application.
The most common gap found in assessments
Internal applications accessible to all authenticated network users: any user with network access can access the application because the application trusts the network rather than verifying the user’s access rights independently. Internal APIs with no authentication: REST APIs on internal servers that require only network access (being on the right network segment) and return sensitive data to any requester. Hardcoded credentials in application code or configuration that cannot be rotated without a code deployment.
Pillar 5
Data — Protection at the Data Layer, Not the Perimeter
Zero trust data protection means that data is protected by controls attached to the data itself — classification, encryption, and access policy that travels with the data rather than being imposed by the perimeter surrounding it. Data in transit between services should be encrypted end-to-end. Data at rest should be encrypted with access to the encryption keys controlled by policy. Sensitive data should be labelled and the label should drive DLP policy, retention policy, and access logging. Data accessed outside the organisational context — on personal devices, in personal cloud storage, in email to external recipients — should trigger the DLP controls that prevent loss rather than relying on the user’s judgment.
What data zero trust requires
Data classification scheme with automated classification tooling that applies sensitivity labels to documents and emails at creation. DLP policies that enforce controls based on classification: classified documents cannot be sent to external email, cannot be uploaded to non-approved cloud storage, cannot be printed on unmanaged devices. Encryption of data at rest in all storage systems, with key management policies that restrict key access to authorised identities. Data access logging at sufficient granularity to detect inappropriate access patterns. Rights management for documents that must remain protected when shared externally.
The most common gap found in assessments
Unclassified sensitive data: most organisations have sensitive data that has never been classified because the classification process was too burdensome or was applied only to new documents. Historical data — the most sensitive data, typically — has no classification labels and is therefore outside all DLP policies. An adversary who exfiltrates a large archive of unclassified historical data may have taken the most sensitive material in the organisation’s possession without triggering any DLP alert.
Pillar 6
Visibility & Analytics — Continuous Monitoring for Dynamic Trust
Zero trust requires that access decisions reflect current context, not the context at the point of authentication. A user who authenticated with strong MFA this morning but whose account then sent 47 emails to an external address with attachments has a different current risk score than when they authenticated. Dynamic trust requires telemetry from all five preceding pillars: identity signals (authentication events, MFA failures, access patterns), device signals (EDR alerts, compliance status changes, unusual processes), network signals (unusual traffic volumes, new connections to uncommon destinations), application signals (unusual data access patterns, privilege escalation attempts), and data signals (DLP alerts, bulk downloads, unusual external sharing). This telemetry must be aggregated and analysed to produce a risk signal that policy enforcement points use in real time.
What visibility and analytics requires
SIEM or XDR platform that aggregates signals from all five other pillars into a unified view. UEBA (User and Entity Behaviour Analytics) that establishes behavioural baselines and detects anomalous deviations. Integration between the analytics platform and the policy enforcement points so that a high-risk signal triggers adaptive access policy (step-up authentication, session termination, access restriction) automatically rather than requiring manual intervention. Log retention and immutability for forensic investigation. Mean time to detect (MTTD) and mean time to respond (MTTR) as tracked operational metrics.
The most common gap found in assessments
Log collection without analysis: organisations collect logs from identity, endpoint, and network systems but do not have the correlation or analytics capability to turn them into actionable signals. The logs exist. The attack is in the logs. No one is reading the logs systematically because there is no SIEM, or the SIEM is not tuned, or the SIEM generates so many alerts that analysts have become alert-fatigued and are dismissing everything. Telemetry without analysis is storage cost, not security capability.
Pillar 7
Automation & Orchestration — Policy Enforcement Without Human Delay
The dynamic access control that zero trust requires cannot be implemented manually. If a high-risk signal requires a human to review and decide whether to terminate a session or restrict access, the decision will arrive minutes or hours after the signal. The adversary will have completed their objective during the response window. Zero trust requires that policy enforcement is automated: defined policies are applied by the policy enforcement point in real time as the risk context changes. This requires the governance to define those policies precisely enough to be implemented in software, and the engineering to implement them reliably without false positive rates that break legitimate business processes.
What automation and orchestration requires
Policy engine that evaluates access requests against current context and enforces the outcome without human intervention. Adaptive access policies: if a user’s risk score exceeds a threshold, require step-up MFA; if it exceeds a higher threshold, terminate active sessions; if a device loses compliance, revoke access immediately. SOAR (Security Orchestration, Automation, and Response) for incident response: playbooks that execute the first N steps of incident response automatically, reducing MTTR for the most common incident types. Infrastructure-as-code for security policy: access policies are defined in version-controlled code, reviewed through the same process as application code, and deployed through tested pipelines.
The most common gap found in assessments
Manual response processes that cannot scale to the alert volume: security operations teams that receive 3,000 alerts per day and have capacity to investigate 50. The 2,950 uninvestigated alerts include the adversary’s activity. Manual response to account takeover indicators that takes hours while the adversary exfiltrates data. No automated revocation of access when an offboarding ticket is raised — departed employees’ accounts remaining active for days or weeks because the deprovisioning process requires manual steps that are not consistently completed.
Pillar 8
Governance & Assurance — Continuous Verification of Control Integrity
Zero trust is not a static architecture but a continuously enforced and continuously validated control system. Governance ensures that the policies, controls, and enforcement mechanisms defined across identity, devices, networks, applications, data, visibility, and automation are not only implemented but remain effective, aligned with organisational risk appetite, and legally compliant over time. Assurance transforms zero trust from a design into an operational reality by validating that controls behave as intended under real-world conditions, including adversarial scenarios, organisational change, and system evolution. Without governance and assurance, zero trust degrades into a collection of point-in-time configurations that drift, weaken, and eventually fail under pressure.
What governance and assurance requires
Formal security governance framework aligned to recognised standards (ISO 27001, NIST, CIS) with clearly defined control ownership and accountability. Continuous control validation through automated testing, red teaming, and adversary simulation (BAS — Breach and Attack Simulation). Policy lifecycle management: definition, approval, implementation, monitoring, and periodic review with measurable effectiveness criteria. Independent audit capability — internal and external — with traceable evidence of control operation. Regulatory alignment for data protection, financial controls, and sector-specific obligations. Metrics-driven oversight: control effectiveness KPIs, risk reduction indicators, and executive-level reporting that ties security posture directly to business risk.
The most common gap found in assessments
Controls assumed to be effective without validation: organisations deploy identity policies, segmentation rules, or DLP configurations and assume they work as designed without testing them against realistic attack paths. Policy drift over time due to exceptions, emergency changes, and undocumented adjustments that accumulate without review. Lack of ownership: no single accountable entity for verifying that a control continues to operate effectively. Compliance treated as a periodic checkbox exercise rather than continuous assurance, resulting in environments that are “compliant on paper” but operationally vulnerable. Absence of adversarial testing means that control failures are first discovered during real incidents rather than controlled simulations.
How “Zero Trust” Implementations Fail
Eight ways organisations declare zero trust complete while the underlying architecture remains perimeter-based. Each one represents a significant residual risk that a motivated adversary will exploit.
The most dangerous outcome of a zero trust programme is not failure to implement — it is the belief that implementation is complete when it is not. An organisation that knows it has not yet implemented zero trust will prioritise the gap. An organisation that believes its zero trust implementation is complete but has left the eight gaps below will not. These are not edge cases of organisations doing poor work. They are consistent patterns found across organisations that have genuinely invested in zero trust programmes led by capable teams, because the gaps are not visible without a structured assessment against the full seven-pillar model.
01
ZTNA is deployed for remote access but VPN remains for “legacy applications”
Zero Trust Network Access (ZTNA) provides application-level remote access without putting users on the corporate network. It is the correct replacement for VPN in a zero trust model. But ZTNA requires applications to be proxied or integrated, which takes time and sometimes is not feasible for legacy applications that cannot support modern authentication. The common compromise: ZTNA for new applications, VPN retained for legacy applications. The result: remote access to the corporate network is preserved for legacy application access, which means network-level access is still available to any user with VPN credentials. The lateral movement surface eliminated by ZTNA is reintroduced through the VPN exception.
What an adversary does with this gap
The adversary phishes VPN credentials from any user who has the legacy application exception — which is typically a broad population because “legacy application” categories expand over time as new applications fail the ZTNA integration test. VPN access provides full network connectivity. The attacker is inside the perimeter with no additional barriers, regardless of what the ZTNA deployment says about zero trust progress.
Architectural approach that addresses this
Legacy application access architecture: for applications that cannot support ZTNA integration, publish the application through an application proxy (not through the corporate network via VPN). The proxy handles authentication and access control; the application does not need to understand identity. If proxying is not feasible, the legacy application is isolated in a network segment accessible only from managed devices with device compliance verification, not from the general VPN network. VPN is eliminated from the remote access architecture rather than preserved as an exception category that grows over time.
02
MFA is deployed but is phishable SMS or TOTP
Multi-factor authentication reduces account takeover risk significantly for most attack scenarios. But adversary-in-the-middle (AiTM) phishing attacks — which are now widely deployed by criminal and nation-state actors using readily available toolkits like Evilginx and Modlishka — proxy authentication in real time, relaying the user’s credentials and TOTP code to the real service while establishing their own authenticated session. SMS-based MFA is additionally vulnerable to SIM swapping. An organisation that has deployed MFA broadly using SMS or TOTP-based authenticators has significantly improved its security against low-sophistication attacks but remains vulnerable to the AiTM attacks that nation-state and sophisticated criminal actors use against high-value targets.
What AiTM phishing looks like in practice
The adversary sends a phishing email with a link to a convincing login page that proxies the real identity provider. The user enters their username, password, and TOTP code. The proxy relays these to the real identity provider in real time and captures the session token issued after successful authentication. The user sees a successful login (then a “something went wrong” page). The adversary has the session token and accesses the account. The MFA deployment did not prevent the account takeover because TOTP provides no protection against session token theft in real-time proxying attacks.
Architectural approach that addresses this
Phishing-resistant MFA: FIDO2/WebAuthn authentication (hardware security keys or platform authenticators like Windows Hello, Touch ID) that are cryptographically bound to the origin URL. A FIDO2 credential registered for login.contoso.com will not authenticate against a proxied page at login.contoso-security.com because the origin does not match. AiTM attacks that work against TOTP do not work against FIDO2. Migration path: FIDO2 for high-risk users and privileged accounts first, then broad rollout to all users as the rollout demonstrates no significant usability barriers.
03
Conditional access policies exist but have so many exceptions that they are not enforced for the majority of access
Conditional access policies that require device compliance and phishing-resistant MFA for all resource access are the enforcement mechanism for zero trust identity and device controls. In practice, these policies are created and then exceptions are added: specific applications are excluded because they do not support modern authentication, specific users are excluded because their devices are not enrolled, specific locations are excluded because a business traveller reported a problem. Each exception is reasonable individually. In aggregate, an organisation that has added 60 exceptions to a conditional access policy may find that the exceptions cover a larger access population than the policy covers.
How exceptions accumulate
An organisation’s conditional access policy requires device compliance for all access. Over 18 months: 14 applications are excluded because they use basic authentication that does not work with conditional access. 23 users are excluded because their personal devices are used for work and cannot be enrolled in MDM. 3 service accounts are excluded because they are used by applications that do not support modern authentication. 5 B2B partner accounts are excluded because they are in a federated tenant that cannot enforce device compliance. The policy has 45 exceptions. The policy covers 60% of identity-authenticated access. 40% of access occurs through exceptions that bypass all zero trust controls.
Architectural approach that addresses this
Exception governance: every conditional access exception is documented with a named owner, a review date, and the specific reason. Exceptions are reviewed quarterly and eliminated when the underlying blocker is resolved. Applications that require basic authentication exceptions are deprecated or migrated to modern authentication on a defined timeline. The exception list is treated as a risk register item reported to the CISO — not a configuration detail managed by the identity team without security leadership visibility.
04
Microsegmentation is implemented for north-south traffic but not east-west
North-south segmentation — controlling what enters and exits the network perimeter — has been practiced for decades through firewalls. Zero trust network controls require east-west segmentation: restricting communication between workloads inside the perimeter. Most organisations that have implemented network segmentation have focused on perimeter controls and have left east-west traffic within network segments largely unrestricted. Once an adversary has established a foothold inside a network segment, they have free communication with every other resource in the same segment. Lateral movement from a compromised development workstation to a production database in the same network segment — because both are on the “internal servers” VLAN — is not prevented by any perimeter control.
What inadequate east-west segmentation enables
The ransomware attack pattern: initial access via phishing, privilege escalation on the compromised endpoint, lateral movement via network shares and SMB to other workstations in the same VLAN, credential harvesting from memory and domain controller, deployment of ransomware across all accessible systems. At each stage, the adversary uses the implicit trust of east-west traffic — no policy prevents a workstation from connecting to another workstation on the same VLAN. The attack pattern requires no vulnerability exploitation of the network layer; it exploits the absence of east-west access control.
Architectural approach that addresses this
Workload microsegmentation: host-based firewalling policies that restrict what each workload can communicate with, not just where it is in the network topology. Identity-based microsegmentation in cloud environments using security groups with explicit allow rules: each workload only communicates with the specific workloads that have a legitimate operational relationship with it. SMB and RDP restricted between workstations: these protocols are the primary lateral movement paths and have no legitimate business requirement to be open between peer workstations. Service mesh for microservices environments with mutual TLS between services and policy-based authorisation at the service level.
05
Service accounts and non-human identities have no lifecycle management
Human user identity governance has matured significantly in most organisations: accounts are provisioned when employees join, modified when roles change, and deprovisioned when they leave. Service accounts — the machine identities used by applications, automation, CI/CD pipelines, and integrations — receive none of this governance in most organisations. Service accounts are created to meet an immediate need, assigned broad permissions to avoid debugging permission errors, and then forgotten. They accumulate over years: accounts for applications that no longer exist, accounts with permissions far exceeding their actual needs, accounts using credentials that have never been rotated, accounts that no one owns. Service accounts are the highest-value targets for lateral movement because they typically have network-level service access, often with administrative permissions, and are not monitored with the same scrutiny as human accounts.
The service account inventory finding in assessments
A typical enterprise assessment finds: service account credentials in plaintext in configuration files across multiple servers, service accounts with domain administrator privileges that were provisioned for a one-time task and never deprivileged, service accounts for decommissioned applications that retain active credentials and broad permissions, and service accounts whose passwords have not been changed in over 3 years. At least one of these credentials will appear in a dark web credential dump if the organisation has experienced any breach in that period.
Architectural approach that addresses this
Service account inventory and governance programme: enumerate all service accounts, identify their owners, review their permissions against least privilege, and establish a rotation schedule. Managed service accounts and group managed service accounts (gMSA) for Windows services that automate password rotation. Workload identity federation using short-lived tokens (OIDC, managed identities) instead of long-lived credentials wherever modern infrastructure supports it. Secrets management platform (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) that provides dynamic credentials with automatic rotation and audit logging. Privileged access workstations (PAW) for administrative access that prevent credential reuse across privilege levels.
06
Cloud environments have permissive IAM configurations that undermine on-premises zero trust controls
Organisations that have invested in zero trust controls for their on-premises environment frequently find that their cloud environments — adopted quickly and often by teams without strong IAM expertise — have permissive IAM configurations that bypass the controls they have built. IAM roles with wildcard permissions, storage buckets accessible to any authenticated user in the organisation, service accounts with project-owner permissions, cloud functions with overly broad execution roles, and API keys stored in code repositories are consistently found in cloud environments of organisations that have achieved significant zero trust maturity in their on-premises environment. The adversary who cannot penetrate the on-premises zero trust controls looks for the cloud accounts with overpermissioned IAM and attacks those instead.
Cloud IAM misconfigurations found consistently in assessments
In a recent sector-typical assessment: 14 IAM roles with “administrator” or equivalent permissions assigned to service principals that required only read access. 7 storage containers with public access enabled containing internal documentation. 3 cloud function execution roles with permissions to read from all storage containers in the project. API keys in a public GitHub repository’s commit history that had not been rotated since the accidental commit 8 months previously. Each of these provides a foothold that bypasses all on-premises zero trust controls.
Architectural approach that addresses this
Cloud security posture management (CSPM) tooling that continuously scans cloud IAM configurations against best practice and alerts on overpermissioned roles, public access settings, and privilege escalation paths. IAM governance integrated into the cloud provisioning pipeline: IAM changes require review and approval, and wildcard permissions are automatically rejected. Least-privilege IAM as a design standard with specific permission sets per workload type rather than inherited broad roles. Regular IAM access reviews for cloud environments on the same cadence as on-premises access reviews.
07
OT and IoT environments are excluded from zero trust scope because “they’re too different”
Operational technology (OT) systems — industrial control systems, building management systems, SCADA — and IoT devices are frequently excluded from zero trust programmes on the grounds that they cannot support modern authentication, cannot run endpoint security agents, and have different operational constraints from IT systems. This is partly true: OT systems often cannot be modified. It is not a justification for exclusion from the zero trust architecture. Excluded OT and IoT systems have network connectivity that provides a lateral movement path from the IT network. Industrial attacks (Industroyer, Triton, Colonial Pipeline) consistently use the IT-OT boundary as the attack path. The OT environment cannot be brought to zero trust maturity quickly — but it cannot be ignored.
The IT-OT boundary as an attack path
The Colonial Pipeline attack: initial access via a legacy VPN account, lateral movement from the IT network to the OT network across a poorly controlled IT-OT boundary, shutdown of the OT environment as a precautionary measure because the OT environment’s security state was unknown. The security decision to shut down the pipeline was made because the organisation did not have sufficient visibility into the OT environment to determine whether it had been compromised. The zero trust gap was not in the OT environment’s inability to support modern authentication — it was in the absence of monitoring and segmentation at the IT-OT boundary.
Architectural approach that addresses this
OT/IT boundary segmentation: the IT-OT boundary is the most critical network segmentation boundary in environments with OT systems. Strict control of all communication paths across this boundary, with all IT-to-OT and OT-to-IT traffic explicitly authorised and monitored. OT network visibility: passive network monitoring (asset discovery, traffic baselining, anomaly detection) that does not require agents or active probing of OT systems. Purdue model or ISA/IEC 62443 segmentation as the OT network architecture standard. Demilitarised zone (DMZ) architecture for any data flows between IT and OT systems with explicit data diodes or firewalls rather than routed connectivity.
08
Zero trust architecture is implemented but not maintained — policy drift reintroduces implicit trust over time
Zero trust is not a state that is reached and then preserved without effort. It requires continuous maintenance: access reviews as roles change, exception governance as new exceptions are requested, policy updates as new applications and services are introduced, microsegmentation updates as new workloads are deployed, credential rotation for service accounts, and monitoring tuning as the threat landscape evolves. Organisations that implement zero trust architecture and then reduce the operational investment required to maintain it will find that policy drift — accumulating exceptions, unreviewed access rights, unrotated credentials, unmonitored new services — progressively reintroduces implicit trust. The architecture remains in place. The effective security it provides degrades.
What policy drift looks like at 24 months post-implementation
An organisation achieves CISA Maturity Level 3 (Advanced) across all five pillars at 12 months post-implementation. At 24 months: conditional access exception count has grown from 12 to 67 as new applications were added without proper modern authentication implementation. 34 new service accounts have been created, 22 without going through the secrets management process. 8 new cloud workloads have been deployed without CSPM review and have permissive IAM. The zero trust architecture is intact; the policy governance that makes it effective has not kept pace with organisational change.
Architectural approach that addresses this
Zero trust governance programme: quarterly access reviews, monthly exception reviews, annual maturity re-assessment against the CISA or NCSC maturity model, continuous CSPM monitoring with breach notification into the security operations workflow, automated detection of new services that have not gone through the zero trust onboarding process, and zero trust onboarding checklist for all new application and service deployments. The governance programme is specified in the architecture engagement and is the mechanism that makes the architecture durable rather than a point-in-time implementation.
Engagement Types — Scope, Price, Timeline
Three engagement types. Maturity assessment, target architecture design, and full enterprise programme.
All three engagements begin from an honest assessment of the current state. Zero trust architecture cannot be designed for a starting point that is not accurately understood. Organisations that believe they are at a higher zero trust maturity than they are will receive an architecture designed to close gaps they do not believe they have — and will not implement it because they do not believe it is necessary. Implementation of the architecture — deploying identity platforms, implementing ZTNA, configuring microsegmentation, deploying SIEM — is performed by your engineering and security teams or by an implementation partner from our specifications and roadmap.
Engagement Type 1
Zero Trust Maturity Assessment
For organisations that want to understand their current zero trust maturity position before committing to an architecture programme. The assessment maps the current state across all seven pillars against the NCSC and CISA maturity models, identifies the gaps between current state and the target maturity level, and produces a prioritised gap report that enables informed decisions about where to invest. Can be engaged as a standalone assessment or as the first phase of a Type 2 or Type 3 programme (in which case the assessment fee is credited against the subsequent engagement).
£32,000
Fixed · VAT excl. · credited if proceeding
6 weeksDepends on estate complexity and the availability of the identity, network, and security teams for assessment interviews and evidence review.
Assessment Coverage
Identity: MFA deployment coverage and type, conditional access policy completeness and exception volume, service account governance, privileged access management maturity
Devices: device inventory completeness, MDM/UEM enrollment coverage, EDR deployment, compliance policy enforcement, unmanaged device access controls
Networks: segmentation architecture, east-west traffic controls, ZTNA or VPN usage for remote access, OT/IT boundary architecture, encrypted traffic coverage
Applications: legacy application authentication, API security posture, secrets management, application-level access control granularity
Data: classification coverage, DLP policy completeness, encryption at rest and in transit, rights management deployment
Visibility and analytics: log collection coverage, SIEM/XDR maturity, UEBA capability, alert fidelity and analyst workload
Automation and orchestration: adaptive access policy automation, SOAR deployment, infrastructure-as-code for security policy, automated deprovisioning
Assessment Methods
Structured interviews with the identity team, network security team, endpoint team, and security operations team — the seven-pillar framework applied to each team’s area
Evidence review: conditional access policy configuration, network segmentation diagrams, device inventory, exception registers, SIEM configuration, and access review records
Technical validation: active review of identity provider configuration, conditional access policy testing against the exception categories, network access from test devices in specific segments
Cloud posture review: CSPM output review for the organisation’s cloud environments, IAM role analysis for privilege creep and wildcard permissions
Maturity scoring: NCSC zero trust maturity levels (Initial, Advanced, Optimal) per pillar with specific evidence for each rating
Assessment Outputs
Maturity scorecard: current maturity level per pillar with the specific evidence for each score and the specific gaps preventing a higher score
Gap register: every identified gap with its severity (critical/high/medium/low), the residual risk it represents, and the effort required to close it
Priority matrix: which gaps to close first based on the combination of severity and implementation effort — the quick wins that provide meaningful security improvement with low effort, and the long-term investments that address the highest-severity gaps
Executive summary: maturity position communicated for board and CISO audience, with benchmarking against sector peers where available from published data
30-day advisory support: questions about the findings answered within 1 business day
The most common finding that surprises leadershipThe gap between believed maturity and assessed maturity. Organisations typically self-assess at one maturity level higher than the structured assessment finds, because the gap between deploying a technology and operating it effectively is not visible without a detailed configuration review. An organisation that has deployed conditional access believes it has a zero trust identity posture. The assessment finds 60 exceptions, 40% of which have no review date and 15% of which cover the highest-risk access paths. The technology is deployed. The security control is not effective.
What Your Team Must Provide
Access to the identity team lead, network security lead, endpoint security lead, and security operations lead for 90-minute assessment interviews each — the assessment requires their direct input, not a written response to a questionnaire
Read-only access to identity provider configuration (Entra ID, Okta, or equivalent), conditional access policy export, and cloud IAM configuration — the assessment cannot be conducted from documentation alone
Network architecture documentation: current network segmentation topology, firewall rule review access, and VLAN/segment design documentation
Security operations: SIEM configuration, current alert volume, and the exception register for all zero trust policy exceptions if one exists
What Is Not in This Engagement
Target architecture design: the assessment identifies the gaps; the architecture that closes them is the subject of Type 2 or Type 3
Penetration testing: the maturity assessment reviews configuration and architecture; it does not conduct active penetration testing of the controls found. See Cybersecurity & Resilience for penetration testing.
Implementation recommendations for specific vendor products: the assessment identifies capability gaps, not product choices; product selection is part of the architecture engagement
Engagement Type 2
Zero Trust Target Architecture & Implementation Roadmap
For organisations that have completed a maturity assessment (Type 1 or equivalent prior work) and are ready to design the target architecture and the roadmap to achieve it. The target architecture specifies what the zero trust environment looks like across all seven pillars at the defined target maturity level. The roadmap sequences the implementation in a way that delivers meaningful security improvement at each stage rather than deferring benefit to a theoretical completion, accounts for the legacy systems and operational dependencies that cannot be eliminated immediately, and provides the implementation specifications that engineering and security teams execute from.
£85,000
Fixed · less £32k Type 1 credit · VAT excl.
14 weeksIdentity and network architecture phases are typically the longest, as they require validation sessions with the teams that own those environments.
Target Architecture
Identity architecture: target state for identity governance, MFA strategy (FIDO2 migration roadmap), conditional access policy design (no exceptions by design), privileged access management architecture, service identity and secrets management architecture
Device architecture: target device management posture, compliance policy design, EDR architecture, BYOD segmentation design, unmanaged device access model
Network architecture: microsegmentation design for the specific environment (cloud, on-premises, hybrid), ZTNA architecture replacing VPN, legacy application access proxy architecture, OT/IT boundary architecture
Application and data architecture: application-level access control design, secrets management implementation, data classification and DLP architecture
Security operations architecture: SIEM/XDR platform selection recommendation, UEBA integration design, adaptive access policy automation, SOAR playbook framework
Vendor and product recommendations: technology selection recommendations for each architecture component — vendor-neutral, based on fit to the specific environment and existing investments
Implementation Roadmap
Phase sequencing: 3–5 implementation phases sequenced to deliver maximum risk reduction at each stage, with explicit rationale for the sequencing decisions
Quick wins: the highest-impact, lowest-effort improvements identified for immediate implementation — typically 5–10 changes deliverable within 30 days that significantly reduce the most critical gaps
Legacy system handling: specific approach for each legacy system that cannot immediately support zero trust controls — isolation, proxy, exception governance, or replacement schedule
Dependencies map: which implementation steps depend on others, and which can proceed in parallel across different teams
Effort and resource estimates: the engineering and security resources required per phase, to enable resourcing decisions before implementation begins
Security benefit per phase: the specific risk reduction each phase delivers, to enable phasing decisions based on security value rather than implementation convenience
Implementation Specifications
Conditional access policy specifications: every policy, its conditions, its grant controls, and its session controls — ready for implementation in Entra ID, Okta, or the organisation’s identity provider
Microsegmentation specifications: the specific firewall rules, security group policies, or service mesh configuration for the target segmentation architecture
ZTNA deployment specification: the application list, access policies, and user assignment for the ZTNA implementation
Secrets management implementation specification: the platform configuration, secret rotation policies, and application integration requirements
Zero trust governance programme: the operational processes — access reviews, exception governance, maturity re-assessment cadence, onboarding checklist — that maintain the architecture after implementation
60-day advisory support: implementation questions answered within 1 business day
What Your Team Must Provide
Completed Type 1 assessment or equivalent prior assessment with documented current-state architecture — the target architecture cannot be designed without an accurate current-state baseline
Technology constraints: existing vendor contracts and commitments, platform standardisation decisions, and budget parameters that constrain the technology selection recommendations
Architecture review sessions: 3 sessions of 2 hours each with the architecture team during the design phase to validate that the architecture accommodates operational requirements not captured in the assessment
Legacy system inventory: a complete list of systems that cannot support modern authentication or cannot be enrolled in device management, with the specific constraint for each
What Is Not in This Engagement
Implementation: all platform configuration, policy deployment, and infrastructure changes are performed by your engineering and security teams or an implementation partner
Penetration testing of the implemented architecture: available as a follow-on engagement to validate that the implementation delivers the intended security posture
Vendor product procurement: we produce vendor-neutral recommendations; procurement is your commercial relationship
Engagement Type 3
Enterprise Zero Trust Transformation Programme
For large or complex organisations where the zero trust transformation spans multiple business units, multiple geographic locations, multiple cloud platforms, or acquired entities at different maturity levels. Also appropriate for organisations operating under regulatory mandates with specific zero trust implementation requirements — UK Government suppliers subject to the GDS zero trust mandate, financial services firms under DORA ICT risk management requirements, or critical national infrastructure operators under NCSC guidance. The enterprise programme provides the architecture, roadmap, and governance framework for a multi-year transformation that must accommodate significant organisational and technical complexity. All enterprise engagements individually scoped.
From £180,000
Individually scoped · VAT excl.
From 20 weeksEnterprise programmes with multiple business units, M&A integration, or regulatory compliance requirements commonly run 28–36 weeks for the architecture and roadmap phase.
What Enterprise Adds
Multi-entity architecture: a unified zero trust framework that accommodates heterogeneous environments across business units or acquired entities, with a migration path for each entity to the common framework
M&A integration architecture: for recently acquired or soon-to-be-acquired entities, a zero trust integration design that does not extend the acquiring organisation’s implicit trust to the acquired entity during the integration period — the most common source of M&A-related security incidents
Regulatory compliance mapping: explicit mapping of the zero trust architecture to specific regulatory requirements — GDS zero trust mandate controls, DORA ICT risk management Article 9, NCSC cyber assessment framework, or sector-specific requirements
Multi-cloud architecture: zero trust architecture spanning AWS, Azure, GCP, and private cloud simultaneously, with a unified identity layer across environments
Programme governance design: the governance structure for the multi-year transformation — programme board, architecture governance, change management, and stakeholder communication framework
Why Enterprise Programmes Are Different
Identity federation across entities: bringing multiple Active Directory forests, multiple identity providers, or multiple Entra tenants into a coherent identity governance model is an architectural challenge that does not exist in single-entity programmes
Network architecture at scale: microsegmentation across large flat networks with hundreds of applications requires systematic application discovery and dependency mapping before segmentation rules can be designed — a significant upfront investment that smaller organisations do not need
Organisational change: a zero trust transformation changes how every user in the organisation authenticates, accesses applications, and operates on their device. Change management at enterprise scale requires dedicated communication, training, and support resources that are programme costs
Executive alignment: a multi-year security transformation programme requires sustained executive commitment and board-level reporting. The programme governance framework must provide the reporting structure that maintains this commitment across leadership changes
Enterprise Requirements
Named CISO-level programme sponsor with authority to mandate security changes across business units
Enterprise architecture team available throughout the programme for technical validation
Business unit representatives for the architecture review process — zero trust affects every business unit and their operational requirements must be incorporated
M&A integration: if the programme includes acquired entities, the acquired entity’s CISO or equivalent and documentation of their current security architecture
Regulatory counsel if the programme is driven by a specific regulatory mandate — the architecture must satisfy the regulator’s interpretation of the requirement, which may differ from the standard framework interpretation
Bilateral Obligations
Client Obligations
Current state documentation and configuration access must accurately reflect the actual production environment
The maturity assessment and architecture design are based on the actual current state of the security environment. Organisations sometimes present their intended state — the configuration they plan to implement, the policies they have documented but not deployed — rather than their actual deployed state. A conditional access policy that is documented but not enforced does not provide zero trust controls. An exception register that was accurate 6 months ago but has not been maintained does not reflect the current exception population. If the assessment is conducted on a curated presentation of the environment rather than the actual environment, the resulting architecture will close gaps that do not exist and miss gaps that do. We verify the actual configuration through direct read-only access rather than relying solely on documentation.
If the actual environment differs significantly from the documentationWe note the discrepancy explicitly in the assessment findings and treat the actual configuration as the baseline. The architecture is designed from the actual current state, not the intended state. Closing the gap between documented and actual configuration is often a significant part of the early roadmap.
The zero trust governance programme must be implemented alongside the technology changes
Zero trust architecture deteriorates without ongoing governance. Access reviews that are not conducted allow excessive permissions to accumulate. Exception registers that are not maintained allow the exception population to grow beyond the policy population. New services that are not onboarded through the zero trust checklist introduce uncontrolled access paths. The governance programme we design is not a bureaucratic overhead to be implemented after the technology changes — it is a necessary component of the architecture that maintains its security value over time. Implementing the technology without implementing the governance produces a zero trust architecture with a two-year effective lifespan before policy drift returns the environment to perimeter-security behaviour.
If the governance programme is not resourced or implementedWe document this as a programme gap. The maturity re-assessment at 12 months post-implementation will reflect the policy drift if the governance programme has not been maintained. We cannot be responsible for security outcomes from architecture components that were delivered but not operated according to the governance programme we specified.
RJV Obligations
Architecture recommendations are vendor-neutral and based on fit to the specific environment — declared conflicts of interest before any recommendation
We have no commercial relationships with Microsoft, Okta, Zscaler, Palo Alto Networks, CrowdStrike, Google, or any other vendor of zero trust platform components. Our product and vendor recommendations are based on technical fit to the specific environment: the existing infrastructure the organisation has already invested in, the skill set of the engineering and security teams, the integration requirements of the legacy systems in scope, and the performance and scalability requirements of the deployment. Where the most technically appropriate recommendation involves a vendor with which we subsequently develop a commercial relationship, we will disclose that relationship before delivering any affected recommendation. Vendor recommendations are not influenced by commercial relationships we have not declared.
If the organisation has an existing vendor relationship that constrains technology selectionWe design the architecture within those constraints and document where the constraint produces a suboptimal technical outcome relative to the unconstrained recommendation. You receive both the constrained recommendation and the unconstrained alternative, so you can assess whether the constraint is worth the trade-off.
Maturity assessment findings reported accurately — including findings that imply prior security investments were ineffective
Zero trust maturity assessments frequently find that previous security investments — MFA deployments that are not enforced, SIEM deployments that are not monitored, microsegmentation that has exceptions larger than the policy — are not delivering the security value that was claimed at the time of implementation. These findings have implications for the people who implemented those controls and for the budget decisions that funded them. We report these findings accurately rather than softening them to protect those implications. A finding that an MFA deployment is not enforced for 40% of access is reported as a critical gap regardless of the effort invested in the deployment. The accurate finding is what enables the organisation to close the gap rather than continuing to believe the gap does not exist.
If a finding is disputed by the team responsible for the assessed controlWe review the evidence together and document the disagreement if it is substantive. Findings are revised where the challenge demonstrates a technical error in the assessment. Findings are not revised in response to the discomfort of the implication. The final report notes any disputed findings and the basis for the dispute.
The assessment session answers one question directly: has your organisation bought zero trust products, or built a zero trust architecture? They are not the same thing and the difference is significant.
90 minutes reviewing your current security architecture against the seven-pillar framework: what controls are deployed in each pillar, what is actually enforced versus documented, where the highest-impact gaps are, and whether the gap profile suggests a focused remediation or a structured maturity programme. You leave with an honest preliminary view of your zero trust position — not based on which products you have purchased, but on what the controls actually do in your environment.
If you believe your zero trust implementation is complete, the assessment session is 90 minutes to validate that belief against the seven-pillar standard. If the eight failure modes above resonate with your current environment, the session identifies which ones apply and which are already addressed. Either outcome is useful. Neither requires a commitment to proceed further.
Format
Video call or in-person in London. 90 minutes.
Cost
Free. No commitment.
Lead time
Within 5 business days of contact.
Bring
What you believe your current zero trust maturity is and what evidence that belief is based on. Which of the seven pillars you have invested in and what you have deployed. Where you believe the most significant gaps are. Any previous security assessments covering your identity, network, or endpoint posture. The regulatory drivers if any (GDS mandate, DORA, NCSC guidance) and their current compliance status.
Attendees
CISO or security lead and a technical architect who understands the current identity and network configuration. Both perspectives are needed. From RJV: a senior security architect specialising in zero trust. No vendor affiliation.
After
Written preliminary maturity assessment within 2 business days. Type 1 scope and fee proposal within 5 business days if you want to proceed.