Iran's Internet Returns After 90 Days Offline: A Threat-Model Decision Tree for Users on the Ground

Think of this as a flowchart in prose. Web monitoring groups report that connectivity inside Iran is returning after roughly 90 days of near-total blackout — a duration that, by any honest reading of the regional record, sits at the outer edge of state-imposed shutdowns globally. The thaw is partial. It is conditional. It is almost certainly instrumented. Before you reach for the same VPN client you used in February, this desk is going to ask you three questions. Your answers route you to a recommendation. The questions matter more than the answer, because the questions are the threat model — and most "best VPN for Iran" content skips that entirely.

Question 1: Is Your Adversary the State Itself, or Just the Pipe Between You and the State?

This is the fork that breaks most VPN advice. The person whose adversary is the state — meaning the apparatus that can compel an ISP, deanonymize a SIM at the BTS level, request travel records, knock on a door — needs a tool optimized for a completely different objective than the person whose adversary is a bored ISP analyst running deep packet inspection at the gateway level. Conflating those two is the single most expensive category error in this space. Listen — we have seen people pick a provider because it had a "kill switch" feature, when the actual exposure was a SIM-card subscriber record that no kill switch can touch.

The state adversary has lawful intercept capability at the ISP, has the legal posture to subpoena upstream transit providers, and increasingly has the operational capacity to fingerprint VPN traffic at the protocol layer using techniques described in the academic DPI literature since around 2017. The pipe adversary has none of those things. The pipe adversary has a Netflow record and a billing system.

If Yes — Your Adversary Is the State

You need a protocol that does not look like a VPN on the wire. Standard WireGuard UDP on port 51820 is, against a competent state-level DPI stack, a flare. The handshake is identifiable. The first packet has known structure. We cite the academic work on DPI fingerprinting of WireGuard handshakes that emerged from 2019 onward — the protocol's elegance is its operational weakness in censored environments. You want obfuscation that wraps the underlying tunnel inside something that pattern-matches as TLS-to-an-HTTPS-server. NordVPN's NordWhisper and ProtonVPN's Stealth are the published commercial implementations in this category from the operators we cover. Neither is a guarantee. Both are better than vanilla.

You also need to assume the device itself is the weak link. A VPN does not protect against an endpoint compromise. If you are running a stock Android device with the carrier's preloaded apps still installed, your threat model has bigger holes than your transport layer.

If No — Your Adversary Is Just the Pipe

Then the calculus shifts almost completely. You are not running from a state — you are running from log retention. Any audited commercial provider whose no-logs claim has survived independent inspection covers this case. ExpressVPN's Lightway, ProtonVPN's standard WireGuard, Surfshark's Nexus stack — any of these resolve the pipe-adversary threat model. You do not need obfuscation. You do not need multi-hop. You need a provider whose audit history has been published with scope you can read.

The honest version: the pipe adversary is a much smaller problem than people in censored regions are sold. The marketing collapses both adversaries into one number on a pricing page, which is why people overpay for capability they cannot use and underbuy capability they need.

Question 2: Do You Need This Connection to Survive a Second Blackout, or Just the Current Thaw?

The first 90-day blackout is a data point. Web monitoring reports of connectivity returning do not mean the political conditions that produced the shutdown have resolved — they mean the operational cost of continued blackout exceeded some internal calculus inside the apparatus that ordered it. That calculus can flip back. Anyone planning around the current thaw as the new baseline is making the same mistake that traders make when they treat a relief rally as a trend reversal.

This is the question that separates a tool you install today from infrastructure you build over the next quarter. The cost difference between those two postures is significant. The capability difference is enormous.

If Yes — You Are Building for the Next Blackout

You need at least two independent transports, configured before the blackout begins. During a near-total shutdown, app stores are unreachable, provider websites are blocked, and getting an installer onto a device becomes the problem that dwarfs every other technical concern. The discipline is: install everything now, while connectivity exists, even if you only use one tool day-to-day. Keep an offline copy of the installer on a device that does not depend on connectivity to retrieve it.

You also need to think about server-side fallback. A provider whose obfuscation depends on a fixed pool of front-end IPs in known datacenters is one IP-list update away from being unreachable. Providers running rotating obfuscation infrastructure outperform here, and the difference is not marketed because most users buy on price.

The other discipline: have a non-VPN fallback. Tor with pluggable transports (obfs4, meek-azure, Snowflake) sits in a different category of resilience. The throughput is bad. The resilience is real.

If No — You Are Routing Around the Current Thaw

The decision compresses considerably. You can pick on the basis of the threat model you answered in Question 1 and stop optimizing for the worst case. A single audited provider with the right protocol set is sufficient. The friction of running two stacks in parallel is not justified by your actual exposure window.

The honest caveat: most readers underestimate how much their threat model will shift in 60 days. The decision to treat this as a temporary connectivity problem is correct for some people and a deferred mistake for others. We are not in the room. You are.

Question 3: Are You Willing to Accept a Protocol That Looks Like a VPN on the Wire?

This is the operational question, and it is where the abstract threat model meets the specific commercial product you can actually buy and run. A protocol that "looks like a VPN on the wire" means the connection, observed by a passive DPI device at the ISP gateway, is identifiable as a tunneled-traffic flow rather than ordinary web browsing. Standard WireGuard, standard OpenVPN UDP, standard IKEv2 — all of these are identifiable. That identification is the trigger for an enforcement action in some jurisdictions and is meaningless in others.

The question matters because the protocols that hide best from DPI are also the protocols with the worst stability, highest latency, lowest commercial maturity, and most fragile cross-platform support. You are paying a real performance and reliability tax for the obfuscation. Whether the tax is worth paying is exactly what this question asks.

If Yes — Standard Protocols Are Fine

