Enterprise VPN Security: What an Assessment Actually Tests

An enterprise VPN is asked to do two jobs that pull in opposite directions. It has to authenticate a person well enough that a stolen password is not sufficient, and it has to hand that person a routable address inside a network that was built on the assumption that anyone holding such an address is trustworthy. Most remote-access programmes are strong at the first job and quietly negligent about the second, because the first is visible on a login screen and the second is invisible until someone lateral-moves from a VPN pool into a file server.

The 2026 record makes the order of priorities unusually clear. The attacks that worked did not start with a phished password; they started with an internet-facing appliance that accepted a session from someone who had proved nothing at all, and they ended with the attacker holding the same network position as a legitimate remote worker. Verizon's 2026 Data Breach Investigations Report puts exploitation of vulnerabilities at the centre of 31 per cent of breaches, up from 20 per cent the year before, and the specific class driving that shift is internet-facing edge devices - VPN gateways, firewalls and remote-access appliances. A remote-access design that assumes the adversary is a user who must be fooled is defending against the wrong actor.

This guide is a working description of what a competent enterprise VPN assessment measures, in an order that matches how the failures actually happen: the appliance first, then the session, then the authorisation inside the tunnel, then the evidence. It is written for the person who has to sign the report, not for the person who has to configure a tunnel, and it is explicit about which parts of the work can be done from a document and which parts require a test.

What an enterprise VPN assessment actually measures

Three questions decide the outcome of a remote-access assessment, and a report that does not answer all three is a configuration review wearing a security label. First: can someone who holds no valid credential obtain a working session, through a flaw in the gateway, a misconfigured authentication path, or a token that was issued to somebody else? Second: once a session exists, what can it reach, and is that reach the smallest set the person's job requires? Third: after either of those goes wrong, is there an artefact that proves what happened, preserved long enough and off the device to survive an attacker who clears logs?

Each of the three decomposes into tests with a binary or numeric answer, which is what makes the work assessable rather than advisory. For the first: is the management interface reachable from the internet, does the gateway enforce certificate validation on every authentication path including the legacy ones, and does a session issued before a patch still work after it? For the second: how many hosts, ports and protocols is the median user able to reach at layer three, and does a group change take effect on an established session? For the third: what is the measured retention window for VPN authentication events, and does the SIEM hold them when the appliance's local store is wiped?

The output is a matrix, not a narrative. Rows are the components a user's traffic passes through - client, authentication path, gateway, tunnel policy, internal authorisation, logging - and columns are the failure modes that matter for each: pre-authentication exposure, credential or session theft, over-broad reach, and absence of evidence. A cell is either tested with a result, or marked untested with the reason and the residual risk. The difference between a matrix and a checklist is that a checklist can be completed by assertion, and a matrix cannot.

The appliance is the attack surface, not the user

A VPN gateway is a special kind of host: it must be reachable by anyone on the internet, it terminates authentication for the whole organisation, it holds the keys and certificates that let it impersonate the network to clients, and in most deployments it stores the sessions that are currently active. Every one of those properties is a liability, and together they make the appliance the highest-value unauthenticated target on the perimeter. An attacker who compromises it does not need to phish an employee, does not need to defeat MFA, and does not need to touch an endpoint - the appliance does the authentication on their behalf and hands them a session the internal network will treat as legitimate.

That asymmetry is why the failure pattern repeats across vendors and years. The compromise is usually a pre-authentication bug - an authentication bypass, a path traversal, a deserialisation flaw or a command injection in the web interface - followed by the harvesting of credentials and configuration from the appliance itself, then a pivot that uses valid accounts so that endpoint detection has nothing to alert on. When the appliance is patched, the attacker's access often survives, because the material they took was the stored credentials and the live session tokens, not the exploit. CitrixBleed, CVE-2023-4966, is the canonical example: session tokens leaked from appliance memory in October 2023, and organisations that patched promptly still had to hunt for and explicitly kill sessions that had been taken before the patch.

The practical consequence for an assessment is that the appliance is examined as a system in its own right, not as a network device that forwards packets. That means its exposed services, its administrative interfaces, its firmware and patch level, its local accounts, its stored secrets, its trust relationships with the identity provider, and the way it logs. A test that only examines tunnel configuration and password policy has skipped the component that has actually been breached in every major remote-access incident of the last three years.

The 2026 record: nine months of edge-device exploitation

