Vpn Standards

VPN standards — tunnels and remote access

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when choosing, designing, deploying, operating and retiring an encrypted tunnel and the remote access built on it: the choice between site-to-site, user remote access and mesh; the market's shift towards ZTNA; WireGuard and its key model; meshes with a control plane (Tailscale, NetBird, Netmaker, ZeroTier, Nebula, Headscale) and the risk of delegating that plane; IPsec/IKEv2 for interoperability; OpenVPN where it is still justified; device posture and the access lifecycle; tunnel operation (MTU/MSS, resolution inside the tunnel, routes and overlaps, concentrator redundancy and capacity); and the security of the concentrator both as an exposed asset and as a source of forensic evidence.

Triggers: wg0.conf, [Interface]/[Peer], AllowedIPs, PersistentKeepalive, Endpoint, PresharedKey, Table=, wg genkey|pubkey|show|setconf|syncconf, wg-quick up|down, systemd-networkd .netdev with [WireGuard]/[WireGuardPeer], NetworkManager wireguard profiles, swanctl.conf, ipsec.conf, ipsec.secrets, charon, strongswan, ke1_mlkem768, ppk=yes, client.ovpn, server.conf, tls-crypt, redirect-gateway, ovpn-dco/win-dco, tailscale up, --advertise-routes, --exit-node, tailnet ACL/grants, netbird up, headscale nodes|preauthkeys, nebula-cert, lighthouse, zerotier-cli join, rosenpass, "split tunneling", "DNS leak", "subnet overlap", "VPN concentrator", "remote access", "always-on VPN".

Guiding principle (inherited from networking-standards: the network is default-deny and documented as code; what is not in the SoT does not exist): the tunnel transports, it does not authorise. A packet leaving wg0 is an untrusted packet that has just entered your network: being inside the VPN is not a credential, is not an authorisation and does not replace any policy. Every tunnel has an owner, a written scope, an expiry date and a filtering rule that receives it.

Not applicable: see networking-standards (parent: topology and addressing/IPAM that avoids the overlaps, VLANs and segmentation, routing and BGP to announce the tunnel prefixes, MTU/MSS as a network design criterion, proxies and load balancing, choice of the perimeter platform —OPNsense/VyOS/appliance—, OOB management plane and ZTNA as an architectural principle), firewall-policy-standards (the policy that filters the traffic leaving the tunnel: flow matrix, forward with policy drop, egress, owner/expiry of each rule, MSS clamping as a rule, conntrack — a wg0 that enters forward with no rules is a VPN without a firewall; here we decide which tunnel exists and how it is operated, there what traverses it), network-troubleshooting-standards (reactive diagnosis: "the VPN connects but I can't browse" is theirs —it is MTU/PMTU and it is proven with a capture at both ends—, as are "it drops after 5 minutes", "it resolves badly inside the tunnel" or "it works for a while"; here we fix the correct value of MTU/keepalive/DNS and why, there they work out which one is wrong in a specific case), identity-access-management-standards (identity: IdP, OIDC/SAML, phishing-resistant MFA, passkeys, SSO, SCIM and deprovisioning, PAM/JIT and break-glass accounts — the user and their authentication are theirs, the tunnel and its termination are ours), cryptography-pki-standards (the algorithms, the PKI and the tunnel certificates: suites, key sizes, issuance and revocation of client and gateway certificates, CRL/OCSP, ACME, CA custody, post-quantum migration criteria — here only what is configured in the tunnel and with what lifetime), secrets-management-standards (custody and rotation of private keys, PSKs and enrolment tokens; never in the repo nor in the config file), dns-standards (the DNS service and its data: which resolver is legitimate, split-horizon, internal zones; here only which resolver is pushed to the client and how it is prevented from querying outside), detection-engineering-standards (rules and analytics over VPN session logs: impossible geolocation, brute force, concurrent sessions), incident-response-forensics-standards (compromise of the concentrator as an incident: containment, appliance imaging, chain of custody, mass credential rotation), vulnerability-management-standards (triage and patching SLA for concentrator CVEs with KEV/EPSS — here the exposure argument, there the formal cadence), observability-standards (metrics, dashboards and alerts for the tunnel as a service), sre-practice-standards (remote-access SLOs and error budget), incident-management-standards (command and communication when the VPN outage is a declared incident), linux-hardening-standards (baseline of the host terminating the tunnel, forwarding sysctl, systemd sandboxing of the daemon), selinux-standards (process confinement), linux-administration-standards (systemd units, systemd-networkd, resolvectl and resolution from the host), bash-linux-scripting-standards (automation scripts), kubernetes-standards (service mesh and mTLS between pods: this is not a VPN), microservices-architecture-standards (east-west mTLS between services), aws-standards/azure-standards/gcp-standards (Site-to-Site VPN, Virtual Network Gateway, Cloud VPN and their managed ZTNA as a provider service), iac-standards/cicd-standards (the code and the pipeline that deploy the config), onprem-standards (platform umbrella), homelab-standards (home tunnel: the boundary is the rigour demanded, not the size), grc-compliance-standards (remote access as an auditable control against ENS/ISO/NIS2/DORA), bcdr-standards (remote access as a critical dependency of recovery: if DR depends on the VPN, the VPN is part of DR), offensive-security-standards (offensive validation of remote access, with scope and authorisation).

