WireGuard Security Guide: Keys, Config and Deployment

WireGuard's cryptography is fixed and well reviewed, so almost every real WireGuard weakness comes from how keys are generated, stored, distributed and retired, and from how AllowedIPs and routing are configured. The protocol deliberately leaves key distribution, user authentication and logging to the operator. This guide explains what WireGuard secures by design, what it leaves to you, and how to deploy it safely on servers, laptops, routers and container platforms. It covers private key handling, preshared keys, cryptokey routing, leak prevention, monitoring and lifecycle at scale. It is written for network, platform and security engineers running WireGuard directly or through a management layer. For a comparison with IPsec and OpenVPN see the VPN Protocols Compared: WireGuard, IPsec, OpenVPN Guide.

Key takeaways

A WireGuard private key is the identity. Anyone holding it is that peer, with no expiry, revocation list or second factor, so key storage and removal are the core controls.
AllowedIPs is both routing and access control. On inbound traffic it decides which source addresses a peer may use, so a careless 0.0.0.0/0 on the wrong side turns a peer into a trusted router for any address.
Add a preshared key per peer pair. It costs nothing in performance, adds a symmetric layer and is the documented slot for mixing in post-quantum key material.
WireGuard authenticates devices, not users. If people connect, MFA, session expiry and offboarding must come from a control plane or surrounding process.
Visibility has to be built. WireGuard is silent to unauthenticated packets and logs little, so latest handshake times, transfer counters and flow logs are your telemetry.

What WireGuard secures by design

WireGuard uses the Noise IKpsk2 handshake with Curve25519 for key agreement, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing and HKDF for key derivation. There is no cipher negotiation, so there is nothing to downgrade. Several properties come free with a correct deployment:

Silence to strangers: a WireGuard listener does not reply to packets that are not correctly authenticated and allocates no state for them, so port scanners see nothing.
Handshake flood protection: under load a responder answers with a cookie instead of doing expensive work. The cookie is a MAC of the sender's IP address using a secret that changes every two minutes.
Replay protection: handshake initiations carry an encrypted TAI64N timestamp, and data packets carry a 64-bit counter checked against a sliding window of about 2,000 values.
Forward secrecy and frequent rekeying: session keys are rotated every 120 seconds (Rekey-After-Time) and packets on keys older than 180 seconds are rejected. Keys are zeroed if no new handshake follows.
Small, auditable code: the whitepaper reports under 4,000 lines of code excluding cryptographic primitives, and the Linux implementation runs in the kernel.

What WireGuard leaves to you

The project's own known limitations page is the best threat model starting point. The table turns those limitations into operator actions.

Limitation (wireguard.com)	Risk	Operator control
Key distribution is out of scope	Keys shared over email, chat or tickets; no revocation	Automated enrolment, central peer registry, removal on leaver or decommission
Not post-quantum by default	Recorded traffic decrypted in future	Per-peer preshared key; PQ handshake fed into the PSK slot where needed
Identity hiding is not forward secret	Compromise of a responder key reveals which peers connected in logged traffic	Protect and rotate server keys; regenerate after suspected compromise
Roaming without extra authentication	An active attacker in path can redirect where encrypted packets are sent (not decrypt them)	Firewall server sockets to known peer ranges where peers are static
Relies on system time as a monotonic counter	Clock jumps lock peers out or enable replay of a stored initiation if time is hostile	Authenticated time sources; alert on large clock changes
No TCP mode, no obfuscation	Blocked on filtered networks; users install ad hoc wrappers	Approved fallback path, not unvetted tunnelling tools
No user authentication or logging layer	Shared devices, no MFA, little audit trail	Control plane with SSO and MFA, plus handshake and flow monitoring

Key generation, storage and preshared keys

Generate on the device: create the private key where it will be used, with umask 077 set first, then wg genkey and wg pubkey. Only the public key should ever leave the device. Central generation followed by distribution creates a second copy you must also protect.
Never put keys on a command line: the wg(8) manual requires private-key and preshared-key to be file paths because process arguments are visible to other users on most systems. The same applies to scripts that echo keys into logs.
Protect configuration files: /etc/wireguard/wg0.conf contains the PrivateKey, so restrict it to root (mode 600) and keep it out of backups that are not encrypted. Note that wg show hides keys by default, but wg showconf and wg show dump print the private key; restrict who can run them.
Keep keys out of source control: infrastructure as code should template configuration and pull private keys from a secrets manager or generate them on first boot. Committed WireGuard keys are a form of ATT&CK T1552.001 Credentials In Files. See the Secrets Management Guide.
Use a preshared key per peer pair: generate it with wg genpsk and set PresharedKey on both sides. Do not reuse one PSK across many peers, which turns it back into a shared secret. Where long-term confidentiality matters, run a post-quantum key exchange and insert the result into this slot, as the WireGuard documentation suggests.
Hardware-backed keys: where platforms support it, prefer clients or management tools that keep the private key in a TPM or secure enclave, consistent with NCSC advice to store VPN private keys in hardware-protected storage.

