A zero trust network access (ZTNA) broker or remote access VPN decides who reaches your internal applications from outside, so whoever controls its admin plane, connectors or certificates controls remote access for the whole organisation. NIST SP 800-207 names subversion of the access decision process as the first threat to a zero trust architecture: a misconfigured or compromised policy administrator can grant access that should be denied. This vendor-neutral guide covers that inside view for network, identity and platform engineers who run a cloud-delivered ZTNA service, a self-hosted broker, a VPN concentrator, or the mix most organisations have during migration. Confirm exact setting names in your supplier's documentation. For appliance hardening and patch timelines see the VPN Security Guide, and for how ZTNA works see the ZTNA Guide.
Key takeaways
- The access policy store is tier 0. Anyone who can edit ZTNA rules or VPN connection profiles can open any internal application to any user, so protect the console like a domain controller or identity provider.
- Connectors are privileged infrastructure inside your network. Their hosts, enrolment tokens and network reach decide how far a policy mistake or a compromised connector can travel.
- Certificates and trusts are the quiet crown jewels. Gateway TLS keys, device tunnel certificate authorities, connector credentials and identity provider signing trusts each let an attacker impersonate users, devices or the service itself.
- The platform runs on non-human identities. Directory bind accounts, SCIM tokens, management API keys and automation agents need an owner, a scope and an expiry like any other service account.
- Logs and configuration history must live outside the platform. Admin audit trails and scheduled configuration exports in a store remote access administrators cannot change make tampering visible and recovery fast.
What the platform holds and can do
NIST SP 800-207 splits zero trust access into a policy engine that makes the decision, a policy administrator that opens or closes the communication path, and policy enforcement points that enable, monitor and end connections. A ZTNA service maps these onto a broker or controller, connectors in front of applications, and usually an endpoint agent. A remote access VPN collapses most of them into one concentrator. Either way, the components below are what you are protecting.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Admin console and management API | Access rules, connection profiles, posture policy, admin roles, identity provider trust | Grants itself or others access to any application, weakens posture checks, adds a backdoor identity source | Separate admin identities, phishing-resistant MFA, privileged access workstations, two-person publishing |
| Policy decision logic | Rules, conditions, device and risk signals | Turns a deny into an allow without changing a user's groups (NIST SP 800-207 section 5.1) | Change control, configuration diffing, audited change logs |
| Connectors or application gateways | Outbound tunnels to the broker; reach to internal applications | A route into internal networks, or a host to pivot from | Dedicated hardened hosts, narrow network reach, protected enrolment credentials |
| VPN concentrator or self-hosted gateway | Internet listener, local accounts, directory bind credential, tunnel keys | Initial access (T1133, T1190), credential harvesting, traffic interception | Management plane off the internet, patching, logs off the box (see the VPN Security Guide) |
| Certificates and keys | Gateway TLS keys, device tunnel CA, connector credentials, SAML or OIDC signing trust | Impersonates the gateway, enrols rogue devices, forges sign-ins | Protected key storage, short validity, inventory, rotation plan |
| Logs and telemetry | Who connected, from which device, to which application | Erased or redirected to hide activity | Real-time export to a separate store, alerts on forwarding changes |
NIST SP 800-207 section 5.5 adds a point teams often miss: the tool that encodes access policy reveals which accounts and applications are most valuable, so it should have the most restrictive access policy in the estate and be reachable only from designated administrator accounts.
The admin plane: roles, console access and change control
| Role | Can do | Should not do |
|---|---|---|
| Platform administrator | Admin roles, identity provider trust, connector enrolment, log export, certificates | Day-to-day access rule edits |
| Access policy author | Draft application definitions and access rules | Publish to production, or approve their own change |
| Policy approver | Review and publish rule changes | Author the changes they approve |
| Operations and help desk | View connection status, look up a user's denied attempts, issue time-limited agent disable codes | Edit rules, posture policy or identity settings |
| Security analyst and auditor | Read connection logs, admin audit logs and configuration | Change anything |
- Two-person publishing: require a second approver to publish rule changes, through the product or through pull request review on exported rules.
- Separate admin identities: administrators sign in with dedicated admin accounts through the identity provider with phishing-resistant MFA, not with the same account they use for daily remote access. For self-hosted gateways, the Australian Signals Directorate's edge device practitioner guidance advises segregating edge devices from the corporate Active Directory forest and managing local accounts through a PAM system or secrets manager that can rotate them after use.
- Management plane off the internet: CISA BOD 23-02 names VPN concentrators and proxies among devices whose networked management interfaces must not be reachable from the internet, and prefers access through a policy enforcement point separate from the interface itself. Apply the same rule to self-hosted brokers and controllers. Cloud console access is out of scope for that directive, so restrict it with conditional access to managed admin devices instead.
- Privileged access workstations and just-in-time roles: do policy and identity changes only from privileged access workstations, with the platform administrator role granted for a time window. See the Privileged Access Workstations Guide and the Tiered Administration and Enterprise Access Model Guide.
- An admin path that survives the platform: if administrators reach the console or connector hosts only through the ZTNA service, a bad rule can lock out the people who can fix it. Keep one documented out-of-band path and one tested break-glass account. See the Break-Glass Account Guide.
- Identity provider trust changes are critical changes: adding a second identity source, changing the SAML signing certificate or loosening assertion checks lets an attacker sign in as anyone (T1556 Modify Authentication Process, T1606.002 SAML Tokens). Alert on every one.
Connectors and gateways inside the network
Connectors dial out from your network to the broker and carry user sessions to internal applications.
- Dedicated hosts: run connectors on hardened virtual machines or containers that run nothing else, have no interactive users, and are patched through the normal process. Apply supplier security updates promptly and subscribe to the supplier's security advisories.
- Narrow network reach: place each connector group in a segment that can reach only the applications it publishes, with host firewall rules to those addresses and ports. A connector with flat access to the data centre turns any rule mistake into network-wide access, which is the VPN problem ZTNA is meant to remove.
- Protect enrolment credentials: provisioning keys or tokens that register a connector to your tenant should be single use or short lived, stored in a secrets manager and revoked after use. See the Secrets Management Guide.
- Inventory and health: alert on a connector registered outside a change, a connector that stops reporting, and unexpected outbound destinations from connector hosts.
- Self-hosted brokers and concentrators: follow the edge device baseline: dedicated management interfaces segregated from data interfaces, unused features and services disabled, one IP version where only one is needed, and replacement before end of support. The VPN Security Guide covers patch timelines and IPsec settings in depth.
- Resilience: NIST SP 800-207 notes that hosting enforcement in a secured cloud or replicating it across locations reduces, but does not remove, denial of service risk to the policy engine and enforcement points. Run at least two connectors per application group and test failover.
Certificates, keys and trusts
| Credential | Used for | Main risk | Control |
|---|---|---|---|
| Gateway or broker TLS certificate | Users' clients trust the service endpoint | Stolen private key lets an attacker impersonate the gateway (T1552.004) | Key generated and kept in a hardware security module or the service's protected store; short validity; tracked renewal |
| Device tunnel certificate authority | Issues machine certificates for always-on device tunnels and device identity | Rogue devices enrolled as trusted (T1649) | Dedicated issuing CA or profile, issuance restricted to managed devices, revocation tested |
| Connector credentials | Connector authenticates to the broker | Cloned connector joins the tenant | Per-connector credential, rotation, alert on duplicate connector identity |
| SAML or OIDC trust | User and admin sign-in through the identity provider | Forged assertions or an added identity source (T1606.002) | Signed assertions, audience checks, certificate rollover tracked, alert on trust changes |
Record every one of these with an owner, issuer, expiry and the systems that trust it, so you can rotate all of them within hours after a gateway compromise. The ZTNA and remote access VPN health check measures this as device tunnel identities owned. See the Machine Identity, PKI and Certificate Lifecycle Guide and, for the CA itself, Securing the internal PKI and certificate authority itself.
Where identity fits: the platform's own non-human identities
Remote access platforms hold service identities that user access reviews miss.
- Directory bind or RADIUS account: the account a gateway uses to look up users and groups. Give it read-only rights to the minimum directory scope, store it in a vault and rotate it after any gateway incident. Assume any credential stored on a self-hosted gateway is exposed if the gateway is compromised, and alert when the account is used from anywhere other than the gateway.
- SCIM provisioning token: creates users and groups in the ZTNA tenant. Rotate it, and keep management API keys to one per integration with an expiry, never mapped to the platform administrator role. See the SCIM Provisioning Guide.
- Automation and AI agents: NIST SP 800-207 section 5.7 warns that software agents administering zero trust components may face a lower bar for authentication, such as an API key rather than MFA, and could be coerced or have their credentials stolen. Scope any agent that onboards applications or answers access requests to draft-only rights, with a human approver for publication.
- Dormant user and supplier accounts: the Colonial Pipeline Ransomware Attack 2021 began with a VPN account that was no longer used, had never been disabled and required no MFA. Enforce end dates on supplier access in the platform itself. See the Remote Access Identity Guide and Service Account Security Guide.
The platform's own logs and configuration integrity
Remote access logs serve two purposes: investigating user sessions, and proving that nobody tampered with the platform. The second is the one most often missing. The NCSC digital forensics and protective monitoring specification for network devices (February 2025) asks for successful and failed authentication with username, method, source and session ID; configuration changes with previous and new values, the actor and the method; configuration export events; attempts to clear or alter logs; near real-time transport over TLS; and heartbeats carrying the version and a SHA-256 digest of the running configuration.
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Access rule or connection profile widened (more users, more destinations, "any") | Internal applications opened beyond intent | Always, with change reference |
| Posture policy relaxed or set to report only | Unmanaged devices gain access | Always |
| Admin role assigned, local admin created, identity provider trust changed | Persistence in the platform (T1098, T1556) | Always |
| Connector registered, removed or offline | New route in, or loss of service | Always |
| Certificate or CA uploaded, replaced or exported | Impersonation or rogue device enrolment | Always |
| Log forwarding disabled or destination changed | Loss of visibility (T1685) | Always |
- Logs off the platform: the ASD edge device guidance says devices should not have access that allows the modification or deletion of any logs. Stream admin audit and connection logs in real time to a SIEM or archive that remote access administrators cannot change, in line with NIST SP 800-53 AU-9(2) and AC-6(9). See the VPN and Firewall Log Detection Guide for the session-side detections.
- Configuration as code: export rules, application definitions, posture policy and identity settings through the API on a schedule, keep them in version control and diff each export against the last approved state. An unexplained diff is a detection and the last good export is your recovery point.
Hardening an existing deployment: a phased approach
- Weeks 1 to 2, inventory: list every gateway, broker, connector, admin account, API key, certificate and identity trust, including legacy VPN profiles left running after a ZTNA migration. Take a baseline configuration export.
- Weeks 2 to 4, admin plane: move administrators to dedicated accounts with phishing-resistant MFA, split authoring from publishing, remove management interfaces from the internet and set up the break-glass path. Test break-glass before removing any old access.
- Weeks 4 to 8, connectors and credentials: move connectors to dedicated hosts in narrow segments, revoke used enrolment tokens, rotate the directory bind account and SCIM token, and replace shared API keys with one key per integration.
- Weeks 6 to 10, logging: forward admin audit and connection logs, build the alerts in the table above, schedule configuration exports with diffing, and then review roles, rules, connectors and credentials quarterly.
Testing and rollback: narrow a connector's network reach first in a pilot group, keep the previous firewall rule documented, and if an application breaks restore only the specific host and port it needs, never the whole segment.
Decision guidance
| Situation | Approach | Trade-off |
|---|---|---|
| Cloud-delivered ZTNA | Focus on tenant roles, identity trust, connectors, API keys and log export; the provider patches the broker | You depend on the provider's controls: ask about admin role granularity, log retention and staff access during procurement |
| Self-hosted broker or VPN concentrator | Everything above plus the edge device baseline and patch timelines | More control over keys and logs, more operational load at the edge |
| Mixed estate during migration | Measure both together; retire legacy VPN profiles on a dated plan | Old gateways are the most common forgotten entry point |
Small and large organisations: a small team can replace two-person publishing with change tickets and weekly export diffs; a large one should delegate admin scopes per region or business unit, manage rules as code and keep platform administrator to a handful of people.
Detection and measurement
- Configuration drift between the live platform and the last approved export.
- Service identity misuse: the directory bind account or API keys used from anywhere other than the gateway or the automation host.
Metrics that show the controls are working:
- Number of platform administrators (our suggestion: five or fewer) and the share holding the role just in time.
- Percentage of rule publications with a second approver or a reviewed pull request.
- Connectors on dedicated hosts with network reach limited to published applications (target 100%).
- Enrolment tokens, API keys and certificates with an owner and expiry in the inventory (target 100%).
- Time to detect an unapproved configuration change, measured in tests.
- Gateways and connectors whose logs reached the central platform in the last 24 hours (target 100%).
For the full scored review of the estate, use the ZTNA and remote access VPN health check.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Remote access policy and managed access points | AC-17, AC-17(1), AC-17(3) | PR.IR-01 | T1133 External Remote Services |
| Admin roles and privileged commands | AC-2, AC-6(5), AC-17(4) | PR.AA-05 | T1078 Valid Accounts |
| Device and service authentication | IA-3, IA-5, IA-9 | PR.AA-01, PR.AA-03 | T1556 Modify Authentication Process, T1649 Steal or Forge Authentication Certificates |
| Keys and certificates | SC-12 | PR.AA-01 | T1552.004 Private Keys |
| Configuration integrity | CM-6 | PR.AA-05 | T1098 Account Manipulation |
| Audit log protection | AU-9(2), AC-6(9) | PR.PS-04 | T1685 Disable or Modify Tools |
| Gateway patching and exposure | SI-2, SC-7 | PR.PS-02 | T1190 Exploit Public-Facing Application |
| Provider and supply chain | SA-9 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- Admins on daily accounts: the same account used for everyday remote access also holds platform administrator rights, so one phished session controls every access rule.
- Pilot connectors left in place: connectors installed in a flat server network during a proof of concept become permanent, with reach to everything.
- Reusable enrolment keys: a connector provisioning key sits in a deployment script or wiki, so anyone who finds it can join a connector to the tenant.
- Forgotten legacy VPN: a concentrator or profile left running after migration keeps local accounts, old cryptography and no MFA. The Colonial Pipeline incident shows the cost of one dormant VPN account.
Practitioner checklist
- Give administrators dedicated accounts with phishing-resistant MFA, privileged access workstations and just-in-time elevation.
- Keep self-hosted management interfaces off the internet and restrict cloud console access to managed admin devices.
- Separate rule authoring from publishing, and keep a tested break-glass account and out-of-band admin path.
- Run connectors on dedicated hardened hosts with network reach limited to the applications they publish.
- Inventory every certificate, CA and identity trust with owner and expiry, and rehearse rotating them.
- Scope the directory bind account, SCIM token and API keys to the minimum, store them in a vault and rotate them.
- Stream admin audit and connection logs to a store remote access administrators cannot change, and alert on rule, trust and forwarding changes.
- Retire legacy VPN gateways and profiles on a dated plan, and remove their certificates and accounts.
Standards and references
- NIST: SP 800-207 Zero Trust Architecture
- CISA: Binding Operational Directive 23-02, Mitigating the Risk from Internet-Exposed Management Interfaces
- Australian Signals Directorate: Mitigation strategies for edge devices, practitioner guidance
- NCSC: Digital forensics and protective monitoring specifications for producers of network devices and appliances
- NIST: SP 800-46 Rev. 2 Guide to Enterprise Telework, Remote Access, and BYOD Security
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1133 External Remote Services
Related NHI Mgmt Group resources: ZTNA Guide · VPN Security Guide · ZTNA and remote access VPN health check · Securing the CASB and SSE platform itself · Edge Device Compromise Investigation Playbook