Remote access gateways sit on the internet edge, accept connections from anyone who can reach them and, once a user is through, often grant far more of the network than that user needs. This health check is a recurring review of the remote access estate you already run: traditional remote access VPN concentrators, zero trust network access (ZTNA) brokers and connectors, or the mix most organisations have while they migrate from one to the other. It gives 12 metrics with formulas and thresholds, the data to collect, the red flags that cannot wait and a findings log. It is for network and identity engineers, remote access platform owners and the managers who sign off external access. It answers the practical questions behind a VPN audit or a ZTNA review: how exposed the gateways are, how much each connection can reach, and whether anyone would notice misuse.
This page measures the estate; it does not explain how to design remote access. For the identity design behind remote access read the Remote Access Identity Guide, and for how ZTNA works the ZTNA Guide. The metrics are vendor-neutral and apply to appliance, virtual and cloud-delivered gateways.
What this health check covers
The review covers every remote access entry point for workforce and third parties: VPN gateways and concentrators, ZTNA brokers, the connectors or agents that publish internal applications to them, the access policies and connection profiles they enforce, the client software on endpoints, and the logs they produce. Operational technology remote access and web proxy or CASB controls have their own health checks and are out of scope here, as are site-to-site tunnels except where a machine identity is used for always-on device tunnels.
- Who runs it: the remote access platform owner collects the data; the identity team validates authentication metrics; security operations validates logging; the head of infrastructure security or the CISO signs off.
- How it differs from the identity design guide: the design guide tells you how remote access should authenticate and authorise. This health check measures how close the running estate is to that design and whether it is drifting.
- Mixed estates: measure VPN and ZTNA together with one denominator where a metric applies to both, and report the split. A good ZTNA score with a forgotten legacy VPN beside it is the most common gap this review finds.
Key takeaways
- The gateway is a target in its own right. Remote access appliances are a recurring entry point for attackers, so software currency and exposed services carry the strictest thresholds here.
- Measure reach, not just access. NIST SP 800-207 describes zero trust as granting no implicit trust based on network location. The share of policies that grant whole network ranges rather than named applications shows how far you are from that.
- Every connection should prove the user and the device. Track authentication through the central identity provider with multi-factor authentication, and device posture actually enforced rather than only reported.
- Third-party and machine access drift fastest. Supplier accounts without expiry dates and device tunnel certificates without owners outlive the reason they were created.
- Logs must name the user, the device and the destination. Connection logs that record only an IP address cannot support an investigation.
How to use this template
Copy the metrics table and the findings log into your own tracker and run this remote access health check each quarter, with the exposure and software checks monthly. Collect each figure from the data source types described, score it against the green, amber and red bands, and log every amber or red result as a finding with an owner and a due date. Where VPN and ZTNA platforms coexist, record each metric per platform and in total. Keep each completed review so the trend is visible to the approver. Replace bracketed placeholders such as [Organisation], [Role] and [Date] with your own values.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Gateway software and security advisory check | Weekly, and on every supplier security advisory | Remote access platform owner | Head of infrastructure security | Running versions per gateway and connector, advisories reviewed, decisions |
| External exposure scan of gateways | Monthly, and after any change at the edge | Security operations | Head of infrastructure security | Scan results listing every service answering on gateway addresses |
| Third-party access review | Quarterly | Supplier relationship owners | Remote access platform owner | Supplier account export with sponsor, expiry and last connection |
| Full metrics review (this page) | Quarterly | Remote access platform owner | CISO or head of infrastructure security | Metrics table, policy and profile exports, findings log |
| Cryptographic configuration review | Twice a year, and when the cryptographic policy changes | Network engineering | Security architecture | Tunnel and listener configuration export compared with policy |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Gateway" means any internet-facing VPN concentrator or ZTNA entry point you operate; "connector" means an internal component that publishes applications to a ZTNA broker. "Access policy" means a VPN connection profile or a ZTNA access rule.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| ZRA-01 | Remote access entry points known | Remote access gateways and connectors found by external scans and internal discovery that are recorded in the asset inventory with an owner ÷ remote access gateways and connectors found | Asset inventory, external attack surface scan, internal discovery scan | 100% | 95% to below 100% | Below 95%, or any unrecorded gateway answering on the internet |
| ZRA-02 | Gateway and connector software currency | Gateways and connectors running a version with no outstanding supplier security fix older than 7 days ÷ gateways and connectors | Device and connector inventory with running version, supplier security advisories | 100% | 90% to below 100%, gaps scheduled within 14 days | Below 90%, any fix outstanding beyond 14 days, or any end-of-support version |
| ZRA-03 | Services exposed beyond the access listener | Gateways answering on the internet with any service other than the remote access listener itself (for example administrative web pages, SSH or management APIs) ÷ gateways | External exposure scan results | 0% | Not used: any exposure is red | Above 0% |
| ZRA-04 | Central authentication with MFA | Remote access authentications in the period that went through the central identity provider and satisfied multi-factor authentication ÷ all remote access authentications | Gateway authentication logs, identity provider sign-in logs | 99% or above | 95% to below 99% | Below 95%, or any local gateway account used for user access |
| ZRA-05 | Application-scoped access policies | Access policies that grant named applications or specific host and port pairs ÷ all access policies (count policies granting a subnet, a whole network or "any" in the denominator only) | VPN profile and split tunnel route export, ZTNA access rule export | 90% or above | 60% to below 90% | Below 60% |
| ZRA-06 | Device posture enforced | Remote access connections in the period where a device posture or managed device check was evaluated and a failure would have blocked or restricted access ÷ all remote access connections | Gateway connection logs with posture result, posture policy configuration | 95% or above | 80% to below 95% | Below 80% |
| ZRA-07 | Session lifetime within policy | Access policies whose maximum session length and idle timeout are at or below the organisation's standard ÷ all access policies | Profile and policy export (session and idle timers) | 100% | 90% to below 100% | Below 90%, or any policy with no session limit |
| ZRA-08 | Split tunnel exceptions approved | Split tunnel or bypass exceptions with an owner, a reason and a review date within the last 12 months ÷ all split tunnel or bypass exceptions | VPN client profile export, exception register | 95% or above | 80% to below 95% | Below 80% |
| ZRA-09 | Gateway-enforced end dates on supplier access | Supplier and contractor access policies or groups on the gateway configured with an enforced end date or time-bound access window of no more than 12 months ÷ supplier and contractor access policies or groups on the gateway | Gateway access policy export, supplier register | 100% | 95% to below 100% | Below 95% |
| ZRA-10 | Deprecated tunnel cryptography | Gateway listeners and tunnel profiles that allow protocols, versions or algorithms outside the organisation's cryptographic policy (for example IKEv1 or TLS below 1.2) ÷ gateway listeners and tunnel profiles | Gateway configuration export, cryptographic policy | 0% | Allowed but unused in the period, with a removal date | Allowed and used |
| ZRA-11 | Device tunnel identities owned | Machine certificates, device tunnel keys and connector registration credentials with a recorded owner, an expiry within policy and an inventory entry ÷ all such credentials in use | Certificate inventory, connector registration records, gateway configuration | 98% or above | 90% to below 98% | Below 90% |
| ZRA-12 | Attributable connection logs | Gateways and connectors whose connection logs (user, device, source address, destination application or network, start and end time) reached the central log platform in the last 24 hours ÷ gateways and connectors | Log platform source list, gateway log forwarding configuration | 98% or above | 90% to below 98% | Below 90%, or any gateway sending no logs |
Reading the results together
ZRA-01 to ZRA-03 measure the gateway as an attack surface. ZRA-04, ZRA-06 and ZRA-09 measure who and what is allowed to connect. ZRA-05, ZRA-07 and ZRA-08 measure how much a connection can reach and for how long. ZRA-10 to ZRA-12 measure the plumbing that keeps sessions trustworthy and investigable. An estate that scores well on authentication but poorly on ZRA-05 has strong front doors on a building with no internal walls; that is the gap moving from VPN to ZTNA is meant to close.
The strict bands on ZRA-02 and ZRA-03 reflect how often edge devices are exploited. CISA hosts a set of edge device guidance from the Canadian Centre for Cyber Security, the UK National Cyber Security Centre and the Australian Signals Directorate's Australian Cyber Security Centre, including mitigation strategies for edge devices and the NCSC's digital forensics monitoring specification for network devices. The ATT&CK techniques these metrics are built to reduce are T1133 External Remote Services, T1190 Exploit Public-Facing Application, T1078 Valid Accounts and, after access, T1021 Remote Services for lateral movement.
How to collect the data
- Discover entry points. Compare the asset inventory with external scan results and the cloud and network teams' lists of gateways and connectors for ZRA-01. Look specifically for gateways left running after a migration and for remote access services enabled on firewalls.
- Record running versions of every gateway, broker component you operate and connector, and compare them with the supplier's security advisories and support lifecycle pages for ZRA-02.
- Scan gateway addresses from the internet for every listening service. Anything other than the remote access listener counts for ZRA-03.
- Join gateway and identity provider logs for ZRA-04. Authentications that appear in the gateway log with no matching identity provider sign-in point to local accounts or certificate-only access.
- Export access policies: VPN connection profiles with their routes and access control lists, and ZTNA rules with their destinations. Classify each destination as application-scoped or network-wide for ZRA-05, and read session and idle timers for ZRA-07.
- Read posture results from connection logs for ZRA-06. A posture check configured in "report only" or "warn" mode does not count as enforced. See the Device Trust and Posture Guide.
- Export client profiles and the exception register for ZRA-08; VPN split tunnelling explains which exceptions are reasonable.
- Join remote access groups to the supplier register for ZRA-09, checking that each supplier policy carries an enforced end date on the gateway itself.
- Export listener and tunnel settings and compare them with the cryptographic policy for ZRA-10; use connection logs to see which deprecated options are actually negotiated.
- Reconcile log sources on the central platform against the gateway and connector list for ZRA-12. The VPN and Firewall Log Detection Guide covers which events to keep.
Where identity fits
Remote access holds non-human identities that user reviews miss: machine certificates for always-on device tunnels, registration tokens that enrol ZTNA connectors, service accounts the gateway uses to query the directory, and API keys used by automation that changes policies. ZRA-11 covers the first two; include the directory service account and automation keys in the platform owner's access review. See the Service Account Security Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.
Red flags that need action now
- A gateway running a version affected by a supplier advisory under active exploitation, or an end-of-support gateway still answering on the internet.
- An administrative web page, SSH or management API reachable from the internet on a gateway address.
- A remote access gateway nobody owns, or one left running after a migration.
- A local gateway account, or a shared account, used for user remote access.
- A supplier account with network-wide access and no expiry date.
- Successful connections from one account at the same time from distant locations, or from hosting provider address ranges, with no triage record.
- A gateway that has stopped sending connection logs.
- New administrator accounts, new access policies or changed authentication settings on a gateway with no change record, which may indicate tampering after compromise. Follow the Edge Device Compromise Investigation Playbook.
Findings log
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-ZRA-01 | [Description, population and figure, e.g. 41 of 96 VPN profiles grant whole internal subnets] | ZRA-05 | [Critical / High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
| HC-ZRA-02 | [Description] | ZRA-02 | [Severity] | [Role] | [Date] | [Status] |
| HC-ZRA-03 | [Description] | [Metric ID] | [Severity] | [Role] | [Date] | [Status] |
Suggested due dates: red flags within 7 days, red metrics within 30 days, amber metrics within 90 days. Narrow network-wide access in stages: log the destinations each group actually uses for 30 days, create application-scoped policies for those destinations, move a pilot group, then retire the broad profile, keeping it disabled rather than deleted for one cycle so you can roll back. Risk acceptance needs the platform owner's signature and an expiry date.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Unknown, outdated or exposed gateways (ZRA-01 to ZRA-03) | Edge Device Security Guide, VPN Security Guide and Edge Device End of Life Replacement Playbook |
| Authentication and posture gaps (ZRA-04, ZRA-06) | Remote Access Identity Guide, Phishing-Resistant MFA Guide and Device Trust and Posture Guide |
| Network-wide reach and long sessions (ZRA-05, ZRA-07, ZRA-08) | ZTNA Guide, Secure Remote Access Beyond VPN Guide and VPN split tunnelling |
| Supplier access without expiry (ZRA-09) | Third-Party Access Guide and Remote Access Policy Template |
| Deprecated cryptography (ZRA-10) | VPN Protocols Compared: WireGuard, IPsec, OpenVPN Guide and Post-Quantum Readiness for VPNs and IKEv2 Guide |
| Device tunnel identities and logging (ZRA-11, ZRA-12) | Machine Identity, PKI and Certificate Lifecycle Guide and VPN and Firewall Log Detection Guide |
Related guides
- Remote Access Identity Guide: the identity design this review measures against.
- ZTNA Guide: how ZTNA brokers and connectors work.
- Zero Trust Maturity Model Guide: where these results place your zero trust programme.
- Third-Party Access Health Check: the programme-level review of supplier access across all channels.
- Edge Device Compromise Investigation Playbook: response when a red flag points to a compromised gateway.
References
- NIST: SP 800-207 Zero Trust Architecture
- NIST: SP 800-46 Rev. 2 Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
- NIST: SP 800-53 Rev. 5 (AC-17 Remote Access, AC-17(1) Monitoring and Control, AC-17(2) Protection of Confidentiality and Integrity Using Encryption, AC-12 Session Termination, SC-7(7) Split Tunneling for Remote Devices, IA-2(1) Multi-factor Authentication to Privileged Accounts, IA-3 Device Identification and Authentication, SI-2 Flaw Remediation, AU-12 Audit Record Generation)
- NIST: Cybersecurity Framework 2.0 (PR.AA-03 users, services and hardware are authenticated, PR.IR-01 networks and environments protected from unauthorised logical access, PR.PS-02 software maintained, DE.CM-01 networks monitored)
- CISA: Guidance and Strategies to Protect Network Edge Devices
- CISA: Zero Trust Maturity Model
- MITRE ATT&CK: T1133 External Remote Services and T1190 Exploit Public-Facing Application
Related NHI Mgmt Group resources: Remote Access Identity Guide, ZTNA Buyer's Guide, CASB and SSE platform health check, Edge Device Exploitation by Threat Actors Guide.