NordVPN is safe for most users, with material caveats around privileged access, mixed-fleet consistency, cross-platform failure testing, and account recovery.
That verdict rests on real evidence in both directions. NordVPN’s core tunnel, leak controls, and account protections address the threats that matter most for ordinary use: interception on public Wi-Fi, ISP visibility, and routine DNS or WebRTC leakage. At the infrastructure layer, the company has twice submitted real servers and authentication systems to independent penetration testing by Cure53. The most recent of those assessments, completed in 2025, also found two High-severity local privilege-escalation paths inside the systems it tested.
Neither fact cancels the other. Before working through what the evidence shows, it helps to be precise about what “safe” is actually being measured against.
What “safe” actually means for a VPN
A VPN cannot be evaluated against every conceivable threat at once. Some risks sit well within what encrypted tunneling and DNS controls are built to handle. Others sit outside what the available evidence establishes NordVPN can protect against.
Interception on a local network, a hostile Wi-Fi hotspot, or an ISP’s own logging sits inside the first category. NordVPN’s encrypted tunnel, private DNS resolution, and kill-switch mechanisms are designed to address exactly this kind of exposure, and the available documentation and testing support that they generally do.
A step further out sits a different set of problems: what happens if a server itself is compromised, if a hosting facility grants unauthorized access, or if someone tries to take over a user’s account rather than intercept their traffic. These threats are only partially addressed by architecture claims alone. They depend on how servers are deployed, who can reach them, and how account recovery is designed. That is where independent testing becomes essential alongside product documentation.
Further still sit threats that NordVPN’s public evidence does not establish it can defeat: traffic correlation at scale, direct device compromise and adversaries with state-level resources. A VPN can be one layer of protection against this kind of threat. It cannot be the whole defense, and nothing in NordVPN’s public record suggests otherwise.
With that frame in place, the next question is what kind of evidence actually backs NordVPN’s safety claims. That starts with a distinction readers often miss.
No-logs audits and security tests are not the same thing
NordVPN has disclosed six distinct no-logs assurance engagements: two by PwC Switzerland, covering its 2018 and 2020 system states, and four annual engagements by Deloitte Lithuania, covering 2022 through 2025. That is a genuinely sustained pattern of external review. It is not, however, six security audits.
A no-logs assurance engagement asks a narrow question: does the system, as configured and described, match the company’s no-logging claims? The public 2022 Deloitte report answers that question with reasonable assurance over NordVPN’s no-logs configuration and deployment, but it explicitly excludes broader security measures, physical access controls, access rights, and the internal-control environment. That exclusion does not mean those controls are weak or absent. It means this particular engagement was never designed to test them.
A separate stream of evidence exists for that: infrastructure penetration testing. Cure53 assessed NordVPN’s real servers, host configurations, and authentication systems in 2022 and again in 2025, and a third, separate stream covers application and account-layer testing, including earlier work by VerSprite and NordVPN’s ongoing bug bounty program through HackerOne. Each of these answers a different question, and none substitutes for the others.
| Evidence stream | What it establishes | What it does not establish |
|---|---|---|
| No-logs assurance (PwC, Deloitte) | Privacy configuration and system description match stated no-logs claims, within scope | Security architecture, physical access, or internal controls, which the public report excludes |
| Infrastructure penetration testing (Cure53) | Real server, host, and authentication-stack security within the tested scope | Continuous, fleet-wide enforcement beyond what was sampled |
| Application and account testing (VerSprite, Cure53, HackerOne) | Findings on apps, APIs, and account surfaces within their tested scope | Infrastructure security or supply-chain integrity |
Six audits, in other words, is an accurate count and a misleading shorthand if it is read as six security tests. One of those streams, infrastructure penetration testing, produced the most consequential finding in this record.
What did the 2025 Cure53 report actually find?
In October 2025, Cure53 spent 21 days with five senior testers examining real components of NordVPN’s infrastructure: host-level hardening, core service configurations, and the authentication stack, including Teleport-based SSH access. This was not a review of documentation or architecture diagrams. It was adversarial testing of real server, infrastructure and authentication components within the assessed scope.
The assessment identified five vulnerabilities. Two were classified as High-severity local privilege-escalation paths, alongside additional weaknesses in token handling and access control. They cannot accurately be described as minor findings.
The public report also records that these findings were fixed and reverified by Cure53 within the assessed scope. Both facts need to be held together. NordVPN exposed meaningful infrastructure components to independent scrutiny, and that scrutiny worked: it found real privilege-boundary problems that a reader would want identified before they became someone else’s discovery. The company also addressed what was found and had that fix independently checked.
What the report does not establish is whether the same standard of hardening reaches every server, provider, and deployment path across NordVPN’s wider infrastructure. Cure53 tested a defined scope, not the company’s entire production environment, and a bounded assessment from October 2025 is not evidence about what has happened, or could happen, everywhere else in the fleet since. That gap sits underneath a broader question about how NordVPN’s servers are actually structured.
| Cure53 2022 (NV-03) | Cure53 2025 (NOR-28) | |
|---|---|---|
| Duration | 25-day penetration test and source-code audit | 21-day assessment, five senior testers |
| Scope | Selected servers and infrastructure | Host hardening, core services, authentication stack, including Teleport-based SSH |
| Findings | One High, two Medium, one Low, plus informational items | Five vulnerabilities, including two High-severity local privilege-escalation paths and token or access-control weaknesses |
| Remediation | Scope-bounded remediation context | Public report records fixes and Cure53 verification within the assessed scope |
| What remains open | Whether findings extend beyond the sampled scope | Whether the same control standard reaches the wider mixed infrastructure |
NordVPN’s server infrastructure: what’s confirmed and what isn’t
NordVPN operates what it describes as a mixed infrastructure model: colocated hardware that the company owns but houses in partner facilities, infrastructure hosted directly by third-party partners, and virtual server locations used where physical hosting is impractical. Each of these introduces a different dependency. Colocated hardware still depends on a facility for power, connectivity, and physical security. Partner-hosted infrastructure introduces additional third-party operational and physical-access dependencies. Virtual locations depend on whichever provider and hypervisor sit underneath them.
What the current public record does not establish is the proportion of NordVPN’s fleet that falls into each category, the specific list of hosting partners in current use, or whether NordVPN owns any data-center facilities outright. That last point is worth stating precisely, because it is easy to get backward: owning server hardware is not the same as owning the building it sits in, and nothing in the record confirms either full ownership or a specific reliance on third-party facilities.
The 2025 Cure53 assessment offers the strongest available evidence that access-control components, including SSH-based administrative access, have been independently tested. It does not offer evidence about the complete employee authorization model, every privileged access path across every provider, or whether logging and segmentation are consistent everywhere traffic is routed. Those remain open questions rather than confirmed weaknesses.
Part of NordVPN’s infrastructure story rests on a specific architectural claim: that its standard servers run without persistent local storage. That claim deserves its own scrutiny.
Does RAM-only mean NordVPN’s servers are secure?
NordVPN states that its standard VPN servers operate on a RAM-only, diskless basis, meaning data is not written to permanent storage during normal operation. If implemented consistently, this can meaningfully reduce what remains on a server after it is powered down, and it can reduce some of the practical consequences if a machine is physically seized.
It is not, on its own, a complete security claim. RAM-only operation does not protect against someone accessing a server’s live memory while it is running, against a malicious or coerced administrator, against a compromised authentication system, or against tampering introduced earlier in the deployment pipeline. It also does not, by itself, confirm that every server across NordVPN’s mixed infrastructure implements the design the same way.
The 2025 Cure53 testing of host hardening and authentication systems provides real, independent support for parts of this architecture. It does not extend that support to the entire fleet, and the two should not be conflated. RAM-only is a genuine design choice with a genuine, bounded benefit. It is not proof of comprehensive infrastructure security.
Infrastructure design is one layer of trust. History is another, and NordVPN carries one incident that still shapes how its infrastructure oversight is judged today.
The 2018 Finland server incident, and why it still matters
In January 2018, a rented server in Finland entered service. The following March, the hosting provider introduced a remote-management account on that server without NordVPN’s knowledge. Whoever had access to that account was able to obtain an expired TLS private key. NordVPN says it was notified on 13 April 2019, around six months before the incident became public in October 2019, after external researchers and social media activity exposed it, rather than through a proactive company disclosure.
The technical exposure itself appears to have been narrow. The key involved had already expired, no evidence has surfaced of confirmed targeted interception using it, and NordVPN states that no activity logs or credentials were exposed, a claim that rests partly on the company’s own account and its underlying architecture at the time. Even so, two things about this incident remain relevant almost a decade later.
The first is that it demonstrates a real failure of third-party hosting oversight. A provider NordVPN relied on introduced unauthorized access to a live server without the company’s awareness for months. The second is a disclosure pattern: the public only learned about it after outside exposure, not because NordVPN chose to announce it early. That combination, a genuine third-party access failure paired with a delayed and reactive disclosure, is what makes the incident more than historical trivia.
It does not, by itself, establish that NordVPN’s current infrastructure is unsafe. Substantial changes followed: a shift toward diskless infrastructure, expanded colocation, a public bug bounty program, and the recurring independent testing described above. Later hardening changes the picture. It does not erase what happened, and how much weight a reader assigns to it depends partly on how much confidence they place in everything that came after.
Server compromise is one failure mode. A more everyday question is what happens when the VPN connection itself drops, and the answer depends heavily on which platform someone is using.
Does NordVPN’s kill switch actually work?
Three distinct categories of evidence exist here, and they should not be blended into one answer.
For Windows, bounded commercial testing has directly observed the kill switch behaving as intended under several conditions: blocking traffic when a network cable is removed, activating when the app is forcibly terminated, remaining active through sleep and wake cycles, and blocking traffic with successful reconnection after a network adapter is removed and restored. This is real, observed behavior, though it reflects a specific set of tested conditions on one platform, not a comprehensive laboratory audit.
For every other platform, the evidence is company documentation describing intended behavior rather than independent testing. iOS and the macOS App Store build are documented to block traffic system-wide on an unexpected drop. The direct-download macOS build instead uses a model that terminates selected applications rather than blocking system-wide. Android relies on OS-level always-on or block-without-VPN settings on supported builds, and Linux offers an optional system-wide kill switch that must be enabled.
A meaningful set of conditions remains untested across every platform, including what happens during a transition from Wi-Fi to mobile data, on a captive portal network, during an authentication or control-plane outage, or after a device restarts or wakes from hibernation. These are gaps in the available evidence, not confirmed failures, and Windows results should not be read as representative of how every other platform behaves.
| Platform | Kill switch model | Evidence type | What remains untested |
|---|---|---|---|
| Windows | Internet and App Kill Switch (App Kill Switch off by default) | Directly observed in bounded testing | Network transitions, captive portals, outages, restart |
| macOS (App Store) | System-wide block on unexpected drop | Documented intended behavior | All edge cases |
| macOS (direct download) | Selected-application termination | Documented intended behavior | All edge cases; differs materially from the App Store build |
| Linux | Optional system-wide kill switch | Documented intended behavior | All edge cases; binary-to-source verification also unresolved |
| Android | OS-level always-on / block-without-VPN on supported builds | Documented intended behavior | ROM variation, battery optimization, captive portals |
| iOS/iPadOS | System-wide block on unexpected drop | Documented intended behavior | Network transitions, OS-level bypass conditions |
Failure behavior protects a user’s traffic. The next layer of exposure sits underneath the tunnel entirely: the account itself.
How strong is NordVPN’s account security?
NordVPN offers confirmed account-security controls: time-based one-time-password MFA, support for physical or platform-backed security keys, ten regenerable backup codes, and token revocation. These controls address common account-takeover risks.
Alongside them sit dependencies worth understanding plainly. Support-assisted MFA recovery can rely on a user’s historic billing amount, payment method, and date rather than something only the account holder would know. Headless Linux authentication tokens can be issued without an expiration date, with revocation available but dependent on the user acting. Comprehensive visibility into every active session is not established in the public record, and neither is whether NordVPN sends alerts on suspicious logins.
The underlying question worth asking is how much of NordVPN’s real-world safety depends on this account and recovery layer rather than on the encrypted tunnel itself. NordVPN’s account and billing systems have also produced a real, externally discovered vulnerability history: a 2019 issue that could expose email addresses, payment details, and purchase history through an authorization flaw, a separate 2019 flaw in the password-reset rate limit, and a 2025 issue that could briefly expose a recent purchaser’s email address. Each was reported as fixed, and none of them establishes that the account layer is inherently weaker than the tunnel. What they do establish is that the account and billing surface is a distinct, historically active target in its own right, separate from the VPN protocol.
One more layer sits underneath all of this: the software supply chain that builds and delivers the app itself.
What’s unverified about NordVPN’s software supply chain
NordVPN’s Linux client is public under the GPLv3 license, with a visible repository and release history. Its Windows, macOS, iOS, and Android clients, along with its backend systems, remain proprietary, which is a stated scope limit rather than a security failing in itself.
What is missing from the public record is any evidence of reproducible builds, a published software bill of materials, an independent build-pipeline audit, or a dedicated assessment of update-channel security. None of these gaps should be read as proof of an insecure build process. Open availability of source code does not by itself establish that distributed binaries are built reproducibly from that source. Reproducible builds, in turn, would not by themselves prove that every distributed binary matches it. Signed binaries prove provenance, not that the pipeline producing them is secure. And the application testing that has occurred, through Cure53 and earlier work by VerSprite, tests the app itself, not the systems that build and ship it. This remains an open evidence gap in NordVPN’s public record, not a confirmed weakness.
NordVPN also bundles several tools alongside the VPN itself, and it is worth being clear about what those do and do not add to the safety picture.
Threat Protection, Meshnet, and other bundled tools: what they don’t prove
Threat Protection Pro adds endpoint and browser-level defenses, such as flagging malicious sites and scanning downloads. It is a useful, adjacent capability, but it says nothing about the security of the VPN tunnel itself, and it should not be read as evidence that the core product is safer. Meshnet and the browser extension each expand what a compromised account or device could reach, since they add authorization surface to the account overall. That is neither automatically good nor automatically bad. It simply means the safety picture for these tools depends on the same account and access questions already discussed above, not on a separate assessment.
One more event belongs in this record, even though it remains unresolved.
The January 2026 breach allegation: what’s confirmed and what isn’t
In January 2026, a threat actor claimed to have compromised a NordVPN-related development server and posted material described as database content, authentication tokens, API keys, and source code. NordVPN disputes the claim and states that the artifacts came from an isolated third-party testing environment containing dummy data, unconnected to production systems.
No public, independent forensic report has confirmed either the attacker’s claim of a production compromise or the full details of NordVPN’s explanation. That leaves the event classified honestly as contested and unresolved, not confirmed, not refuted, and not something this record can currently close either way. It is treated here as a real open question, but a subordinate one. It does not carry the evidentiary weight of the confirmed 2025 Cure53 findings or the documented 2018 incident, and it should not be mistaken for the central reason behind this article’s verdict.
Taken together, this evidence points to one open question that matters more than any other for NordVPN’s safety verdict.
The one question that matters most
The 2025 Cure53 assessment found two High-severity local privilege-escalation paths, and those findings were addressed and reverified within the tested scope.
What the evidence does not resolve is whether that same standard, the same discipline in patching, access control, and privileged-account management, extends across NordVPN’s entire mixed infrastructure, including the partner-hosted and virtual server locations that fall outside any single Cure53 engagement.
This is the single factor most capable of moving the verdict in either direction. Independent evidence that the same controls hold consistently across the wider fleet would meaningfully strengthen the case that NordVPN is safe for most users. Evidence that controls are inconsistent elsewhere in that fleet would meaningfully weaken it. Right now, neither exists publicly, and that absence, not a specific known failure, is the honest state of the evidence.
That open question affects different readers differently, depending on what they are actually protecting against.
Who can reasonably trust NordVPN?
Ordinary users face routine threats: public Wi-Fi interception, ISP visibility, and everyday DNS or leak exposure. NordVPN’s encrypted tunnel, private DNS, and documented or directly observed kill-switch behavior are reasonably well matched to that threat model. Platform-specific gaps and account-recovery dependencies still apply, but they do not change the basic picture for this group.
Privacy-conscious users care about more than interception: they want to know how much operational and infrastructure detail has actually been reviewed. The repeated no-logs assurance engagements and the RAM-only design provide real, if scope-bounded, support here. Mixed infrastructure and incomplete public mapping of hosting partners remain genuine considerations for this group specifically.
High-risk professionals, including journalists, researchers, lawyers, and activists, face a materially different calculation. Infrastructure testing and account controls are relevant and meaningfully positive, but the 2018 disclosure history, the account-recovery dependencies, and the incomplete cross-platform failure testing all argue for added caution. This group should treat NordVPN as one part of a broader operational security practice rather than a complete answer on its own.
High-value or state-targeted users face threats this evidence simply does not speak to. No evidence in this record supports relying on NordVPN alone to defeat device compromise, traffic correlation, or advanced state-level surveillance. That does not make NordVPN a standalone defense for this threat model. Users facing these risks need a broader operational-security strategy.
The final safety judgment
The evidence supports a conditional verdict, not an unconditional one. It supports NordVPN’s ability to address the common network-level threats most ordinary users face, and it supports that the company’s infrastructure has been subjected to genuine, independent adversarial testing on two separate occasions. That same testing, in 2025, found real privilege-boundary weaknesses that were reported as fixed and reverified within the scope Cure53 examined.
What the record does not support is a claim of full-fleet verification, permanent or universal remediation, or protection against advanced and targeted threats. It does not support treating the January 2026 allegation as resolved in either direction. And it does not support pretending that NordVPN’s account-recovery dependencies or its untested cross-platform failure behavior are minor footnotes rather than real, open considerations.
NordVPN is safe for most users, with material caveats around privileged access, mixed-fleet consistency, cross-platform failure testing and account recovery. That confidence is earned by real technical testing and real, disclosed remediation, and it is bounded by exactly what that testing did not cover. Readers who fall outside the ordinary-use case, whether by profession or by the specific threats they face, should weigh the caveats above at least as heavily as the reassurance.