NIST SP 800-207

Where the primary driver is identity rather than network topology, deploy zero trust using an enhanced identity governance approach. Access is granted based on identity, device, and attribute assertions, with the network providing limited reachability only.

• architecture document selecting EIG model
• device trust signal integration
• attribute assertion design
• transition plan from legacy network trust

• identity centric model declared but network ACLs still primary
• device trust signals limited to managed laptops
• service accounts excluded from the model

Where workload to workload control is the primary concern, deploy micro segmentation that places each resource or small group of resources behind its own gateway. Use software defined controls rather than relying on VLAN topology.

• segmentation design document
• policy as code repository with reviewable diffs
• workload identity issuance process
• policy coverage metrics across workloads

• policies coarse grained per subnet rather than per workload
• no workload identity, decisions rely on IP
• policy changes deployed manually

Implement a Software Defined Perimeter that hides resources from unauthorized clients and only exposes them after authentication and authorization. Resources become invisible to attackers performing reconnaissance.

• SDP design document
• client agent rollout report
• external attack surface scan showing concealment
• policy linkage between SDP gateway and policy engine

• SDP applied to a subset of users while VPN remains for others
• no validation that resources are hidden from unauthenticated probes
• client agent deployment incomplete on contractor devices

Classify every data source and computing service in the enterprise as a resource that requires access decisions, including SaaS applications, internal APIs, and personal devices accessing enterprise services. Maintain a current inventory that supports policy decisions.

• enterprise resource inventory covering on premise, cloud, and SaaS
• data classification mapped to resources
• scope statement for the zero trust programme
• quarterly reconciliation between CMDB and policy engine

• shadow SaaS not represented in the inventory
• personal device access uncatalogued
• data classification not aligned with access policy attributes

Apply encryption and authentication to all communications, regardless of whether the traffic originates inside or outside the corporate perimeter. Do not grant trust based on network location alone.

• TLS coverage report for internal services
• mutual TLS or service mesh evidence
• policy stating that internal network is untrusted
• exceptions register for legacy plaintext protocols

• internal HTTP services remain unencrypted because they are inside the firewall
• no mutual authentication between services
• VPN treated as a trust boundary that bypasses ZTA

Grant access to enterprise resources on a per session basis. Trust is evaluated at each request and is not perpetuated by long lived tokens that allow indefinite access to other resources.

• token lifetime policy by resource sensitivity
• session re evaluation triggers in policy engine
• audit log demonstrating per session decisions
• design document for continuous access evaluation

• long lived refresh tokens issued without re evaluation
• no policy reasserted on context changes
• session lifetime tied to legacy SSO rather than risk

Make access decisions using dynamic policy that incorporates user identity, device posture, application sensitivity, and behavioral attributes. Static IP based or group based rules alone are not sufficient.

• policy engine rule library
• attribute source catalog (IdP, MDM, EDR, risk engine)
• decision log sample showing attribute influence
• review cadence for policy effectiveness

• policy still primarily group based
• device posture not consumed by the policy engine
• no logging of which attributes influenced a decision

Continuously measure and monitor the security posture of devices and workloads. Posture signals must feed back into the policy engine so that access can be tightened or revoked when integrity drops.

• device compliance dashboard
• telemetry feed catalog into the policy engine
• examples of access revocation driven by posture change
• service level objectives for posture data freshness

• posture data refreshed daily, too slow for access decisions
• managed devices in scope but personal devices unmonitored
• no automatic action when posture drops

Authentication and authorization are strict, enforced before access, and re evaluated as risk signals change. Step up authentication is applied when risk increases, and weak factors are not accepted for sensitive resources.

• authentication factor catalog with assurance levels
• step up policy mapped to resource sensitivity
• continuous access evaluation events in IdP logs
• phishing resistant factor adoption metrics

• SMS or push factors still accepted for sensitive resources
• step up not configured for high risk transactions
• session continues unchanged after risk signal escalates

Collect and analyze data about asset state, network activity, and access decisions, and use the results to improve the security posture and policy quality. Feedback should be measurable, not anecdotal.

• analytics dashboard for ZTA programme
• examples of policy changes driven by telemetry
• key risk and key performance indicators
• quarterly programme review