Between January and October 2026 the public record contains a steady sequence of remote-access appliances exploited before or without authentication, which is more useful to an assessment than any single advisory because it shows which design decisions kept recurring. Check Point's CVE-2026-50751 was an improper authentication flaw in IKEv1 certificate validation, rated 9.3, with exploitation observed from 7 May 2026, a public advisory on 8 June 2026 and a federal remediation deadline of 11 June 2026 under a binding operational directive. Palo Alto's CVE-2026-0257 was an authentication override cookie in GlobalProtect, raised to 7.8 in the v4 scoring system, where the appliance reused its HTTPS certificate for cookie encryption and did not verify a signature when decrypting it - a design shortcut that turned a certificate into a session-forging tool. Ivanti Connect Secure had CVE-2026-104935, unauthenticated remote command execution. Cisco's CVE-2026-76418 was a denial of service in ASA and FTD SSL VPN reached through a logic error in secondary authentication, and the vendor's own stated mitigation was to disable secondary authentication, which is an unusual way to stay online. In October, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell and rated 9.8, exploited PHP embedded in appliance management interfaces, with fixes shipping on 21 October 2026; the same month brought further Citrix NetScaler and F5 BIG-IP APM issues.

Four patterns in that list should change how you scope the work. The flaws cluster in legacy authentication code paths - IKEv1, secondary authentication, compatibility modes - which are exactly the paths that an upgrade programme leaves switched on because something still depends on them. They cluster in the management plane, which in several cases is the same HTTP service the user portal uses, separated only by a virtual host or a port. They include denial of service, which is not a data breach but is an outage on the system that remote work now depends on. And they are reachable without credentials, so the usual control set - strong passwords, MFA, least privilege - does nothing to stop them.

The correct reading of this record is not that VPN is obsolete; it is that a VPN gateway must be operated like a public-facing web application, with an owner, an inventory entry, a patch SLA measured in hours during active exploitation, and an assumption that its pre-authentication attack surface will be probed continuously. An assessment that does not establish those four facts is measuring the wrong decade.

Five components of a remote-access path, and who owns each

Remote access fails at the seams between components, and the seams are where ownership is unclear. Naming the five components and their owners before testing is what turns a vague engagement into a scoped one. The client is the endpoint and its VPN or agent software: it holds credentials, certificates, configuration profiles and, in split-tunnel deployments, the routing table that decides what leaves the machine unencrypted. The authentication path is the chain from client to decision - local database, RADIUS or LDAP, SAML or OIDC identity provider, certificate authority, MFA service - and it fails at whichever link is weakest, not at the strongest.

The gateway is the appliance, its exposed services and its cryptographic configuration. The tunnel policy is what the gateway grants once authentication succeeds: address pool, routes, DNS servers, split-tunnel lists, idle and absolute timeouts, and the group mapping that decides which of those a given user receives. The internal authorisation layer is everything behind the tunnel that decides what the resulting address may actually touch - firewall rules, security groups, VLAN segmentation, application-level authentication - and it is the component most often assumed rather than tested.

Assigning a named owner to each is not bureaucracy; it is the mechanism by which findings become work. In most organisations the client belongs to endpoint management, the authentication path to identity, the gateway to network operations, the tunnel policy to whoever last wrote the firewall change, and the internal authorisation layer to infrastructure security - five teams, four of which believe another team is responsible for the whole. An assessment that reports a finding without naming the owner produces a document that is agreed with and never actioned, which is the most common way remote-access risk persists for years.

Protocol choice: IKEv2, TLS-VPN and WireGuard compared honestly

The protocol decision is usually made once, years ago, and then inherited. It is worth reopening, because the three families move through the network differently and fail differently. IKEv2/IPsec (RFC 7296) carries traffic in ESP (RFC 4303), uses UDP 500 and 4500, supports MOBIKE (RFC 4555) for roaming across networks without rekeying, and supports fragmentation of IKE messages (RFC 7383) which matters when a middlebox drops large UDP packets. It is the fastest and most stable option for a mobile workforce, and it is the option with the deepest history of pre-authentication vulnerabilities - the 2026 Check Point flaw was in IKEv1 certificate validation, not in IKEv2, but the point stands that the negotiation itself is attack surface.

TLS-based remote access puts the tunnel inside TLS 1.3 (RFC 8446) on 443. Its advantage is that it looks like the web, so it survives networks that block UDP and it inherits a decade of scrutiny of TLS implementations. Its disadvantages are that a TLS VPN concentrated on one hostname is a single reverse proxy for every internal application, and that several widely deployed products implement the session layer themselves, badly - which is how cookie reuse, unsigned tokens and memory disclosure of session identifiers keep appearing.

