Zero Trust

Introduction

Zero Trust is a philosophy of constrained implicit trust. It asks organisations to stop assuming that network location, device ownership or employment status is enough to justify access.

Why It Exists

The old perimeter model became fragile as organisations adopted cloud services, remote work, supplier access, SaaS platforms and distributed delivery. Zero Trust exists because trust now has to be explicit, contextual, limited and continuously reviewable.

Historical Context

Zero Trust developed as security practitioners recognised that internal networks were no longer inherently safe. Breaches, lateral movement, unmanaged devices and hybrid infrastructure made it clear that implicit trust was creating unnecessary blast radius.

Core Principles

• Verify explicitly using identity, device, location, workload and risk context.
• Use least privilege and just-enough access.
• Assume breach and design for containment.
• Continuously monitor whether access remains justified.

Operational Interpretation

In operational terms, Zero Trust should change how people make decisions. It should influence review questions, design constraints, evidence expectations and escalation paths. If it only appears in policy documents, architecture packs or procurement questionnaires, it has not yet become part of the operating system of the organisation.

Common Misunderstandings

• Reducing Zero Trust to MFA rollout.
• Buying a product and assuming the operating model has changed.
• Ignoring service-to-service trust, privileged administration and data access.

Common Failure Modes

• Privileged accounts remain broad because operational teams fear lockout.
• Identity governance is weak, so orphaned access survives role changes.
• Network segmentation exists on diagrams but exceptions allow broad movement.
• Monitoring detects activity but ownership of response is unclear.

Relationship To Other Frameworks

Zero Trust rarely stands alone. It connects to the surrounding operating model because platforms are made of governance, delivery, security, data, people and evidence. The related topics below should be read as neighbouring disciplines rather than optional extras.

Practical Organisational Examples

• A remote workforce project becomes a Zero Trust discussion when leaders realise VPN access gives contractors broad network reach beyond the systems they support.
• A SaaS integration is redesigned so API access is scoped, logged and revocable rather than using a shared long-lived secret.
• A production support model moves from standing admin rights to just-in-time elevation with approval and audit evidence.

Worked Scenario

An organisation moves support work to a managed service provider. The quick route is to give the supplier VPN access and membership of broad support groups so incidents can be resolved quickly. It works operationally until somebody asks which production systems the supplier can reach, how access is revoked, and whether activity can be reconstructed after an incident.

A Zero Trust approach narrows the route. Access is tied to named identities, device posture, service scope, just-in-time elevation and audit evidence. The supplier can still do the job, but the organisation no longer carries the unnecessary assumption that being on the network means being broadly trusted.

Governance Implications

Governance should define where trust is granted, who can approve exceptions, how long elevated access lasts and what evidence proves controls are working. The hard part is not policy; it is maintaining access discipline when delivery pressure rises.

Delivery/Engineering Implications

Delivery teams need patterns that make secure choices practical: identity-aware proxies, service accounts with narrow permissions, secrets management, automated policy checks and rollback paths that do not require permanent broad access.

Architecture Implications

Architecturally, Zero Trust depends on explicit trust boundaries, segmentation, identity flows, telemetry and policy enforcement points. It should reduce the damage a compromised user, device, service or supplier can cause.

Evidence And Implementation Notes

The operating evidence for Zero Trust is access behaviour. Review identity lifecycle records, privileged access patterns, device posture coverage, service-to-service permissions, network paths, policy decisions and alert handling. A Zero Trust programme that cannot show who had access, why they had it, when it was reviewed and how misuse would be contained is probably still mostly aspiration.

Implementation should start where implicit trust is most dangerous: administrator access, production systems, sensitive data, supplier routes and unmanaged devices. The mistake is trying to transform every path at once. The better route is to reduce the highest blast radius first, then extend the same discipline into lower-risk areas.

The phrase Zero Trust can invite absolutism, but the real work is calibrated trust. Access is still granted. The difference is that it is explicit, scoped, monitored and easier to revoke.

Trade-offs And Tensions

Zero Trust introduces friction deliberately. That friction can be valuable when it prevents broad compromise, but harmful when it blocks legitimate operational work or drives people towards shadow access routes. The design challenge is to make secure behaviour easier than insecure workarounds.

There is tension between central policy and local operational reality. A security team may define a sensible access policy, but a production support team may need emergency access during incidents. If the model does not provide a safe emergency path, permanent broad access will return under a different name.

