Digital Infrastructure Under Sanctions: The Iranian Case
Earlier in this series
Sanctions are usually discussed as an economic or political instrument. I want to discuss them as an infrastructure problem. My consulting practice serves clients in Iran and abroad, and my degree work in Estonia focused on how networks behave under the restrictions of the Iranian internet. From that vantage point, the question is not whether sanctions are justified — that is not my lane — but what they do, mechanically, to a country's digital stack, and what that means for the people responsible for defending it.
I wrote in Why Isolated States Build Cyber Resilience Differently that constrained environments produce distinctive security architectures. Sanctions are one of the strongest constraints there is. They press on four channels at once: hardware supply, software licensing, cloud access, and payment rails.
Hardware: the grey-market supply chain
Enterprise hardware — servers, network equipment, storage, even replacement parts — is designed to move through authorized distribution channels. Sanctions close those channels. What replaces them is a chain of intermediaries: equipment purchased in third countries, re-exported, and sold without warranty, without support contracts, and often without any verifiable provenance.
The security consequences are direct. A defender cannot open a support case with a vendor that legally cannot serve them. Firmware updates arrive late or not at all. Equipment stays in service far beyond its intended lifecycle because replacement is expensive and uncertain. And provenance matters in security: when you cannot verify where a device has been between the factory and your rack, your supply-chain assurance drops to near zero. Organizations adapt with spare-parts inventories and cannibalized equipment. It works, until it doesn't.
Software: licensing walls and the patch gap
Most commercial software vendors cannot legally sell into a sanctioned market. The predictable result is that organizations run software they could not buy: unlicensed copies, outdated versions, or products abandoned mid-lifecycle when a vendor withdrew.
For defenders, the most damaging effect is the patch gap. Modern vulnerability management assumes a working relationship with vendors — update channels, security advisories, support entitlements. Remove that relationship and patching becomes slow, manual, and incomplete. Unlicensed software often cannot update through official channels at all, which means known vulnerabilities stay open longer. The same logic that sanctions apply to commerce ends up applying to security fixes, even though nobody designed it that way.
Cloud: exclusion and its substitutes
Major Western cloud providers restrict access from sanctioned jurisdictions, as their compliance obligations require. This is a bigger deal than it sounds. Over the past decade, cloud platforms quietly became the default delivery mechanism for security itself — managed detection, identity services, backup, DDoS absorption, email filtering. Losing cloud access means losing the modern security toolchain, not just compute.
The substitution pattern is a domestic one: local data centers, local cloud platforms, and a strong self-hosting culture. Some of this substitution is genuinely capable. But substitution is adaptation, not equivalence. Domestic platforms carry a smaller security ecosystem around them — fewer third-party integrations, fewer independent audits, a thinner market of specialists. And concentration on a few domestic providers creates its own systemic risk. I drew the distinction in Digital Sovereignty vs Digital Isolation: capability you build by choice behaves differently from capability you build because the alternative was taken away.
Payments: the invisible fourth channel
This is the channel outsiders underestimate. Even where a vendor is willing and licensed to sell, sanctions on payment rails can make the transaction impossible. The modern software economy runs on recurring card payments and international transfers. Cut those rails and every SaaS subscription, certificate renewal, domain registration, and threat-intelligence feed becomes a procurement project involving intermediaries, added cost, and added risk.
For security teams, this shows up as attrition. Services lapse not because anyone decided to drop them, but because the payment failed and there was no clean way to fix it. A defense posture assembled from subscriptions degrades quietly when the subscriptions cannot be paid.
The substitution economy, summarized
Across all four channels, the same pattern repeats. Official channels close; informal ones open. Domestic alternatives grow; open-source adoption deepens; self-hosting returns. Organizations get remarkably good at operating without vendor relationships — a resilience skill in its own right, and one I have watched clients develop to a level that would surprise their peers in unconstrained markets.
But the ledger has a cost side, and the costs land disproportionately on defenders:
- Slower patching and longer exposure windows for known vulnerabilities.
- No vendor support during incidents, when it matters most.
- Thin threat-intelligence access, since commercial feeds are largely unreachable.
- Unverifiable supply chains for the hardware underneath everything.
- Tooling drift, as teams train on older or improvised stacks.
- Quiet service attrition through broken payment rails.
Attackers, meanwhile, are barely inconvenienced. Offensive activity does not depend on licenses, warranties, or payment compliance. Sanctions asymmetrically tax defense.
The policy point
None of this is an argument about whether sanctions should exist. It is an observation about externalities. Sanctions regimes are designed with trade, finance, and strategic industries in mind. Their effect on defensive cybersecurity is a side effect — but a real one, borne by hospitals, banks, utilities, and ordinary users inside the sanctioned country, who still face the same global threat landscape as everyone else. Some sanctions frameworks include carve-outs for communications technology, and as reported, their practical effect has been uneven, because compliance-averse vendors tend to over-comply rather than parse exemptions.
I ended When the Internet Goes Dark with the point that connectivity failures are governance failures before they are technical ones. Sanctions belong in the same frame. If policymakers want sanctioned populations to remain defensible — and stated policy in several jurisdictions says they do — then the defensive externalities need to be designed for, not discovered later.
For defenders working inside these constraints, the practical lesson is older than any sanctions regime: assume no external help, minimize dependencies you cannot control, and build a security program that survives on what you can actually obtain. It is a hard school. It also produces some of the most resourceful security engineers I have ever worked with.