WireGuard is the smallest design of the three: a Noise_IK handshake, Curve25519, ChaCha20-Poly1305, BLAKE2s, HKDF, UDP only, and a cryptokey routing table that maps public keys to permitted addresses. Its attack surface is genuinely narrow and its performance is good. What it does not have is identity. A peer is a public key; there is no certificate chain, no user directory, no built-in MFA and no session concept - so an enterprise that adopts it must build user identity, key distribution, revocation, per-user policy and audit on top, and revocation means removing a key and re-issuing one, which is an operational problem, not a protocol one. WireGuard is an excellent transport and a poor access-control system on its own; treat it as the tunnel and put the decisions elsewhere.

Whichever is chosen, the assessment checks the same crypto facts rather than the brand: only IKEv2 with certificate-based authentication on the IPsec side, no aggressive-mode IKEv1 and no pre-shared keys shared across users, a modern TLS profile with no legacy ciphers and no fallback, and PFS enabled so that a compromised long-term key does not decrypt recorded traffic. NIST SP 800-77 Rev. 1 is blunt about the first of those: pre-shared keys should not be used within an administrative domain, and remote access should use EAP-TLS or machine certificates, precisely because a PSK held by many peers means any peer can impersonate the gateway to another.

Authentication: certificates, SSO and phishing-resistant MFA

Remote access authentication should answer two separate questions: is this device one we issued, and is this person who they claim to be. Device identity comes from a certificate issued by an internal authority and bound to the endpoint, ideally with a hardware-backed key. User identity comes from the corporate directory through SAML or OIDC, with a second factor that resists phishing. When the two are collapsed into one password - or into one password plus a one-time code that a proxy page can relay - the gateway cannot distinguish a legitimate employee on a corporate laptop from an attacker on a laptop who has the password and a live code.

The standard to measure against is NIST SP 800-63B-4, which sets out authenticator assurance levels and is explicit that phishing resistance is a property of the authenticator, not of the flow around it. For remote access into a network that holds regulated data, the practical floor is AAL2 with a phishing-resistant second factor - a FIDO2 or passkey credential in the platform authenticator or a hardware key - with TOTP and push-notification approvals treated as acceptable only where a platform cannot support better, and SMS treated as a fallback of last resort rather than a control. Push fatigue is not a hypothetical: repeated approval prompts until someone taps accept is a documented pattern, and the mitigation is number matching plus a rate limit, or removal of push entirely.

Three configuration details decide whether that theory survives contact with the appliance. First, the strongest requirement must apply to every authentication path, including the client-certificate portal, the web portal for browser-only access, the administrative login, and any legacy IKEv1 or IPsec PSK profile still switched on for an old device - the weakest path sets the real level, and the 2026 CVEs were concentrated in exactly those legacy paths. Second, group membership must be derived from the identity provider at login, not maintained in a local table on the appliance that nobody reviews; NIST SP 800-77 calls for periodic audit of the authorised user list, and a local table is where leavers live on for years. Third, the account must be disabled in the directory and the session killed on the appliance, because disabling an account does not terminate an established tunnel - a distinction that turns a same-day offboarding into a week of network access.

Where MFA fails: cookies, sessions and pre-authentication bugs

MFA is a control on the act of authenticating, not on the session that results, and almost every remote-access compromise of the last three years exploited that gap. Three mechanisms account for most of it. Cookie and token theft: once the gateway issues a session cookie or SAML assertion, possession is sufficient, and an attacker who obtains it by infostealer malware, an adversary-in-the-middle proxy or a memory disclosure on the appliance does not need the second factor at all. CVE-2026-0257 is the appliance-side version of this, where an authentication override cookie could be forged because it was encrypted with a certificate the attacker could obtain and was not signature-verified on decrypt.

Pre-authentication bypass: the flaw is reached before any credential is checked, so MFA is not in the path. CVE-2026-50751, CVE-2026-104935 and the PHP2Shell pair are all in this category. And session fixation and replay, where an attacker establishes a session and arranges for a victim to inherit it, or replays a token that the gateway does not bind to the client.

What an assessment can actually verify is narrow but decisive. Are session cookies marked Secure, HttpOnly and SameSite, and is the idle timeout enforced server-side rather than by the client? Is there a documented way to kill a specific session, and has it been tested - meaning killed, then replayed from a second machine to confirm it no longer works? Is the SAML or OIDC response bound to the request, with a short assertion lifetime and a replay cache? Does the gateway bind the session to the client certificate or to a device posture signal, so that a token copied off one machine cannot be used from another? A gateway that fails the cookie-theft test makes the entire MFA investment decorative, and that test takes an hour.

Split tunnelling is a policy decision, not a checkbox