Zero Trust also creates architectural tension. Legacy systems may not support modern identity, fine-grained authorisation or telemetry. Treating those systems as failures can be less useful than isolating them, wrapping access and planning a transition. The aim is risk reduction, not ideological purity.

Implementation Pattern

Start with an access inventory. Identify privileged users, service accounts, supplier access, high-risk applications, unmanaged devices and sensitive data routes. Then prioritise the paths where compromise would cause the most damage.

Implement in layers: strong identity, device posture, least privilege, just-in-time access, segmentation, monitoring and review. Each layer should produce evidence. For example, privileged access tooling should show who elevated, who approved, what was accessed and when access expired.

Use exception management as part of the design. Exceptions are inevitable, especially around legacy systems and operations. The mature question is whether exceptions are visible, temporary, owned and reviewed.

What To Measure

Useful measures include privileged account count, standing admin access, orphaned accounts, supplier access age, MFA coverage, device compliance, service-account scope, policy-denial patterns and access-review completion. These measures should be interpreted by risk, not volume alone.

Incident and audit evidence matters too. Can the organisation reconstruct a privileged session? Can it show that access was revoked after role change? Can it detect unusual lateral movement? Zero Trust should make those answers easier, not merely produce another security dashboard.

When This Becomes Urgent

Zero Trust becomes urgent when implicit trust is clearly larger than the organisation’s ability to monitor or contain it. Supplier access, remote administration, legacy VPNs, broad production permissions, unmanaged devices and shared service accounts are all common triggers.

Incidents make the urgency obvious, but waiting for an incident is expensive. A better trigger is blast-radius analysis: if a compromised account or device could move widely, access assumptions need redesign. This is especially important during cloud migration and acquisition integration, where old network boundaries rarely match the new operating model.

Review evidence should include identity lifecycle data, privileged access logs, service-account inventory, device posture, network paths, segmentation exceptions, supplier access and alert response. The question is not whether the organisation has Zero Trust branding, but whether trust is explicit, limited and reviewable.

What Mature Organisations Do Differently

Mature organisations phase Zero Trust by risk. They start with privileged access, sensitive data, critical services and supplier routes, then improve coverage using evidence rather than slogans.

Where Smaller Organisations Should Simplify

Smaller organisations should begin with MFA, strong identity lifecycle, least privilege, device hygiene, admin separation and clear logging. That is not the whole model, but it reduces the most common implicit-trust failures.

Operational Review Questions

• What decision is Zero Trust meant to improve in this organisation?
• Which piece of evidence would show that it is working during normal delivery, not only during review?
• Where would teams work around it if deadlines compressed, an incident escalated or a supplier pushed back?
• Which exception would become dangerous if it quietly became normal practice?
• Which neighbouring topic changes the answer: Trust Boundaries, Architectural Segmentation, NIST SP 800-53 Rev. 5?

Signals To Look For

A useful review looks for behaviour, not only artefacts. The strongest signal is usually not whether Zero Trust is named in a policy, but whether it changes prioritisation, design, access, release, recovery or escalation. Look for repeated delays, unclear ownership, manual workarounds, unmanaged exceptions, untested assumptions and evidence that only appears when an audit or executive review is imminent.

The second signal is proportionality. Weak organisations either ignore the topic until something breaks or turn it into a heavy process that teams route around. Stronger organisations know where the topic matters most, where a lighter control is enough and where additional evidence is justified by risk.

Diagram Concept

The current topic diagram is a relationship map. A mature diagram for this page should show the operating boundary created by Zero Trust: the decision points, ownership handovers, evidence loops, escalation routes and related concepts that make the idea inspectable. The visual should help a leader ask better questions and help an engineer understand what changes in delivery.

Related Topics

Start with Trust Boundaries, Architectural Segmentation, NIST SP 800-53 Rev. 5. These relationships are deliberately practical: they show where this topic changes an adjacent architecture, governance or delivery conversation.

Further Reading

• NIST SP 800-207 Zero Trust Architecture
• NCSC Zero Trust guidance
• CISA Zero Trust Maturity Model
• NCSC Cyber Assessment Framework
• NCSC Cyber Essentials
• Platform Clarity topics: Trust Boundaries, Architectural Segmentation, NIST SP 800-53 Rev. 5