Menu

Zero Trust: Building a Security Model for the Modern Day Workplace

Blog

Zero Trust: Building a Security Model for the Modern Day Workplace

Manoj Sharma

Manoj Sharma

Founder & Lead Coach · CISSP, CCSP, CISM, CRISC

Published 12 Jan 2026Updated 2 Aug 202614 min read291 views

Quick Answer

What is Zero Trust, and how do the NIST and CISA standards define and measure it?

Zero Trust is a security model built on "never trust, always verify" — no user, device or request is automatically trusted, even inside the network. It is defined canonically by NIST SP 800-207 (August 2020), which sets out seven technology-agnostic tenets and a logical architecture separating decision from enforcement: the Policy Engine and Policy Administrator form the Policy Decision Point, while the Policy Enforcement Point sits close to each resource, fed by Policy Information Points. The CISA Zero Trust Maturity Model v2.0 (April 2023) measures maturity across five pillars — Identity, Devices, Networks, Applications and Workloads, Data — plus three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance), scored across four stages: Traditional, Initial, Advanced, Optimal. NIST SP 1800-35 (June 2025) provides 19 example implementations from 24 vendors. Zero Trust is not a product. Cybernous, led by instructor Manoj Sharma, coaches CISSP and CISM with a 98.4% first-attempt pass rate.

What is Zero Trust?

Zero Trust is a security model built on one core principle: "never trust, always verify." It assumes no user, device or request is automatically trusted — even if it is inside the network. Every access request is verified, authorised and continuously validated before access is granted.

The goal is simple: reduce breach impact by restricting access to only what is necessary. It moves security away from perimeter-only defence into an identity-first, context-aware model that matches modern threats.

Core Idea

Zero Trust is not a product. It is a policy + architecture that forces verification at every hop. No vendor can sell you Zero Trust, and any vendor claiming to is selling you a component of it at best.

That is the principle. But principles are where most Zero Trust conversations start and stop, which is exactly why so many programmes stall. So let us do something different in this article: let us anchor every claim to the actual standards, because they exist, they are free, and they are far more specific than the marketing.

The Standards That Actually Define Zero Trust

The term "Zero Trust" is widely credited to John Kindervag during his time as an analyst at Forrester around 2010. But it became an engineering discipline rather than a slogan when the standards bodies documented it. These are the four you should know.

StandardPublishedWhat it gives you
NIST SP 800-207
Zero Trust Architecture
August 2020The canonical definition. Seven tenets and the PE/PA/PEP logical architecture. Describes what Zero Trust is, vendor-neutral.
CISA Zero Trust Maturity Model v2.0April 2023The assessment framework. Five pillars, three cross-cutting capabilities, four maturity stages. Tells you how mature you are.
NIST SP 1800-35
Implementing a Zero Trust Architecture
June 2025 (final)The practice guide. 19 example builds from 24 collaborating vendors using commercial off-the-shelf technology. Tells you how to actually build it.
DoD Zero Trust Strategy2022The prescriptive, mission-aligned variant. Seven pillars and 45 mapped capabilities, targeting adoption across DoD components by FY2027.
Know the Division of Labour

These are not competing frameworks and you do not choose between them. SP 800-207 describes what Zero Trust is — the architecture and principles. The CISA ZTMM measures how mature your implementation is — the assessment. SP 1800-35 shows how to build it — the practice guide. Definition, measurement, implementation. Use all three, in that order.

The Seven Tenets of NIST SP 800-207

NIST published Special Publication 800-207, "Zero Trust Architecture," in August 2020. It runs to 59 pages and it is the document every serious Zero Trust conversation traces back to. At its heart are seven tenets, written to be deliberately technology-agnostic. Paraphrased:

  1. All data sources and computing services are resources. Every device, server, SaaS application, API endpoint and data store is something to be protected.
  2. All communication is secured regardless of network location. Being on the corporate LAN confers no trust whatsoever.
  3. Access is granted per session. Trust is not persistent. Authenticating once does not authorise you forever.
  4. Access is determined by dynamic policy — including client identity, application state, the requesting asset, and behavioural and environmental attributes.
  5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. Device health is an input to the access decision.
  6. All authentication and authorisation are dynamic and strictly enforced before access is allowed — a continuous cycle, not a gate you pass once.
  7. The enterprise collects as much information as possible about the current state of assets, infrastructure and communications, and uses it to improve its security posture.
Read Tenet 2 Again

