I’ve spent most of this month writing about Iranian cyber operations and Gulf energy infrastructure because, frankly, the news hasn’t given me a choice. But buried under the Hormuz crisis coverage this week is one of the most important pieces of technical analysis I’ve read all year: the Atlantic Council’s breakdown of what they’re calling “the coming compute war” in Ukraine. I want to talk about it in detail. Because this is not just a military strategy story. This is the most expensive, most violent, most clearly documented real-world proof of a principle that every enterprise architect and CISO should have tattooed somewhere visible: single points of failure are not theoretical risks. They are catastrophes waiting for the right moment.

What’s Actually Happening in Ukraine Right Now

Ukraine is producing drones at industrial scale. The Atlantic Council’s analysis puts current production at over three million annually across aerial, ground, and maritime categories, heading toward seven million in 2026. The strategy makes sense: drones are cheap, precise, numerous, and difficult to intercept at scale. An 800-drone coordinated swarm is not an abstract concept in 2026 — it’s an operational reality that Ukrainian commanders are deploying in the Kharkiv sector.

Here’s where it gets technically interesting and immediately terrifying at the same time.

The entire operational architecture of Ukraine’s drone warfare depends on Starlink. Not as a nice-to-have. As the sole viable command-and-control uplink. The Atlantic Council analysis is blunt: “If these tactical uplinks were effectively denied — whether by Russian terminal jamming, cyberattacks aimed at user networks, or corporate policy shifts — Ukraine would possess no terrestrial or satellite alternative capable of sustaining its current command tempo. If the link goes down, the current architecture of warfighting would collapse within days.”

That sentence should stop you cold. The second largest ground war in Europe since World War II, involving a drone arsenal of millions of units and billions of dollars in Western military aid, is operationally dependent on a single private commercial satellite network controlled by one person. And Russia figured this out.

Per the Atlantic Council scenario: in May 2026, in the Kharkiv sector, a Ukrainian commander launches an 800-drone swarm. Eighteen minutes into the mission, Russian electronic warfare assets sever the swarm’s tactical Starlink ground uplinks. The swarm continues on preprogrammed instructions — it doesn’t abort — but the real-time targeting, coordination, and adaptive response capabilities are gone. Russia has learned to specifically target Starlink uplinks because they are the bottleneck through which Ukraine’s entire drone command architecture flows.

Meanwhile, in a separate and deeply ironic development reported by CNN, Euronews, and Ukrainian defence officials: Russia itself has been equipping its Molniya strike drones with Starlink terminals acquired through illicit channels — captured units, secondary markets, intermediaries in Europe. A Starlink terminal costs $400-500 wholesale. Attached to a Molniya drone, per Ukrainian defence advisor Beskrestnov, it makes the drone unjammable by ground-based electronic warfare, controllable in real time from inside Russia, and accurate to tens of metres on targets hundreds of kilometres away. The technology Ukraine depends on to fight is also being weaponised against Ukraine because it’s a single network controlled by inadequately verified terminals.

Russia’s Energy Attack Strategy — The Compute Dependency Trap

Russia has been systematically attacking Ukrainian energy infrastructure since mid-January 2026. Per Al Jazeera and Reuters tracking, Russia has struck Ukrainian energy infrastructure 217 times in the period. Power stations, gas pipelines, thermal power plants — Kyiv’s Darnytsia plant was heavily damaged in February 2026. Hundreds of thousands of people without heat at -20°C.

This looks like a humanitarian atrocity, which it is. But it also has a specific cyber-strategic logic that’s being underreported. When Russia destroys Ukrainian domestic power generation capacity, it forces Ukraine’s military communications and data processing infrastructure onto cloud computing and satellite connectivity — infrastructure that Russia can interdict, degrade, or threaten through means other than missiles. The Atlantic Council analysis describes this as “deliberately degrading Ukraine’s domestic compute capacity and increasing dependency on cloud infrastructure that can be interdicted.” It is a compute dependency trap. Destroy the physical compute and communications capacity. Force reliance on externally controlled alternatives. Then threaten those alternatives.

The Starlink whitelist incident illustrates how this plays out. SpaceX in February 2026 implemented stricter verification and whitelist controls to block unauthorized Russian military use of Starlink terminals — and the process temporarily disrupted some Ukrainian users. Ukraine’s defence ministry had to negotiate with a private company to maintain its battlefield communications. Elon Musk’s public statement — “their entire front line would collapse if I turned it off” — made in March 2025 when US-Ukraine tensions were elevated, is a fair description of the dependency. One person’s corporate policy decision has direct battlefield consequences. That is a single point of failure of a scale and type that no military planner, enterprise architect, or resilience professional should be comfortable with.

Foreign Policy’s analysis of “Starlink Has Privatized Geopolitics” documents the broader implication: “Commercial satellite providers are no longer passive enablers; they are actors whose technical decisions can shape tactical outcomes.” This is true in warfare and it’s going to be true in enterprise very soon, as commercial satellite networks become critical infrastructure for remote operations, maritime logistics, and industrial connectivity.

Why This Matters Beyond Ukraine

Here is the link that mainstream coverage keeps missing, and it’s the one I want to make explicit.

Ukraine’s Starlink dependency is a military example of an architectural mistake that enterprises make constantly. The specific mistake is: building operational capacity on a single external dependency with no verified fallback, no resilience architecture, and no contingency for that dependency being degraded, denied, or arbitrarily changed by the party controlling it.