Split tunnelling sends some traffic through the tunnel and the rest directly to the internet. Disabling it - full tunnel - means inspecting, filtering and logging all remote traffic, at the cost of concentrating the entire organisation's bandwidth through one appliance and adding latency to every video call. Enabling it means the endpoint's own security stack, and whatever DNS and egress filtering it enforces, becomes the only control on that traffic, and that the user's home network sees the destinations and the metadata. Both are defensible; the indefensible position is to have made the choice implicitly.

The technical question is not on or off but what is on the list. A split-tunnel configuration typically excludes RFC 1918 ranges, the corporate domain suffix, and specific subnets from the tunnel and sends everything else direct. The failure modes are mapping mistakes: an excluded range that overlaps an internal subnet, so internal traffic leaves unencrypted and is routed to a home router that answers it; a DNS resolver that is excluded along with the traffic, so internal names are resolved by a public resolver or by a lookalike on the local network - a DNS leak that is invisible from the appliance; and IPv6 enabled on the client while only IPv4 is tunnelled, so traffic quietly takes the path nobody is watching. Each is testable: connect, then compare the client's effective routes and resolver against the intended list, and probe an internal name from the outside.

Compensating controls are what make the decision reviewable. If split tunnelling is on, the device must be managed, disk-encrypted, running EDR with a positive health signal, and the egress must go through a cloud proxy that logs by user rather than by IP. If it is off, the appliance needs enough throughput and redundancy that a firmware update or a capacity problem does not stop the business, and the inspect-and-log promise must actually be implemented rather than assumed from the tunnel's existence. NIST SP 800-77 accepts either policy, and explicitly notes that an organisation may forbid split tunnelling and simultaneous connection to another network - the point is that the policy is written down, enforced on the client, and tested.

Always-on, capture portals and the leak surface

A tunnel that users start when they feel like it is a tunnel that exists about 70 per cent of the time, and the remaining 30 per cent is where the unmanaged path opens. Always-on VPN addresses that by connecting at boot and reconnecting after any network change, with a kill switch that drops all traffic while the tunnel is down. The assessment tests the kill switch adversarially rather than reading the setting: block the gateway's address on the client firewall, reboot the laptop, then try to reach an external address and check whether it resolves and loads. A kill switch that leaks during the reconnect window is the normal finding, not the exception, and DNS is usually the first thing through.

Capture portals are the other half of the same problem. A captive portal on a hotel or airport network intercepts HTTP and returns a redirect, and a naive always-on client interprets that as reachable internet, declares success, and sends traffic the wrong way; a naive browser then sends the user to a login page that is not yours. The design answer is to treat any network behind a capture portal as untrusted, keep the tunnel closed until the portal is passed, and never allow the client to display an internal login form on a network it has not authenticated. This is the class of issue that produces credential-harvesting pages that look exactly like your VPN portal, so the assessment should test what the client does on a network where a rogue portal answers for every name.

Then the leak surface, which is larger than most inventories admit: IPv6 traffic on a dual-stack client that routes around an IPv4-only tunnel; WebRTC exposing local addresses to a web page inside the tunnel; multicast and mDNS announcements to the local segment; DNS over HTTPS in the browser bypassing the tunnel's resolver entirely; and cloud sync clients that reach the internet directly because their destination is in the split-tunnel exclude list. Each is a configurable behaviour and each should be tested from a client in a real remote location, not from the office.

Authorisation inside the tunnel: segmentation and least privilege

The most common and most expensive finding in enterprise VPN assessments is not a weak cipher; it is a flat grant. A user authenticates, receives an address from a pool, and the pool's firewall rule permits the whole internal range on all ports - so a compromised or careless endpoint has the same reach as the office LAN. Embedded devices, unpatched servers, management interfaces and the hypervisor console are all reachable from a home laptop, and nothing between the tunnel and those assets asks a second question. This is the exact network position that NIST SP 800-207 exists to remove: the architecture is built on the premise that network location is not a proxy for trust, and a VPN that grants full internal reach after login is the purest example of the model it argues against.

Least privilege inside the tunnel is achievable without replacing the VPN. Group-based tunnel policy maps an identity-provider group to a distinct address pool, so finance, engineering and contractors land in different ranges; firewall rules between pool and assets are written per pool, not per VPN interface; and the sensitive destinations - hypervisor management, database ports, backup infrastructure, out-of-band management - are reachable only through a jump host that authenticates and records the session. Where the appliance supports per-application policy, use it, but do not assume it: several products implement application-level rules by name resolution and fall back to the underlying route when resolution changes.

