Safeguard
Industry Analysis•

Systemic cyber risk: a concentration checklist for your stack

Systemic risk is many failures from one shared dependency. A checklist to find your concentration points, with examples from CISA and Microsoft sources.

Safeguard Security Team
3 min read

Systemic cyber risk means one shared dependency failing and taking many organizations with it. It does not need an attacker. You reduce it by finding your concentration points: shared providers, shared update channels, shared time and network sources, and shared credentials, then planning a way to operate without each.

Two documented examples

In July 2024 a software update from an independent security company disrupted IT systems worldwide. Microsoft estimated it affected 8.5 million Windows devices, less than one percent of all Windows machines, and said it was not a Microsoft incident. Recovery required manual remediation steps, scripts and hundreds of engineers helping customers.

For satellite links, CISA and the FBI warned that a successful intrusion into a SATCOM network could expose the environments of that network's customers. One provider failing reaches many customers.

Different causes, same shape: a trusted shared component fails, and the effect is correlated.

The concentration checklist

Update channels. Which agents or tools update themselves on every machine at once? Can you stage rollouts, for example a small ring first? Can you pause an update centrally?

Cloud and hosting. Is any single region or provider the only home for a critical service? Do you know the manual restore steps?

Identity. If your single sign-on provider is down, can you still reach admin consoles through a break-glass account?

Network and connectivity. Is there a second path if one carrier or satellite link fails?

Time. Do all systems share one time source? See GPS timing: the hidden dependency in your stack.

Build and release. Does one registry, one CI service or one signing key gate every release?

Third parties. Which vendors would stop your business if they stopped? Check contracts for incident notification, as CISA advises for SATCOM.

What to do with the answers

Rank the findings by two things: how many systems fail together, and how long recovery takes by hand. Then pick the top three and write a runbook for each, including who decides to fail over, and rehearse one.

You cannot remove every shared dependency. You can make sure a failure is a bad afternoon rather than a bad week.

Click through it at your own pace, or open it full screen.

Staged rollouts as a simple defence

Of everything on the list, staged rollout is the cheapest control for correlated failure. Release every change, whether your own or a vendor's, to a small group first. Wait long enough to see problems. Then widen. If a tool does not let you stage or pause updates, record that as a risk and ask the vendor for it.

Pair it with a tested manual recovery path. In the 2024 example, Microsoft's account lists manual remediation steps and scripts, which shows that recovery sometimes means touching machines one by one. Know in advance how you would do that for your fleet and how long it would take.

Quick check

Does systemic risk require an attack?

No. A faulty update from a shared provider disrupted millions of devices in 2024 without a Microsoft vulnerability or a reported attacker behind it, according to Microsoft's account.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.