• telemetry collected but never reviewed against policy
• no metrics tying programme spend to risk reduction
• logs siloed by tool rather than fused

Stand up a Policy Engine that decides whether to grant or deny access by combining policy, trust algorithm, and signals from external data sources. The engine must support deterministic logic that auditors can replay.

• policy engine architecture document
• trust algorithm specification
• decision replay capability evidence
• high availability configuration

• policy engine decisions not logged in a way that supports replay
• trust algorithm opaque to the security team
• single point of failure for access decisions

Implement a Policy Administrator that executes the decisions made by the Policy Engine by establishing or shutting down communication paths between subject and resource. Decisions and the actions taken must be logged consistently.

• Policy Administrator integration with PEP fleet
• audit log showing session start and revocation events
• incident playbook covering forced session termination
• redundancy and failover design

• Policy Administrator unable to terminate established sessions
• logs lack correlation between decision and action
• no failover configured for Policy Administrator

Deploy Policy Enforcement Points in front of every protected resource, whether at the application, gateway, micro service, or network layer. Coverage gaps undermine the entire architecture.

• PEP inventory mapped to resource list
• bypass detection logic in monitoring
• exception register for resources without PEP
• phased migration plan to close coverage gaps

• legacy applications excluded indefinitely
• PEP bypass detected only after incident
• no measurement of resources still relying on perimeter trust

Uses a single PEP gateway portal to broker access so that no agent is required on the requesting device, at the cost of limited visibility into the device.

• Resource portal configuration
• Evidence of brokered access through the portal PEP

• Limited device posture visibility via portal
• Portal bypass routes to resources

Runs vetted applications or processes in sandboxed compartments on the asset, isolating them from the rest of the device and from local attacks.

• Sandboxing configuration for vetted applications
• Isolation boundary evidence

• Applications running outside the sandbox
• Weak isolation allowing local compromise

Enterprise network requirements enabling ZTA, including basic connectivity for assets, distinct logical access control, observable network traffic, and resources unreachable without going through a PEP.

• Network design showing resources reachable only via PEP
• Evidence all traffic is observable and logically segmented

• Resources reachable without traversing a PEP
• Unobservable or untrusted network segments

The trust algorithm evaluates each request in isolation, or takes subject history and request patterns into account for a contextual access decision.

• Evidence the TA uses subject history/context
• Contextual signals incorporated into decisions

• Each request evaluated in isolation without context
• No use of behavioral history

The trust algorithm either requires a set of qualifying criteria to be met, or computes a single confidence score evaluated against a threshold to grant access.

• Documented trust algorithm logic (criteria or score based)
• Thresholds and qualifying criteria definitions

• Undocumented or static trust criteria
• Score thresholds not risk-justified

Splits the policy enforcement point between a device-installed agent and a resource-side gateway that connect only after the policy administrator approves the session.

• Device agent and resource gateway deployment design
• Evidence that connections require PA approval

• Agents not installed on all in-scope devices
• Direct resource access bypassing the gateway

Places a gateway PEP at the boundary of a resource enclave (a group of resources), suitable for legacy applications or on-premises data centers that cannot protect resources individually.

• Enclave gateway placement diagram
• List of resources protected per enclave PEP

• Over-broad enclaves reducing granularity
• Lateral movement possible within an enclave

Creates, stores, and manages enterprise user accounts and identity records, including the subject attributes used by the policy engine.

• Identity store and account lifecycle records
• Subject attribute schema used in access decisions

• Orphaned or stale accounts
• Attributes not synchronized to the policy engine

Generates and logs certificates issued by the enterprise to resources, subjects, services, and applications.

• Enterprise PKI / certificate issuance logs
• Certificate inventory for resources, subjects, and services

• Self-signed or unmanaged certificates in use
• No certificate lifecycle or revocation process

Collects security-centric information for analysis to refine policies and warn of possible active attacks against enterprise assets.

• SIEM data sources and correlation rules
• Evidence that SIEM findings refine access policy

• SIEM alerts not fed back into policy refinement
• Insufficient coverage of ZTA components

Catalog the subjects (human users and non-person entities) and their privileges as a precursor to developing a zero trust architecture.