Two tests decide whether this is real. First, the reachability map: from a standard remote session, enumerate what responds across the internal range on the ports that matter, and compare the count and the composition against the intended policy; a median user reaching more than a handful of services is a finding, even if every one of them is patched. Second, the group change test: move a test account between groups, then check whether an established session keeps the old reach. Cached authorisation on the appliance is normal in several products, and it means revoking a group does not revoke access until the tunnel is re-established.

The management plane is the real target

Nearly every VPN appliance exposes at least two services on the same host: the user-facing portal and the administrative interface. In a surprising number of deployments they are the same HTTPS listener on the same port, separated by a virtual host or a path, and the administrative interface is reachable from the internet because remote support was needed once in 2019. That single design decision converts a user-facing pre-authentication bug into an administrative one, and it is the reason appliance compromises so often end with new local accounts and modified configuration rather than with data exfiltration alone.

The requirement is straightforward and rarely met: the management interface must not be reachable from the internet on any port or protocol, must be on a dedicated management network or reached through the same VPN it manages, and must require its own strong authentication with named accounts rather than a shared administrator login. Where the vendor provides a separate management plane - a distinct interface, port or service that can be firewalled - use it, and verify that the user portal cannot reach it. Also verify the appliance's own outbound access: a gateway that can reach the internet on arbitrary ports is a beaconing platform once compromised, and egress should be limited to the update and licencing endpoints it actually needs.

Three artefacts make this auditable. An exposure check from outside the network that lists every port the appliance answers on, so that an unknown listener is discovered before an attacker finds it. A configuration export showing named administrative accounts, their roles and their last login, with any shared or vendor-default account documented and rotated. And a review of local accounts on the appliance itself, because vendor support accounts and forgotten API users survive directory migrations and password resets and are the first thing an attacker looks for after gaining a foothold.

Patch discipline on a device that must stay reachable

Patching an internet-facing appliance is different from patching a server, because the device cannot be taken offline without disconnecting the workforce and cannot be left unpatched without exposing it. The 2026 record sets the clock: for CVE-2026-50751 the interval between the vendor advisory and the federal remediation deadline was three days, and exploitation predated the advisory by a month. An organisation working to a 30-day patch window for remote-access gateways is not slow; it is operating on a timeline that no longer exists.

What makes the difference is inventory and authority rather than effort. Every remote-access component must be in the asset inventory with a named owner, its exact firmware version, its end-of-support date and its exposure - including the appliances bought by a business unit, the ones behind a partner's firewall, and the client software that is only visible through the endpoint management console. End-of-support devices need a replacement date, not a compensating control, because the compensating control is the firmware that no longer arrives. Then a tiered SLA that is written down and tested: within 24 hours for a vulnerability under active exploitation with a pre-authentication vector, 72 hours for high severity, and a maintenance window that has been rehearsed so that the update does not become the outage.

The step that is almost always skipped is what happens after the patch. Firmware updates do not invalidate sessions, stored credentials or local accounts; an attacker present before the update is present after it. So the deployment procedure needs a post-patch phase: rotate the appliance's credentials and any shared secrets, revoke and reissue user and device certificates issued since the last known-good date, terminate all active sessions, review local accounts and configuration diffs against the previous known-good export, and hunt for the indicators the vendor published. That phase is the difference between closing the vulnerability and removing the intruder, and it is where most incident response engagements in this space begin.

Logging: what to record, where it goes, how long it survives

A VPN gateway is the best-positioned sensor on the perimeter - it sees who connected, from where, with which device, to what, for how long - and in most organisations its logs are the weakest link in the investigation. The failure is never the absence of logging; it is logging to the device's own disk, with a retention default measured in days, on a host that an attacker with administrative access can wipe. The assessment measures three things: what is recorded, where it is sent, and how long it is kept out of the attacker's reach.

What must be recorded is specific. Successful and failed authentications with the identity asserted, the source address, the client version and the device identifier; authorisation decisions, including the group or role the session received; session start, end and bytes transferred, with the reason for termination; administrative logins and configuration changes with the before and after values; certificate validation failures, especially on the legacy paths; and any event the appliance emits about its own integrity. Failed logins alone are close to useless, because the attacks that matter in 2026 do not fail to log in - they never log in.

Where it goes matters as much as what. Logs must stream in near real time to a collector the appliance cannot modify, over a channel that survives compromise of the gateway, with the appliance holding only a short local buffer. Syslog over TLS to a SIEM, or the vendor's own cloud telemetry if it is enabled and reachable, satisfies that; a local file that is rotated at 100 MB does not. And retention must be longer than the detection lag. If the median time to discover a remote-access intrusion is measured in weeks, a 30-day retention window means the first day of the intrusion is already gone when the investigation starts, and a 12-month window is the difference between scoping a breach and guessing at one - which is also what GDPR Article 33 requires you to be able to do within 72 hours.

