Most zero trust programmes report activity, such as tools bought and pilots run, rather than how much of the estate is actually governed by per-request, identity-based access decisions. This health check gives ten programme progress metrics, at least one per pillar (identity, devices, networks, applications and workloads, data) plus the cross-cutting visibility capability, each with a formula, a data source type and green, amber and red thresholds. It is run quarterly by the zero trust programme lead and reported to the security steering group. It does not place you on a maturity stage: that is the job of the Zero Trust Maturity Model Guide and the CISA Zero Trust Maturity Model Guide. It also does not check how the ZTNA broker or VPN gateway is configured; that is the ZTNA and remote access VPN health check. This page measures coverage: how far the programme has moved the estate, pillar by pillar, between assessments.
What this health check covers
The ten metrics follow the tenets in NIST SP 800-207: no implicit trust from network location or asset ownership, all communication secured regardless of location, access granted per session with the fewest privileges needed, dynamic policy using the state of identity and device, and continuous monitoring of asset posture. Each metric turns one tenet into a ratio you can collect from systems you already run. The identity design behind several of them is explained in the Zero Trust Identity Guide; this page measures it and does not repeat it.
| Pillar or capability | Metrics | Tenet measured (NIST SP 800-207) |
|---|---|---|
| Identity | ZTP-03 MFA coverage, ZTP-08 continuous authentication share, ZTP-09 least privilege score | Strictly enforced authentication and authorisation; per-session, least privilege access |
| Devices | ZTP-02 device posture enforcement | Monitor and measure the integrity and posture of all assets; dynamic policy |
| Networks | ZTP-04 microsegmentation coverage, ZTP-05 legacy VPN users, ZTP-06 east-west policy coverage, ZTP-07 encrypted internal traffic | No trust from network location; all communication secured |
| Applications and workloads | ZTP-01 applications behind a policy enforcement point | Access to individual resources on a per-session basis |
| Visibility and analytics (cross-cutting); data | ZTP-10 telemetry coverage | Collect as much information as possible about the state of assets and requests |
Key takeaways
- Measure coverage of the estate, not tool deployment: every metric has the full in-scope population as its denominator, so an unmanaged application or device lowers the score.
- Non-human identities count: service accounts, workloads and agents sit inside ZTP-03, ZTP-07, ZTP-08 and ZTP-09; a programme that measures only staff sign-ins overstates progress.
- Legacy access is a metric of its own: users who still hold network-level VPN access show how much implicit trust remains, whatever else has been deployed.
- Report pillars side by side: pillars move at different speeds, so present ten numbers and their trend, never one blended score.
- Thresholds are starting points: the values below are NHI Mgmt Group recommendations; record your own target per metric and the reason for any change.
How to use this template
Copy the metrics table and the findings log into your tracker. Fix the scope first: list the in-scope applications, devices, network segments, human and non-human identities, and record the count for each, because those counts are the denominators. Then collect each figure from the data sources described, score it against the thresholds and log every amber or red result as a finding with an owner and due date. Keep each quarterly run so the trend can be reported. Re-baseline the denominators each quarter: a score that rises because the inventory shrank is not progress.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Scope and denominator refresh | Quarterly, before the KPI run | Zero trust programme office | Zero trust programme lead | Application, device, segment and identity inventories with counts |
| Full KPI run (ZTP-01 to ZTP-10) | Quarterly | Zero trust programme lead | CISO or security steering group chair | KPI workbook, findings log, steering minutes |
| Legacy VPN and exception review (ZTP-05) | Monthly | Network and identity engineering | Zero trust programme lead | VPN group export, exception register with expiry dates |
| Board or risk committee summary | Half-yearly | CISO | Board or delegated committee | Pillar trend chart, top findings, decisions minuted |
| Independent re-performance | Yearly | Internal audit | Audit committee | Re-performed samples and variance notes |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "In-scope application" means an application in your inventory used by staff, suppliers or services. "Policy enforcement point" (PEP), as used in NIST SP 800-207, means a component that allows, denies or ends a session based on a policy decision: an identity-aware proxy, a ZTNA broker, an identity provider with conditional access, an API gateway or a service mesh sidecar.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| ZTP-01 | Applications behind a policy enforcement point | In-scope applications reachable only through a PEP that evaluates identity and device per session / in-scope applications | Application inventory; identity provider application registrations; ZTNA and proxy published application lists; firewall rules showing direct paths | ≥ 90% | 60% to below 90% | < 60%, or any crown jewel application reachable directly |
| ZTP-02 | Device posture enforcement | Access policies for in-scope applications where a device compliance or posture signal is evaluated and a failure blocks or restricts access / access policies for in-scope applications | Conditional access and PEP policy exports; device management compliance policies | ≥ 90% | 70% to below 90% | < 70% |
| ZTP-03 | MFA coverage, phishing-resistant share | (a) Human sign-ins to in-scope applications that satisfied MFA / all human sign-ins; (b) privileged, remote and supplier sign-ins using FIDO2/WebAuthn or PKI / privileged, remote and supplier sign-ins | Identity provider sign-in logs with authentication method | (a) ≥ 99%; (b) ≥ 95% | (a) 95% to below 99%; (b) 70% to below 95% | (a) < 95%; (b) < 70% |
| ZTP-04 | Microsegmentation coverage | Workloads in scope (servers, virtual machines, containers) assigned to a segment with an enforced allow-list policy / workloads in scope | Segmentation platform, host firewall or cloud security group exports; CMDB workload list | ≥ 80%; 100% for crown jewel systems | 50% to below 80% | < 50%, or any crown jewel system unsegmented |
| ZTP-05 | Legacy VPN users | Active accounts holding network-level VPN access (subnet or full tunnel) / active accounts with any remote access; plus count of those unused for 30 days | VPN group membership; VPN connection logs; directory account status | ≤ 10% and falling, zero unused | 10% to 30%, or unused accounts with a removal date | > 30%, any unused account without a removal date, or any VPN access without MFA |
| ZTP-06 | East-west policy coverage | Observed internal flows between workloads that match an explicit allow rule / observed internal flows (default-allow and "any" rules count as unmatched) | Flow logs (cloud VPC flow logs, NetFlow, segmentation platform flow maps); rule exports | ≥ 90% | 60% to below 90% | < 60% |
| ZTP-07 | Encrypted internal traffic | Internal service-to-service and user-to-application connections using TLS 1.2 or later, or mutual TLS / internal connections observed | Flow logs with port and protocol; TLS inspection or sensor data; service mesh mTLS mode reports | ≥ 95% | 80% to below 95% | < 80%, or any cleartext authentication protocol in use |
| ZTP-08 | Continuous authentication share | Sessions to in-scope applications where the PEP re-evaluates risk or device signals during the session and can revoke it (CAEP or equivalent signal) / sessions to in-scope applications | Identity provider session and token logs; Shared Signals receiver configuration | ≥ 60% and rising | 25% to below 60% | < 25%, or session revocation untested |
| ZTP-09 | Least privilege score | Human and non-human identities with no standing privileged assignment and no unused entitlement older than 90 days / identities in scope | IGA and PAM exports; cloud entitlement reports; access activity data | ≥ 90% | 70% to below 90% | < 70% |
| ZTP-10 | Telemetry coverage | Data sources needed for access decisions and investigation (identity provider, PEPs, endpoint detection, flow logs, data access logs for sensitive stores) sending to the central log platform in the last 24 hours / required data sources | Log platform source list; required source register | ≥ 98% | 90% to below 98% | < 90%, or any PEP not logging decisions |
Notes on the formulas
- ZTP-01 counts exclusivity: an application published through a proxy that is also reachable over the flat network or VPN does not count. Check firewall rules for direct paths, which is the coverage question; broker configuration belongs to the ZTNA health check.
- ZTP-03 follows CISA guidance: CISA describes FIDO/WebAuthn as the only widely available phishing-resistant authentication, with PKI smart cards as the other strong option, and advises starting with administrators, help desk and the services that already support FIDO. See the Phishing-Resistant MFA Guide.
- ZTP-04 and ZTP-06 differ: ZTP-04 asks whether a workload has a segment policy at all; ZTP-06 asks whether the traffic actually observed is explained by explicit rules. A high ZTP-04 with a low ZTP-06 means segments exist with permissive rules. NSA's network and environment pillar guidance treats data flow mapping as the starting point for both.
- ZTP-07 includes machine traffic: NIST SP 800-207 states that all communication is secured regardless of network location, and OMB M-22-09 required US federal agencies to enforce HTTPS for all web and API traffic, including internal traffic. Count service accounts and workloads, not only browsers. See the mTLS Guide.
- ZTP-08 needs a test: a session counts only if revocation on a risk or device change has been tested in the quarter. OpenID CAEP 1.0 (published 29 August 2025) defines event types such as session-revoked, credential-change and device-compliance-change. See CAEP and Continuous Access Evaluation.
- ZTP-09 includes machines: service accounts, API keys and workload roles with standing administrator rights are often the largest gap. See the Least Privilege Techniques Guide and the Identity Security Metrics Guide.
Reading the results together
- ZTP-01 high, ZTP-05 high: applications are published through a PEP, but the old network path was never closed. Retire VPN groups as each application moves.
- ZTP-03 high, ZTP-02 low: strong authentication from any device. A stolen session on an unmanaged device still works.
- ZTP-04 high, ZTP-10 low: segmentation without telemetry; blocked lateral movement will go unnoticed and rules will drift.
- ZTP-08 low with ZTP-03 high: trust is decided once at sign-in and held for the life of the token, which is the implicit trust the programme set out to remove.
How to collect the data
- Fix the denominators: export application, device, workload and identity inventories (including service accounts and workload identities) and agree the in-scope list with owners.
- Export access policy: identity provider conditional access, ZTNA and proxy published applications, API gateway routes, for ZTP-01, ZTP-02 and ZTP-08.
- Pull sign-in logs: 30 days of identity provider sign-ins with authentication method and device state for ZTP-03.
- Pull network evidence: segmentation and firewall rule exports and 7 to 30 days of flow logs for ZTP-04, ZTP-06 and ZTP-07; VPN group membership and connection logs for ZTP-05.
- Pull entitlement data: IGA, PAM and cloud entitlement exports with last-used dates for ZTP-09.
- Check the log platform: compare active sources with the required source register for ZTP-10.
- Trace samples: pick five applications and five service accounts and walk each through every relevant metric. A metric that cannot be traced is reported amber at best.
Red flags that need action now
- An active VPN account with network-level access that has not been used for 30 days or does not require MFA (ZTP-05). The Colonial Pipeline attack began with a legacy VPN account that was no longer used, still active and not protected by MFA.
- A crown jewel application reachable directly from the internal network or VPN, bypassing the PEP (ZTP-01).
- Privileged administrators signing in without phishing-resistant MFA (ZTP-03).
- A default-allow or "any to any" rule between production segments (ZTP-06).
- Cleartext authentication or management protocols observed on internal networks (ZTP-07).
- Service accounts or workload roles with standing administrator rights and no owner (ZTP-09).
- A PEP that does not log its allow and deny decisions centrally (ZTP-10).
Findings log
| Finding ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-ZTP-01 | [Number] in-scope applications still reachable directly over VPN | ZTP-01, ZTP-05 | [High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
| HC-ZTP-02 | [Number] access policies with no device signal | ZTP-02 | [Severity] | [Role] | [Date] | [Status] |
| HC-ZTP-03 | [Percentage] of internal flows matched only by permissive rules | ZTP-06 | [Severity] | [Role] | [Date] | [Status] |
| HC-ZTP-04 | [Number] service accounts with standing privileged access | ZTP-09 | [Severity] | [Role] | [Date] | [Status] |
| HC-ZTP-05 | [Finding] | [Metric] | [Severity] | [Role] | [Date] | [Status] |
Group items with a shared root cause into one finding. A risk accepted finding carries an expiry date and the approver's name and is reopened at the next quarterly run.
Framework mapping
| Metric | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| ZTP-01, ZTP-02, ZTP-08 | AC-17 Remote Access; SI-4 System Monitoring | PR.AA-05 |
| ZTP-03 | IA-2(1) and IA-2(2) Multi-factor Authentication | PR.AA-03 |
| ZTP-04, ZTP-05, ZTP-06 | SC-7 Boundary Protection; SC-7(5) Deny by Default, Allow by Exception | PR.IR-01 |
| ZTP-07 | SC-8 Transmission Confidentiality and Integrity | PR.DS-02 |
| ZTP-09 | AC-6 Least Privilege; AC-2 Account Management | PR.AA-05 |
| ZTP-10 | CA-7 Continuous Monitoring; SI-4 | DE.CM-01, DE.CM-09 |
| The health check itself | PM-6 Measures of Performance; CM-8 System Component Inventory | GV.OV-03, ID.AM-01, ID.AM-02 |
Remediation map
| Finding type | Metrics | Where the fix is explained |
|---|---|---|
| Applications outside a PEP; legacy VPN | ZTP-01, ZTP-05 | ZTNA Guide; ZTNA vs VPN |
| Weak or missing MFA, no device signal | ZTP-02, ZTP-03 | Phishing-Resistant MFA Guide; Zero Trust Identity Guide |
| Segmentation and east-west gaps | ZTP-04, ZTP-06 | Network Segmentation Guide; Microsegmentation vs ZTNA |
| Cleartext internal traffic | ZTP-07 | mTLS Guide; Service Mesh Security Guide |
| Sign-in-only trust | ZTP-08 | CAEP and Continuous Access Evaluation; Shared Signals Framework Guide |
| Standing privilege, machine identities | ZTP-09 | Least Privilege Techniques Guide; Workload Identity Federation Guide |
| Missing telemetry | ZTP-10 | SIEM Log Source Onboarding Checklist |
Related guides
- Zero Trust Maturity Model Guide: place these results on a maturity stage.
- Zero Trust Implementation Roadmap Template: turn red findings into roadmap items.
- Zero Trust Executive Briefing: the board view of the same programme.
- Security Metrics and KPIs Programme Guide: how to run a metrics programme around these KPIs.
References
- NIST: SP 800-207 Zero Trust Architecture
- CISA: Zero Trust Maturity Model
- OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- NSA: Advancing Zero Trust Maturity Throughout the Network and Environment Pillar
- CISA: Implementing Phishing-Resistant MFA
- OpenID Foundation: Continuous Access Evaluation Profile 1.0
Related NHI Mgmt Group resources: Zero Trust Identity Guide, CISA Zero Trust Maturity Model Guide, ZTNA and remote access VPN health check, Identity Security Metrics Guide.