Configuration hardening

A WireGuard configuration has few fields, which makes each one significant. The reference below uses the field names from wg(8) and wg-quick(8).

Field	Secure setting	Why
`[Interface] PrivateKey`	Per device, generated locally, file mode 600	It is the peer's identity
`[Interface] ListenPort`	Fixed on servers (51820 is common) and allowed only from expected sources; omit on roaming clients	Predictable firewall rules; clients do not need to listen
`[Interface] FwMark`	Set when using policy routing for full tunnel	Lets the tunnel's own packets bypass the tunnel route; used by wg-quick
`[Peer] PublicKey`	One peer per device, registered with an owner	Enables per-device removal
`[Peer] PresharedKey`	Unique per peer pair	Symmetric defence in depth and PQ slot
`[Peer] AllowedIPs` (server side)	Exactly the client's tunnel address, e.g. `/32` and `/128`	Stops a client spoofing other addresses
`[Peer] AllowedIPs` (client side)	`0.0.0.0/0, ::/0` for full tunnel, or explicit internal ranges for split tunnel	Defines what the client sends into the tunnel
`[Peer] Endpoint`	DNS name or IP of the server on clients only	Servers learn client endpoints from authenticated traffic
`[Peer] PersistentKeepalive`	Off by default; 25 seconds only behind NAT where inbound reachability is needed	Keepalives make the peer chattier and more visible

Do not use WireGuard as a firewall: AllowedIPs controls source addresses per peer, not which services a peer may reach. Add host or gateway firewall rules on the wg0 interface so a compromised laptop cannot reach every internal subnet. See the Network Segmentation Guide.
Disable forwarding where not needed: only hub or gateway nodes should have IP forwarding enabled. A peer-to-peer mesh member that forwards becomes an unintended router between segments.
Apply changes without dropping sessions: use wg syncconf to apply a changed configuration, which alters only differing settings, rather than tearing the interface down during peer removal.
Run unprivileged where possible: user-space implementations and management agents should run with the minimum capabilities needed (on Linux, typically CAP_NET_ADMIN) rather than as full root.

Routing and leak prevention

A full-tunnel client must not send traffic outside the tunnel when the tunnel is down or when a DHCP renewal rewrites routes. The WireGuard routing documentation describes three approaches:

Policy routing with fwmark: mark the tunnel's own UDP packets, then route all unmarked traffic through a table whose default route is wg0. Because the exemption follows the mark rather than a fixed endpoint IP, it survives server roaming. This is the technique wg-quick uses.
Overriding routes: adding 0.0.0.0/1 and 128.0.0.0/1 leaves the default route in place but can lose the endpoint route when links change. It is simple but fragile.
Network namespaces: move physical interfaces into a separate namespace and leave only wg0 in the main one. Ordinary processes then have no path to send cleartext. This is the strongest isolation for servers and containers.

Also route DNS through the tunnel (the DNS option in wg-quick configurations) and handle IPv6 explicitly: including ::/0 in AllowedIPs or blocking IPv6 egress prevents an IPv4-only tunnel from leaking IPv6 traffic. NCSC guidance favours full tunnel over split tunnelling for managed devices.

Choosing between full and split tunnel

Full tunnel: all client traffic goes through the hub, so the organisation's egress filtering and monitoring apply everywhere. The cost is hub bandwidth and latency. Prefer it for managed laptops handling sensitive data.
Split tunnel: only internal ranges listed in the client's AllowedIPs use the tunnel. It suits server-to-server overlays and contractor access to a single service, where the peer should reach nothing else. Keep the list as narrow as possible and pair it with firewall rules on the hub.
Small versus large estates: a small team with a few peers can manage hand-written configs and a spreadsheet registry; beyond a few dozen peers, manual key distribution becomes the main source of error and a control plane or configuration management with a secrets store is worth the overhead.

Where identity fits

In most WireGuard estates the majority of peers are not people: they are servers, routers, Kubernetes nodes and CI runners, each holding a long-lived private key with no built-in expiry. That makes WireGuard keys non-human identities. Treat them the same way as API keys and certificates: an inventory entry, an owner, a rotation schedule and immediate removal when the workload or device is retired. For user access, layer SSO with phishing-resistant MFA through a control plane and remove the user's device keys on offboarding. See the Cryptographic Key Management Guide and the Remote Access Identity Guide.

