What DuckDuckGo's VPN audit can and cannot tell you
Securitum signed off on DuckDuckGo's no-logs policy last month. The audit is better than most and thinner than some, and understanding why is the difference between useful privacy scepticism and reading marketing copy.
Eighteen months ago, Securitum found a high-severity bug in DuckDuckGo's VPN. A malicious program running on your Mac could quietly reroute traffic around the tunnel using a DHCP quirk known as TunnelVision, no elevated privileges required. That bug has since been fixed.
Last month, the same Polish firm published a second report, this time a no-logs audit, and signed off on every claim DuckDuckGo makes about how its infrastructure handles user data.
Both things are true at the same time. Understanding why they sit comfortably together, and what each kind of audit does and does not prove, is the difference between useful privacy scepticism and the affiliate-padded summaries that pass for VPN coverage most places you'll read about it this week.
Table of contents
Two audits, two questions
A security audit asks whether the thing can be broken. You run the software, probe it, read its code looking for bugs, and write up whatever you manage to exploit or prove exploitable. The 2024 report on DuckDuckGo's VPN is that kind of document. It found two high-severity issues: the macOS TunnelVision leak, and a Windows service flaw that let any local user disable the tunnel via a writable IPC socket. It found a handful of medium-severity bugs, including a broken Exclude Local Networks toggle on macOS and iOS. And it found a longer tail of low and informational findings. Most of the serious issues have been fixed, to Securitum's satisfaction. Several of the lower-severity ones sit marked "NOT RETESTED" eighteen months later, which isn't ideal but is, frankly, normal industry practice.
A no-logs audit asks something entirely different: does this thing retain data it says it doesn't retain? You cannot answer that by poking at the software from outside. You have to look at the servers. You have to look at the code that writes to them. You have to look at the pipelines that deploy to them and the people who can push changes. That's what the new report does.
What Securitum actually did this time
The new assessment ran from October 2025 to January 2026, using two auditors for twelve person-days of work. DuckDuckGo gave Securitum what audit reports call white-box access: source code to the proprietary VPN daemon that DuckDuckGo internally calls Wedge, the deployment playbooks that configure the fleet, and shell access to production servers chosen at random by the auditors themselves. That last point matters more than it sounds. If you only get shown a demo server, you're looking at a stage set. Random selection from live infrastructure is how you catch the version of reality where things have been tidied up for the visit.
If you only get shown a demo server, you're looking at a stage set. Random selection from live infrastructure is how you catch the version of reality where things have been tidied up for the visit.
From there, the work splits into four techniques, each answering a question the others cannot.
- Documentation review and interviews tell you what the system is supposed to do. You read the architecture, talk to the engineers, and understand the intent of the design. On its own this is worth very little: it's marketing with a confidentiality agreement.
- Source code and configuration analysis tells you what the code could do if it ran. You search for logging calls, inspect the Nginx build, read the systemd unit files, look for anything that writes user-attributable data to disk. On its own, though, the code you reviewed might not be the code that's actually running in production.
- Live system inspection tells you what the deployed code is doing right now. You SSH in, list running processes, look at open files, check for log directories that shouldn't exist. This is where you catch the gap between the audited source and the running binary. On its own, however, it's a snapshot, and a snapshot can be gamed if you know when the auditor will visit.
- Change management review tells you whether the clean state you inspected can be trusted to persist. Every server you looked at was built from an Ansible playbook; every change to that playbook goes through a pull request review; every production deploy of the Wedge binary needs explicit approval from a restricted group. If the process is strong, a future engineer cannot quietly introduce a logging change without getting caught. If it's weak, today's clean audit is worth almost nothing tomorrow.
Each technique is limited on its own. But taken together, they cover the ways a no-logs claim can fail.
Serious audits use all four. Token audits use one and call it a day.
What the audit found, in plain terms
The headline findings, stripped of consultant-speak:
DuckDuckGo's egress servers are bare-metal boxes, not shared virtual machines, hosted by i3D and DataPacket and dedicated entirely to DuckDuckGo traffic. This matters because a shared VPS means your hosting provider's other tenants can observe side channels you'd rather they didn't.
The tunnels use WireGuard, which is what any competent VPN should be running in 2026. The server-side Nginx builds are custom and stripped of logging directives. The DNS resolver on the egress boxes caches in memory with a 24-hour TTL and does not write queries to persistent storage. If someone seized a DuckDuckGo server mid-flight and dumped its RAM, they would recover a shared pool of recently resolved domains with no user attribution. If they seized one that was powered off, they'd get nothing useful.
The authentication architecture is the single nicest thing in the report. Your subscription identity, the thing tied to your payment method and email, lives on a completely separate API from the VPN controller. The controller only ever sees an ephemeral WireGuard public key and the fact that someone holding a valid signed token wants to connect. There is no persistent table mapping "this subscriber" to "this VPN session at this time." When the session ends, the state is cleared. This is the right design.
The Scam Blocker feature, which checks visited domains against a threat list, mostly runs locally on your device. When the client does need to ask the server about a domain, it sends only a four-character hash prefix rather than the full URL. DuckDuckGo's servers cannot reconstruct your browsing history from those fragments, and Securitum verified the implementation matches the claim.
The full list of what Securitum verified
Securitum checked each of the nine no-logs claims DuckDuckGo makes and marked every one "Confirmed." For reference, in plain English:
- No tracking or logging of user activity on the servers that route your traffic.
- No persistent record of connection metadata such as DNS queries; the internal resolver caches in memory only, with a 24-hour expiry.
- No inspection or logging of the content of network traffic.
- No monitoring of which websites or services users connect to.
- The VPN servers are dedicated bare-metal machines, not shared virtual slices.
- The no-logs configuration is identical across every server and every geographic region.
- Changes to anything log-related require dual control: pull request review and a separate deployment approval.
- The active configuration files on production servers have no logging directives enabled.
- Subscription authentication and VPN session authentication use separate tokens, and the VPN controller never sees identifying user information.
What the audit cannot tell you
Here's where most coverage will stop. Securitum's report is a good one. It's reasonably detailed, it describes real techniques, and the firm isn't a rubber-stamp operation. None of that means it answers every question you should have.
Retention and compulsion are different questions, and a no-logs audit only answers one of them.
Twelve person-days is not a lot. Spread across two auditors and three months, that's six days of active work each. The depth has limits, and the auditors themselves flag some of them: the group of engineers with write access to production repositories was noted as broad, with a recommendation to enforce stricter multi-factor controls and cross-checks. This doesn't invalidate the no-logs finding. It does suggest the perimeter could be tighter.
The controller infrastructure runs in Microsoft Azure. DuckDuckGo controls its Azure tenant, but Microsoft is in the data path for authentication flows. The report doesn't interrogate what Azure's own platform-level logging captures, because that isn't DuckDuckGo's to audit. If your threat model includes compelled process by a US cloud provider, this isn't nothing.
Retention and compulsion are different questions, and a no-logs audit only answers one of them. What Securitum verified is that DuckDuckGo doesn't store user-identifiable data after the fact. What no audit of this shape can tell you is what DuckDuckGo could be asked to do with a live session in flight. The ephemeral state on the controller, and the cached DNS entries on the egress servers, exist for the duration of your connection. A sufficiently targeted legal request delivered during that window is outside the scope of a retention audit, and you should assume it's outside the scope of any retention audit from any VPN provider. The architectural separation of subscription identity from VPN routing makes this harder than it would otherwise be, which is genuinely good. It does not make it impossible.
The third-party hosting providers sit upstream of the VPN servers in a network sense. DuckDuckGo doesn't log your traffic, and Securitum verified that. i3D and DataPacket's upstream transit providers can still see encrypted WireGuard flows entering and leaving the servers they rent out. That's a fundamental property of running VPN services on infrastructure you don't own end to end, and it's true of essentially every commercial VPN on the market, but it's worth being honest about.
An audit is a snapshot. It tells you that on the dates Securitum looked, the system was as described. The change management review gives you reasons to think the snapshot will stay accurate, but reasons are not proofs. Audits only sustain trust when they're repeated. Mullvad has had multiple audits from Cure53 and Assured AB across several years. Proton's VPN has been through Securitum before as well. This is DuckDuckGo's first no-logs audit, which is a starting line rather than a finish line.
One more caveat, which applies to every commercial VPN audit including this one: DuckDuckGo paid Securitum to do the work. That's the industry norm, and it doesn't invalidate the findings; the auditors have their reputations to protect, and there are real ways to tell a serious audit from a rubber-stamp one (most of the questions at the end of this piece). But "independent" is not the same as "adversarial." Nobody shows up to a commissioned audit looking to blow up the client. The correct posture is to read the methodology carefully, notice what was and wasn't in scope, and calibrate trust accordingly.
The verdict
DuckDuckGo's VPN is a perfectly defensible choice for users who want a no-logs service from a company with a real privacy track record and a serious engineering team. The architecture is thoughtful. The no-logs claim is credible in the specific sense that the evidence Securitum reviewed actively supports it rather than merely failing to disprove it. The 2024 security audit found real bugs and most of them got fixed, which tells you the process works when the pressure is on.
The combination matters in practice. In 2026, public Wi-Fi, hotel networks and patchy international mobile roaming remain the environments where local snooping is plausible rather than theoretical, and that's what the 2024 client fixes address. Retention audits address the other half: what happens to your traffic once it's safely inside the provider's network, and what survives after you disconnect. You want both to be clean. For DuckDuckGo, they now are, on the dates and under the conditions Securitum examined.
What the audit is not is an unconditional privacy guarantee. No VPN is.
What audits like this one let you do is move from trusting a marketing claim to trusting a body of evidence, examined by named auditors, on known dates, under conditions you can pick apart for yourself. That is genuinely useful.
How to read any VPN audit after this one
The questions that separate a real audit from a glorified press release are short and worth memorising:
- Is the report public in full, or only a summary? Securitum's DuckDuckGo report is public in full. That's the correct standard. "Audited by a major firm, report available on request" is worth very little.
- Did the auditors have live access to production, or just a demo environment? Live and randomly selected is the strong version. A curated test fleet is much weaker and you'd never know from the executive summary.
- Did they review source code, or just infrastructure? Both is better than either.
- How much time did they actually spend? Person-days matter more than calendar months. A three-month engagement with twelve working days in it is not a three-month engagement.
- Are the auditors named? Do they have a track record? Securitum does. Maciej Szymczak and Marek Rzepecki have their names on this one.
- Is this the first audit, or part of a pattern? Pattern beats one-off every time. A single clean audit is a starting point, not a conclusion.
Run that list against most of the audit claims on most VPN marketing pages, and you'll notice how few pass. The ones that do, including this one, earn a conditional trust. They do not earn a blank cheque. That's the right stance to bring to any privacy tool, including the ones you already use.
DuckDuckGo