• Catalog of subjects (users and NPEs) and privileges
• Privilege review records

• Incomplete actor inventory
• Excessive standing privileges

Inventory and monitor enterprise-owned and non-enterprise assets, including hardware, digital artifacts, and their current configuration state.

• Enterprise asset inventory with configuration state
• Monitoring of non-enterprise assets

• Shadow IT and unmanaged assets
• Inventory not continuously maintained

Define the criteria and subject/resource attributes the policy engine uses to grant or deny access for the candidate resource.

• Defined access criteria and attributes per candidate resource
• Policy approval records

• Policies too permissive at cutover
• Attributes unavailable to enforce policy

Identify business processes and data flows, evaluate their risk, and prioritize which to migrate to ZTA, often starting with lower-risk processes.

• Business process and data flow mapping with risk ratings
• Prioritized ZTA candidate list

• Processes and data flows undocumented
• Risk not used to sequence migration

The risk associated with automated agents (NPEs) configuring and enforcing policy, including false positives and false negatives in automated decisions.

• Controls over non-person entities administering policy
• Review of automated decision false positive/negative rates

• Automated agents with unchecked authority
• No human oversight of automated policy changes

Applies ZTA to accommodate visitors and contracted service providers who require limited, controlled access to specific enterprise resources.

• Access policy for contractors and nonemployees
• Time-bound and scoped access records

• Contractors granted standing broad access
• No deprovisioning at engagement end

Applies ZTA to enable secure resource sharing between two distinct organizations through policies governing cross-enterprise access.

• Cross-enterprise collaboration access policies
• Federation/trust agreement evidence

• Shared resources lacking granular cross-org policy
• Unverified external identities

Applies ZTA where applications and data sources are hosted across multiple cloud providers, securing direct cloud-to-cloud access without backhauling through the enterprise.

• Multi-cloud access architecture
• Evidence of secured cloud-to-cloud access

• Cloud-to-cloud traffic implicitly trusted
• Inconsistent policy across cloud providers

Applies ZTA to resources accessed by the general public or registered customers who are not enterprise-managed subjects.

• Policy separating public-facing from internal resources
• Customer identity assurance evidence

• Public services on the same trust plane as internal
• Weak customer authentication

Applies ZTA to an organization with a headquarters plus geographically dispersed locations and remote workers that have no full enterprise-owned network.

• ZTA design for remote workers and satellite sites
• Policy coverage for off-network access

• VPN-only model treated as zero trust
• Remote sites outside policy enforcement

Gathers information about the current state of enterprise assets and applies updates to configuration and software, feeding asset posture to the policy engine for access decisions.

• CDM system configuration and asset inventory feed
• Evidence that device posture informs access decisions
• Patch and configuration state reports

• Asset posture not actually consumed by the policy engine
• Unmanaged or unknown assets not covered by CDM

Ensures the enterprise remains compliant with applicable regulatory regimes and supplies the policy rules the enterprise must enforce.

• Mapping of regulatory obligations to enforced access policies
• Compliance system feeding policy rules into the PE

• Compliance requirements documented but not encoded as enforceable policy
• No traceability from regulation to policy rule

The attributes, rules, and policies about access to enterprise resources that serve as the starting point for authorizing access to a resource.

• Documented data access policies and attribute rules
• Attribute-to-policy mapping used by the PE

• Access policies coarse-grained rather than per-resource
• Attributes not authoritatively sourced

Aggregates asset logs, network traffic, and resource access actions to provide near real-time feedback on the security posture of enterprise systems.

• Centralized activity log architecture
• Log coverage matrix for assets, network, and resource access
• Retention and protection settings

• Gaps in log coverage of resource access events
• Logs not analyzed in near real time

External sources providing information on newly discovered attacks and vulnerabilities to help the policy engine make and update access decisions.

• Threat intelligence feed subscriptions and integration config
• Evidence that intel updates trust/access decisions

• Threat feeds collected but not operationalized into policy
• Stale or single-source intelligence

The risk that attackers obtain valid credentials (for example via phishing or social engineering) or that insiders abuse legitimate access.

• MFA and phishing-resistant authentication evidence
• Insider threat monitoring controls

