Kill Switch and AES-256: What Actually Protects You the Moment a VPN Tunnel Drops in 2026

The marketing copy for the four providers this desk is allowed to discuss — NordVPN, ExpressVPN, Surfshark, ProtonVPN — uses two phrases that have hardened into furniture. AES-256 encryption. Kill switch. Pull any landing page. The phrases are there. They have been there for years.

We pulled them too. We put them next to a threat model. The conclusion was not what the landing pages imply.

What the Numbers Actually Say

AES-256 is a block cipher specified in NIST FIPS 197 (November 2001). The "256" refers to key length in bits. The brute-force search space is 2^256 — a number so large that the conventional shorthand is "not breakable by classical computing within the heat-death horizon of the observable universe." That part is correct. The cipher itself has no known practical attack against full-round AES-256 in 2026. We will concede that openly: as a primitive, AES-256 is sound, and saying otherwise would be dishonest.

The concession ends there.

The threat model question is not whether AES-256 is breakable. The threat model question is what AES-256 protects against once it is composed into a VPN tunnel. The composition is where the interesting attack surface lives. AES-256 inside the WireGuard whitepaper is not the same construct as AES-256 inside OpenVPN with a misconfigured TLS 1.2 control channel. The cipher is the same. The system around the cipher is not. CVE-2021-3711 (OpenSSL SM2 decryption buffer overflow, disclosed 2021-08-24) and CVE-2022-0778 (OpenSSL infinite loop in BN_mod_sqrt, disclosed 2022-03-15) both targeted the composition layer — TLS plumbing OpenVPN depends on — not the cipher itself. Reviewers who write "AES-256 means uncrackable" are confusing a primitive with a system.

Now the kill switch. A kill switch is a piece of client software whose job is to block all traffic from the network interface when the VPN tunnel goes down — typically by inserting firewall rules (Windows Filtering Platform on Windows, PF or NFTables on macOS and Linux respectively) that drop packets unless they are routed through the tunnel. Every one of the four providers in this desk's scope advertises one. The implementations are not identical. ProtonVPN's permanent kill switch is documented at the OS firewall level and survives reboots; ExpressVPN's "Network Lock" was assessed by Cure53 in the firm's published 2022 audit of the Lightway protocol stack; NordVPN's kill switch was within scope of the PwC Switzerland assurance engagements published 2018-11, 2020-12, and the 2022 series; Surfshark's kill switch was reviewed by Cure53 in the 2023 audit of the Surfshark client and server infrastructure.

So the cipher is sound and the kill switches are reviewed. Reasonable readers might stop reading here. They should not.

What Nobody Mentions

The tunnel drop is not one event. It is a race condition. There is a window — measurable in milliseconds — between the moment the tunnel fails and the moment the kill switch enforces its firewall rule. The window is small. It is not zero. Whether it matters depends entirely on what your adversary can do during that window.

A passive observer at your ISP collecting NetFlow data on five-minute aggregation buckets does not care about a 200ms window. Your real IP would not show up as a distinct flow in their pipeline at that resolution. The threat model says: kill switch is sufficient.

A DPI-capable observer — your ISP if regulatory pressure has pushed them to deploy nDPI or a commercial DPI appliance, a hostile WiFi gateway, a captive portal in a hotel that logs every DNS query — operates at packet resolution. They see the half-second of cleartext DNS resolutions that escape before the firewall rule lands. They see the SNI of the TLS handshake your browser already had in-flight when the tunnel collapsed. The kill switch did not fail. The kill switch did exactly what it advertised. The threat model just exceeded what the kill switch is built to defend against.

The 2020-12 PwC assurance report on NordVPN's no-logs configuration — and we will name what we can verify here — examined server configuration snapshots at the time of inspection. That scope is the whole story. The report does not, and was not designed to, assert that no packet ever escaped the tunnel during a transient failure on a customer endpoint. That is a question about client-side state machines, not server-side configuration. The 2022 Cure53 ExpressVPN Lightway audit looked at the protocol stack, including the kill switch component, and found no critical issues — within the scope they were paid to test. Audits are not magic. They are documents with explicit scope sections, and the scope is the contract.

There is a separate problem nobody talks about. WireGuard, the protocol all four providers now offer in some form, has a documented design property: it preserves the last-known peer endpoint across roaming. That is good for performance. It is awkward for kill switch semantics. The protocol does not have a built-in notion of "the tunnel is down" the way OpenVPN's TLS control channel does — it is connectionless at the protocol layer. The kill switch has to infer tunnel health from handshake liveness and packet flow. The inference is good. It is not instantaneous.

The Real Cost

We tried to put a number on this. Specifically: what is the realistic exposure window during a tunnel drop on consumer client software, on a residential connection, in 2026.

For most adversaries the user has in mind — generic targeted advertising surveillance, ISP browsing-data monetization, geo-restriction enforcement, casual public-WiFi snooping — the realistic exposure window is short enough that the kill switch is doing the job the user expects. The math works. The user wanted plausibility against passive aggregate observers. AES-256 plus a reviewed kill switch delivers that. The 200ms race does not materially change the picture because the adversary is not operating at that resolution.

For adversaries with DPI capability, the math shifts. Hotel WiFi gateways logging SNI; hostile captive portals; ISPs under regulatory mandate to log per-flow metadata (which now applies in more jurisdictions than it did in 2020 — see the UK Investigatory Powers Act 2016 as amended, the Australian Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018, the French Loi Renseignement as updated); these are adversaries who can use a transient drop. The realistic exposure is one or two outbound DNS queries plus whatever HTTPS sessions were already mid-flight. That is enough to deanonymize a session if the adversary already has a correlation hypothesis they are testing.

