Zero Trust (NIST SP 800-207)

Introduction: Zero Trust (NIST SP 800-207)

Zero Trust is a cybersecurity paradigm that shifts defences from static, network-based perimeters to a model centred on users, assets and resources. NIST Special Publication 800-207, published by the National Institute of Standards and Technology in August 2020, is the authoritative reference architecture for Zero Trust Architecture (ZTA). It defines Zero Trust not as a single product or technology but as an evolving set of principles that assume no implicit trust is granted to any asset or user account based solely on its physical or network location (for example, being inside a corporate LAN) or on asset ownership. Every access request is treated as though it originates from an untrusted network, and each is authenticated, authorised and continuously validated before access to an enterprise resource is granted.

This guide is written from the perspective of a CERT-In empanelled auditor and PCI QSA, translating the abstract tenets of SP 800-207 into a concrete, evidence-driven assessment programme. It maps the seven tenets, the logical architecture (Policy Decision Point, Policy Enforcement Point, Policy Engine, Policy Administrator), the deployment models and the trust-algorithm variations into auditable control statements. Because Zero Trust is a strategy rather than a certifiable standard, an organisation is assessed for maturity and design conformance rather than pass/fail compliance. The framework is complementary to the NIST Cybersecurity Framework, NIST SP 800-53 controls, CISA's Zero Trust Maturity Model, and the DoD Zero Trust Reference Architecture, all of which are referenced where relevant.

What is Zero Trust

Zero Trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defences from static, network-based perimeters to focus on users, assets and resources. A Zero Trust Architecture (ZTA) uses Zero Trust principles to plan industrial and enterprise infrastructure and workflows. The core assumption is that the enterprise-owned network environment is no different from, or is no more trustworthy than, any non-enterprise-owned network. Trust is never granted implicitly and must be continually evaluated.

NIST SP 800-207 articulates Zero Trust through seven foundational tenets. These tenets are the abstract requirements against which any ZTA design should be measured:

1. Tenet 1 — All data sources and computing services are considered resources. A network may be composed of multiple classes of devices, and the enterprise may classify personally-owned devices as resources if they access enterprise-owned resources.
2. Tenet 2 — All communication is secured regardless of network location. Network location alone does not imply trust. Access requests from assets on enterprise-owned network infrastructure must meet the same security requirements as requests from any other non-enterprise-owned network; all communication is done in the most secure manner available, protecting confidentiality and integrity and providing source authentication.
3. Tenet 3 — Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before access is granted, and access is granted with the least privileges needed to complete the task. Authentication and authorisation to one resource do not automatically grant access to another.
4. Tenet 4 — Access to resources is determined by dynamic policy — including the observable state of client identity, application/service and the requesting asset — and may include other behavioural and environmental attributes.
5. Tenet 5 — The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted; the enterprise evaluates the security posture of the asset when evaluating a resource request using a continuous diagnostics and mitigation (CDM) or similar system.
6. Tenet 6 — All resource authentication and authorisation are dynamic and strictly enforced before access is allowed. This is a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually re-evaluating trust in ongoing communication.
7. Tenet 7 — The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications, and uses it to improve its security posture.

The logical architecture of a ZTA centres on a Policy Decision Point (PDP), which is split into a Policy Engine (PE) that makes the ultimate grant/deny decision using a trust algorithm, and a Policy Administrator (PA) that executes that decision by establishing or shutting down the communication path. The Policy Enforcement Point (PEP) sits in the data plane and enables, monitors and terminates connections between a subject and an enterprise resource. Supporting the PDP are data sources such as CDM systems, threat intelligence feeds, activity logs, data-access policy, PKI, ID management and SIEM systems.

Who must comply

Zero Trust is a voluntary architectural strategy for the private sector but is mandated for United States federal civilian agencies and increasingly expected of their supply chains. In India, the CERT-In directions and the sector-specific guidance from RBI, SEBI and IRDAI increasingly reference Zero Trust principles. The following table summarises the applicability landscape.

• Chief Information Security Officers responsible for enterprise security architecture and roadmap.
• Enterprise and security architects designing identity, network and data controls.
• Cloud and platform teams operating IaaS, PaaS and SaaS estates.
• Identity and access management teams owning authentication, authorisation and privileged access.
• Governance, risk and compliance functions aligning ZT to regulatory obligations.
• Third-party and supply-chain risk managers extending trust evaluation to partners.

Structure of Zero Trust

Because SP 800-207 is principle-based, practical assessment blends the NIST tenets and logical components with the pillar taxonomy popularised by CISA's Zero Trust Maturity Model (ZTMM) and the DoD Reference Architecture. This guide organises controls into a coherent structure spanning the seven tenets, the logical architecture components, the five CISA pillars, and the three cross-cutting capabilities. The following table lays out this control structure.

Master assessment checklist

This is the core of the guide. It enumerates every tenet, logical component, pillar and cross-cutting capability as an auditable checklist. For each group there is a table with two columns: what to verify, and the typical evidence an auditor should collect. No control area is skipped.