The enterprise equivalents are everywhere. A logistics company that depends entirely on a single cloud provider for its operations — and has never tested what happens when that provider has a multi-region outage. A manufacturing company whose SCADA systems depend on a single VPN provider for remote access — and has no fallback when that provider is disrupted. A healthcare organisation whose EHR runs on a single SaaS platform with no local failover capability. A financial services firm whose trading operations depend on a single third-party data feed with no verified backup.

These are not exotic failure scenarios. They are the single-point-of-failure patterns I’ve been writing about in this blog for years, and they remain rampant because building genuine resilience is expensive and unglamorous and the failure modes are not visible until something goes wrong. As I wrote in my post on the Marquis vs. SonicWall lawsuit — where a firewall vendor’s own backup service handed ransomware gangs the keys to a fintech company’s network — the problem with single-vendor dependency is that you inherit the vendor’s failure modes along with their services. Ukraine inherited SpaceX’s geopolitical exposure along with its satellite network.

The Russia-Ukraine electronic warfare dynamic also has a direct enterprise parallel. Russia is jamming Starlink ground terminals because they’re the bottleneck. Attackers in enterprise environments do the same thing: they identify the single control plane through which everything flows — the SIEM, the identity provider, the network management platform — and they hit that. I wrote about this exact pattern in my coverage of the Cisco SD-WAN mass exploitation campaign: attackers targeted the SD-WAN management console because owning the management plane means owning everything it manages. Same logic. Different scale.

And there’s a satellite-specific dimension that’s coming into enterprise relevance fast. Commercial satellite connectivity is increasingly critical for maritime operations, remote industrial facilities, and global logistics. My research on submarine cable infrastructure and satellite surveillance covers exactly this convergence of satellite and physical infrastructure dependency. The lesson from Ukraine is that satellite connectivity is not as resilient as its architecture suggests when adversaries specifically target the ground terminal layer rather than the satellites themselves. Enterprise designers depending on commercial satellite links for critical operations need to apply the same resilience thinking military planners are now applying in Ukraine: assume the link can be degraded or denied, and design accordingly.

What Went Wrong — Root Cause

The root cause is not that Starlink is a bad product. It’s excellent. The root cause is architectural monoculture combined with the absence of fallback planning. Ukraine built an entire military operational architecture on the assumption that Starlink would always be available, at sufficient capacity, on terms controlled by Ukraine. None of those assumptions held.

The specific failure mode the Atlantic Council describes for cloud-dependent drone operations is worth quoting for the enterprise audience: “When Russia induces intermittent denial through jamming or cyberattack, cloud-centric architectures don’t just degrade — they fail. The arithmetic is merciless.” Intermittent degradation of a single critical dependency causes cascading failures across everything dependent on it. This is true for satellite uplinks and it’s true for cloud providers and it’s true for identity providers and it’s true for any critical single-point dependency in your architecture.

The Fix — Fixer’s Advice

The military lesson has direct enterprise application, and I want to be concrete about what that looks like.

Step one: Map your single points of failure — actually map them. Not at the marketing brochure level of “we use the cloud for resilience.” At the actual architectural level. Which cloud provider? Which region? Which specific services? If your ERP goes down because AWS us-east-1 has an outage, is that your only option or do you have a genuine failover? Which identity provider? If Okta or Azure AD has an outage, can your staff authenticate to critical systems? Which network management platform? If your SD-WAN management console goes down, can you manage your network without it? List every critical operational dependency, identify whether it’s a single point, and document the business impact of losing it.

Step two: Test your failover. Actually test it. Not with a diagram. By actually simulating the failure. Conduct a planned exercise where you cut access to your primary cloud provider for a critical workload and verify the fallback kicks in. If you’ve never tested it, it doesn’t work. Ukraine is learning this lesson at enormous cost. Test your failover before the actual outage forces the lesson.

Step three: Implement redundant communications paths for critical operations. If your operational communications depend on a single internet service provider, single satellite uplink, or single network path, add a secondary path now. For remote operations — offshore facilities, manufacturing plants, logistics hubs — consider heterogeneous connectivity: primary fibre or satellite, secondary 4G/5G cellular, backup VSAT from a different provider. The paths should be from different providers, use different underlying infrastructure, and terminate through different physical access points.

Step four: Build for degraded-mode operations. Design critical systems to function — with reduced capability — when external dependencies are unavailable. This is what the Atlantic Council recommends for Ukrainian drone operations: “Forces must either process data locally at the edge — transmitting only highly compressed targeting summaries upstream — or accept that cloud-dependent systems will fail when links are degraded.” The enterprise equivalent is local caching of critical data, offline authentication capabilities, manual fallback procedures for critical operational processes, and edge computing for time-sensitive decisions that can’t wait for a cloud round-trip.

Step five: Audit your third-party dependencies for concentration risk. If your critical operations depend on a single vendor for network management, your single cloud management plane, your single identity provider — you have the same structural vulnerability Ukraine has with Starlink. Vendor concentration risk is not just a procurement concern. It’s an operational resilience concern. Diversify where the cost of diversification is lower than the cost of the failure scenario.

Step six: Verify your corporate policy risk with critical third parties. Ukraine’s dependency on Starlink introduced geopolitical corporate policy risk — the possibility that SpaceX’s policy decisions, shaped by one person’s political opinions, could affect battlefield outcomes. Enterprises have the equivalent: cloud provider terms of service, SaaS platform acceptable use policies, telecom operator agreements that contain provisions you’ve never read. What happens to your operations if your primary cloud provider decides to suspend your account — for billing disputes, regulatory reasons, or geopolitical pressure from a government? Have you read those terms? Do you have a plan?

My research on Horizontal Peace in Ukraine covers the structural dynamics of the conflict that make the Starlink dependency so strategically significant — and why the compute war dimension is likely to intensify regardless of kinetic outcomes.