ExpressVPN is safe with material caveats. Under ordinary conditions (a public Wi-Fi network, an ISP trying to see what you’re doing, the everyday leaks that undermine cheaper or poorly built VPNs) the evidence supports real confidence.
That confidence comes from repeated, independent testing of the protocol and the app themselves. It gets thinner the moment you ask a harder question: who actually controls the servers your traffic passes through, and what could they see if something went wrong?
That second question is where this investigation spends most of its time, because it’s where the evidence runs out.
ExpressVPN has also had a real failure. For roughly 21 months, a defect in how the Windows app handled DNS traffic during split tunneling meant the tunnel could look active while some traffic quietly went around it. It was fixed once discovered. But it happened while the company was running one of the more extensive public audit programs in the VPN industry, which tells you something worth sitting with: audits and safety aren’t the same thing.
What “Safe” Means Here
Before any evidence, it’s worth being precise about what this investigation is and isn’t answering.
“Safe” here means resistant to harm: can the app, the account, and the infrastructure withstand interception, compromise, and failure, and does the product fail safely when something breaks. That’s a different question from whether ExpressVPN keeps logs, what it could hand over to a government, or how its no-logs claims hold up under legal pressure. Those questions belong to a separate investigation into ExpressVPN’s privacy practices, not this one.
Within that safety frame, four kinds of threats matter most: someone watching your traffic on the network (an ISP, a hostile Wi-Fi operator), an attacker going after your account directly, a compromised or seized server, and simple operational failure, the app crashing, the connection dropping, the DNS quietly leaking. This article works through each in turn, and it explicitly does not attempt to say anything about whether ExpressVPN can resist a well-resourced state intelligence service. No consumer VPN’s evidence base supports that claim, and this one doesn’t try to.
Do the Basics Work?
Strip away the marketing and a VPN has one core job: encrypt your traffic, hide your IP address, and make sure nothing slips out around the tunnel. On the available evidence, ExpressVPN does this job under normal conditions.
Its encrypted tunneling and DNS/IPv6 leak protection have held up across repeated rounds of independent testing. Network Lock, ExpressVPN’s kill-switch feature, is designed to block traffic entirely if the VPN connection drops, and its intended behavior is clearly documented by the company. What hasn’t been independently verified is how it performs across every real-world failure condition: app crashes, a laptop waking from sleep, a captive Wi-Fi portal at a coffee shop.
Feature presence isn’t the same as proven effectiveness in every circumstance, and the difference matters more than it might seem, because it’s exactly the gap that produced the one confirmed failure covered later in this piece.
The Protocol and the App: What’s Actually Been Tested
This is the strongest layer of evidence in the entire investigation, and it’s worth understanding why.
ExpressVPN’s Lightway protocol has gone through three rounds of independent testing by Cure53, a respected security research firm, spanning 2021, 2022–23, and a more recent 2024 assessment of the newer Rust implementation. The earlier two rounds, conducted against the versions and code in scope at the time, turned up nothing rated Critical, High, or Medium.
The 2024 Rust engagement is more interesting precisely because it found something: one High-severity denial-of-service issue, alongside one Medium, one Low, and two informational findings. Cure53 examined exact source commits under a white-box setup, meaning the testers had full visibility into the code rather than working blind.
A browser-extension assessment and a separate Praetorian review of the Rust implementation, both completed in 2024, add further scrutiny at this layer.
The finding worth sitting with isn’t that Lightway is flawless, it’s that even actively audited software can carry a real, High-severity issue. That’s not a mark against the audit process; it’s what a working audit process looks like. It’s also the clearest evidence that testing needs to be continuous, not a one-time seal of approval, a point this article returns to below.
None of this evidence extends beyond the specific versions and commits examined. A clean 2021 report says nothing about a 2023 build; a strong 2024 finding doesn’t cover whatever ships next year.
The Servers: Where the Evidence Runs Thin
If the protocol layer is where ExpressVPN’s evidence is deepest, the server infrastructure is where it’s shallowest, and this is the layer that matters most for anyone thinking seriously about trust.
ExpressVPN’s TrustedServer architecture is built around RAM-only servers with no persistent storage, standardized deployment across the fleet, and a design intended to make no-logs claims technically enforceable rather than just promised. This design has genuine, credible support: PwC, Cure53, and KPMG have each examined specific components of it across multiple engagements. Within the scopes they covered, at the times they covered them, the design holds up.
What none of those engagements establish is what happens across the entire live fleet, all the time. No public evidence maps which servers are owned outright, which are rented, colocated, or run in the cloud, or which company hosts any given machine. Nothing publicly verifies whether administrative credentials are unique per server, whether privileged actions get logged and reviewed, or how much damage a single compromised host could actually do before it was contained.
That last question deserves to be stated plainly, because it’s the one that matters most: if a single server were compromised, how far could the damage spread? The honest answer, based on what’s publicly available, is that nobody outside the company can currently say.
That’s not evidence that the controls are weak. It’s an absence of evidence either way, and the distinction matters: an unverified system and a broken one are not the same thing, even though both leave a reader without proof of safety.
The arrangement works like this in principle: a hosting provider is responsible for securing its own physical premises and hardware, while ExpressVPN is responsible for making sure that even if one of its servers is fully compromised, the damage doesn’t spread, through things like isolated secrets, frequent rebuilds, and segmented systems that don’t trust each other by default.
What’s not established is which of these measures ExpressVPN actually has in place, or whether they hold consistently across the full fleet rather than in whichever sample happened to be audited.
Audits Are Not the Same as Ongoing Protection
As of 30 July 2026, ExpressVPN’s Trust Center listed 28 named third-party audit or assurance engagements, spanning back to 2018. That’s a genuinely substantial public record, and it’s worth taking seriously rather than dismissing as marketing.
But it’s worth being precise about what that number does and doesn’t prove. It establishes that a lot of testing activity has happened. It doesn’t establish that every one of those 28 reports is fully public, equally deep, or still relevant to what’s running in production today. Some are detailed technical write-ups with exact commit references; others are company summaries of assurance work that isn’t independently inspectable in the same depth.
An audit is a snapshot: it tells you the system looked a certain way on the day it was examined, in the specific area that was examined, and nothing about the days after.
That distinction between activity and assurance isn’t academic. It’s the thing that explains how a company running 28 audit engagements could also run a broken DNS configuration in production for close to two years without noticing.
The Windows DNS Defect
Here’s what actually happened, stripped of interpretation.
A defect in ExpressVPN’s Windows app, tracked as CVE-2024-25728, affected how the software routed DNS traffic during split tunneling: the feature that lets some apps use the VPN while others bypass it. Under the affected configuration, the tunnel could appear connected and working normally while DNS lookups quietly took a different path than the rest of the encrypted traffic.
The National Vulnerability Database’s record establishes the affected version range and a high severity score. The defect was present starting with an early-2022 Windows release and remained active until it was discovered externally and disclosed in early 2024, a window of approximately 21 months.
ExpressVPN brought in Nettitude to independently assess the fix once it was made, and that targeted remediation review confirmed the specific patch worked as intended.
A few things are important to keep separate here.
First, this was a silent failure: the kind that’s more concerning than a crash, precisely because nothing alerted the user that anything was wrong.
Second, no evidence shows that any of ExpressVPN’s earlier, named audit engagements were ever in scope for this specific split-tunneling behavior. That’s a meaningful distinction: this wasn’t a case of an auditor missing something in front of them. It was a gap in what got tested at all, sitting underneath an otherwise active audit program.
Third, the fix itself has been independently reviewed and the affected configuration addressed, this is a resolved historical incident, not an indication of an ongoing leak.
When Things Go Wrong More Broadly
The DNS incident is the one confirmed case of ExpressVPN failing silently. It’s worth being equally clear about what remains untested.
ExpressVPN’s own documentation describes how Network Lock is supposed to behave during a crash, a sleep-wake cycle, a network switch, or a captive portal login, but broad, independent, empirical testing of those scenarios doesn’t appear in the public evidence.
That’s a different category of gap than the DNS defect. The DNS incident is a documented, specific implementation flaw that ran undetected in production for a defined period. The untested failure modes are simply that, untested. Neither confirmed safe nor confirmed broken.
Treating the two as the same kind of problem would overstate what’s actually known.
The Account Layer
A VPN’s encryption doesn’t matter much if the account guarding it is the weaker link.
ExpressVPN’s account recovery relies on email, which is a documented and confirmed dependency. What isn’t established, at least not at a level the public evidence supports, is whether ordinary consumer accounts support authenticator-app, SMS, or hardware-key multi-factor authentication, or how the backend handles things like rate limiting, session management, and support-agent access to accounts. This should be read as a gap in available evidence rather than a finding that these protections are missing. It’s entirely possible stronger controls exist behind the scenes; there’s just no independently verifiable record of them at this depth.
Some of the broader uncertainty here connects to organizational changes at the company more generally, covered next.
Does the Company’s History Change Anything?
Two pieces of ExpressVPN’s corporate history come up often enough to be worth addressing directly, and both deserve to be kept separate from the technical safety verdict.
The first is organizational: ExpressVPN’s parent group went through a restructuring in 2023 that included senior leadership departures and roughly 200 group-level job losses, followed by a further, independently reported workforce reduction at ExpressVPN in 2025.
These events are well documented. What isn’t established is their functional effect on security engineering, incident response, or infrastructure operations. No evidence connects the restructuring to the DNS defect, and drawing that line would be speculation dressed up as analysis.
The second is Daniel Gericke, a former ExpressVPN executive whose pre-ExpressVPN work with the UAE’s Project Raven is documented in a U.S. Department of Justice deferred prosecution agreement. ExpressVPN has said it was aware of his history when it hired and retained him; he departed the company in 2023.
There’s no public evidence that Gericke had any ongoing access to ExpressVPN’s systems after his departure, and none that his historical conduct translated into any compromise of ExpressVPN’s product or infrastructure. This is a governance and hiring-history question, not a current technical-risk finding, and the two shouldn’t be blended together.
For further detail on ExpressVPN’s ownership and corporate structure, see STACK’s dedicated investigation into who owns ExpressVPN.
Safe for Whom?
The evidence supports different levels of confidence depending on who’s asking.
Ordinary users (people mainly worried about public Wi-Fi, ISP tracking, or common leaks) are the group this evidence supports most comfortably. Repeated, recent, independent testing of the protocol and app layer covers exactly the threats this group faces day to day.
Privacy-conscious users who want more than “the design looks sound” will find the unresolved infrastructure and account-backend questions genuinely relevant. For this group, an audited design isn’t quite enough reassurance on its own.
High-risk professionals (journalists, researchers, lawyers, activists) are the group for whom the infrastructure and privileged-access gap matters most. The combination of unverified full-fleet controls, unresolved account security, and incomplete failure-mode testing means the evidence cannot support the same level of confidence for this group.
Anyone facing state-level or highly targeted threats should understand plainly that nothing in this evidence base supports the claim that a consumer VPN, ExpressVPN or otherwise, defeats that level of adversary. That’s a boundary, not an oversight.
The Question That Matters Most
Underneath every specific gap in this investigation (the account backend, the untested failure modes, the workforce changes) sits one recurring question: can ExpressVPN’s server-hosting, privileged-access, and full-fleet operational controls be independently verified as deeply as its protocol and application security?
Right now, the answer is no.
Not because the infrastructure has been shown to be weak, but because it simply hasn’t been examined with the same rigor as the code running on top of it. That asymmetry (deep proof at the application layer, thin proof underneath it) is the single factor that does the most to shape how much confidence this verdict can carry.
What Would Change This
This verdict isn’t fixed. It would move with new evidence, specifically:
- Independent verification of the full-fleet hosting setup and privileged-access controls, not just a sample.
- A dedicated audit of the account backend, not just the recovery flow.
- Empirical testing of Network Lock and failure behavior across real-world conditions, not just documented design intent.
None of these exist publicly today. Their absence is exactly what keeps this verdict at “material caveats” rather than something stronger.
Would I Use It?
For ordinary use (protecting a laptop on hotel Wi-Fi, keeping an ISP from seeing browsing habits) the evidence here supports real confidence, and the answer is yes. The protocol and app have been tested repeatedly and recently, and the one confirmed failure was both specific and fixed.
Where hesitation creeps in is anything higher-stakes: journalism, activism, legal work, or any situation where the infrastructure layer genuinely matters and not just the app on the screen. In those cases, the honest answer is that ExpressVPN is asking for a degree of trust the public evidence can’t yet fully back up, and that’s worth knowing going in rather than discovering later.
The Bottom Line
ExpressVPN has earned real, specific confidence at the layer it has tested most: the protocol and the application. It has not yet earned the same confidence at the layer that would matter most if something ever went wrong at scale: the servers themselves, and who can reach them.
Both things are true at once. ExpressVPN’s audit programme is genuinely extensive, and a material DNS defect still ran undetected in production for close to two years. Neither fact cancels the other out. Together, they’re the clearest reason this verdict is “safe with material caveats” rather than an unqualified yes: and the clearest reminder that a long list of audits is not the same thing as an on-going guarantee.
This investigation evaluates ExpressVPN’s resistance to compromise and failure. It does not evaluate ExpressVPN’s logging practices, data retention, or exposure to legal or government requests, those questions are addressed separately in STACK’s investigation into whether ExpressVPN is private.
Continue your research: