VPN Security Audits: Code, Infrastructure and Logging Claims

"Independently audited" is one of the most used phrases in VPN marketing, and one of the least explained. An audit sounds like a stamp of approval, yet the word covers very different work. Someone reading source code for bugs is doing an audit. Someone attacking a test server for a week is doing an audit. Someone interviewing staff and checking configuration files against a written policy is also doing an audit. These have different goals, find different problems and prove different things.

This article explains the main VPN security audit types: code and application reviews, penetration tests, infrastructure audits, logging-claim assurance, and certifications, along with what each can and cannot show. The aim is for you to read a claim such as "audited" and ask the right follow-up questions. For a shorter overview, see VPN audit explained. This piece goes into the types and their limits.

Why audits exist and what they can prove

A VPN asks for an unusual amount of trust. Your traffic passes through software you cannot inspect and servers you cannot visit, run by a company whose internal practices you cannot see. Marketing statements are cheap. An audit is an attempt to replace some of that trust with outside evidence.

An audit has four ingredients:

1. A scope: exactly which systems, versions and statements were examined.
2. A method: what the reviewers did (read code, ran attacks, checked settings, interviewed people).
3. A time: the days or weeks during which the work happened.
4. A report: findings, their severity, and whether they were fixed.

Without those four things, "audited" is a slogan. With them, it is information. Even then, an audit is a snapshot. It tells you about the system on the days it was reviewed, not about next month's software update or a server added later. And an audit can only test the questions it was asked: a thorough review of the app says nothing about how the company handles customer support data, and a review of the servers says nothing about the app on your phone.

It helps to keep a simple frame in mind: an audit shifts probabilities, it does not remove risk. Our overview of the VPN trust model explains why some trust always remains, however good the evidence.

Type 1: Source code and application review

In a code audit, reviewers read the source code (or inspect the compiled app, if source is not shared) looking for security flaws. For a VPN client this typically means:

• How the app stores credentials and settings on the device.
• How it handles the tunnel: whether traffic can leak when the connection drops, whether the kill switch behaves as claimed.
• Whether it uses cryptographic functions correctly and keeps secrets out of logs and crash reports.
• What third-party libraries and trackers are inside, and whether the app asks for permissions it does not need.
• How it talks to the provider's servers and whether those connections are properly protected.

What it does well. It can find bugs that are almost impossible to discover from outside, such as a rarely used code path that writes sensitive data to a file. It also tests the actual product you install.

What it misses. It looks at one version of one component. A new release can introduce new bugs. If the review covers only the app, the servers and the company's data practices are untouched. And a review is bounded by time: reviewers sample, they do not read every line with infinite attention.

Open source is related but different. Publishing source code lets anyone inspect it, which is valuable, but publication is not an audit. An independent review is somebody actually doing the reading and writing it up. See open-source VPNs for how to weigh the two.

Type 2: Penetration testing

A penetration test, or pen test, is an authorised attack. Testers behave like a hostile party: they scan systems, try to break in through web interfaces, APIs and servers, try to escalate privileges, and report how far they got.

For VPN services, pen tests commonly target:

• The customer-facing website and account portal.
• The provider's APIs, including login and payment-related endpoints.
• The VPN servers' exposed services.
• Sometimes the mobile and desktop apps from a running-attack point of view.

What it does well. It shows what is exploitable in practice, with evidence. A finding such as "an unauthenticated user could read other accounts' data" is concrete and ranked by severity. It is also relatively fast and repeatable, so a provider can run one after every major change.

What it misses. A pen test finds what the testers manage to find in the time available, within the rules agreed beforehand. "No critical issues found" means exactly that, not "no issues exist". It says nothing about internal policies, and it does not read the source code unless the test is run with source access (a "white-box" test), which finds more but is also more expensive.

A good pen test report lists the testers' approach, the number and severity of findings, and whether each was fixed and retested. Be wary of a summary that lists only the pass.

Type 3: Infrastructure and configuration audit

An infrastructure audit examines the servers and the way they are run. Instead of attacking from outside or reading app code, the reviewers look at the real systems, often with administrative access.

Typical questions:

• How are servers configured? Are unneeded services disabled, are updates applied, is remote access restricted?
• How is access controlled? Who in the company can log in to a server, with what authentication, and is it recorded?
• Are servers built from a standard, reviewed image, and can they be rebuilt cleanly?
• Is there a record of changes, monitoring and an incident-response plan?
• How is the network segmented, and how are keys and certificates managed?

What it does well. It looks behind the curtain at what is really deployed, which no outside test can do. It can verify statements such as "our servers do not store X" by checking the actual configuration.

What it misses. The reviewers sample servers; they cannot check every machine at every moment. A configuration can be changed the day after the review. And if the provider uses rented or third-party data centres, parts of the physical layer lie outside the reviewer's reach.

For readers, this type of audit is the closest to a check on operating practice, and it feeds into the next category.

Type 4: Logging-claim assurance

Many providers say they do not keep records of what users do. A logging-claim audit is an attempt to check that statement. Reviewers compare the provider's published policy with what they find: configuration files, system settings, database contents, backup practices, and sometimes interviews with engineers.

A strong version of this audit:

• States the exact claim being tested, in the provider's own words.
• Describes the sample of servers and systems examined, and how they were chosen.
• Covers more than the VPN servers: also authentication systems, payment and support tools, and analytics in the app.
• Says what was and was not found, and is dated.