Also existing and on the boundary: ha-clustering-standards (the concentrator pair as a cluster resource: VIP, quorum, fencing and failover — the HA mechanics are theirs, the tunnel state that must survive the failover is ours) and podman-systemd-containers-standards (the tunnel daemon or the mesh agent run as a container with Quadlet: unit, network and privileges are theirs).

2. Default decisions / Toolchain

Verify the latest version and the project's status on the web before committing to anything (§8). Release dates obtained from api.github.com and from the upstream git, not from HTML pages.

A criterion of choice, not of taste. WireGuard if you control both ends. IPsec if the other end imposes it or there is a certification requirement. OpenVPN if the path is hostile and you need TCP/443. Managed mesh if you have mobile clients, NAT everywhere and identity-based ACLs. ZTNA if what you need to publish is an application, not a network.

3. Structure and conventions

3.1 The starting decision: which model solves your problem

• The market shift is real and has a technical cause, not a fashion one: the concentrator VPN grants network access after a single authentication, and that model broke along two simultaneous paths — (1) the concentrator became the preferred and exploited target (§5.1), and (2) the perimeter ceased to exist with SaaS and remote work. NIST SP 800-207 says it without hedging: location on the network does not grant trust.
• Operational translation, not a slogan: you do not have to "remove the VPN". You have to (a) stop using the tunnel as authorisation —each access is authorised by identity, device and application—, and (b) reduce the VPN to transporting what cannot yet be published per application, with minimal scope and an expiry date. The VPN survives as a transport layer, it dies as a trust layer.
• Migration criterion: publish first what is HTTP(S) (proxy/ZTNA), then what speaks a protocol with its own identity (SSH with certificates, RDP behind a broker), and leave the rest in the tunnel —with an inventory and a review date. A VPN that "stays for everything else" without a list is the same old VPN with a new name.

3.2 WireGuard: what you have to understand before writing a wg0.conf

• Fixed crypto with no negotiation: ChaCha20-Poly1305, Curve25519, BLAKE2s, HKDF. There are no suites to choose, no downgrade to negotiate and no "phase 1/phase 2" to mismatch. That is its main value against IPsec and it is not up for discussion; if your requirement demands cryptographic agility or a specific certified algorithm, WireGuard is not your protocol (see cryptography-pki-standards).
• UDP and silence by design: it does not answer anyone who does not present a valid key. A scan does not see it. That reduces surface, but it also means that a connection failure tells you nothing: diagnosis is asymmetric and needs a capture at both ends (network-troubleshooting-standards).
• AllowedIPs is routing and access control at the same time — the most common conceptual error.
  • On egress: it defines which destinations are routed through that peer (wg-quick creates the route).
  • On ingress: it is cryptokey routing — a packet arriving through the tunnel with a source outside that peer's AllowedIPs is dropped. It is the only authorisation WireGuard has.
  • Practical consequence: AllowedIPs = 0.0.0.0/0, ::/0 on a client peer of the server means "this peer can spoof any source". Each peer carries exactly its /32 (and its /128), or the prefix of the site it legitimately routes, and nothing else.
  • 0.0.0.0/0 is legitimate only on the client side towards the server (full-tunnel) or on a peer that really is the default exit.
  • This does not replace the firewall: WireGuard validates the source, not the destination nor the port.
