the crypto was never the hard part

For two years at the MSP I carried a pager that was, functionally, a subscription to one IPsec tunnel. It linked a client's warehouse to their office across town, and every second or third Tuesday it would rekey badly and drop, and someone in shipping would call because the label printer had gone quiet. The fix was always the same. Restart the service, watch the phase two negotiation until it looked healthy, log the ticket. One Monday in 2021 I got tired of it, stood up a WireGuard tunnel between the two sites on a lunch break, and turned the IPsec box off. The tunnel has not paged me since, and I do not work for that client anymore, and I still think about that printer.

Here's the thing. WireGuard is free, it is open source, and it merged into the mainline Linux kernel back in 2020, so the protocol part of this conversation is over. It won. The part everyone gets wrong is that WireGuard is not a VPN product. It is a protocol, a few thousand lines of kernel code where OpenVPN and the IPsec stacks carry hundreds of thousands, and it deliberately does none of the work you actually get paid for. No user directory. No single sign on. No way to hand out an address or expire a key. Every vendor selling "WireGuard" in 2026 is selling the management layer around it, and the crypto, the part everybody worries about, is the piece that was never at risk.

what it actually is

A VPN protocol with a fixed cipher suite, which means no negotiating algorithms with a peer, which means no downgrade tricks. ChaCha20-Poly1305 for the data, Curve25519 for the keys, and a handshake that finishes in a round trip. There is no server certificate to expire, no certificate authority to babysit, no PKI. You have a keypair, your peer has a keypair, and each side keeps a short list of which key is allowed to claim which IP addresses. That last bit is called cryptokey routing, and it is the entire data model. The whole config for a peer fits on a screen:

[Interface]
PrivateKey = <redacted>
Address = 10.10.0.4/32
DNS = 10.10.0.1

[Peer]
PublicKey = <redacted>
Endpoint = home.example.net:51820
AllowedIPs = 10.10.0.0/24, 192.168.30.0/24
PersistentKeepalive = 25

The AllowedIPs line is doing the security work. It is a routing table and an access control list at the same time, so if a laptop key should only reach one subnet, you write one subnet and the kernel silently drops the rest. Compare that to the average enterprise VPN client, where "connected" means "routes to everything."

The other property nobody believes until they see it: the tunnel is silent when idle. No packets flow until there is traffic, so from the outside there is nothing to fingerprint on the wire, and when you switch from coffee shop wifi to a phone hotspot the tunnel just moves with you, same address, no reconnect ceremony.

the part everyone gets wrong

People hear "simple" and think "easy at scale." Those pull in opposite directions. Adding a peer by hand takes ninety seconds. Adding the four hundredth peer by hand takes an org chart, and the protocol will not help you, because there is no built-in enrollment, no directory integration, no MFA prompt, and no way to push a config. This is why Tailscale, Firezone, Netbird, and half the zero trust market exist. They are key management wrapped around WireGuard, and that wrapper is a controller that knows your device inventory, which is a genuinely new trust decision that "we use WireGuard, it's open source" does not cover.

The second misread is operational. Because the tunnel is silent, a monitoring system that expects heartbeats will read an idle WireGuard peer as dead. On the warehouse tunnel we learned to send a ping every five minutes just so the dashboard looked alive. The tunnel was never down. The dashboard was wrong. I lost a couple of evenings to that before it clicked, and I have met two other engineers who lost the same evenings.

where it breaks

Key lifecycle, first and worst. The protocol has no key expiry and no revocation story. A key works until someone edits a config and removes it. I got this wrong in a way that still bothers me: I sold an old phone in 2022 and left its peer entry enabled for about eight months, because nothing prompted me to remove it. That phone walked out of my house with a live key to my home network, and the only reason the story ends boringly is luck and the fact that the buyer probably never opened a terminal. Nothing bad happened. That is not evidence. It is a streak.

Networks that hate UDP, second. WireGuard runs over UDP and offers no TCP fallback, so on some hotel and corporate networks it simply will not connect, and the workarounds are third party hacks of varying taste. If your threat model includes "I need a tunnel from anywhere," test it from an actual conference wifi before you depend on it.

Platform dependency, third, and this one is current. In April 2026 TechCrunch reported that the WireGuard developer could not ship software updates because Microsoft locked the account tied to his builds, which stalled the Windows client's update path while two companies argued about an account. Nothing about the protocol was broken. The distribution was. That distinction is the entire supply chain lesson, and it applies to every tunnel you run: the code being correct is not the same as the update reaching you.

And privacy, last, because consumer VPNs advertise this protocol by name. WireGuard moves the trust from the tunnel to the endpoint. The exit server sees your real address, some implementations hold session state in memory, and if you write your config to disk you have written your private key to disk. "WireGuard inside" on a commercial VPN is a statement about transport, not about who is watching.

what to do

• Generate keys on the device that will use them. A private key that has touched a paste bin, even once, even yours, is burned.
• One keypair per device per network, and the smallest AllowedIPs that does the job. Broad routes are how one laptop becomes a bridge.
• Put a key rotation on the calendar, quarterly, thirty minutes, all peers. If that feels excessive, ask what an unrevoked phone key was worth for eight months.
• Use PersistentKeepalive only on peers behind NAT that need to stay reachable. Everywhere else it is battery drain and a beacon.
• If you are deploying past a dozen peers, evaluate the management layer honestly. The question is not "does it use WireGuard" but "who runs the controller, and what happens when that account gets locked."

One useless detail to end on: my laptop config still has a peer labeled fridge-cam for a camera that died in 2023. The line is commented out, not deleted, because deleting it would mean admitting the fridge camera era is over, and I am not ready for that conversation.

The tunnel is the easy part. The bookkeeping is the product.

Audit your peers. Tonight, before the phone story becomes your story.