Safe deployment: a phased rollout

Decide the topology: hub and spoke (simplest to audit), site-to-site, or full mesh. Choose a management approach: hand-written configuration for a handful of peers, configuration management with a secrets store for tens, a control plane with SSO for hundreds or more.
Write the baseline: key generation on device, per-pair PSK, server-side /32 AllowedIPs, interface firewall rules, full-tunnel routing method, DNS, logging requirements and the key rotation interval.
Build the peer registry: record public key, owner, device, tunnel addresses, creation date and review date. The registry, not the server config, is the source of truth.
Pilot: deploy to a test ring of engineers or a non-production site. Verify leak behaviour by stopping the tunnel and checking that no traffic reaches the internet, test roaming between networks, sleep and resume, and that telemetry reaches monitoring.
Expand in rings: move to one business unit or environment at a time, keeping the previous remote access method available.
Rollback plan: keep the old VPN or access path enabled until two clean rings have completed. Rollback is removing the WireGuard route and re-enabling the old profile, so document it and test it once.
Operate: rotate keys on schedule and on any suspected compromise, prune peers with no recent handshake, and patch WireGuard tools, kernels and management agents with the rest of the estate.

Detection and measurement

WireGuard does not log handshakes or failures by default. Collect wg show <interface> dump (or the latest-handshakes and transfer fields) on a schedule, being careful that full dump output includes the private key and should be filtered before shipping. Combine it with firewall flow logs on the listen port and on wg0. Alert on handshakes from unexpected source networks, sudden transfer spikes on a peer, peers appearing outside the registry and configuration file changes. Remote use of tunnels maps to ATT&CK T1133 External Remote Services and misuse of a stolen key to T1078 Valid Accounts.

Metric	What it shows	Target
Peers in configuration but not in the registry	Unmanaged keys	Zero
Peers with no handshake in 30 days	Dormant keys to remove	Pruned monthly
Peers without a unique preshared key	Missing defence in depth	Zero for production
Server-side AllowedIPs broader than one host per client	Spoofing or routing risk	Zero unless documented gateway
Keys older than the rotation interval	Lifecycle drift	Under 5 per cent
Time from leaver or decommission to peer removal	Offboarding effectiveness	Same business day

Common failure patterns

One key shared by many devices: a single client config is copied to every laptop or container image. Removing one device then means rekeying all of them, so nobody does.
Private keys in repositories and images: configs committed to Git or baked into AMIs and container images expose keys to everyone with read access.
Wide server-side AllowedIPs: a client entered with a subnet or 0.0.0.0/0 on the server can source traffic as any internal address.
Tunnel treated as the access policy: no firewall rules on wg0, so any connected peer reaches every network routed through the hub.
No offboarding: peers are never removed because there is no registry. Like the dormant account behind the Colonial Pipeline ransomware attack, a forgotten but valid credential stays usable.
Leaks on full tunnel: DNS and IPv6 bypass the tunnel because only IPv4 default routes were added.

Framework mapping

Framework	Reference	WireGuard control
NIST SP 800-53 Rev. 5	AC-17, AC-17(2)	Authorised remote access with encrypted sessions
NIST SP 800-53 Rev. 5	SC-12, IA-5	Key generation, storage, rotation and removal of peer keys
NIST SP 800-53 Rev. 5	CM-7, AU-2	Minimal forwarding and services; handshake and flow logging
NIST CSF 2.0	PR.DS-02, PR.AA-03, DE.CM-01	Data in transit, device authentication, network monitoring
ISO/IEC 27001:2022 Annex A	A.8.20, A.8.24	Networks security, use of cryptography including key management
MITRE ATT&CK v20	T1133, T1078, T1552.001	Remote service abuse, stolen keys, keys in files

Practitioner checklist

Generate every private key on its own device with umask 077; never pass keys as command-line arguments.
Restrict configuration files to root and keep keys out of Git, images and unencrypted backups.
Configure a unique PresharedKey for every peer pair.
Set server-side AllowedIPs to exactly each client's tunnel addresses.
Add firewall rules on the WireGuard interface; disable IP forwarding on non-gateway peers.
Use fwmark policy routing or namespaces for full tunnel, and route DNS and IPv6 deliberately.
Maintain a peer registry with owner, purpose and review date, and prune peers with no recent handshake.
Layer SSO and MFA for user access through a control plane and remove device keys on offboarding.
Collect handshake and transfer telemetry, filtering out private keys, and alert on unregistered peers.

WireGuard Security Guide: Keys, Configuration and Safe Deployment