• Keys: one private key per device, generated on the device (wg genkey), never reused between nodes or between environments, umask 077, 0600 file, and never in the repo (secrets-management-standards). The public key is a device identifier, not a person's: there is no user identity in WireGuard.
• Rotation: WireGuard does not rotate keys on its own. Rotation is a coordinated operation (add the new peer, migrate, retire the old one) and for that reason, beyond a handful of nodes, it is automated or it does not happen — which is exactly the argument for a managed mesh (§3.3). Set a cadence (annual as a floor, immediate on a leaver or on suspicion) and test the removal: a peer deleted from the server loses access instantly; checking that is the gate.
• PresharedKey: an additional symmetric layer per peer pair. Its intended use is post-quantum resistance (§3.6), not generic "more security". If it is used, it is one more secret to hold in custody and rotate per pair.
• PersistentKeepalive: 25 s is the reference value for the peer that is behind NAT or a stateful firewall, and it exists so the NAT association does not expire. Rules: it is set by the side that is behind the NAT, not by the public server; setting it on every peer of a mesh is traffic and battery in exchange for nothing. Without it, the symptom is the classic "it works when I initiate, not when they initiate" and "it drops when I stop using it".
• Roaming: WireGuard updates the peer's Endpoint upon receiving an authenticated packet from a new IP. That is its great mobile virtue, and also the reason why filtering by the client's source IP does not work as a control.
• Real limits that must be said out loud: no identity management, no user authentication, no MFA, no key distribution, no ACLs beyond AllowedIPs, no NAT traversal of its own (it needs a reachable end or a relay), no centralised revocation. All of that is provided by another layer; if you do not provide it, it is not there.
• Table = off when you want to control routing by hand (dynamic routing over the tunnel, policy routing); with automatic Table and AllowedIPs = 0.0.0.0/0, wg-quick installs policy rules that can break management access to the host itself. Remote change ⇒ rescue window open (§4).

3.3 Managed meshes: what you buy and what you give up

What they add over plain WireGuard (and why past a certain size it is not optional): federated identity against your IdP, automatic key distribution and rotation, identity-based rather than IP-based ACLs, NAT traversal (STUN/UPnP/hole punching) with fallback relays when the punch fails —DERP in Tailscale/Headscale, own relays in NetBird—, mesh DNS, immediate joins and removals, and visibility of which node talks to which.

What you give up: the control plane is the new root of trust.

• Whoever controls the coordinator distributes keys, ACLs and routes. Its compromise is not "a metadata leak": it is the ability to introduce a node into your network or to rewrite who can talk to whom. Treat it with the same criteria as your IdP or your CA, not as a network tool.
• Evidence that the client and the plane are real surface, not theoretical — Tailscale's own 2026 bulletins (verbatim from their bulletins page): TS-2026-004 (4 Jun) Tailscale SSH Unix socket forwarding did not respect symlink permissions; TS-2026-005 (3 Jun) Tailscale Serve Unix socket proxy targets were not restricted to root; TS-2026-006 (11 Jun) Tailscale SSH allowed users to be addressed by numeric UID, bypassing root user restrictions; TS-2026-007 (10 Jul) Insufficient inbound packet filtering in Services permitted access to loopback-bound listeners; TS-2026-008 (13 Jul) A single malformed HTTP request to a node running Tailscale Serve or Funnel could pin a CPU core indefinitely; TS-2026-009 (13 Jul) Insecure command line argument handling in Tailscale SSH permitted root user access in violation of ACLs. Read it for what it is: a privileged agent on all your nodes, with features that expose services and that bypass ACLs when they fail. Subscribe to the bulletins of whichever provider you choose and treat its patching as privileged-agent patching, not app patching.
• Questions answered in writing before adopting: is the control plane self-hostable? can the provider add a node to your network without your consent? do the relays see cleartext traffic (they should not: encryption is end to end) or do they only forward it? where does the plane live and under which jurisdiction? what happens to the network if the provider goes down —do already-established tunnels survive, do new joins not? what bulletin history does it have? what licence and what business model, and what happens if they change?
• The business model changes and it affects you: in 2026 there was movement in prices and licences in this space (Tailscale towards per-seat pricing; ZeroTier tightening the self-hosted controller; NetBird formalising its self-hosted edition). Do not pin any of those conditions from memory — verify the current one before committing to a platform (§8).
• A written exit criterion from day one: what you do if the provider changes its licence, raises the price or disappears. The "whole plane in-house" option (Headscale/NetBird self-hosted/Nebula) is precisely the insurance against that, at the cost of operating it yourself.
• Nebula is the different choice: certificate-based with your own CA, no phoning home, no SaaS; in exchange, operating the CA and the lighthouse is on you (cryptography-pki-standards).

