Contact

Guide

SingLink VPN: what an external security audit can, and cannot, verify

·The Openscore VPN team

security-audit · singlink · tls · protocols · transparency

A real VPN security audit has five parts, and most of them require the provider to open its servers and its source code to an authorized firm. We did the parts that can be done honestly from the outside on SingLink VPN, and we are explicit about where the outside view ends.

Editorial update, 28 July 2026: VPNTestor has published a separate SingLinkVPN v2.5 security assessment statement. That statement records a 100/100 result reported by the assessment team, while also disclosing that the signed report, scoring worksheet, build matrix, and underlying test evidence are not publicly available. This article remains the independently reproducible public-source baseline as of 17 July 2026; the later statement does not retroactively turn unavailable evidence into public evidence.

What a VPN security audit actually covers

Professional audits, the ones by Securitum (Proton VPN’s no-logs audit) or Cure53 (Mullvad’s infrastructure), span five areas:

  • Transport / TLS posture of the provider’s web and API endpoints. Externally observable.
  • Client-app security: leak protection, kill switch, certificate validation, stored secrets, permissions, trackers. Partly observable from the app binary and store listing.
  • Protocol and cryptography review. Requires a published spec or the source of the crypto layer.
  • No-logs and infrastructure audit: inspecting live production servers, configs and change-control. Requires authorized, on-site access.
  • Source-code review of the clients and backend. Requires the code.
We do the observable parts and we do not scan, probe, or penetration-test any provider’s infrastructure without authorization. The deep parts below are marked as needing an authorized engagement, which is a thing SingLink would have to commission and publish, not something an outsider can assert.

Transport layer: what we measured

Connecting to singlinkvpn.com and reading the handshake and headers (the same thing SSL Labs does), the transport layer is modern and correct:

  • TLS 1.3 negotiated, with the ChaCha20-Poly1305 AEAD cipher and HTTP/2.
  • A valid certificate (Google Trust Services, current through October 2026).
  • Standard headers are present (X-Frame-Options, X-Content-Type-Options, a referrer policy), though these are largely Cloudflare defaults, and the site is served behind Cloudflare rather than from SingLink’s own edge.

The one gap at this layer: no HSTS header (Strict-Transport-Security) is sent, so a first visit is not pinned to HTTPS. Minor, and a website’s TLS says nothing about the VPN tunnel itself, but a security review notes it.

The protocol: the finding that matters most

SingLink does not run a standard, reviewable VPN protocol. Its own materials describe a proprietary “SingLink” / “SingLink 2.0 Beta” protocol kernel, and the App Store listing offers only “industry-standard encryption” and “intelligent routing” with no protocol named and no specification published.

This is the central limitation of any SingLink security audit. WireGuard has a formally verified handshake; OpenVPN has been independently audited by OSTIF and QuarksLab. A closed, undisclosed protocol can be neither. The site claims AES-256-GCM, but with no spec, no source, and no third-party review, that claim is vendor-stated and unverifiable from outside. A proprietary tunnel is not automatically weak, but it asks you to trust it precisely where the industry has learned to demand proof.

Independent audit and transparency

On the public record, SingLink has no independent security audit and no no-logs audit, its clients are not open source, and it publishes no transparency report or warrant canary. There is nothing to read against the Securitum or Cure53 template above. By contrast, the providers those firms audited publish the reports and open their client code. So SingLink’s strongest security claims, the encryption and the no-logs promise, currently rest entirely on the vendor’s own word.

Logging, jurisdiction and ownership (from SingLink’s own documents)

  • Its privacy policy asserts a zero-backend, client-side architecture (“We have NO backend servers”), which sits in direct tension with the marketed 120+ country server network, and claims to collect no email while account signup and the Terms require an email account. The no-logs story does not resolve internally.
  • Jurisdiction is claimed as the British Virgin Islands, but the same page lists a registered and mailing address in Wyoming, USA, a Five Eyes country. The claimed privacy jurisdiction and the disclosed legal address do not match.
  • The operating entities are named (SingLink LLC; parent SingLink Corporation) but no founders or ultimate beneficial owner are disclosed.

What we could not verify, and why

These are real audit items that an outside assessment cannot close, and we will not fake them:

  • Leak protection (DNS, IPv6, WebRTC) and kill-switch fail-closed behaviour: these require running the app on a device and capturing traffic (see our review checklist). SingLink does not disclose a kill switch in its feature comparison.
  • Actual no-logs behaviour, server hardening, and RAM-only claims: these require an authorized, on-site infrastructure audit of the kind Securitum ran for Proton.
  • Client source and the crypto implementation: these require the code, which is not public.

Bottom line

The part of SingLink a stranger can measure, the website’s transport layer, is modern and fine. Everything that actually decides a VPN’s security, the protocol, the independent audit, the open code, the verified no-logs, is either unverifiable by design (a proprietary, unpublished protocol) or simply absent (no audit, no source, no transparency report). A VPN earns security trust the way Proton and Mullvad did: by opening its protocol, its code and its servers to independent review and publishing the result. On today’s public record, SingLink has not, so its security rests on trust rather than on evidence anyone can check.

Sources and methodology

Every claim in this note rests on the site's published method. Read it in full on the methodology page, or return to the notebook.