Test the configuration instead of assuming it

Configuration is a claim; behaviour is a fact. The tests below are the ones that consistently produce findings, and each takes minutes with a test account and a laptop on a network that is not yours. Credential: an expired certificate is rejected; a certificate from a different issuing authority is rejected; a valid certificate with a revoked serial is rejected, and the revocation check actually happens rather than being skipped when the responder is unreachable. Account state: a disabled directory account cannot authenticate; a deleted account's active session is terminated; a user removed from the VPN group loses reach on the next connection and, separately, on the current one.

Second factor: authentication without the second factor fails rather than falling back to password-only; a replayed one-time code fails; a replayed SAML assertion fails; and an identity provider outage produces a closed door rather than an open one - the fail-open configuration is a classic finding, and it is invisible until the day the IdP is down. Tunnel policy: with the tunnel up, the effective routes and resolver match the intended list; the kill switch holds across a reboot with the gateway blocked; internal names do not resolve from outside; the client does not connect automatically to a network behind a capture portal.

Authorisation: the reachability map from a standard account matches the intended policy; a jump host is required for sensitive destinations; a group change takes effect within a stated time. Exposure: an external scan finds only the ports you expect, and the management interface is not among them. Evidence: each of the above appears in the SIEM within the expected latency, with the fields needed to answer who, from where, to what. A test that produces no log entry is a finding of equal weight to a test that produces a bypass, because it means the same failure will be invisible next time.

The client is now part of your perimeter

Remote access moved the trust boundary onto devices you do not own the network for. A managed laptop on a home router, a personal phone on a train, a contractor's machine that will never join the domain - each is an endpoint whose security posture you cannot inspect structurally, which is why posture checking exists and why it is usually configured too weakly to matter. The assessment asks what the gateway does when a device is unhealthy, not whether a posture check is enabled: does it deny access, restrict it to remediation, or log a warning and let the user in, which is the observed default in most deployments that bought the feature.

Three client controls carry most of the weight. Device identity: a certificate bound to the machine and stored in a TPM, so that a copied profile cannot be used from another device. Posture: disk encryption, the EDR agent running with a recent signature and a positive health signal, OS patch level, and host firewall state, all evaluated at connection rather than at enrolment. Update enforcement: a minimum client version, so that a vulnerability in the client itself cannot be exploited by a user who declines the prompt - and because client CVEs exist in volume and the update dialog is the control that decides whether they matter.

BYOD deserves a separate decision rather than an implicit permission. If personal devices may connect, the honest option is a browser-based portal with application-level authentication and no network-level tunnel, so the device never gets a routable internal address; the dishonest option is a full tunnel on an unmanaged device, which imports every weakness of that device into the network and adds the user's personal cloud storage to the effective data-egress surface. Whichever is chosen, the endpoint's own DNS and the local network's ability to observe traffic must be part of the documented risk, not an afterthought.

Third-party and vendor access

Support vendors, managed service providers, auditors and integration partners are the population most likely to hold a credential that nobody offboards, because the account is created by whoever needed it and owned by nobody afterwards. Vendor access through the general VPN is the specific pattern to eliminate: a shared account, a broad group mapping, a password in a shared vault, and a session that nobody watches. The 2026 pattern of appliance compromise makes it worse, because a vendor account that exists for remote support is exactly the foothold an attacker wants for persistence that looks legitimate.

The design that works separates vendor access from employee access entirely: a dedicated gateway or a dedicated realm with its own authentication, time-bound accounts created for a ticket and expired when it closes, a fixed source address allow-list where the partner can provide one, session recording at the jump host, and a named sponsor in the organisation who is accountable for the access. Every session is logged with the sponsor, and access review is monthly rather than annual, because a partner relationship that ended in March is still letting someone in during November if nobody looks.

The assessment's vendor tests are simple and rarely performed: count the accounts that belong to non-employees and check each against an active contract; attempt to authenticate with a vendor account outside its approved window; check whether a vendor session is recorded and whether the recording is retrievable; and confirm that terminating the contract removes the account the same day, including its certificates and any appliance-local entry. A vendor inventory that cannot be reconciled with the contract register is a finding in itself, and in our experience it is the single most reliable source of unnecessary remote access.

VPN, ZTNA and SASE: choosing on constraints, not fashion