"All communication is secured regardless of network location" is the tenet that quietly kills the traditional model. It means the corporate LAN is not a trusted zone. It means the VPN does not make you an insider. If your architecture still treats "inside the firewall" as a trust signal, you do not have Zero Trust — you have a perimeter with better branding. This single idea is also the most commonly tested Zero Trust concept on security certifications: network location never grants trust.

The Architecture: PE, PA and PEP

Here is the part most Zero Trust articles skip, and it is the part that turns the philosophy into something you can draw on a whiteboard. SP 800-207 defines a logical architecture with a clean separation between deciding and enforcing.

ComponentPlaneRole
Policy Engine (PE)ControlMakes the decision. Runs a trust algorithm over identity, device posture, telemetry and threat intelligence to grant, deny or revoke access.
Policy Administrator (PA)ControlExecutes the decision. Establishes or tears down the communication path and issues credentials or tokens.
Policy Decision Point (PDP)ControlThe PE and PA together. The "brain."
Policy Enforcement Point (PEP)DataSits between subject and resource. Enables, monitors and terminates connections on the PDP's instruction. The "gatekeeper," placed close to the resource.
Policy Information Points (PIPs)SupportingFeed the PE: IAM systems, device posture, SIEM and activity logs, threat intelligence, data classification.
CONTROL PLANEPolicy Decision PointPolicy EnginePolicyAdministratorPolicy InformationIAM · device postureSIEM · threat inteldecisionDATA PLANESubjectuser + deviceUNTRUSTED — alwaysrequestPEPenforce · monitor · endResourceapp · data · serviceTRUST ZONE
The NIST SP 800-207 logical architecture — decisions in the control plane, enforcement in the data plane, close to the resource.

Why this separation matters practically: it decouples the access decision from the infrastructure. Policy logic is centralised so it stays consistent, while enforcement is distributed close to each protected resource. That is what lets one policy apply identically to an on-premises database, a SaaS application and a cloud workload — which is precisely the problem a perimeter cannot solve.

Why Zero Trust is Necessary Today

Five reasons Zero Trust has become essential:

  • Rising threat landscape: attackers bypass perimeter defences through phishing, stolen credentials and supply chain routes.
  • Remote work and cloud adoption: the "office network" is no longer the default safe zone.
  • Insider threats: malicious or compromised insiders cannot be ignored.
  • Data breach prevention: selective access plus continuous verification reduces blast radius.
  • Compliance requirements: modern frameworks expect tighter access control and monitoring.

There is also a regulatory driver worth knowing even outside government. US Executive Order 14028, Improving the Nation's Cybersecurity, led to OMB Memorandum M-22-09 in January 2022, which required federal agencies to meet specific Zero Trust milestones by the end of FY2024. The CISA maturity model was built to support exactly that transition. Government mandates have a habit of becoming enterprise expectations, and this one has.

Key Components: The CISA Pillars, Correctly Mapped

If you are implementing Zero Trust, you need the building blocks — and here it matters to use the real structure rather than a flat list, because the structure carries meaning.

The CISA Zero Trust Maturity Model version 2.0, published in April 2023 and still the current version, defines five pillars and three cross-cutting capabilities. The distinction is not pedantry: the pillars are the domains you secure; the cross-cutting capabilities are how you operate all five at scale rather than by hand.

The five pillars

PillarWhat it covers
IdentityStrong authentication and authorisation to verify users. Phishing-resistant MFA, continuous validation, least privilege.
DevicesDevice security posture checks before access — compliant, patched, trusted. Posture is an input to every decision.
NetworksMicro-segmentation and least privilege to restrict lateral movement. Encrypted traffic by default.
Applications & WorkloadsSecure application design, per-application access controls, policy enforcement at the resource.
DataClassification, encryption and access controls to protect sensitive information. The pillar most organisations are weakest on.

The three cross-cutting capabilities

CapabilityWhat it does
Visibility & AnalyticsComprehensive visibility that informs policy decisions and facilitates response.
Automation & OrchestrationLeverages those insights for streamlined operations and incident response at machine speed.
GovernanceManages regulatory, legal and operational requirements in support of risk-based decisions — and ensures the right people, processes and accountability are in place.
The Component List Almost Everyone Gets Wrong

