Notifications
Clear all
Topic starter
11/07/2026 8:32 pm
TL;DR: An AWS outage disrupted connectivity worldwide, and 90% of the global attack surface is served by software from just 150 companies, according to SecurityScorecard, underscoring how concentration and interdependence can turn a single failure into widespread disruption. The resilience lesson is that dependency mapping and recovery design now matter as much as perimeter defence.
NHIMG editorial — based on content published by SecurityScorecard: analysis of the AWS outage and the fragility of digital interdependence
By the numbers:
- 90% of the world’s global attack surface is served by software from only 150 companies.
Questions worth separating out
Q: How should organisations reduce outage risk in cloud-dependent identity workflows?
A: Start by mapping which authentication, authorisation, and automation paths depend on each cloud provider or SaaS layer.
Q: Why do third-party dependencies create resilience risk for IAM programmes?
A: Because many IAM and NHI controls rely on external services to issue, validate, or broker trust.
Q: What do security teams get wrong about cloud outage preparedness?
A: They often focus on application restart plans while ignoring identity, token exchange, and third-party integration failure.
Practitioner guidance
- Map upstream dependency chains Build a service-to-provider dependency map that includes cloud infrastructure, SaaS, identity services, and managed integrations.
- Test identity fallback paths Run recovery exercises that verify whether service accounts, federated logins, and machine-to-machine authentication still work when the primary cloud provider or token service is degraded.
- Separate availability from compromise scenarios Document different playbooks for provider outage, authentication failure, and suspected intrusion so teams do not treat every disruption as the same event.
What's in the full article
SecurityScorecard's full article covers the operational detail this post intentionally leaves for the source:
- The Fox News Chicago segment transcript and the resilience framing SecurityScorecard used to explain the outage.
- The 90% of the world’s global attack surface figure and how the company uses it to discuss concentration risk.
- The practical guidance on auditing interconnected products, infrastructure, and third-party dependencies.
- The broader societal resilience argument for designing systems that can recover quickly after provider failure.
👉 Read SecurityScorecard's analysis of the AWS outage and digital interdependence →
AWS outage and digital supply chains: what resilience teams should recheck?
Explore further
11/07/2026 9:00 pm
Concentration risk is now a governance issue, not just an availability issue. The AWS outage shows how quickly digital dependence can turn one provider failure into a broad operational event. SecurityScorecard’s point about 90% of the global attack surface being served by only 150 companies underscores how few upstream nodes now carry too much organisational risk. Practitioners should treat dependency concentration as a board-level control problem, not an engineering inconvenience.
A question worth separating out:
Q: Who is accountable when a provider outage disrupts business operations?
A: Accountability usually sits across infrastructure, security, application, and vendor management teams, because the risk arises from shared dependency decisions. Governance should assign ownership for dependency mapping, continuity testing, and acceptable blast radius so no single group can assume someone else will handle it.
👉 Read our full editorial: AWS outage exposes the fragility of digital supply chains