Zero Trust Network Access replaces the network-level grant with a per-application broker: the user authenticates to an identity provider, a policy engine decides whether this user on this device may reach this application now, and the connector exposes only that application. SASE packages the same idea with cloud-delivered inspection and egress control. Both are real improvements on two specific failures - flat internal reach and inspection that depends on traffic passing through one appliance - and both are worse than a well-configured VPN on other dimensions, which is why the decision should be made on constraints rather than on a vendor's slide.

A VPN is still the right answer where the workload is not HTTP: SSH, RDP, database protocols, industrial and laboratory systems, and anything that needs layer-three reachability or a fixed address. It is the right answer where the organisation must own the egress point, either because data cannot leave a jurisdiction or because the inspection appliance is already there. And it is the right answer where the user population, the appliance footprint and the operational skill already exist, because a migration that nobody can operate is a downgrade regardless of architecture.

ZTNA is the better answer where the applications are web-based or can be fronted by a connector, where the workforce is highly mobile, and where the audit requirement is per-application access rather than network access - the difference between being able to say who reached the payroll system and who could reach the payroll subnet. The trade-off must be stated plainly: you lose uniform layer-three inspection unless you keep a proxy or a cloud egress path, you take on a new dependency on the broker's availability and on the connector's software supply chain, and you inherit a policy engine whose rules are now the access control system and therefore deserve the change control that used to belong to the firewall. Hybrid estates are normal; two overlapping access paths that both work is the failure state, and it is the subject of the next section.

A migration that does not leave two front doors open

The dangerous phase of any VPN-to-ZTNA programme is the middle: the new path is live for early adopters, the old gateway is still up for everyone else, and both authenticate against the same directory and reach the same assets. An attacker does not need to defeat the better path - they take the one nobody is watching, and the old gateway is usually the one that stopped receiving patches once the migration was announced. Every migration plan should therefore be written as a sequence of closures, each with a date and an owner, rather than a sequence of enablements.

The order that works: inventory every application and confirm it is reachable through the new path before touching the old one; move groups in slices small enough to reverse within a day; keep the old gateway in a break-glass role with a shrinking allow-list and an alert on any connection through it, so that residual use is visible rather than silent; then decommission on a calendar date, not when convenient. During the overlap, both paths must enforce the same authentication strength, because the weaker path defines the effective security level of the whole estate.

Two details decide whether the closure actually closes. The first is DNS and routing residue: internal names that still resolve to the old gateway's pool, split-tunnel routes still pushed by a client profile that people kept, and a client installed on endpoints that no longer receive updates - all of which keep working after the gateway is "decommissioned" if the network still accepts them. The second is certificate and credential hygiene: revoke the old gateway's server certificate, revoke device certificates issued for it, and remove its trust from the identity provider, so that a restored backup or a forgotten appliance cannot silently rejoin the federation. A decommissioned appliance that still holds a valid trust relationship is the "two front doors" problem in its final form.

What the assessment matrix and the report must contain

A report that a board can act on has four parts, and the first is the one most reports omit: the scope statement, listing every component tested, every component known to exist but not tested, and the reason. That section prevents the false comfort that comes from a report titled "VPN assessment" which examined one gateway in one region and left four regional appliances, two inherited from an acquisition, untested. It should also state the assessment date, the firmware versions tested and the test accounts used, because a report without versions cannot be compared with next year's.

The second part is the matrix itself, one row per control area and one column per severity, with each finding carrying the test that produced it, the observed behaviour, the affected component and the owner. Findings should be phrased as behaviour, not as absence: "an expired device certificate was accepted by the IKEv2 gateway on 4 of 4 attempts" is actionable, while "certificate validation should be reviewed" is not. Include the negative results too - the tests that passed - because the fact that the kill switch held and the disabled account was rejected is what allows the next assessment to be cheaper.

The third part is the remediation sequence, ordered by what closes the most risk per unit of effort, with the quick wins separated from the projects. Rotating the appliance's credentials, removing the internet-reachable management interface, killing stale sessions and enabling log forwarding are usually hours of work and remove more exposure than a protocol migration that takes two quarters. The fourth part is the evidence appendix: configuration exports, scan output, log excerpts with timestamps, and screenshots that show the timestamp of the test rather than a generic settings page. Without that appendix the report is an opinion, and an auditor - or an insurer, or a court - will treat it as one.

Compliance evidence: ISO 27001, NIS2, DORA and Article 32