You will find countless articles listing Zero Trust "components" as a flat set of eight — typically Identity, Devices, Network, Data, Applications, Infrastructure, Visibility & Analytics and Automation & Orchestration. Two problems. First, Infrastructure is not a CISA pillar — it belongs to Microsoft's six-pillar model, which is a legitimate but different framework. Mixing them produces a list that matches neither. Second, and more seriously, that list omits Governance entirely — the cross-cutting capability that covers accountability, regulatory alignment and risk-based decision-making. Governance is the one that determines whether your Zero Trust programme survives its first budget cycle. Leaving it out of the model is how it gets left out of the plan.

How Mature Are You? The Four Stages

This is the most practically useful thing CISA produced, and it costs nothing to use. The ZTMM defines four maturity stages for each pillar. Version 1.0 had only three; v2.0 added Initial specifically because the jump from Traditional straight to Advanced proved too large for most organisations to cross in one step — an unusually honest piece of standards design.

StageWhat it looks like
TraditionalManually configured lifecycles and attributes. Static policies addressing one pillar at a time. Least privilege set only at provisioning. Siloed enforcement, manual response, limited log correlation. Trust is implicit, based on network location.
InitialAutomation begins for attribute assignment and lifecycles. First cross-pillar integrations. Some responsive change to least privilege after provisioning. Aggregated visibility for internal systems.
AdvancedAutomated controls with cross-pillar coordination. Centralised visibility and identity control. Policy enforcement integrated across pillars. Enterprise-wide awareness.
OptimalFully automated attribute assignment. Dynamic policies driven by automated triggers. Open-standards interoperability across functions. Centralised visibility.
Use This as a Free Assessment

Score each of the five pillars against these four stages, honestly, today. You will almost certainly find you are not at one uniform level — most organisations are Traditional in some pillars and Initial in others, and Data is typically the weakest. That uneven map is your roadmap: it shows where to spend, and it protects you from over-investing in the pillar you already understand while remaining blind elsewhere. This is a better first move than any purchase.

Implementing Zero Trust: A Step-by-Step Guide

Step 1: Define your scope

Identify the vital assets and resources that need protection. Zero Trust is resource-centric — you cannot protect what you have not enumerated.

Step 2: Assess your current security posture

Evaluate existing controls and identify gaps. Score yourself against the CISA maturity stages above, pillar by pillar.

Step 3: Implement strong IAM

Use MFA and RBAC, and move toward policy-based access where possible. Identity is the pillar everything else depends on — weak identity attributes produce weak decisions, no matter how sophisticated your policy engine.

Step 4: Micro-segment your network

Divide networks into smaller segments to limit lateral movement and contain breaches.

Step 5: Enforce least privilege

Grant only the minimum access required to do the job — and re-evaluate it continuously rather than only at provisioning. That difference is precisely what separates Traditional from Advanced in the maturity model.

Step 6: Monitor and log everything

Continuous monitoring and logging for faster detection and investigation. Remember tenet 7: telemetry is not just for the SOC, it is an input to the access decision itself.

Step 7: Security processes

Establish the essential workflows — access reviews, patching, incident handling, approvals. This is where Governance lives in practice.

Step 8: Continuously evaluate and improve

Regularly review controls, tune policies, and adapt to new threats.

Implementation Truth

If you cannot measure access, you cannot control it. Zero Trust succeeds when you combine identity + device posture + logging into one decision engine. That sentence is not a metaphor — it is a literal description of the Policy Engine consuming its Policy Information Points.

What NIST SP 1800-35 adds

If steps 1–8 feel abstract, this is the antidote. In June 2025, NIST's National Cybersecurity Center of Excellence published the final version of SP 1800-35, "Implementing a Zero Trust Architecture" — the product of a multi-year collaboration with 24 vendors that produced 19 example ZTA implementations built entirely from commercial off-the-shelf technology, with the technical detail needed to replicate them.

Two things about it are worth internalising. First, it organises those builds on a "crawl, walk, run" model — explicitly acknowledging there is no one-size-fits-all ZTA and that this is an incremental journey. Second, it covers several distinct architectural approaches, including enhanced identity governance (EIG), software-defined perimeter (SDP), micro-segmentation and secure access service edge (SASE) — which is a useful corrective to the assumption that Zero Trust has one shape. It also maps its security capabilities to the NIST Cybersecurity Framework and SP 800-53r5, so the work you do here counts toward controls you already report on.

Benefits of a Zero Trust Model

  • Reduced attack surface
  • Improved data protection
  • Supports regulatory needs for data protection
  • Enables secure remote work and cloud adoption
  • Better visibility into network and user activity
  • Simplified security management through policy-driven access
  • Stronger overall security posture