For adversaries with MLAT authority who can compel logs from your endpoint device's OS telemetry stack, the kill switch is not in scope. The cipher is not in scope. None of the four providers are in scope. The user is shopping for a remedy that does not match the disease. We are saying this plainly because the affiliate-marketed framing does not.

The dollar figure on the gap, if you want one: zero, for most realistic threat models the consumer VPN reader actually has. Meaningful, for the subset who think a VPN is anonymity. Negative, for users who lower other defenses (Tor, compartmentalization, OS hardening) because they think the VPN already solved it.

If You Only Remember One Thing

AES-256 is sound. The kill switch works. Both are doing the job they were designed to do. The mismatch is not between the products and their specs — it is between the products and the threat models reviewers paste onto them.

Decide what you actually want defended. If it is "my ISP should not have a browsing-history product to sell," you are well-served. If it is "no observer anywhere should be able to correlate me to this traffic," AES-256 and a kill switch are not the relevant primitives. They are the floor, not the ceiling.

Signals to Watch

Watch four indicators over the next 12-18 months as the picture evolves: (1) post-quantum cipher rollouts in WireGuard implementations — ML-KEM (NIST FIPS 203, finalized 2024-08) integration in any of the four providers' production builds; (2) whether kill switch behavior under WireGuard roaming gets independent benchmarking by a firm other than the provider's own contracted auditor; (3) audit scope expansion at the four providers — specifically whether client-side state machine assertions enter the test scope, not just server-side no-logs snapshots; (4) jurisdictional shifts that affect MLAT reach into the providers' headquarters countries, particularly any movement on the EU e-Evidence Regulation implementation timelines.

FAQ

Does AES-256 itself have any known practical attack in 2026?

No. Full-round AES-256 has no known practical cryptanalytic attack as of 2026. Side-channel attacks on specific implementations exist and have generated CVEs over the years, but the cipher as specified in NIST FIPS 197 remains sound. The relevant security question is not the cipher — it is the surrounding protocol composition, the TLS or noise-protocol control channel, and the client-side state machine that decides when traffic is allowed to leave the interface.

What is the actual exposure window when a VPN tunnel drops?

On consumer client software in 2026, the window between tunnel failure and kill switch enforcement is measurable in tens to low hundreds of milliseconds, depending on OS firewall layer and how the client detects the drop. WireGuard's connectionless design makes the inference slower than OpenVPN's explicit TLS control channel signal. The window is irrelevant against passive aggregate observers and meaningful against DPI-capable observers who see the cleartext DNS queries and TLS SNI fields that escape during the gap.

Are the kill switches in NordVPN, ExpressVPN, Surfshark, and ProtonVPN audited?

The four providers have had components reviewed by third-party firms — PwC for NordVPN's no-logs configuration in 2018, 2020, and 2022 series engagements; Cure53 for ExpressVPN's Lightway stack in 2022 and Surfshark's client and server infrastructure in 2023; ProtonVPN publishes open-source clients which receive ongoing independent review. The scope of these engagements is what matters. Server-side configuration snapshots and protocol-stack reviews do not automatically cover every client-side race condition.

Is "no-logs" the same as audited?

No, and this confusion drives more bad VPN decisions than any other. A no-logs policy is a stated commitment. An audit is a third-party engagement with a defined scope and a defined point in time. The audit may verify that at the moment of inspection the server configuration matched the claim. It does not verify continuous behavior, does not cover every node, and does not extend to compelled cooperation under legal process. Read the audit's scope section before you read its conclusion.

Does a VPN protect against fingerprinting and tracking?

Not in the way the marketing implies. A VPN reroutes your network traffic and conceals your IP from the destination. It does nothing about browser fingerprinting, cookies, login state, or behavioral analytics. If your threat model includes correlation by ad-tech vendors with persistent identifiers, the VPN is not the relevant tool. Browser hardening, container isolation, or Tor for sessions that justify it are the correct primitives.

Are any of the four providers headquartered in a 14-eyes jurisdiction?

The answer requires nuance the affiliate sites skip. The 5/9/14-eyes framework refers to specific signals-intelligence cooperation agreements. It is not the only mechanism for cross-border legal data requests. MLAT requests, CLOUD Act compelled disclosure for US-touched providers, and EU mutual legal assistance frameworks all operate independently of the eyes-framework shorthand. Check the headquarters jurisdiction against the specific treaty obligations and recent enforcement posture, not the marketing badge that says "outside 5-eyes."

Should I prefer WireGuard or OpenVPN for kill switch reliability?

For raw performance and connection establishment time, WireGuard is the better choice. For kill switch determinism — the property that the client can quickly and confidently assert the tunnel is down — OpenVPN's explicit TLS control channel makes the state machine simpler. WireGuard's connectionless design means kill switches infer health from handshake liveness, which adds a few hundred milliseconds of ambiguity. For most threat models this difference does not matter. For DPI-capable adversaries during a transient drop, it can.

What threat model does AES-256 plus a kill switch actually defend?

A passive aggregate-traffic observer at your ISP or on shared WiFi infrastructure, monetizing browsing metadata, enforcing geo-restrictions, or conducting low-resolution surveillance. That is a real threat model and the combination is appropriate for it. It does not defend against a DPI-capable observer collecting per-packet during the kill switch race window, against endpoint compromise, against browser fingerprinting, or against compelled legal disclosure reaching the provider. Match the tool to the adversary you actually have.