Remote access sits at the intersection of more regulatory requirements than any other infrastructure component, and the same tests satisfy most of them if the evidence is captured properly. Under ISO/IEC 27001:2022, Annex A 8.20 (networks security), 8.21 (security of network services), 8.22 (segregation of networks), 8.5 (secure authentication), 5.15 (access control) and 8.16 (monitoring activities) all point at the same artefacts: a documented access policy, a group model that matches it, an authentication configuration that enforces it, and logs that show it working. The audit question is never whether MFA is enabled; it is whether the configuration has been reviewed since the last change and whether a sample of sessions can be traced.

NIS2 (Directive (EU) 2022/2555) adds an obligation that changes the design rather than the documentation: Article 21(2) requires multi-factor authentication and secured communications for administrative access, and Article 23 requires an early warning within 24 hours of a significant incident and a full notification within 72. Both are only possible if VPN authentication and session logs are centralised, time-synchronised and retained beyond the appliance - which is why the logging section above is a compliance requirement as much as an engineering one. DORA, applicable from 17 January 2025 for financial entities, adds the register of information and third-party concentration: a remote-access service delivered by a provider that also holds the identity provider and the egress is a concentration risk that must be documented, not merely observed.

GDPR Article 32(1)(b) requires confidentiality of processed data and 32(1)(d) requires regularly testing and evaluating the effectiveness of the measures - a remote-access assessment is the most direct evidence of the latter that exists for this system. Article 5(1)(f) covers integrity and confidentiality, and Article 33's 72-hour notification is achievable only with retained logs. The practical advice is to run one assessment and produce three artefacts from it: the technical report, a control-evidence mapping for the auditor, and a two-page summary for the risk committee. Producing them separately is how organisations end up with three inconsistent versions of the same truth.

Cost, scope and the lawful boundary

Scope, not effort, drives the cost of this work, and the scope question to settle first is how many gateways exist. As a worked example with stated assumptions: an organisation with 2,000 employees, 12 per cent peak remote concurrency, two gateways in one region and one inherited appliance from an acquisition, tested to the matrix above with configuration review, a reachability map and a credential-hygiene check, is a two-to-three week engagement for one experienced tester plus a short remediation window. The same organisation with nine gateways across four regions, two identity providers and a ZTNA pilot in flight is several times that, almost entirely because of the inventory and evidence work rather than the exploitation. Any quotation that does not ask how many internet-facing gateways you have is a guess.

The lawful boundary is not negotiable and it is simple: testing is performed only on systems the client owns or is expressly authorised in writing to test, by people named in that authorisation, within a scope document that lists addresses, dates, test accounts and the actions that require a separate approval - denial of service, credential stuffing, destructive tests. A remote-access gateway is a production service that the business depends on, so even authorised testing needs a rollback plan, a named contact on the client side, and an out-of-hours window for anything that could interrupt a session. Nothing in this guide is an invitation to test a system you do not control; unauthorised access to a computer system is a criminal offence in most jurisdictions, and an assessment report is not a defence for one.

The reason to state that plainly is that the same techniques are described in the same words by people selling the opposite service. Everything above is written from the defender's side, for an organisation that wants to know where its own remote access would fail. If you need that answer for your own estate, the work is lawful, documented and repeatable; if you need it for someone else's, it is a crime, and no framing changes that.

Frequently asked questions

How long does an enterprise VPN assessment take?

For a single gateway with one identity provider, two to three weeks including reporting. The variable is not the number of users but the number of distinct gateways, authentication paths and client profiles, because each combination needs its own tests and its own evidence.

Do we have to take the VPN down to test it?

Not for the configuration, credential and authorisation tests, which use dedicated test accounts. Denial-of-service and firmware-change tests do need a window, because they can interrupt sessions; those are scheduled separately and with a rollback plan.

Is MFA enough on its own?

No. MFA protects the act of authenticating, not the resulting session, and it does nothing against a pre-authentication flaw in the gateway itself - which is the failure mode behind every major remote-access compromise of the last three years.

Should we replace our VPN with ZTNA?

Only where the applications can be brokered per application and where you accept the trade in layer-three inspection and the new dependency on the broker. For SSH, RDP, database and industrial workloads, a well-configured VPN with segmented groups remains the better fit.

What is the single highest-value fix?

Remove internet reachability from the management interface and segment the tunnel grant so a session cannot reach the whole internal range. Both are usually days of work and both remove exposure that no amount of password policy addresses.

Is testing our own gateway lawful?

Yes, with written authorisation from the system owner and a scope document, which is what any professional engagement provides. Testing a system you do not own is not.

If you need an independent read on your own remote-access estate, our authorised penetration testing and web and infrastructure security audit engagements cover the appliance, the authentication path and the tunnel policy described here, and the contact page is the place to describe your scope. Bring an inventory of internet-facing gateways and the identity providers behind them; that list is the engagement.