VPN Encryption Claims: What the Documentation Must Say

Look at the big number beside an algorithm name and ask what it actually measures. It does not tell you which connection is protected, which protocol supplies the protection, or which settings your client supports. A page that cannot tie its claim to one of those is advertising rather than documentation. The checks below are a reading order for whatever summary you were handed, and the first claim you cannot attach to a specific connection is where to stop.

Identify which connection the claim covers

One product page can discuss tunnel encryption, HTTPS to the account portal and encryption of stored data inside a single paragraph. Those are different paths and different storage systems, so a property of one says nothing about the others. Decide which of the three the sentence is about before comparing it with a competitor. The same word, encryption, appears in all three contexts and means a different thing each time.

For the tunnel itself, look for a documented protocol and a documented set of supported security settings. Those three labels are not interchangeable: a default suite ships without you choosing it, an optional mode only applies if the profile selects it, and a negotiated result is whatever the two peers agreed on at connect time. A vendor that blurs them has told you less than it appears to.

Check the protocol and the suite it permits

Start from the client profile rather than a comparison graphic. The profile names the protocol, and the protocol decides which suites are even possible, as the two common cases show.

An IKEv2 proposal list is a menu the gateway chooses from, so the suite you get can differ between two gateways with identical client settings. WireGuard has no such menu, which makes its claim easier to verify and narrower to describe. Neither arrangement is stronger by itself; the point is that the documentation has to say which one it means.

A cipher name alone also leaves out authentication, key establishment, metadata exposure and retention. Modern constructions combine encryption and integrity in one suite, while older ones separate them, so quoting a single algorithm name can hide which property you actually get. Ask for the negotiation policy in writing when the page does not state it.

Check peer authentication and update state

Peer authentication belongs in the claim even when the marketing text skips it. Strong encryption to an unverified recipient is not the result anyone intended, and a tunnel that cannot tell you who answered is protecting less than it appears to. Look for how the client validates the server: a certificate chain, a pinned key or a preshared secret. Those are different trust models with different failure modes.

Then check the implementation and its update state, because a documented cipher in an unpatched client describes a version you may not be running. Published limitations from the protocol authors are worth reading for the same reason. A client that has not been updated in a year is making a different claim than the page in front of you.

Check where the tunnel ends

A client-to-server tunnel ends at the VPN server. Application encryption, such as HTTPS to the service behind it, can protect traffic farther along the route, and past the server it may be the only protection left. Read the operator's explanation of endpoints and decide which of those layers the claim refers to.

Logging policy and account tracking stand outside encryption entirely. An operator can carry encrypted content while observing timing, addresses and volume, so a claim about payload confidentiality answers nothing about what gets recorded. Treat retention as a separate question with its own evidence.

Record what the documentation does not say

When a property is missing, record that it is missing instead of inferring it from the software's name or reputation. An audit covers only the properties and components it actually examined, and a gap in the documentation is a finding in its own right. Write the gap down while you still remember which page produced it.

On a box you control, read the suite back from the live session, using the client status page or the security-association listing on the gateway, and file that value next to the client version. That record turns a vendor claim into something comparable later, when an update changes the negotiated result. If the client and the documentation disagree, trust the negotiated result and report the discrepancy rather than reconciling it silently.