Is WireGuard secure? Yes, in the ways a tunnel protocol can be: it uses one fixed set of modern cryptographic primitives with no negotiation to get wrong, its codebase is small enough to be read in full, and it has been independently reviewed and formally analyzed. According to the WireGuard project, the implementation is under 4,000 lines of code, against the hundreds of thousands in older VPN stacks. Fewer lines, fewer places for bugs, easier audits. That is the case for it, and it is a strong one.
What "secure" does not cover is just as important. WireGuard secures the tunnel between two peers; it does not manage keys, does not hide that you use it, does not by itself forget your address when you disconnect, and does not decide what runs on the server. Below, what it protects, what it leaves to you, and a short checklist for your own setup.
The cryptography, in one paragraph
WireGuard fixes the algorithms instead of negotiating them: Curve25519 for key agreement, ChaCha20-Poly1305 for encryption and authentication, BLAKE2s for hashing, HKDF for key derivation, per the project's documentation. There is no "which cipher suite did we end up with" and no downgrade path, which removes an entire class of the problems that have plagued older protocols. If one of these primitives is ever broken, the protocol version changes; you do not patch a config file, you update the software. The handshake also provides forward secrecy: session keys rotate, so a key captured later does not unlock earlier traffic.
Small code, real reviews
Older VPN stacks carry decades of features, options and compatibility layers, and their size makes full audits impractical. WireGuard's size makes them practical, and they have happened: the protocol has been the subject of formal verification work and independent security reviews, and the Linux implementation was accepted into the mainline kernel, which brings its own review process. None of that makes it bug-free; it makes bugs easier to find and fix, and it means the protocol's claims have been checked by people other than its author. How it compares with the older protocol in day-to-day terms is in WireGuard vs OpenVPN.
What WireGuard protects
Everything between your device and the peer: content, DNS if it is routed through the tunnel, the addresses of the sites you visit. An observer on the café Wi-Fi or at your ISP sees encrypted packets to one address and their volume. The tunnel survives network changes without a new handshake, so there is no gap when your phone moves from Wi-Fi to cellular, provided the app keeps the tunnel up.
What it deliberately leaves to you
Key management. Each peer needs the other's public key, distributed somehow. Paste them by hand, use a config generator like ours, or use a mesh service that distributes them; the trade-offs of that route are in WireGuard vs Tailscale. Lose a private key, or leave a stale peer in the server config, and the cryptography cannot help you.
DNS. WireGuard carries packets; it does not decide where your DNS queries go. If the client sends them outside the tunnel, your ISP still gets your list of sites while the tunnel looks fine. Check with the IPv6 leak test and What Is My IP; the fixes are in Is my DNS leaking.
The kill switch. Not part of the protocol. If the tunnel is down, traffic goes out unencrypted unless the app or the OS blocks it. Details in What is a VPN kill switch.
The server. Whatever runs on the far end sees your traffic in the clear as it leaves for the internet. WireGuard does not make a bad provider good; the policy does, or does not.
The IP-address caveat
By design, a WireGuard server keeps the last address of each peer in memory while the peer is configured, so that it can send packets back. There is no built-in timer that forgets it. On a personal server that is harmless. On a shared service it means the provider has to add its own mechanism to drop client addresses after disconnect, and to rotate keys so that a static key does not tie a user to sessions over time. This is a known, documented property, and it is why "we run WireGuard" is not by itself a privacy statement; what the provider does about it is. A provider's policy should say whether the source address is kept after the connection is established; ours states it is not, in the privacy policy.
Visibility on the network
WireGuard does not try to look like anything else. Its handshake has a recognizable pattern, and networks that inspect traffic can identify it and, where they choose, drop it. That is a reachability problem, not a security one: identified is not decrypted. Where reachability matters, protocols built to resemble ordinary HTTPS, such as VLESS with Reality, are the complementary tool; what they are is in What is VLESS and Reality.
A five-minute check of your own setup
- Client config: the server's public key is the one you meant, and AllowedIPs is 0.0.0.0/0 and ::/0 if you want everything in the tunnel.
- DNS in the config points at a resolver reached through the tunnel; verify with the leak tests above.
- Kill switch on in the app or the OS.
- Server: no stale peers, one key per device, the WireGuard port the only one open.
- Software up to date on both ends.
Bottom line
WireGuard is secure as a protocol in a way few of its predecessors can claim: fixed modern cryptography, a codebase small enough to audit, and audits that have actually happened. What it does not do, it does not do on purpose: keys, DNS, kill switch, server behavior and address retention are your job or your provider's. Judge a setup by those, not by the protocol's name.
404 VPN uses WireGuard alongside VLESS, resolves DNS inside the tunnel, includes a kill switch, and does not keep the source IP after the connection is established, as stated in the privacy policy. Test it on the free plan, starting on the home page.