A. Foundational tenets (SP 800-207 Section 2)

B. Logical architecture components (PDP / PE / PA / PEP)

C. Identity pillar

D. Devices pillar

E. Networks pillar

F. Applications and Workloads pillar

G. Data pillar

H. Visibility and Analytics (cross-cutting)

I. Automation and Orchestration (cross-cutting)

J. Governance (cross-cutting)

Scoping

Scoping a Zero Trust programme means defining the protect surface — the critical data, assets, applications and services (DAAS) that the architecture must safeguard — rather than trying to protect the entire, ever-expanding attack surface at once. A well-defined scope prevents boil-the-ocean failure and enables incremental, risk-prioritised rollout.

• Identify the protect surface: enumerate the specific DAAS elements (crown-jewel data, sensitive applications, critical assets and services) that carry the greatest business and regulatory risk.
• Map transaction flows: understand how traffic moves to and around the protect surface, including user-to-application, application-to-data and workload-to-workload flows.
• Determine the subjects and entities: human users, service accounts, workloads, devices and third parties that require access to in-scope resources.
• Define the boundaries of each deployment model (enhanced identity governance, micro-segmentation, network infrastructure/SDP) applicable to the scope.
• Establish exclusions and dependencies: legacy systems that cannot yet participate, and the compensating controls applied to them.
• Confirm regulatory overlays that expand or constrain scope (for example, cardholder data environment for PCI DSS, or personal data under DPDP).

Implementation approach

A pragmatic Zero Trust rollout is phased. Each phase below lists its principal activities and the deliverables an auditor should expect to see. The phases align with the Kindervag five-step model and the CISA maturity progression from Traditional to Optimal.

Phase 1 — Discovery and strategy

• Activities: secure executive sponsorship; define the Zero Trust vision and guiding principles; inventory identities, devices, networks, applications and data; identify the initial protect surface; perform a current-state maturity baseline against the CISA pillars.
• Deliverables: approved ZT strategy and charter; DAAS/protect-surface register; asset and identity inventories; baseline maturity assessment report; prioritised roadmap.

Phase 2 — Design the target architecture

• Activities: select deployment models and trust-algorithm approach; design the PDP/PE/PA and PEP placement; define policy model (RBAC/ABAC) and attribute schema; design identity, device, network, application and data controls; plan telemetry and analytics integration.
• Deliverables: target ZTA reference architecture; policy design and attribute catalogue; PEP placement map; data and telemetry design; integration blueprint.

Phase 3 — Foundational identity and device controls

• Activities: consolidate identity stores and federation; deploy phishing-resistant MFA and conditional access; implement PAM with JIT/JEA; roll out device inventory, posture checks and EDR; enforce device compliance as an access precondition.
• Deliverables: MFA and conditional-access coverage reports; PAM configuration; device-compliance policy and dashboards; identity-lifecycle automation.

Phase 4 — Network, application and data enforcement

• Activities: replace broad VPN access with ZTNA/SDP; implement segmentation and micro-segmentation; enforce mTLS and workload identity; deploy application-layer authorisation; classify and protect data with encryption and DLP.
• Deliverables: ZTNA rollout evidence; segmentation policies; workload-identity configuration; data-classification and DLP reports; per-application access policies.

Phase 5 — Visibility, automation and continuous improvement

• Activities: centralise telemetry into SIEM; build detection and UEBA use-cases; automate response through SOAR; establish feedback loops to the policy engine; measure KPIs; conduct periodic maturity reassessments and tabletop exercises.
• Deliverables: SIEM/analytics coverage matrix; SOAR playbooks; KPI dashboards; continuous-improvement backlog; reassessment reports and management reviews.

Maturity model

CISA's Zero Trust Maturity Model defines four stages of maturity across each pillar and cross-cutting capability. An assessment scores each pillar independently and then aggregates to an overall maturity profile. The stages are summarised below.

For programmes aligning to the DoD model, a complementary view distinguishes a Target Level of Zero Trust (the minimum set of activities required for baseline effectiveness) and an Advanced Level (the full set achieving the strategic end-state). Auditors should record the target maturity per pillar and the timeline to reach it.

Assessment and audit approach

A Zero Trust assessment is design- and maturity-oriented. The following ordered steps describe a rigorous audit engagement.

1. Define the engagement scope, protect surface and target maturity with the sponsor, and agree the assessment criteria (SP 800-207 tenets, CISA ZTMM, or DoD activities).
2. Gather and review documentation: strategy, architecture, policies, inventories and prior assessments.
3. Conduct stakeholder interviews across identity, device, network, application, data, security operations and governance functions.
4. Perform current-state mapping of each pillar and cross-cutting capability to the chosen maturity model.
5. Validate control effectiveness through configuration review, log inspection and, where agreed, technical testing (for example, lateral-movement and access-bypass testing).
6. Assess the logical architecture: verify PE/PA/PEP existence, placement, non-bypassability and trust-algorithm suitability.
7. Identify gaps between current and target maturity, rating each by risk and effort.
8. Score each pillar and produce an aggregated maturity profile with heat-map visualisation.
9. Develop a prioritised, phased remediation roadmap with owners and timelines.
10. Report findings to management, and agree a reassessment cadence to track progress.

