VPN Protocol Transparency Report 2026: Only 3 of 20 Had Dedicated Public Assessments

Executive summary

VPN providers often place tunnel protocols, modified protocols, obfuscation transports, and composed stacks in the same app menu or marketing category. They are not equivalent. The registry classifies each technology by the role it plays, then records what public source and assessment evidence could be located.

Of the 20 core records, 3 had a dedicated public protocol assessment. Another 2 had a related public assessment, while 15 had no public protocol audit meeting the registry definition located by July 13, 2026. The denominator excludes four adjacent technologies that the registry classifies separately.

Public source was also uneven. 3 technologies had full public source and 3 had partial public source. Six exposed only the base protocol, not the provider-specific changes, and 8 were closed in this snapshot.

VPN Protocol Registry v0.1.0

What the 20 core records document

Dedicated assessment 3 of 20

Full or partial source 6 of 20

Restricted-network relevance 17 of 20

Post-quantum related 4 of 20

Four findings from the core dataset

1. Dedicated assessments were located for three technologies

The dedicated-assessment group contains Lightway, Mimic, Dausos. The registry uses a narrow rule: the public assessment must focus on the protocol or its implementation. A no-logs engagement, broad app audit, or private report does not qualify.

AmneziaWG and GhostBear had related public assessments. They remain separate because those reports did not amount to a dedicated protocol-design or implementation assessment under the registry method.

2. Six technologies had full or partial public source located

The snapshot records 3 as full source and 3 as partial. Source for a standard base such as WireGuard or OpenVPN does not automatically expose a provider's changes, wrappers, address-management layer, or deployed service. That is why the 6 base-only records are not counted with the public source group.

3. Restricted-network positioning was common

17 of 20 records included restricted networks among their documented purposes, and 13 included censorship circumvention. A design goal is not a result from every country or ISP. Filtering methods, app versions, network paths, and deployments change.

4. Four records had a post-quantum-related status

3 were recorded as production and 1 as optional. The mechanisms do not protect identical parts of the connection, so the count is not a list of four equivalent "quantum-safe VPNs." Each record needs to be read against its mechanism and caveats.

The same marketing category hides four technical roles

The core cohort contains 8 tunnel protocols, 6 provider variants, 3 obfuscation transports, and 3 composed stacks. Treating all 20 as interchangeable "VPN protocols" hides what each name actually changes.

Full evidence table

This table shows all 20 records used in the report. Labels describe the public evidence located for the dated registry release. The table does not order providers or assign a security score.

Scroll horizontally to see every column.

The downloadable files add purposes, post-quantum status, and record caveats. The exact tagged registry release contains the complete source register, assessment records, generated dossiers, schemas, and checksums.

Methodology and limitations

The report analyzes the 20 records marked core in the immutable July 13, 2026 VPN Protocol Registry v0.1.0 release. The unit of observation is one provider-developed technology, not one provider and not every VPN protocol in existence. Four adjacent technologies remain in the source dataset but are excluded from every headline count.

Each record was checked against the registry's normalized source register. Fields include classification, technical base, transport, purposes, rollout, platforms, source status, public assessment status, post-quantum status, caveats, and the last verification date. The report calculates its figures from the checked-in snapshot instead of copying totals into the page by hand.

Absence claims are deliberately limited. "No public protocol audit located" records the result of the documented search up to the verification date. It cannot exclude private work, unpublished findings, documents outside the search, or evidence published after the snapshot. Public source does not prove production parity, secure implementation, or sound operation. Assessment status does not establish logging behavior or overall provider trustworthiness.

Read the site-wide research and correction policy for release, evidence, independence, and update rules.

Download, reproduce, and cite the report

Canonical source files

The exact VPN Protocol Registry v0.1.0 GitHub release is the canonical source for the JSON, CSV, generated dossiers, schemas, source register, citation metadata, and checksums used here. The archived release is available through the preferred dataset DOI, 10.5281/zenodo.21813597.

Provider responses

Providers were not asked to respond before this first report was published. On-record responses received after publication will be added below with the date received and a link to any supporting public evidence. A response does not silently overwrite the frozen v0.1.0 dataset.

Providers can send a response or evidence link to steve@dovpn.com. Factual corrections follow the policy below.

Corrections and updates

Corrections are logged rather than folded into the report without notice. A page-level wording correction changes the modified date and receives a note here. A correction to a registry record follows the registry release process so the source, reason, and affected version remain visible. Send a record ID, evidence link, and explanation to steve@dovpn.com.

No corrections have been recorded for this report. Readers who need help choosing a setting can use the separate VPN protocol comparison and selector.