3.4 IPsec/IKEv2: when and with what discipline

• It is used when the other end imposes it (a third party's appliance, a carrier, a certification requirement) or when you need standardised PQC (§3.6). It is more complex and has more surface —strongSwan's 2026 CVE history confirms it (§8)—, but it is still alive because it is the only common denominator between vendors.
• IKEv2 always; IKEv1, aggressive mode, XAUTH and group PSKs are vetoed.
• The classic phase-2 mismatch: phase 1 (IKE_SA) comes up, phase 2 (CHILD_SA) does not, and the log does not say so clearly. Causes in order of frequency: ESP proposals that do not match (encryption, MAC, PFS group), traffic selectors (local_ts/remote_ts) that are not identical and mirrored on both sides, and tunnel vs. transport mode. Rule: the proposal is agreed in writing with the third party before configuring, is written explicitly at both ends (no long lists "just in case", which mask the disagreement and negotiate downwards), and the selectors are compared literally. One side with 0.0.0.0/0 and the other with a /24 is the number-one cause of "it comes up and it drops".
• Rekeying: define IKE_SA and CHILD_SA lifetimes that are coherent at both ends and with different margins, or you will have exactly periodic outages (symptom: "it drops every 8 hours"). Suspect rekeying on any outage with a regular periodicity.
• MOBIKE (RFC 4555) for mobile clients: it allows changing IP/interface without renegotiating. It is what makes IKEv2 usable on a laptop hopping from WiFi to 4G. Enable it or accept reconnections.
• IKE fragmentation: messages with certificates or with PQ keys exceed the MTU. Enable IKEv2 fragmentation (RFC 7383) and do not block ICMP; otherwise the tunnel "sometimes does not come up" depending on which certificate the client uses.
• NAT-T (UDP/4500): needed in almost every real scenario. Modern strongswan is configured with swanctl.conf; ipsec.conf/starter is the legacy path and is being retired.
• DPD (dead peer detection) enabled on both sides, or a dead tunnel will still be "up" in the table and traffic will fall into a black hole.

3.5 OpenVPN: where it is still justified

• Valid justifications, and only those: the path blocks UDP and you need TCP/443 to look like web traffic; there are legacy clients or platforms with no acceptable WireGuard client; you need integrated user authentication (PAM, LDAP, plugins) without building another layer.
• TCP-over-TCP is a real penalty (TCP meltdown): use it as plan B, not as the default. If UDP is available, UDP.
• Non-negotiable minimum config: tls-crypt (better than tls-auth: besides authenticating, it encrypts the control channel and hides OpenVPN's fingerprint), server and client certificates with remote-cert-tls, an active and tested CRL, AEAD encryption (AES-GCM/ChaCha20-Poly1305), TLS ≥1.2 with 1.3 preferred, and verify-x509-name so that a client certificate cannot impersonate the server.
• DCO changes performance and the deployment model: the ovpn module upstream since Linux 6.16 (replacing the out-of-tree ovpn-dco-v2; ovpn-backports for earlier kernels), and on Windows win-dco is the default with tap-windows6 as fallback — wintun was removed in 2.7. If you depended on wintun, that is a deployment change, not a detail.
• redirect-gateway turns the client into full-tunnel: it is a risk decision (§3.7), not a default value.

3.6 Post-quantum: what exists today and what does not

• WireGuard does not ship PQC. Its crypto is fixed; the only extension point is the PresharedKey, and by design (the project itself documents it as the intended use of that hook). Selling a WireGuard deployment as "quantum-safe" is forbidden.
• Via WireGuard: Rosenpass runs a separate PQ exchange and injects the result into the PSK hook, refreshing it periodically; the WireGuard protocol stays intact. Real status: pre-1.0 (v0.2.3, 3 Aug 2026). Adopt it knowing it is pre-1.0 software and that its deployment is all-or-nothing per peer except in permissive mode. NetBird integrates it as an option.
• Via IPsec: RFC 9370 (multiple key exchanges in IKEv2, with IKE_INTERMEDIATE so that large keys do not blow up IKE_SA_INIT) + RFC 8784 (PPK) is the standardised route. strongSwan supports it since 6.0.0 (ke1_mlkem768, ppk=yes). It is the defensible option if the requirement is formal/certifiable.
• Criterion: the threat model is harvest now, decrypt later. If your traffic has value over 10+ years, hybrid (classical + PQ, never PQ alone) is reasonable today in IPsec and experimental in WireGuard. The algorithms, their standardisation status and the migration plan are decided in cryptography-pki-standards, not here.

3.7 User remote access: the full cycle

• Identity first: authentication against the corporate IdP with phishing-resistant MFA (passkeys/FIDO2). No shared secret, no "the certificate is already the user", no SMS. The policy and the IdP, in identity-access-management-standards.
• Short-lived credentials > permanent keys. The goal is for the client credential to expire on its own: a short-lived certificate issued after authenticating at the IdP, or a token/profile that expires. A permanent key on a lost laptop is permanent access until someone remembers to revoke it. If you use permanent keys (plain WireGuard), revocation is a process with an owner and with proof, not an intention.
• Split tunnelling: an explicit, documented risk decision, never an inherited default.
  • Full tunnel: all traffic passes through the organisation — full inspection, filtering and logging; in exchange, latency, bandwidth cost, concentrator capacity and a connectivity SPOF for the user.
  • Split tunnel: only corporate traffic enters the tunnel — better performance and cost; in exchange, you lose visibility of the rest of the device's traffic and you accept that the endpoint is exposed to the Internet while it is "inside".
  • Criterion: if your content control and your telemetry live on the endpoint (EDR + forced DNS resolution + proxy), split tunnelling is defensible; if they live at the perimeter, split tunnelling disables them. Decide, write it down and review it; the hybrid (split by destination, with the sensitive traffic and DNS forced into the tunnel) is the usual balance point.
  • What is never acceptable: split tunnelling that leaves DNS resolution outside the tunnel (§3.8) or that lets the client act as a bridge between the Internet and the corporate network.
• Device posture as a condition of access: managed and inventoried device, encrypted disk, EDR alive and up to date, patched OS, and continuous reassessment, not just at connection time. A laptop that complied on connecting and stops complying an hour later must lose access. BYOD without posture ⇒ per-application ZTNA, never a network tunnel.
• Deprovisioning the same day — and "the same day" is a measurable commitment: the leaver in the IdP revokes VPN access, revokes the certificate, removes the peer from the concentrator and cuts active sessions. Most deployments fail at that last point: blocking the login does not evict whoever is already inside. Test deprovisioning quarterly with a test account (§4).
• Always-on with a captive-portal exception: the client brings the tunnel up at boot and only allows traffic outside it for the visited network's portal, with a short expiry.

3.8 Tunnel operation: what breaks in practice

• MTU and MSS: the number-one cause of "the VPN connects but some websites don't load" — the TCP handshake (small packets) works, the transfer (large packets with DF) hangs.
  • Adjust the tunnel MTU and also do MSS clamping in forward: they are complementary measures, not alternatives. The reference values and the calculation, in networking-standards; the nft rule that applies it, in firewall-policy-standards.
  • Do not block ICMP type 3 code 4 (fragmentation needed) nor ICMPv6 packet-too-big: without them PMTUD dies and the failure is silent and intermittent.
  • Watch offload (GRO/GSO/TSO) on the tunnel interface: it aggregates above the MTU and drops with DF set.
  • Diagnosing a specific case belongs to network-troubleshooting-standards; here we fix that the value must be set, tested with a large packet and DF, and documented.
• DNS inside the tunnel and DNS leaks: the client must use the corporate resolver for corporate traffic. The typical leaks are (a) the client keeps the local DHCP resolver, (b) the OS queries several resolvers in parallel and the outside one wins, (c) the browser uses its own DoH and bypasses the whole system resolver, and (d) mDNS/NetBIOS resolving outside. Controls: push the resolver and the search domains from the tunnel, a browser policy that disables uncontrolled DoH, and active verification that the query leaves where it should. Which resolver is legitimate and how it is designed: dns-standards.
• Routes and address overlap — the classic of merging two sites with 192.168.1.0/24: there is no elegant fix, only three ways out, in order of preference: (1) renumber one of the sides (correct, painful, definitive); (2) 1:1 NAT of the overlapping prefix in the tunnel, with a documented "mirror" range in the IPAM —it works, it breaks everything that carries IPs embedded in the protocol or in configuration, and it multiplies the cost of diagnosis; (3) publish only specific services via proxy/ZTNA and do not join the networks. Prevention belongs to networking-standards: an addressing plan with large blocks and no overlaps from day one, because mergers do come.
• Routes announced with judgement: a peer that announces 0.0.0.0/0 to the mesh becomes everyone's exit without anyone deciding it. Tunnel routes are approved like any other routing change, and they are filtered (AllowedIPs in WireGuard, route ACLs in the mesh, --advertise-routes requiring explicit approval in Tailscale/Headscale/NetBird).
• Concentrator redundancy and capacity: active/passive or active/active pair with a DNS name or a virtual IP, exercised failover, and sizing by concurrent users on the worst day (not by headcount) with margin for the continuity scenario —March 2020 taught that the concentrator sized for 30% of headcount is a business incident. If DR depends on the VPN, the VPN is critical DR infrastructure (bcdr-standards).
• The tunnel is monitored as a service, not as an interface: "the peer is configured" is not "the tunnel works". See §6.

4. Mandatory quality gates

In increasing order of cost. The first five block the deployment.

1. Configuration validation before applying: wg-quick strip / wg setconf against the candidate config, swanctl --load-all in test mode, openvpn --config ... --test-crypto, networkctl for the units. A config that does not validate does not even reach staging.
2. Review of AllowedIPs as a security gate, not a network one: no peer with more reach than it should have; 0.0.0.0/0/::/0 only on the side that legitimately requires it and with written justification. This gate is the WireGuard equivalent of the firewall's "any/any".
3. Rescue window open on every remote change that touches the tunnel, routes or remote access: OOB console, a second administration path or a timed rollback (systemd-run --on-active restoring the previous config unless confirmed). Changing the tunnel through the tunnel itself with no safety net is the most predictable self-lockout in the trade.
4. Mandatory negative test: (a) a removed peer loses access immediately; (b) a source outside its AllowedIPs is dropped; (c) traffic between two VPN clients is denied if the policy says so; (d) the concentrator exposes nothing beyond its tunnel port. A tunnel tested only along the happy path is not tested.
5. End-to-end MTU test with a large packet and the DF bit, not just a default ping, and with the real application (a large transfer, not a curl to a one-line page). This is the gate that avoids 90% of the "the VPN is behaving oddly" tickets.
6. DNS leak and route test after each client or profile change: resolution goes out where it should, the traffic that must go to the tunnel goes to the tunnel, and what must not, does not. With split tunnelling active this test is mandatory on every profile change.
7. Quarterly deprovisioning drill: a test account marked as a leaver in the IdP ⇒ check that it loses access and that its active session is cut. Document the real time to cut-off.
8. Concentrator failover drill in a window: site-to-site tunnels re-establish, the clients reconnect, and how long it takes is measured. A secondary that is never exercised is not redundancy.
9. Load test before the high season or the continuity event: the target concurrent users with realistic traffic, measuring encryption CPU, sessions and bandwidth.
10. Periodic review of the inventory of tunnels and peers (quarterly): every tunnel and every peer with an owner, reason, scope and last activity; inactive ones are retired. A peer belonging to a provider whose contract ended a year ago is permanent access nobody remembers.

5. Security

5.1 The VPN concentrator is a first-order target — with data, not rhetoric

Evidence (CISA KEV catalogue, version 2026.07.29, 1,656 entries; consulted directly from CISA's JSON, not from a press note). Actively exploited vulnerabilities in remote-access and perimeter devices added since Jan 2025:

Mandatory reading of that table (risk class, never an exploitation procedure):

• The dominant family is pre-auth authentication bypass, not execution after authenticating. The "only valid users" control does not protect a device whose flaw is before that check.
• Exploitation arrives in days, sometimes hours, and the groups using it seek persistence in the appliance itself —where your EDR does not reach and your software inventory does not look.
• The old CVE kills: CVE-2021-20035 was being actively exploited in 2025. An appliance with no patching window accumulates exploitable debt for years.
• No vendor is clean. The choice of brand is not a security control; the patching process is.

Design consequences — this is what you have to do with that data:

• Minimal exposure: only the tunnel port to the Internet. The concentrator's management plane is never published (neither administration HTTPS, nor SSH, nor API) — it is reached over OOB or via a bastion (networking-standards). A good part of the CVEs in the table affect management or portal interfaces that were exposed.
• An emergency patching window committed in writing before purchase: hours, not weeks, for a KEV on the edge device. The formal cadence and the risk-based SLA, in vulnerability-management-standards.
• Minimal surface by design: a WireGuard daemon on a minimal, hardened Linux host that is patchable in minutes has orders of magnitude less surface than an appliance with a web portal, integrated SSO, antivirus and management console. When you can choose, choose the small thing.
• Assume the concentrator is compromised in the threat model: segment what is behind it, filter the tunnel's outbound traffic, do not store domain credentials on the appliance and have decided in advance how you isolate it and rebuild it from a clean image (incident-response-forensics-standards). A compromised appliance is not cleaned, it is rebuilt.
• Watch the vendor actively: subscribe to its advisories, and review KEV as an operational trigger. One of your products entering KEV is an incident, not a maintenance task.

5.2 Cryptographic and key hygiene

• No negotiation is better than negotiation: where you can choose, prefer a fixed-suite protocol (WireGuard). Where you negotiate (IPsec/TLS), the proposal is explicit and short; long lists "for compatibility" are a downgrade waiting to happen.
• No private key leaves the device that uses it. Local generation, 0600 permissions, out of the repo and out of cleartext backups (secrets-management-standards).
• Proven revocation: CRL/OCSP working and verified with a genuinely revoked certificate; peer removal verified. An untested revocation does not exist.
• PSKs and enrolment tokens: short expiry, single use where possible, and rotation. A mesh enrolment token is a key to enter your network.
• Algorithms, lengths, PKI and the post-quantum plan: cryptography-pki-standards.

5.3 The tunnel does not authorise: filtering and segmenting what leaves it

• forward with policy drop and a flow matrix for the traffic entering from the tunnel, just as for any other zone (firewall-policy-standards). The VPN zone is one more zone and is usually the least trusted: devices you do not fully control, on networks you control not at all.
• Isolation between VPN clients unless there is an explicit requirement: by default, one client does not talk to another client.
• Filtered tunnel egress: a compromised client on full-tunnel uses your Internet exit with your reputation.
• Access per application, not per network, whenever the protocol allows it. The concentrator is the transport; authorisation is provided by identity.

5.4 Session logging and forensics

• What is logged, as a minimum: authenticated identity, device, public source IP and its geolocation, IP assigned inside the tunnel, start and end timestamps, disconnect reason, bytes, and the result of the posture evaluation. Without the association tunnel-IP ↔ user ↔ time window, no later investigation can attribute anything.
• Retention at least equal to the organisation's investigation window, with protect

…(truncated)