What it does well. It converts a vague promise into a checked statement about a particular time. If the provider's wording is precise, the audit can say "at this date, on the sampled servers, we found nothing that contradicts the claim".

What it misses. It cannot see the future. It usually cannot see every server. It depends on the provider showing the reviewers everything, and a determined dishonest operator could hide things. The audit also only tests the claim as written: if the policy is narrow ("we keep no browsing records") it says nothing about metadata the policy does not mention. Read the underlying promise first; our guide to VPN logging policies shows what to look for in the wording.

Treat any single audit as a data point, not a guarantee.

Type 5: Cryptography reviews and certifications

Cryptography and protocol reviews

Some audits focus narrowly on the cryptography: the protocol design, the way keys are exchanged, and the implementation of encryption in the code. Specialist reviewers check for mistakes such as weak randomness, incorrect use of ciphers, or a handshake that can be downgraded.

Standard protocols such as WireGuard and IPsec have been reviewed publicly for years, and standards bodies publish guidance. NIST's guide to IPsec VPNs and its zero-trust architecture document are examples of authoritative material on how such systems should be designed and configured. When a provider builds something custom, an independent cryptographic review matters more than when it uses a well-studied protocol correctly.

What it misses. Perfect cryptography does not protect you if the server is misconfigured or the app stores a token insecurely. This is why a single audit type is never enough.

Certifications and compliance attestations

Frameworks such as ISO 27001 (an information security management standard) and SOC 2 (a reporting framework for service organisations' controls) are not VPN-specific. They examine whether an organisation has defined processes and follows them: access reviews, change management, incident handling, staff training.

What they do well. They signal a mature process, and they are audited by accredited bodies against a known standard.

What they miss. They do not test the VPN app's code, and they do not say what the product does with your traffic unless the scope explicitly includes it. The scope statement, which is often a short paragraph on the certificate or in the report's introduction, is the part that matters. A certification of the company's head office, for example, may not include the servers at all.

Comparing the types side by side

Type	Main question	Typical evidence	Main limit
Code and app review	Is the software built safely?	Findings in a specific version	Only that version, only that component
Penetration test	Can an attacker get in today?	Demonstrated exploits and severities	Limited by time and agreed rules
Infrastructure audit	Are servers run and configured safely?	Configuration and access checks	Sampling; configuration can change later
Logging-claim assurance	Does reality match the stated policy?	Statement checked at a date	Only the claim as written, at that time
Cryptography review	Are the design and implementation sound?	Specialist analysis	Does not cover operations
Certification	Does the organisation follow a framework?	Accredited attestation	Scope may exclude the product
Bug bounty (ongoing)	Can outsiders find flaws continuously?	Public disclosure programme	Not an assessment of the whole system

A bug bounty is not an audit but is often mentioned alongside them: the provider invites researchers to report flaws and pays for valid ones. It adds ongoing scrutiny but does not give a full assessment.

How to read an audit claim in five minutes

Use these questions when you meet "audited" on a website.

1. Who paid and who did the work? Independence matters. A report by a recognised outside firm is stronger than a self-assessment.
2. What was in scope? The app, the servers, the website, a policy statement, or just one component? Scope is everything.
3. When, and which version? Note the dates and the app or server build. A report from several years ago, or of a different product line, is weak evidence.
4. Is the report public? A full or summarised report you can read beats a badge. If only a logo is shown, ask for the document.
5. What were the findings and were they fixed? An honest report lists problems. A spotless report is more suspicious than one that records issues and their fixes.
6. Does it match the claim made next to it? If the page says "our service is secure" and the report examined only the marketing site, the claim goes further than the evidence.
7. Is there a pattern of repeat audits? A provider that is re-audited regularly and publishes the results shows more commitment than one that did a single audit years ago.

A practical example

Priya is comparing two services for use on hotel Wi-Fi. Service A displays an "audited" badge. Service B publishes a PDF. She reads both.

Service A's page links to a one-paragraph announcement from two years ago: an outside firm reviewed "the client application" for a week. She notes that this covers one component, that the version is old, and that no findings are listed.

Service B's report is dated last year, covers the apps and the account system, lists nine findings with severity levels, and says eight were fixed and one was accepted with a stated reason. It also states clearly what was not covered: the physical data centres.

Neither service is proven safe or unsafe. But Priya can make a more informed choice, and she knows what to ask Service A: "Is there a more recent, fuller report?"

What audits do not replace

An audit, however good, does not replace your own habits and judgement.

• It does not make a VPN anonymous or stop phishing; see what a VPN cannot protect you from.
• It does not stop you from leaking data through your browser, accounts or apps.
• It does not remove the need to read a provider's privacy and logging terms, and to check that the provider's description of its own service is accurate and modest.
• It is not permanent. Look for recent evidence and for the provider's willingness to publish transparency reports; see VPN transparency reports.

When you are buying, a sensible approach is to weigh audits as one factor among clear terms, working support, a fair payment model and your own trial of the apps.

Summary

"Audited" can mean a code review, a penetration test, an infrastructure inspection, a check of a logging statement, a cryptography review or a company-level certification. Each answers a different question, covers a defined scope at a particular time and leaves other questions open. To read a claim well, ask who did it, what was covered, when, in which version, whether the report is public and whether the findings were fixed. If you prefer a simple prepaid option while you study providers, the pricing page lists the passes available.