NCSA Zero Trust Guidelines
A source-based guide to NCSA's Zero Trust Guidelines, published as version 1.0, for executives, policy owners, technical teams, system administrators, and security engineers planning a risk-based transition from perimeter security to continuous verification.
- Target Audience
- Executives, policy owners, technical teams, and security engineers planning a move away from perimeter-based security
- Mandatory Frequency
- Review protect surfaces, policy, and maturity under the guidance; not an annual pentest mandate
- Required Scope
- Identity, devices, networks, applications and workloads, and data under the Zero Trust Maturity Model
- Non-Compliance Risk
- Lateral movement when the internal network is still trusted by default
Zero Trust principles and adoption scope
The guidance shifts the assumption from trusting an internal network to verifying every access request against identity, device posture, and session context.
Every request receives a contextual decision and least-privilege enforcement.
- Resources are services — Protect data, applications, assets, and services
- Authorize per session — Grant only the access needed for the request
- Use contextual policy — Evaluate identity, device, location, and behavior
- No trust from location — Internal network position does not establish trust
- Check asset posture — Continuously assess devices and systems
- Secure communications — Authenticate and protect every path
- Improve with telemetry — Feed events back into policy decisions
- All resources, including data, applications, services, and devices, should be treated as assets that need protection regardless of where they reside.
- Access should be granted per session and adjusted to risk using relevant evidence such as identity, device posture, location, and behavior.
- The seven Zero Trust principles emphasize strict authentication and authorization, continuous security monitoring of assets, and using collected information to improve controls.
Architecture and policy decision points
The document explains that requesters and their devices pass through policy decision points before they can reach a resource, separating decision, session-management, and enforcement responsibilities.
The PE evaluates the request; the PA creates or ends the session. Resource traffic passes through the PEP. Test both the decision and its enforcement.
- Requester and device — Send the request with context
- Policy Engine (PE) — Evaluates policy and trust signals
- Policy Administrator (PA) — Creates or ends the session
- Enforcement point (PEP) — Opens, monitors, or ends the connection
- Resource — Allows only authorized access
- The Policy Engine evaluates policy and supporting information to decide whether access is permitted.
- The Policy Administrator establishes or terminates communication paths and manages session credentials according to that decision.
- The Policy Enforcement Point opens, monitors, or terminates connections and should draw on identity, device, security telemetry, and other relevant information sources.
A five-step risk-based transition
The guidance starts with a defined protect surface and expands incrementally instead of changing every system at once.
Begin with the protect surface and real flows before selecting technology.
- Define the Protect Surface — Identify data, applications, assets, and services
- Map transaction flows — Understand communications and dependencies
- Design the architecture — Select approaches for context and risk
- Define 5W1H policy — Specify who, what, when, where, why, and how
- Monitor and maintain — Use logs, alerts, and feedback to improve policy
- Define the Protect Surface and a risk-based strategy, then map Transaction Flows to understand the relationship among data, applications, assets, and services.
- Design the Zero Trust architecture for that surface, considering identity, segmentation, microsegmentation, cloud, or hybrid approaches according to context and risk.
- Define policy through the 5W1H framework: Who, What, When, Where, Why, and How. Then monitor, log, alert, and continually review protect surfaces and policy.
Gap analysis, maturity, and continuous operations
Gap analysis needs to cover strategy, governance, data, assets, operations, and control effectiveness rather than comparing tool inventories alone.
Assess each pillar separately across Traditional, Initial, Advanced, and Optimal maturity, then define targets and improvements.
- Identity — Assess authentication, privileges, and identity risk
- Devices — Assess device posture and trust signals
- Networks — Assess segmentation, connections, and telemetry
- Applications and workloads — Assess access and workload protection
- Data — Assess classification, access, and protection
- Use the Risk Management Framework to structure the gap analysis across preparation, categorization, control selection, assessment, authorization, and monitoring.
- Use the Zero Trust Maturity Model to assess the five pillars of identity, devices, networks, applications and workloads, and data, with connected risk indicators.
- Establish roles, accountability, communication, training, and feedback loops so policy can adapt to incidents and changing environments.
Requirements and Testing Scope Matrix
Summary of the referenced clauses, the testing scope they cover, and the expected evaluation cycle.
| Reference | Mandate Title | Scope Required | Testing Cycle |
|---|---|---|---|
| Seven tenets (NIST SP 800-207 as cited by NCSA) | Verify every access request against identity, device posture, and session context | Policy Engine, Policy Administrator, and Policy Enforcement Point | Per-session verification under the guidance, not an annual pentest cadence |
| Five pillars (CISA ZTMM as cited by NCSA) | Assess maturity of identity, devices, networks, applications and workloads, and data | Protect surface, transaction flows, and 5W1H policy | Assessed in context and expanded incrementally |
Compliance Readiness Self-Assessment
Select items your organization has completed to evaluate your readiness score.
Frequently Asked Questions (FAQ)
Key answers and practical guidance addressing common compliance questions.
How does Zero Trust Architecture (ZTA) differ from traditional perimeter-based security?
Traditional security relies on perimeter firewalls, whereas Zero Trust operates on the principle of Never Trust, Always Verify, requiring explicit authentication and authorization for every request regardless of origin.
Where should an organization begin when adopting Zero Trust Guidelines?
The guidance starts with a defined protect surface and a risk-based strategy, then maps transaction flows, designs the architecture, and writes policy with the 5W1H framework before expanding incrementally rather than changing every system at once.
