When common‑use becomes common risk: what Collins Aerospace should have had in place before Europe’s airports went dark
Events across 20–21 September laid bare an uncomfortable truth about digital dependency in aviation. A cyber‑related disruption affecting Collins Aerospace’s MUSE common‑use passenger processing software triggered check‑in and baggage‑drop failures at several major European hubs, including Heathrow, Brussels and Berlin, forcing a reversion to manual procedures and prompting cancellations and long queues. Airports and the company alike confirmed that the impact centred on electronic customer processing rather than air traffic control or in‑flight safety systems, but the operational shock was significant and persisted into Sunday.
Reuters’ on‑the‑ground copy recorded Heathrow, Brussels and Berlin as among those affected, with Brussels Airport advising airlines to cancel half of Sunday’s departures to manage the fallout. The Independent’s live reporting corroborated the extended disruption window and relayed Heathrow’s acknowledgement that an outage in a Collins system had impacted check‑in, while the European Commission noted no sign of a “widespread or severe attack” against aviation safety. Together, these accounts establish a clear picture: a supplier‑side failure propagated rapidly through multiple airports that share a common platform for passenger processing.
It is worth understanding what MUSE is and why its failure ripples so far, so fast. Collins describes ARINC cMUSE as its next‑generation CUPPS platform—“common‑use passenger processing system”—deployed on‑premises or in the cloud, allowing multiple airlines to share desks and gates and often integrating with self‑service kiosks and bag drops. Collins’ own materials emphasise cloud options via AWS to deliver flexibility and speed of deployment. Those characteristics are attractive for operations; they also concentrate systemic risk if security and resilience engineering are not first‑class.
At the time of writing, neither motive nor attacker attribution has been confirmed publicly. Reuters also noted prior claims on breach‑tracking sites that Collins was targeted by ransom‑seekers in 2023, which the company did not comment on; that history does not explain this event but underlines why suppliers into critical services must assume persistent, capable threats and engineer accordingly.
What “better prepared” looks like for a critical software supplier
A supplier operating shared, multi‑tenant platforms across essential transport hubs carries responsibilities on three axes: prevent compromise, contain blast‑radius, and restore service quickly. Each axis has concrete, testable measures.
First, the preventive stack needs to start at the software supply chain and change pipeline. For a platform that can incapacitate dozens of airports if misconfigured or tampered with, the update path must be gated by independent code review, reproducible builds, strict signing with hardware‑backed keys, and progressive “ring” deployments with automatic health‑based rollbacks long before changes reach the broad fleet. Canary cohorts at a handful of low‑risk sites and synthetic transaction monitoring should be mandatory. In a modern CUPPS stack, where cloud components are advertised as a flexibility boost, the attack surface is necessarily broader; that demands continuous verification of dependencies, isolation of build systems, and adversarial validation of the pipeline itself through red‑team exercises.
Secondly, containment is non‑negotiable. A fault or compromise in a centralised service must not become a single point of failure for entire terminals. True containment means multi‑region segregation for cloud services; per‑airport tenancy and control planes that can be severed without loss of local operations; strict network segmentation between orchestration, data, and device planes; and default‑deny, least‑privilege identity for agents, kiosks, and DCS integrations. Where common‑use is the operating model, graceful degradation should be the design goal: kiosks and agent desktops must retain a signed, time‑boxed “local operations” mode that continues to print tags and boarding passes against a cached, integrity‑checked subset of the day’s flight data and reconciles on reconnect. Collins markets vMUSE/cMUSE for rapid, flexible deployment; the same architecture should be demonstrably capable of safe, offline operation with provable limits if the central service is unavailable or distrusted.
Thirdly, recovery needs a clock. For a platform embedded in essential services, recovery time objectives and recovery point objectives should be public, contractually binding, and regularly evidenced through live failover drills with airport partners. That evidence should include audited playbooks for isolating suspect components, switching tenants to a clean standby control plane, and reconciling any offline transactions without risking duplicate bag tags, boarding passes, or broken chain‑of‑custody. The weekend’s reports of manual workarounds demonstrate resilient human processes; they should have been complemented by supplier‑led, well‑rehearsed technical failovers that restored automation within hours, not days.
Governance and regulatory duties that already apply
For European operations, supplier‑side resilience and security are not merely best practice; they flow from law and regulation. The EU’s NIS2 framework, transposed into national law from October 2024, expands obligations for essential and important entities and sharpens requirements around supply‑chain risk management, incident reporting, and “appropriate and proportionate” technical and organisational measures. Aviation actors and their key ICT suppliers now sit squarely in scope, and regulators will expect demonstrable control over dependencies and rapid, transparent response when incidents occur. In the United Kingdom, the NIS Regulations continue to impose duties on operators of essential services in transport and on relevant digital service providers. Alongside these, EASA’s emerging information‑security baseline (Part‑IS) is raising expectations for cyber‑safety assurance across the aviation lifecycle, including ground systems. Together, these regimes imply that a supplier in Collins’ position must be able to evidence secure development practices, robust operational controls and a tested, effective incident‑management capability that minimises operational harm.
Communication and trust
Passengers and crews felt the disruption most acutely at check‑in. Clear, timely communication is part of preparedness. Airports did advise travellers to check with airlines and, in Brussels, to attend only with a confirmed flight; yet the weekend’s reporting is threaded with accounts of people left “in the dark” for long stretches. In supply‑chain incidents of this type, the platform owner is the authoritative voice on failure mode, workarounds and safety boundaries. Preparedness, therefore, includes pre‑agreed joint communications with airports and airlines, plain‑English status pages, and near‑real‑time updates on restoration milestones, all of which reduce chaos and help shift operations from blanket cancellations to risk‑based prioritisation.
A practical blueprint for next time
If we were advising a common‑use platform vendor today, we would begin with design authority and test evidence. The platform should present a formal threat model for each trust boundary—build, deploy, control plane, data plane, and device edge—mapped to tests that run continually in CI/CD and in production via chaos and security engineering. Rollout should be progressive and automated with circuit‑breakers; health telemetry should be aligned to business outcomes such as bag‑tag print success, DCS authorisations and kiosk transaction latency, rather than only low‑level service metrics. Each airport tenant should have an independent kill‑switch and a local‑first mode that can be invoked by the tenant when it cannot trust the supplier, not the other way around. Every quarter, the vendor should run black‑start exercises with a subset of airports: cut the platform off, prove that manual plus local‑mode keep the terminal moving, then demonstrate rapid, safe reconciliation. And twice a year, red‑teamers should be given scope to target the build pipeline, control plane and tenant isolation, with findings tied to tracked, time‑bound remediation.
None of this is novel; it is the application of hard‑won lessons from payments, cloud infrastructure and safety‑critical engineering to the aviation ground environment. What is novel is the level of dependency that modern air travel has on a handful of common‑use providers. The benefit of shared platforms is obvious. So is the cost when one of them stumbles.
Closing thought
Collins Aerospace, who oddly do NOT have ISO27001 certification (https://certcheck.ukas.com/certified-entity/a5ef2f61-8d95-5114-a268-20a264bd7e8e) or Cyber Essentials Plus (on a sub division is certified – https://registry.blockmarktech.com/certificates/7a99ac5e-0d2b-4d8d-b3ab-ce287247368e), is hardly the first supplier to experience a cyber‑related disruption, and it will not be the last. But when a vendor’s platform is the digital turnstile of Europe’s busiest airports, “security by intention” is not enough. The standard must be higher: provable resilience, segmented architectures with small blast‑radii, and drills that turn a bad day into an inconvenience rather than a crisis. The weekend’s incident should be a watershed moment for the sector—and a prompt for suppliers and regulators alike to demand evidence, not assurances.
Sources and notes. We reviewed Reuters’ contemporaneous reporting and The Independent’s live coverage to corroborate impact, scope and official statements. Collins’ product literature was consulted to characterise the cMUSE platform and its deployment model. UKAS certcheck was used directly to check certification status, along with the UK’s National Cyber Security Centers Cyber Essential Scheme.