Evidence request list

The following categorised list is the evidence an auditor typically requests. It should be tailored to the agreed scope.

• Strategy and governance: Zero Trust strategy, charter, roadmap, target architecture, policy repository, RACI matrix, risk register entries, management-review minutes.
• Identity: identity-store schema, federation configuration, MFA policy and coverage, conditional-access policies, PAM configuration and JIT logs, access-review and recertification records, service-account inventory.
• Devices: asset/device inventory, MDM/UEM exports, device-posture and compliance policies, EDR coverage and alert records, BYOD policy, exception register.
• Networks: network architecture and segmentation diagrams, micro-segmentation policies, ZTNA/SDP configuration, VPN decommission plan, IDS/IPS/NDR logs, protective-DNS and DDoS evidence.
• Applications and workloads: application inventory, SSO and authorisation configuration, service-mesh/workload-identity config, WAF/RASP rules, SDLC policy, SAST/DAST/SCA and penetration-test reports.
• Data: data catalogue and classification policy, encryption standards, KMS/HSM and key-rotation logs, DLP policies and incident logs, IRM configuration, retention and disposal records.
• Visibility and analytics: log-source inventory, SIEM ingestion and retention settings, detection and UEBA use-cases, threat-intel integration, KPI dashboards.
• Automation and orchestration: SOAR playbooks, automated-response configuration, IGA/JML automation records, automation audit trails and approval gates.
• Prior assessments: previous maturity assessments, penetration-test reports, audit findings and remediation-tracking evidence.

Roles and responsibilities

KPIs to track

• Percentage of resources fronted by a Policy Enforcement Point (PEP coverage).
• Percentage of users and privileged accounts using phishing-resistant MFA.
• Percentage of access requests evaluated by dynamic, risk-based policy.
• Percentage of managed and unmanaged devices with enforced posture checks and EDR.
• Proportion of applications behind ZTNA/SDP versus legacy VPN access.
• Extent of micro-segmentation coverage across the protect surface.
• Percentage of sensitive data classified, encrypted and under DLP monitoring.
• Mean time to detect and mean time to respond for access-related incidents.
• Rate of successful lateral-movement attempts in red-team or purple-team exercises (target: declining).
• Percentage of privileged sessions granted just-in-time versus standing privilege.
• Log-source and telemetry coverage across the five pillars.
• Maturity score per pillar and overall, trended over time.

Readiness checklist

• Executive sponsorship secured and a documented Zero Trust strategy approved.
• Protect surface (critical DAAS) identified and transaction flows mapped.
• Complete inventories of identities, devices, applications and data maintained.
• Phishing-resistant MFA enforced across users and privileged accounts.
• Conditional, risk-based access policies operational.
• Privileged access managed with just-in-time and just-enough access.
• Device posture and EDR enforced as a precondition for resource access.
• Segmentation and micro-segmentation implemented for the protect surface.
• Broad VPN access replaced by application-layer ZTNA/SDP where feasible.
• Data classified, encrypted at rest and in transit, and monitored by DLP.
• Policy Enforcement Points front all in-scope resources and cannot be bypassed.
• Centralised telemetry, SIEM and analytics feed the policy engine.
• Automated response (SOAR) capable of isolating devices and revoking sessions.
• Governance, roles and continuous-improvement cadence established.
• Current-state maturity baselined and a phased roadmap agreed.

Common gaps

• Treating Zero Trust as a single product purchase rather than an architecture and strategy.
• Incomplete asset and identity inventories, leaving unknown resources unprotected.
• MFA present but not phishing-resistant, and not extended to service and privileged accounts.
• Standing privileged access persisting because just-in-time access is never implemented.
• Network segmentation stopping at coarse VLANs without true micro-segmentation, so lateral movement remains easy.
• Policy Enforcement Points that can be bypassed through legacy paths or direct network access.
• Device posture checked only at logon and never re-evaluated during a session.
• Data left unclassified and unencrypted, so data-centric controls cannot be applied.
• Telemetry gaps that starve the policy engine of the signals needed for dynamic decisions.
• No feedback loop from analytics to policy, leaving the trust algorithm static.
• Governance and ownership undefined, so pillars evolve in silos and inconsistently.
• Legacy and operational-technology systems excluded indefinitely without compensating controls.

Zero Trust mapped to other frameworks

Zero Trust does not replace existing control frameworks; it provides an architectural strategy that many of them can express. The table maps Zero Trust concepts to representative controls in other frameworks to aid integrated compliance.

Frequently asked questions

Need help with Zero Trust?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.