Ransomware Hits Aviation: Third-Party Risk Goes Systemic
A ransomware attack on Collins Aerospace's MUSE system halted passenger processing at Heathrow, Brussels, and Berlin airports. One vendor, one attack, industry-wide disruption.
September 19, 2025. A ransomware attack takes down passenger processing at Heathrow, Brussels, and Berlin airports. Flights delayed. Check-in systems offline. Chaos across borders.
The attackers didn’t compromise three separate targets. They hit one: Collins Aerospace’s MUSE system, a passenger processing platform used by multiple airlines across multiple airports.
One vendor. One attack. Industry-wide disruption.
The Concentration Problem
MUSE (and its variant vMUSE) handles check-in, boarding, and passenger data for airlines worldwide. When it went offline, airlines lost the ability to process passengers. Manual fallbacks existed—paper boarding passes, offline check-in—but the scale overwhelmed staff who hadn’t trained for this scenario in years.
This is vendor concentration risk in its purest form. Modern enterprises outsource critical functions to specialized providers. Those providers achieve scale by serving many customers. The result: a single point of failure that affects an entire sector.
Aviation isn’t special. Every industry has these concentration points:
- Financial services: Payment processors, core banking platforms, SWIFT messaging
- Healthcare: Claims processing, EHR systems, lab result networks
- Retail: Logistics providers, inventory management, payment gateways
- Manufacturing: ERP systems, supply chain visibility platforms
When these shared systems fail, entire industries feel the impact.
What the Aviation Attack Revealed
The Collins Aerospace incident exposed several uncomfortable truths:
Fallback procedures were rusty. Airlines had contingency plans for system outages, but staff hadn’t practiced them recently. The transition to manual processes was slow and inconsistent.
Cross-border coordination was weak. Each airport operated semi-independently during the outage. There was no unified incident command across affected locations.
Recovery timelines were unclear. Airlines couldn’t tell passengers when systems would be restored because they didn’t control the timeline. Collins Aerospace did.
Contractual SLAs didn’t match operational reality. Breach notification clauses and uptime guarantees don’t help when you’re standing in front of 300 stranded passengers.
Rethinking Third-Party Risk
Traditional vendor risk assessment focuses on onboarding: questionnaires, certifications, contract terms. Important, but insufficient.
Modern third-party risk requires:
Dependency mapping. Which vendors, if compromised, would halt operations? Not just IT vendors—any service provider in a critical path.
Continuous monitoring. Vendor security posture changes over time. Point-in-time assessments miss drift. Use external attack surface monitoring and threat intelligence feeds.
Operational fallbacks. For each critical vendor, what’s the manual workaround? How long can you operate that way? When did you last test it?
Incident response integration. Your IR playbooks should include vendor failure scenarios. Who do you call? What’s the escalation path? How do you communicate with customers when the problem isn’t yours to fix?
Concentration awareness. If your top five customers all use the same platform, you have concentration risk even if you don’t use it directly.
Checklist: Third-Party Resilience
- Identify vendors that could halt operations if compromised or offline
- Document manual fallback procedures for each critical vendor dependency
- Test fallbacks at least annually—tabletop isn’t enough, run actual drills
- Include third-party breach scenarios in incident response exercises
- Review vendor contracts for breach notification SLAs and liability terms
- Monitor critical vendors’ external attack surface continuously
- Assess concentration risk: which vendors serve your entire industry?
- Establish direct contacts with vendor security and incident response teams
The Uncomfortable Reality
You cannot fully control third-party risk. You can only manage it.
This means accepting that some vendor failures will happen, and planning accordingly. Resilience isn’t about preventing all failures—it’s about limiting blast radius and recovering quickly.
The September aviation incident lasted hours, not days. But it could have been worse. Organizations that had practiced fallback procedures recovered faster. Those that hadn’t were still sorting out backlogs days later.
The question isn’t whether a critical vendor will have an incident. It’s whether you’ll be ready when they do.
At Dédalo, we help organizations map third-party dependencies and build operational resilience. If you need to assess your vendor risk posture, we can help.