Proton VPN is safe for most users, with material caveats for high-risk users.
That is the direct answer. What follows is why.
Under normal conditions, Proton VPN encrypts traffic, masks the user’s public IP address, and provides platform-specific controls designed to block traffic if the VPN connection drops. Those controls are well documented, but their behavior has not been independently tested across every platform and failure condition. Where the picture gets harder is not in what Proton VPN claims, but in how much of the current product has actually been independently confirmed to work the way it says it does.
Safety here depends on who is using the app, on which platform, and against which threat. A commuter connecting to airport Wi-Fi and a journalist working under state surveillance are not asking the same question, even when they type the same search.
The strongest part of Proton VPN’s case is architectural: modern protocols, documented failure controls, and a public source-code record that experts can inspect. The weaker part is verification. Proton has been independently assessed before, but not recently, not completely, and not in a way that confirms the exact binary a user downloads today matches the code that was reviewed. Current build integrity, current cross-platform testing, and the physical control of Proton’s own infrastructure remain, to varying degrees, unresolved.
This investigation tests five things: what Proton VPN protects against, how strong the independent evidence actually is, how protection differs by platform, what happens when something fails, and how much of the infrastructure story rests on Proton’s word rather than outside confirmation.
The safety snapshot
| Overall verdict | Safe for most users, with material caveats for high-risk users |
| Ordinary users | Materially positive under normal conditions |
| High-risk users | Conditional and platform-dependent |
| Confidence | High for historical facts; incomplete for current implementation |
| Strongest reassuring evidence | Historical independent app assessments plus documented current controls |
| Biggest assurance gap | Current binary and build integrity |
| Strongest documented platform position | Windows, with Linux close behind but more environment-dependent |
| Most evidence-constrained surfaces | Browser extension and Android TV, for different reasons |
| Apple platforms | Documented exceptions, not categorically unsafe |
Safe for most users does not mean proven safe for every threat.
Is Proton VPN safe? The direct answer
Proton VPN is generally safe for ordinary users under normal conditions. The evidence does not support the same unqualified conclusion for high-risk users.
That split is not a hedge. It reflects two genuinely different evidentiary standards. An ordinary user is asking whether a VPN will keep casual network observers, insecure Wi-Fi, and routine account attacks at bay. Proton VPN’s documented design answers that question credibly. A high-risk user, facing a state-level adversary, a censoring network, or a targeted supply-chain attack, is asking something closer to: has this exact software, on this exact device, been independently confirmed not to fail under pressure? For that question, the public record has real gaps.
Neither conclusion is complete on its own. Proton VPN’s design is stronger than its current independent verification. That relationship, more than any single feature, is what this investigation is built around.
What “safe” means in this investigation
This article asks whether Proton VPN can resist compromise and fail safely. It does not ask what Proton VPN can see, log, or disclose about its users, which is a separate question and belongs to a separate investigation. A privacy issue only belongs here if it creates a safety or harm exposure; otherwise it stays out of scope.
Two threat tiers run through the rest of the piece.
Ordinary threats include hostile or insecure Wi-Fi, routine ISP observation, local network interception, everyday DNS or IP leakage, common account theft, and normal app interruptions like a crash or a dropped connection.
Elevated threats include targeted surveillance, censorship and network interference, malicious or compromised software updates, supply-chain compromise, access by hosting-provider staff or infrastructure administrators, physical server seizure, and advanced endpoint compromise.
A VPN cannot protect a compromised endpoint. No tunnel, however well built, secures a device that is already infected or physically accessed.
Against the ordinary end of that list, here is what Proton VPN documents.
What Proton VPN protects ordinary users against
Under normal operating conditions, Proton VPN’s documented behavior is materially positive. WireGuard is the current primary protocol on most platforms, and the client code for Proton’s principal application families is publicly visible. DNS-leak protection is documented through Proton-operated resolvers. Kill-switch controls exist across every native platform in some form. The account layer supports multi-factor authentication and session management.
What matters here is how clearly those controls are documented and how much independent evidence supports them. Several of them were reviewed by outside researchers in the past. Two historical assessments, from SEC Consult in 2019 and Securitum in 2021, examined the applications directly rather than taking Proton’s word for it. Their scope and limits are covered in full in the next section.
What this section cannot claim is that today’s build has been independently retested. The strongest part of Proton VPN’s ordinary-user case rests on documentation and historical review, not on a current, comprehensive re-examination of the exact software now running on a user’s device.
That documented picture is strong. What it doesn’t yet include is independent confirmation of the current build, which is where the evidence gets thinner.
Where Proton VPN’s current safety evidence falls short
This is the decisive section of the investigation, because it holds the decisive hinge: current binary and build integrity.
In plain English: Proton publishes source code, but the reviewed public evidence does not show an independent party confirming that the distributed app was built from that exact source. No independent binary-to-source correspondence was established in the reviewed public evidence. Source-code visibility and shipped-binary correspondence are two different guarantees, and only the first one is confirmed here.
Open source does not verify the downloaded binary.
Proton maintains active, publicly visible repositories for its principal application families, including Windows, Android, the combined iOS and macOS codebase, Linux, and the browser extension. That repository activity continues into 2026, and build instructions exist to varying degrees of completeness across platforms. What is missing is a reproducible-build system: no public mechanism was located that lets an outside party independently compile the published source and confirm it produces the exact binary Proton distributes. Without that, source visibility is a transparency signal, not a verification system.
This is not evidence of a mismatch. Nothing in the record suggests Proton’s shipped software differs from its published source. The point is narrower and, for a safety verdict, still important: the reviewed public evidence does not show an independent party closing that loop. That is not a claim that platform stores provide no verification at all; it is a specific gap in the public source-to-distributed-binary assurance chain.
The same gap runs through the update chain. Proton VPN reaches users through several channels: direct download and in-app updates on Windows and macOS, Apple’s App Store on iOS and macOS, APT and RPM repositories on Linux, Google Play, F-Droid, and a direct APK on Android, browser extension stores, and manual configurations on routers and third-party clients. Each of those channels is a legitimate way to get Proton’s software. None of them comes with independent public confirmation of signing-chain strength, update-metadata protection, rollback resistance, repository-signing practices, or identity consistency across channels. Official distribution gives users a legitimate route to Proton’s software; it does not, on its own, establish complete build and update-chain assurance.
Every historical audit and every line of visible source code becomes more valuable once this gap closes. Until it does, it caps how much confidence any of that other evidence can carry.
Independent assessments do exist, but their scope and age matter as much as their existence.
How strong is the independent evidence?
Proton VPN has been independently assessed, but not comprehensively verified across its current applications, binaries, and infrastructure. Three distinct kinds of assessment sit behind that sentence, and conflating them is one of the easiest ways to overstate what has actually been proven.
SEC Consult, 2019
SEC Consult conducted a six-day source-code review of the Windows client, version 1.10.2, in the first quarter of 2019. Proton issued fixes in September 2019, and SEC Consult checked selected remediations in October, with the final report dated November 2019. The report recorded two Medium and two Low-severity findings. Two were fixed and independently verified by the auditor. Two were accepted by Proton rather than technically eliminated, meaning Proton judged the residual risk acceptable rather than removing the underlying issue entirely. That distinction matters: accepted is not the same as fixed, and the public record should be read accordingly.
This review is historical and version-bound. It says something meaningful about Windows client 1.10.2 in 2019. It does not speak to the current Windows build, and it did not cover macOS, Linux, the browser extension, or any protocol introduced since.
Securitum, 2021
Securitum carried out a multi-platform application penetration test across named historical versions of the Android, iOS, Windows, macOS, and Linux clients in August and September 2021. The public attestation records one Low-severity finding and nine recommendations, but only limited technical detail was made public, and no detailed retest report was located. The exact Linux product covered is not entirely clear from the public record, and the browser extension, Android TV, and the Stealth protocol were not established as being in scope.
This was a real, multi-platform security test, and it is a meaningfully broader assessment than the 2019 Windows-only review. It is also five years old at the time of writing, covering application generations that have since changed.
Securitum, 2022 to 2026
Securitum has published five consecutive annual no-logs assessments covering 2022 through 2026. These examine server-side logging practices and privacy claims, not application security. They are valuable, recent, and recurring evidence that Proton’s stated no-logging practices held up under outside examination each year. They are not a substitute for an application-security audit, and treating them as one would blur exactly the distinction this article is trying to preserve.
| Assessor | Date | Type | Scope | Findings | Current relevance |
|---|---|---|---|---|---|
| SEC Consult | Q1–Q4 2019 | Source-code review | Windows client v1.10.2 | 2 Medium, 2 Low (2 fixed and verified, 2 accepted) | Historical only; version-bound |
| Securitum | Aug–Sep 2021 | Multi-platform penetration test | Android, iOS, Windows, macOS, Linux (named historical versions) | 1 Low, 9 recommendations | Historical only; no detailed public retest |
| Securitum | 2022–2026 | No-logs assessment | Server-side logging and privacy practices | No prohibited logging identified in scope, each year | Recent and recurring, but privacy scope only, not app security |
Independent assessments do exist and their scope and age matter as much as their existence. What differs, once assessments end and the product keeps shipping, is how protection plays out across individual platforms.
Safety by platform
Safety is not uniform across Proton VPN’s applications, and treating Windows behavior as representative of every platform is a common mistake worth avoiding directly.
Windows and Linux carry the strongest documented position, each offering Standard and Advanced kill-switch modes, with the Advanced mode surviving a system restart. Linux introduces more environment variance, since firewall and DNS-resolver behavior can differ by distribution. Android relies on the operating system’s own Always-on VPN and “block connections without VPN” controls rather than a Proton-specific mechanism, which is a legitimate design choice but a different evidentiary path.
Apple platforms carry disclosed limitations. Neither macOS nor iOS offers an Advanced kill-switch mode; both are Standard only. Proton discloses a brief real-IP exposure window during server switching on macOS, and documents that some Apple-service DNS requests may bypass the VPN on both macOS and iOS. These are disclosed exceptions, not evidence of a broken product, but they are real and worth knowing before relying on either platform under elevated threat conditions.
The browser extension and Android TV sit furthest from independent scrutiny. No dedicated public assessment covers either. Android TV should not be assumed to inherit Android’s evidence, since no confirmation was located that the TV build shares precisely the same code.
| Platform | Kill-switch model | Strongest documented protection | Disclosed limitation | Independent assessment status |
|---|---|---|---|---|
| Windows | Standard + Advanced (survives restart) | Broadest historical review coverage | Update-chain and current-build verification unresolved | SEC Consult 2019; Securitum 2021 |
| macOS (direct/App Store) | Standard only | WireGuard, Stealth, documented DNS protection | No Advanced mode; brief exposure window during server switching; Apple-service DNS exceptions | Historical SEC Consult; Securitum 2021 |
| Linux (GUI/CLI) | Standard + Advanced | WireGuard, OpenVPN, custom DNS support | Distribution-dependent firewall and resolver behavior | Referenced in 2021 attestation; exact product unclear |
| Android | OS-native Always-on / block-without-VPN | Proton DNS, Stealth, multiple protocols | OEM variance; split-tunnel behavior not independently tested | Historical SEC Consult; Securitum 2021 |
| iOS/iPadOS | Standard only | WireGuard, Stealth, local-network blocking | No Advanced mode; Apple-service DNS exception | Historical SEC Consult; Securitum 2021 |
| Android TV | Not separately detailed | Smart routing, Stealth documented | No TV-specific kill-switch or leak record | No dedicated assessment |
| Browser extension | None (browser-only scope) | HTTPS proxy-style protection for browser traffic | No device-wide protection; no device-level kill switch | No dedicated public assessment |
Apple platforms have documented exception windows. That is a disclosed limitation, not evidence that macOS or iOS are unsafe.
Kill-switch behavior is one of the clearest examples of that platform variance, and it connects directly to how the product handles failure more broadly.
Kill switch, DNS, and failure behavior
Proton VPN documents meaningful fail-closed controls, but current public evidence does not establish that every platform always fails safely across every edge case.
Windows and Linux offer both Standard and Advanced kill-switch modes, with Advanced surviving a restart. Android uses the operating system’s own always-on and block-without-VPN settings. macOS and iOS offer Standard mode only, with the exceptions already noted. The browser extension has no device-level kill switch at all, which follows directly from its browser-only scope.
DNS-leak protection is documented through Proton-operated resolvers, though a user’s own custom DNS settings, or a browser’s secure-DNS configuration, can override or interfere with that design. IPv6 behavior is platform- and rollout-dependent rather than uniform.
What the public record does not cover is a rigorous, current, cross-platform test of how these controls behave at the edges: an application crash, a background daemon failing, a system restart, sleep and wake cycles, switching networks, a captive portal, a protocol falling back to another, split tunneling, DNS falling back to an unprotected resolver, a delayed connection at startup, or a failure that exposes traffic silently rather than visibly. No study covering these conditions across Proton VPN’s current applications was located.
That is not the same as evidence of failure. It is an absence of current, reproducible testing, and it means confidence in edge-case behavior should be lower than confidence in the documented, steady-state behavior described above.
Kill-switch and leak behavior sit on top of the protocols actually carrying the traffic, which have their own separate evidence gaps.
Protocols and encryption
Standard cryptographic building blocks are not, by themselves, proof that a full implementation and its fallback logic are safe. Each protocol Proton VPN offers carries a different evidence status.
- WireGuard is the current primary protocol on most platforms, source-visible in Proton’s repositories, but no current Proton-specific independent assessment of the implementation was located.
- OpenVPN remains available, mainly on Linux and through manual configurations; manual setups inherit whatever risk comes with the third-party client and configuration a user chooses.
- IKEv2 is now limited to macOS and is being phased out, so older references that list it more broadly are stale.
- Stealth, Proton’s own protocol built around WireGuard and an obfuscated TLS tunnel for restrictive networks, is source-visible but has no independent cryptographic review, obfuscation assessment, or reproducible censorship-resistance test on the public record.
- Smart Protocol is not a cryptographic protocol at all; it is client-side selection and fallback logic that chooses among the others, and its full decision tree and downgrade behavior under hostile conditions remain unresolved.
- Proton Protocols, a newer architecture still rolling out and possibly in beta on Linux, is not covered by any historical assessment, since it postdates them.
The gap around Stealth deserves particular weight, because it is precisely the protocol built for the population most likely to depend on it: users on restrictive or censored networks. Its design is credible and its purpose is clear, but “designed for a hostile network” and “independently confirmed to withstand one” are different claims, and only the first is currently supported.
Proton’s 2026 roadmap references groundwork for future post-quantum encryption. No deployed post-quantum feature was found in the current product.
Stealth and Smart Protocol matter most for users on restrictive networks, which is also where the browser extension’s narrower scope becomes relevant.
Is the browser extension as safe as the app?
No, in scope, not in quality. Proton’s browser extension protects browser traffic through an HTTPS proxy-style connection. It is not a device-wide tunnel, offers no protection to non-browser applications, and has no device-level kill switch. That is an architectural boundary, not a defect: the extension was never designed to replace the native app.
The browser extension is not a device-wide VPN.
Unsupported browser protocols can bypass it. Traffic that starts before the extension finishes loading may go unprotected. Other extensions or experimental browser features can interfere with it. DNS, WebRTC, and DNS-over-HTTPS behavior across different browser engines and failure states remain independently unresolved, and no dedicated public assessment of the extension was located.
The open question is not whether the extension does what it says. It is whether its limits are visible enough to a user who might reasonably expect browser-only protection to behave like the full app. That question is preserved here as open rather than resolved either way.
Where the extension’s boundary is architectural, Secure Core’s boundary is evidentiary: a paid feature whose infrastructure claims go further than what has been independently confirmed.
Secure Core: what it adds, what remains unverified
Secure Core strengthens Proton VPN’s documented safety architecture, but not its independently verified infrastructure case.
Secure Core is a paid-only feature. Proton states that its Secure Core servers, located in Iceland, Sweden, and Switzerland, are wholly owned, provisioned from Proton’s own offices, and connected through Proton-operated IP resources.
Secure Core is documented more deeply than it is independently verified.
That is a company statement, and it is worth taking seriously as one.
What is missing is outside confirmation of it. No public evidence establishes legal hardware ownership, control of the racks or facilities housing the servers, who has physical access to them, how administrator privileges are managed, whether deployment images are verified, how Proton would recover from a compromised node, whether server memory is protected from live inspection, or how far a single compromise could spread across the fleet.
Proton states that its servers use full-disk encryption fleet-wide, which is a real control, but it does not by itself establish RAM-only operation, secure boot, or resistance to a live administrator or hosting-provider compromise. Full-disk encryption protects data at rest; it says nothing about a server that is already running.
None of this means Secure Core’s claims are false. It means the strongest infrastructure story in the Proton VPN lineup is also the one furthest from independent physical verification, which matters most for exactly the users Secure Core is built to reassure.
Infrastructure is not the only layer with unresolved boundaries. The account layer sitting on top of the tunnel has its own.
Account security: where compromise is more likely
Account compromise is not tunnel-cryptography compromise, but it can still affect sessions, access, and settings.
Proton’s account layer supports TOTP-based two-factor authentication, U2F and FIDO2 hardware security keys, multiple authorized devices, recovery codes, a list of active sessions, and the ability to revoke individual sessions or all other sessions at once. Account Monitor is also available, though it may function retrospectively rather than as a real-time login alert.
What is not established in the public record includes how long VPN authentication tokens persist and where they are stored on each platform, how immediately a native app reflects a session revocation, what credential-stuffing or rate-limiting defenses exist, what happens when a support agent assists with account recovery, and what triggers an account lockout.
These are two architecturally separate systems. An attacker who compromises a Proton account could gain access, create new sessions, or change settings, but that is not the same as compromising the tunnel encryption, the application code, or the server infrastructure itself. Both layers matter, and neither substitutes for the other.
Taken together, application, infrastructure, and account evidence sit at very different levels of independent confirmation, which is worth classifying directly.
What has been independently verified?
This is the article’s evidentiary spine, made explicit. The record supports a narrower claim than “audited and open source, therefore safe”: specific application generations, on specific platforms, at specific points in time, were independently assessed. That is different from an ongoing guarantee.
| Protection or claim | Evidence class | Current? | Main limitation |
|---|---|---|---|
| SEC Consult 2019 review | Independently assessed within scope | No | Windows only, version 1.10.2, historical |
| Securitum 2021 penetration test | Historically assessed | No | Limited public detail, no retest, scope gaps on extension/TV/Stealth |
| Securitum 2022–2026 no-logs reports | Recurring but scope-limited | Yes, annually | Privacy/server-side scope, not app security |
| Public source repositories | Source-visible | Yes | Does not establish binary correspondence |
| Current kill-switch behavior | Company-documented | Yes | No current reproducible edge-case testing |
| Protocols (WireGuard, Stealth, Smart Protocol) | Source-visible / company-documented | Yes | No current independent protocol assessment |
| Secure Core | Company-documented | Yes | No independent physical or operational verification |
| Binary correspondence | Unresolved | — | No reproducible-build system located |
| Update chain | Unresolved | — | Signing, rollback, and cross-channel identity unconfirmed |
| Bug bounty program | Company-documented mechanism | Yes | Case-specific discovery, not a safety proof point |
| Account controls | Company-documented | Yes | Does not validate app or tunnel security |
The no-logs audits are not application-security audits. They are real, recent, and recurring evidence about a different question, the one answered in
(L)Is Proton VPN Private(L).
The bug bounty deserves the same treatment. Proton operates an official program with published scope and a disclosure process, and its current stated maximum reward is $100,000. That program is a genuine, ongoing mechanism for finding issues. It is not proof that issues are absent, and it should not be read as a standalone safety guarantee.
One more distinction this classification supports: whether any of it differs between the free and paid tiers.
Free vs. paid: does safety differ?
Application-layer protection is broadly similar across tiers. Free and paid users share the same application families on a given platform, along with the same documented core protections, and Stealth is available on supported free-plan platforms. The standard kill switch is available on both tiers where the platform supports it.
Secure Core is paid-only, and free-tier server selection is more restricted than paid. Beneath that, full equivalence of infrastructure and monitoring between free and paid servers is not publicly established either way.
None of this supports concluding that the free tier is unsafe because it costs nothing, or that paid is safer in every respect purely because of price. Tier is one axis of difference. Who is using the product, and against what threat, is the more consequential one.
Who should exercise more caution?
Ordinary users
For public Wi-Fi exposure, ISP observation, routine DNS and IP leakage, and common account-security risks, Proton VPN’s documented protections are materially positive under normal use.
Higher-risk users
For targeted surveillance, censorship, malicious updates, supply-chain compromise, infrastructure-level access, and situations that depend on verified fail-closed behavior, the assessment becomes conditional and platform-dependent. A high-risk user on Windows or Linux with the Advanced kill switch enabled sits on materially stronger documented ground than one relying on the browser extension or an Apple platform, where the Advanced mode does not exist.
High-risk users are not one group. A journalist working from a laptop with Advanced kill-switch protection enabled faces a different practical risk than an activist relying on the mobile app in a country actively blocking VPN traffic. Neither situation is served well by a single blanket answer, and this investigation does not offer one. A consumer VPN, on its own, should not be assumed to defeat every advanced or state-level threat.
All of this, protection, evidence, platform, infrastructure, and threat model, resolves into one conditional judgment.
The final safety verdict
Proton VPN’s documented design and historical assessments support a positive ordinary-user safety verdict. Confidence falls when the question shifts to current binaries, adversarial failure states, censorship resistance, and independently verified infrastructure control.
Working through what this investigation found: the core protective capability is credible under normal conditions.
The independent evidence behind that capability is real but historical, covering specific application generations rather than an ongoing guarantee. The current implementation gap, centered on binary and build-chain integrity, is the single factor most capable of changing that picture if it were resolved.
Platform behavior is not uniform: Windows and Linux carry the strongest documented fail-closed posture, while Apple platforms have disclosed exceptions and the browser extension provides a deliberately narrower layer of protection. Failure-state behavior is documented in principle but not independently tested across current edge cases. Infrastructure control, especially around Secure Core, remains substantially company-stated rather than independently confirmed.
And threat-model fit varies enough that no single verdict serves every reader equally.
Safe for most users does not mean proven safe for every threat. That is the sentence this entire investigation was built to earn, not merely assert.
The STACK View
Proton VPN has done enough to support a positive safety verdict for ordinary use, but not enough to close the gap between visible source code and the software people actually install and run.
For most users, that gap is not the deciding factor. Modern protocols, documented DNS-leak protection, platform kill switches, and a credible historical audit record are real protections against the threats an ordinary user actually faces: an unsecured coffee-shop network, routine ISP observation, and common network-level exposure. On that ground, Proton VPN earns its verdict through evidence, not through marketing.
For users facing targeted surveillance, censorship, supply-chain threats, or infrastructure-level adversaries, the calculation changes without becoming a rejection. It becomes a list of specific, material requirements rather than a settled question: current binary verification, current cross-platform testing under adversarial conditions, and independently confirmed control over Secure Core’s physical and administrative environment. None of those assurance layers was established in the reviewed public evidence. Their absence does not mean Proton VPN fails under pressure. It means the reviewed public evidence does not show an independent party confirming, recently and rigorously, that it doesn’t.
What Proton VPN gets right is architecture: a design built with the right instincts, documented openly, and backed by real, if aging, independent scrutiny. What keeps this from a stronger verdict is not a discovered flaw. It is the space between what has been shown and what has been verified, and that space is widest exactly where the stakes are highest.
Frequently asked questions
Is Proton VPN safe? Generally safe for most ordinary users under normal conditions. High-risk users should weigh the current gaps in audit recency, binary-build verification, and infrastructure confirmation before relying on it against a serious adversary.
Has Proton VPN been independently audited? Specific application versions were independently reviewed in 2019 and 2021. Five recurring assessments from 2022 through 2026 examine no-logs practices, which is a different question from application security.
Does open source prove Proton VPN is safe? No. Proton publishes source code that experts can inspect, but no public system confirms that the binary a user downloads was actually built from that source.
Does Proton VPN leak? Documented DNS and IP leak protections exist and are described clearly by platform, but no current, reproducible cross-platform test of edge-case failure behavior was located. That is an evidence gap, not a finding of leaks.
Is Proton VPN safe on iPhone and Mac? Yes, with disclosed exceptions. Neither platform offers the Advanced kill-switch mode, and both have documented DNS or server-switching exceptions. That is a limitation, not a case for calling Apple apps unsafe.
Is Proton VPN Free safe? Broadly yes at the application layer, since free and paid share the same core protections on a given platform. Secure Core is paid-only, and full infrastructure equivalence between tiers is not publicly established.
Is Proton VPN safe for journalists and activists? Conditional. It depends heavily on platform choice, configuration, and the specific threat being defended against. High-risk users are not one uniform group, and no single answer serves all of them.
Is the browser extension as safe as the native app? No, by design rather than by defect. It protects browser traffic only, has no device-level kill switch, and has not received a dedicated public independent assessment.