Pick on audit history and client quality, not protocol theatre. ExpressVPN's Lightway stack went through a Cure53 penetration test with the full source published; ProtonVPN's applications and infrastructure have been audited by Securitum across multiple cycles; NordVPN has published external audits of its no-logs posture. The protocol you connect with — WireGuard, OpenVPN, IKEv2 — matters less than the underlying provider trust model. You optimize for the operator, not the wire format.

If No — You Need Obfuscation, and You Will Pay for It

Then the field narrows. NordVPN's NordWhisper, ProtonVPN's Stealth, Surfshark's Camouflage Mode — these are the commercial obfuscation implementations on offer from operators we cover. Expect higher latency. Expect occasional handshake failures requiring reconnection. Expect the obfuscation feature to be unavailable on some platform/protocol combinations. None of this is failure — it is the inherent cost of wrapping a tunnel inside a protocol it was never designed to impersonate. Budget the friction in advance.

If You Answered Everything: The Recommendation Matrix

Eight combinations. Each row is one route through the decision tree. The recommendation cell is what we would actually suggest to a reader matching that profile — terse on purpose, because the analysis is in the sections above.

The matrix is not advice. It is a structured way to see where your specific combination of answers lands so that the editorial reasoning behind each row is auditable. The right-hand column compresses several paragraphs into one sentence by design — if a sentence reads thin to you, the section it summarizes is where the substance lives. Re-read that section and decide whether you accept the compression.

A note on the apparent contradiction across rows. The "Pipe / No / No" row looks like it punishes the reader for over-buying — that is intentional. Most VPN content sells up. This desk sells across. If your threat model does not need the capability, the responsible recommendation is not to buy it, even when buying it is the more profitable answer for the publication.

What This Piece Does Not Cover

This piece does not cover the specific technical mechanism by which Iranian ISPs implement filtering and re-routing during a national shutdown — that is a network-engineering question and the public record on it is partial, with much of the substantive analysis sitting behind credentialled access at organizations like the Open Observatory of Network Interference. We are not in a position to extend that record from inside this desk.

It does not cover the legal exposure of running a VPN inside Iran under the country's current statutory framework. The relevant texts and enforcement posture have shifted multiple times in the last decade, and the gap between what is written and what is enforced is exactly the sort of jurisdictional nuance that requires local counsel, not a privacy desk three thousand miles away. Anyone who tells you otherwise is selling something.

It does not cover the operational security of devices, accounts, or personal contacts inside Iran. A VPN is one layer of one stack. The endpoint, the SIM, the accounts logged into the device, the contact graph that connects you to people the apparatus is watching — all of those sit outside the transport layer, and a VPN does not touch any of them. Treating a VPN purchase as the complete answer to the threat is the mistake we see most often, and the one that has the worst downstream consequences.

Each of those is a separate piece, written by someone qualified to write it. We would rather name the gaps than fill them with confidence we have not earned.

FAQ

What does it mean that connectivity is "returning" to Iran after the blackout?

Web monitoring groups report that traffic levels measurable from outside Iran have risen toward pre-shutdown baselines after roughly 90 days of near-total disconnection. "Returning" is not the same as "restored" — observability is partial, the recovery appears uneven across networks, and the political conditions that produced the original shutdown have not visibly changed. Treat it as a thaw with conditions, not a return to the prior status quo.

Is a standard commercial VPN enough to bypass Iranian filtering right now?

For a passive-ISP threat model, often yes — for a state-level adversary with DPI capability, frequently no. Standard WireGuard and OpenVPN connections are fingerprintable at the protocol layer using techniques in the published DPI literature, and providers without obfuscation features can be blocked or flagged. If your exposure is more than commercial filtering, you want NordWhisper, Proton Stealth, or an equivalent obfuscated transport.

Why not just use Tor instead of a VPN?

Tor with pluggable transports (obfs4, meek-azure, Snowflake) is structurally more resilient against state-level censorship than commercial VPNs, because the protocols are explicitly designed to resist identification. The tradeoff is throughput and latency — both are materially worse than a VPN, often by an order of magnitude. Many practitioners run both: a VPN for daily use, Tor as a fallback during enforcement spikes or when the VPN layer fails.

Are no-logs claims from major providers verifiable?

A no-logs claim is a marketing statement until an independent auditor has examined the provider's configuration, infrastructure, and operational practices. Audits by firms such as Securitum, Cure53, PwC, and KPMG have been published for several of the providers we cover, but every audit has a documented scope. "Audited" without reading the scope is meaningless. The scope is the story.

Should I install a VPN now in case there is a second blackout?

If you are reading this from inside Iran and have any non-zero estimate that another shutdown could occur in the next 12 months, yes — install your tooling while connectivity exists. During a near-total blackout, app stores are unreachable, provider domains are blocked, and the operational problem of getting an installer onto a device dominates every technical concern. Pre-positioning installers offline is the discipline.

Does paying for a VPN create a financial paper trail to me?

Subscription payments create records at the payment processor, the bank, and the provider. Cryptocurrency payments reduce but do not eliminate that exposure, depending on how the crypto was acquired. For threat models where payment-trail correlation matters, the relevant disciplines are paying via privacy-preserving payment rails or pre-paid instruments — not the VPN choice itself. The transport layer and the billing layer are separate problems.

How long should I expect a VPN purchased today to remain operational inside Iran?

Honest answer: unknown, and the operators do not commit to a number for good reason. Server IPs get blocked, obfuscation patterns get fingerprinted, and the cat-and-mouse dynamic between operators and censors is continuous. Providers with active obfuscation engineering teams and infrastructure rotation budgets outperform on this metric — and that capability rarely appears on the pricing page. Treat operational longevity as variable, not advertised.