• Password-only access to sensitive resources
• No detection of anomalous credential use

The risk that an attacker disrupts or denies access to the policy administrator or PEP, blocking legitimate access decisions.

• Resilience and redundancy design for PA/PEP
• DoS protection evidence

• Single points of failure in the decision path
• No capacity or DoS testing

The risk arising from dependence on proprietary or non-interoperable data formats and components across the ZTA.

• Use of open standards across ZTA components
• Vendor lock-in risk assessment

• Proprietary formats preventing component substitution
• No interoperability testing

The risk that stored monitoring data and network/system information become high-value targets for attackers seeking to map and exploit the environment.

• Protection controls for stored monitoring and network data
• Access controls on log/telemetry stores

• Monitoring data stored without strong access control
• Sensitive network maps left unprotected

The risk that the policy engine and policy administrator configuration are improperly accessed or manipulated, corrupting access decisions across the enterprise.

• Access controls and change management for PE/PA configuration
• Audit logs of policy administrator actions

• Broad admin access to policy components
• No monitoring of PE/PA configuration changes

The risk that encrypted or unanalyzable traffic limits the enterprise's ability to inspect, analyze, and act on network activity.

• Encrypted traffic inspection or metadata analysis approach
• Coverage of east-west traffic

• Blind spots in encrypted traffic
• No analysis of internal traffic

Adopt zero trust as a staged programme rather than a single deployment. Define a roadmap that prioritizes high value resources, identifies dependencies, and measures progress through declared milestones.

• multi year ZTA roadmap
• prioritized resource backlog
• milestone report with measured outcomes
• executive sponsor briefings

• roadmap focuses on tools rather than resources protected
• no measurement of resources actually behind ZTA controls
• executive sponsorship lapses after initial funding

Ensure that ZTA integrates with existing security investments including SIEM, EDR, MDM, and ticketing systems. Avoid building parallel stacks that compete for telemetry and create blind spots.

• integration matrix between ZTA components and existing controls
• ticketing workflow design for access exceptions
• telemetry consolidation plan
• tool retirement decisions log

• EDR posture not consumed by policy engine
• ticketing not integrated for access provisioning
• duplicate telemetry stores impose unnecessary cost

Identify and treat threats specific to zero trust deployments, including disruption of the Policy Engine, theft of administrator credentials, stolen authentication tokens, and supply chain risk in policy components.

• threat model covering Policy Engine, Administrator, and PEPs
• privileged access workflow for ZTA components
• supply chain due diligence for ZTA vendors
• tabletop exercise covering policy engine outage

• policy engine administrators not on privileged access workstations
• no tested fallback for policy engine outage
• supply chain assessment limited to perimeter vendors

Integrate Continuous Diagnostics and Mitigation data sources so that asset state, software inventory, and vulnerability data are available to the Policy Engine in near real time.

• data feed catalog from CDM systems
• data freshness service level objective
• schema mapping document
• integrity check logs on incoming feeds

• data feeds run as nightly batch when decisions are made hourly
• schemas mismatch causing dropped attributes
• no validation of source data integrity

Treat the Identity Provider as a critical input to the Policy Engine. Maintain accurate user and service identity attributes including role, group membership, employment status, and risk score.

• identity attribute catalog used by policy engine
• joiner mover leaver process
• service account inventory and ownership register
• risk score consumption design

• leavers retain access for weeks because attributes lag
• service account ownership unclear
• no integration of risk score from IdP into decisions

Select ZTA components that fit the workflow, perform initial deployment in monitoring/observation mode, then expand the ZTA across the enterprise.

• Initial deployment in monitoring mode evidence
• Expansion plan and rollback procedures

• Enforcement enabled without an observation phase
• No rollback or staged expansion plan

Document the trust algorithm that combines inputs into a decision. Specify which inputs are mandatory, which are weighted, and how thresholds are determined. Treat the algorithm as a controlled change managed artifact.

• trust algorithm specification
• change history with approvals
• examples of decisions explained by the algorithm
• review cadence by security and risk leadership

• algorithm exists only inside the policy product configuration
• no change history for weighting adjustments
• auditors cannot replay decisions