Where Zero Trust Programmes Fail

Since this article is meant to be useful rather than promotional, here are the failure modes worth naming.

  • Buying a "Zero Trust product." There isn't one. Vendors supply PEPs, PDPs and PIPs; you supply the architecture and the policy.
  • MFA as the finish line. Multifactor authentication is necessary and nowhere near sufficient — stolen credentials and session abuse still succeed where enforcement and monitoring are weak.
  • Weak signals in, weak decisions out. If your identity and device posture data is poor, your policy engine is making confident decisions on bad inputs.
  • Legacy applications. Older apps often cannot enforce policy at the resource boundary and need gateways, enclaves or phased modernisation. Plan for this rather than discovering it.
  • Set-and-forget drift. Policies need continual tuning as environments and attacker techniques evolve. Without telemetry and governance, the intent decays quietly.
  • Declaring victory. Self-reporting "we've done Zero Trust" after deploying MFA and calling the VPN a ZTNA is the most common outcome of all.

The Future of Zero Trust

Zero Trust will keep expanding as cloud adoption grows and threats evolve. Expect stronger automation, AI-driven security decisions, and deeper integration across identity, endpoints and workloads.

It will also extend beyond traditional IT into IoT and OT, where segmentation, identity and continuous verification will become essential — and considerably harder, since much OT equipment predates the idea that a device should have an identity at all. The focus will shift toward proactive threat hunting and real-time incident response across every layer.

The most interesting frontier is machine and agent identity. As AI agents begin to plan, act and call tools on behalf of users, the Zero Trust question — who is this, what are they allowed to do, and does that still hold right now? — applies to non-human actors holding credentials at machine speed. The tenets do not change. The population of subjects does.

Where This Meets CISSP & CISM

Zero Trust is high-yield exam material and it maps cleanly onto what you already study. Least privilege and access control sit in CISSP Domain 5 (Identity and Access Management); secure architecture in Domain 3; network segmentation in Domain 4; and the governance and risk framing throughout Domain 1 — which is also the heart of CISM. The most commonly tested principle is the one from tenet 2: network location never grants trust. If an answer option implies the corporate LAN is inherently safe, it is wrong. Expect scenario questions asking which control best enforces Zero Trust for a given requirement — that is judgment, not recall.

Architect Security, Don't Just Operate It

Zero Trust is an architecture and governance discipline — exactly what CISSP and CISM teach. Cybernous coaches working professionals through both, with 60+ hours of live practice, 5,045+ questions and 1:1 mentoring from Manoj Sharma. 2,000+ certified across 40+ countries, 98.4% first-attempt pass rate.

Explore the CISSP Success Toolkit →

Conclusion

Traditional perimeters cannot protect modern workplaces on their own. Zero Trust provides a practical framework to minimise blast radius, strengthen identity controls, and protect data across cloud and on-premises environments.

But treat it as engineering, not philosophy. The standards are written, free and specific: SP 800-207 tells you what it is, the CISA maturity model tells you where you stand, and SP 1800-35 shows you nineteen ways others have built it. Zero Trust is not a one-time project — it is a continuous journey where strategy, policy, tools and a security-first mindset work together. If your organisation is serious about resilience, Zero Trust is no longer optional. Start by scoring your five pillars honestly. That map is worth more than any product on the market.

Continue Reading

Frequently Asked Questions

Zero Trust is a security model built on the principle "never trust, always verify." It assumes no user, device or request is automatically trusted — even when it originates inside the corporate network — and requires every access request to be verified, authorised and continuously validated before access is granted. The goal is to reduce breach impact by restricting access to only what is necessary, moving security away from perimeter-only defence toward an identity-first, context-aware model. The canonical definition comes from NIST Special Publication 800-207, "Zero Trust Architecture," published in August 2020, which defines seven technology-agnostic tenets and a logical architecture separating policy decisions from policy enforcement. Crucially, Zero Trust is not a product you can buy — it is a policy and architecture discipline. Vendors supply components (enforcement points, decision engines, signal sources), but the architecture and the policy are yours to design. Any vendor claiming to sell you "Zero Trust" in a box is selling a component at best. It is also not a one-time project but a continuous journey, which is why maturity models exist to measure progress.
NIST Special Publication 800-207, "Zero Trust Architecture," is the canonical, vendor-neutral definition of Zero Trust. Published in August 2020 and running to 59 pages, it is the document that every serious Zero Trust conversation traces back to. It does two main things. First, it defines seven foundational tenets, written deliberately to be technology-agnostic: all data sources and computing services are resources; all communication is secured regardless of network location; access is granted per session; access is determined by dynamic policy including identity, application state, asset posture and behavioural attributes; the enterprise monitors the integrity and security posture of all assets; all authentication and authorisation are dynamic and strictly enforced before access; and the enterprise collects extensive telemetry to continuously improve its posture. Second, it defines a logical architecture — the Policy Engine and Policy Administrator (together the Policy Decision Point) in the control plane, and the Policy Enforcement Point in the data plane. It describes what Zero Trust is rather than how to build it or how mature you are; NIST SP 1800-35 and the CISA Zero Trust Maturity Model cover those respectively. It is free to download from NIST.
The CISA Zero Trust Maturity Model version 2.0, published in April 2023 and still the current version, defines five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Alongside these sit three cross-cutting capabilities that span all five pillars — Visibility and Analytics, Automation and Orchestration, and Governance. The distinction matters and is frequently misreported. The pillars are the domains you secure; the cross-cutting capabilities are how you operate all five at scale rather than by hand. Visibility and Analytics supports comprehensive visibility that informs policy decisions and facilitates response. Automation and Orchestration leverages those insights for streamlined operations and incident handling. Governance enables organisations to manage regulatory, legal and operational requirements in support of risk-based decision-making, and ensures the right people, processes and accountability are in place. You will often see articles listing Zero Trust components as a flat set of eight that includes Infrastructure — that belongs to Microsoft's six-pillar model, not CISA's — and that omits Governance entirely. Governance is frequently the capability that determines whether a Zero Trust programme survives contact with reality.
The CISA Zero Trust Maturity Model v2.0 defines four maturity stages, assessed separately for each of the five pillars: Traditional, Initial, Advanced and Optimal. Traditional is the legacy starting point — manually configured lifecycles and attributes, static policies addressing one pillar at a time, least privilege established only at provisioning, siloed enforcement, manual response, and limited correlation of logs and telemetry, with trust often implicit based on network location. Initial marks the first concrete step: automation begins for attribute assignment and lifecycle management, early cross-pillar integration appears, some responsive change to least privilege occurs after provisioning, and visibility becomes aggregated for internal systems. Advanced introduces cross-functional coordination, centralised visibility and identity control, and policy enforcement integrated across pillars. Optimal features fully automated attribute assignment, dynamic policies driven by automated triggers, open-standards interoperability, and centralised visibility. Notably, version 1.0 defined only three stages; v2.0 added Initial precisely because the jump from Traditional straight to Advanced proved too large for most organisations to make in one step. Score each pillar honestly — most organisations sit at different stages across pillars, and Data is typically the weakest.
They do different jobs and you use both rather than choosing between them. NIST SP 800-207 is an architectural reference that defines Zero Trust principles, the logical components (Policy Engine, Policy Administrator, Policy Enforcement Point) and deployment scenarios. It describes what Zero Trust is — the definition, vendor-neutral and technology-agnostic. It is most useful when your security, IT and architecture teams need a common authoritative definition they can share. The CISA Zero Trust Maturity Model v2.0 is an assessment framework. It tells you how mature your Zero Trust implementation currently is, scoring five pillars across four maturity stages with three cross-cutting capabilities. It is most useful for establishing a baseline, identifying gaps and prioritising a roadmap. Completing the set, NIST SP 1800-35 is the practice guide showing how to build it, with 19 example implementations. The clean way to hold this: SP 800-207 is the definition, CISA ZTMM is the measurement, SP 1800-35 is the implementation. Use them in that order — define what you are building, measure where you are, then follow proven build patterns.
NIST SP 1800-35, "Implementing a Zero Trust Architecture," is the practical counterpart to SP 800-207. Published in final form in June 2025 by NIST's National Cybersecurity Center of Excellence (NCCoE), it is the product of a multi-year collaboration with 24 vendor partners that produced 19 example Zero Trust Architecture implementations built entirely from commercial off-the-shelf technology, with detailed technical information so organisations can replicate them. Two aspects are particularly valuable. First, it organises the example builds using a "crawl, walk, run" model, explicitly acknowledging there is no one-size-fits-all approach and that implementing Zero Trust is a continual, incremental journey — a refreshingly honest framing from a standards body. Second, it covers several distinct architectural approaches rather than assuming one shape, including enhanced identity governance (EIG), software-defined perimeter (SDP), micro-segmentation and secure access service edge (SASE). It also maps the implemented security capabilities to the NIST Cybersecurity Framework and NIST SP 800-53r5, meaning the work counts toward controls you likely already report against. It is published in both a high-level PDF for orientation and a full web version with in-depth technical detail, and it is free.
Micro-segmentation divides the network into smaller zones, each acting as its own perimeter with its own access controls. Its purpose is to limit lateral movement: even if an attacker compromises one segment, they cannot move freely across the environment to reach more valuable targets. This directly addresses one of the central weaknesses of perimeter-based security, where breaching the outer boundary historically granted broad internal access. In Zero Trust terms, micro-segmentation is a core capability of the Networks pillar in the CISA maturity model, and NIST SP 1800-35 treats it as one of several distinct architectural approaches to building a ZTA — alongside enhanced identity governance, software-defined perimeter and SASE. Practically, it means that traffic between segments is authenticated and authorised rather than implicitly permitted, which is tenet 2 of SP 800-207 applied inside your own network. It is worth being clear that micro-segmentation alone is not Zero Trust; it is one pillar's contribution. An organisation with excellent segmentation but weak identity signals will still make poor access decisions, because the policy engine can only be as good as the information feeding it.
Identity and access management is central to Zero Trust — it is the pillar everything else depends on. IAM verifies every user and device before access and enforces strong controls like multifactor authentication to ensure only authorised access to applications, data and systems. In the NIST SP 800-207 architecture, IAM is one of the primary Policy Information Points feeding the Policy Engine, which means the quality of your identity data directly determines the quality of every access decision your architecture makes. This is the practical reason identity comes first in any sensible implementation sequence: weak identity attributes produce weak decisions, no matter how sophisticated the policy engine consuming them. A critical caveat, however: MFA is necessary but not sufficient. Deploying MFA and declaring Zero Trust complete is probably the single most common failure mode in the field. Stolen credentials and session abuse still succeed where enforcement and monitoring are weak, because authenticating once does not satisfy tenet 3 — access is granted per session and trust is never persistent. Mature identity means continuous validation, behavioural baselining, real-time revocation rather than time-based expiry, and governing machine identities as rigorously as human ones.
Zero Trust reduces remote work risk by removing the assumption that gave the traditional model its shape — that being on the network means being safe. It applies least privilege, continuous monitoring and adaptive access controls based on real-time risk signals rather than location. This is tenet 2 of NIST SP 800-207 in practice: all communication is secured regardless of network location. It follows that a VPN connection does not make someone an insider, and the corporate LAN is not a trusted zone. Under a Zero Trust model, a user working from home and one sitting in the office are evaluated identically — on their identity assurance, their device posture, the resource requested and the surrounding context. That is what makes it genuinely suited to distributed work rather than a bolt-on. Practically, it also tends to improve the experience: done well, Zero Trust removes VPN friction rather than adding it, because access is granted to specific resources per session rather than by dropping users onto a network segment. The architecture achieves this by placing enforcement points close to each resource, so the same policy applies whether the resource is on-premises, in SaaS or across multiple clouds.
No, and this is the most consequential misunderstanding in the field. Zero Trust is a policy and architecture discipline — a set of principles about how access decisions are made and enforced. Vendors legitimately supply components of a Zero Trust Architecture: Policy Enforcement Points, Policy Decision Points, and the Policy Information Points that feed identity, device posture, telemetry and threat intelligence into the decision. NIST SP 1800-35 demonstrates 19 example implementations built entirely from commercial off-the-shelf technology, so products absolutely matter. But the architecture and the policy are yours to design, and no purchase substitutes for that. Several failure modes follow from getting this wrong. Buying a "Zero Trust product" and declaring victory. Treating MFA as the finish line. Rebranding the VPN as ZTNA and changing nothing structurally. Self-reporting maturity that no measurable architectural change supports. The honest test is straightforward: if network location still functions as a trust signal anywhere in your environment, you do not have Zero Trust regardless of what you purchased. Start with the free CISA maturity assessment instead — scoring your five pillars honestly is a better first move than any procurement.

You might also like

Ready to accelerate your certification journey?

Join Cybernous' structured programme with live mentoring, hands-on practice, and a proven track record.