One vendor's ransomware stopped four European airports. See what was actually confirmed, why insurance is priced into the attack, and what to rehearse.
A ransomware attack on one check-in software vendor stopped passenger processing at Heathrow, Brussels, Berlin Brandenburg, and Dublin in September 2025. None of those airports was breached. All of them stopped working, which is the distinction between managing liability and managing continuity.
On the evening of Friday 19 September 2025, ransomware hit systems supporting Collins Aerospace’s ARINC vMUSE platform, the software airlines use to share check-in desks and boarding gates.
By Saturday morning, staff at several major European airports were writing boarding passes by hand. Hundreds of flights were delayed or cancelled across the weekend.
Separating confirmed fact from reporting matters here, because much of the coverage blurred the two. ENISA confirmed the disruption was caused by ransomware. RTX, the parent company, confirmed a ransomware incident in a filing with the US Securities and Exchange Commission. The UK’s National Crime Agency arrested a 40-year-old man in West Sussex under the Computer Misuse Act, later releasing him on conditional bail.
The variant was never officially confirmed. Researchers pointed to HardBit, other reporting suggested Loki, and attribution remained contested throughout. Treat the family as probable rather than established.
One characteristic of the suspected variant deserves more attention than it received, because it turns an abstract argument into a concrete mechanism.
HardBit emerged in October 2022 and became notable for a specific negotiating tactic, as SecurityWeek reported at the time. Its operators pegged ransom demands to the victim’s cyber-insurance limits.
Read that again with the liability question in mind. An organisation buys insurance to transfer financial risk. The attacker then reads the policy limit and prices the demand to it.
Liability transfer does not sit outside the attack. It becomes an input to the attacker’s pricing model. So “we are covered” answers a finance question and leaves the operational one untouched.
Discover how Threatcop protects your workforce from modern cyber threats.
RTX’s SEC disclosure included a line worth reading carefully. The MUSE airport systems, it noted, operate outside the RTX enterprise network, residing on customer-specific networks.
That statement is accurate and appropriate. Investors need to know whether a subsidiary’s incident reached the parent’s core systems, and scoping the blast radius is exactly what a disclosure should do.
It also does nothing for an airport. From Heathrow’s position, the relevant fact is that passenger processing stopped, and the architectural boundary protecting RTX’s enterprise network was not a boundary protecting its customers.
That gap is the whole lesson. A vendor can be truthful about its own containment while your operations are down, because the two of you are measuring different things. Assurance describes their exposure. Continuity describes yours.
Recovery went badly in a way that carries a general lesson. Researchers tracking the response reported that devices kept getting reinfected, forcing recovery to restart repeatedly.
That is what turns a weekend incident into a multi-day one. Restoring systems into an environment where the threat persists produces a loop rather than a recovery, and each cycle costs another day of manual operations.
Kevin Beaumont, the researcher who tracked it publicly, noted that the payloads were detected by free antivirus using static detections that were years old. Sophistication was not the obstacle.
Cost framing for the human layer sits in why weak human controls raise compliance costs. For a customer organisation, the practical consequence is a planning assumption rather than blame. Fallback procedures need to survive not the outage you imagined, but one that recurs, because a vendor’s recovery may fail more than once.
Both are legitimate. They answer different questions, and confusing them produces contracts that satisfy legal review and fail during an incident.
| Question | Liability answer | Resilience answer |
|---|---|---|
| Is the vendor certified? | ISO 27001 and SOC 2 on file | Certification scope checked against the system you depend on |
| What if they are breached? | Indemnity clause and insurance | Named fallback procedure, rehearsed |
| How long until service returns? | Service level agreement with credits | Your own tolerance, measured, with a plan beyond it |
| Who is accountable? | Contractually, the vendor | Operationally, you, in front of your customers |
| What did they tell us? | Written assurances | Evidence of configuration and patch state |
| How exposed are we? | Single-supplier risk noted in the register | Concentration mapped across the sector |
The right-hand column costs more and is the only one that keeps passengers moving. Supply chain patterns of this kind appear in when a supplier failure becomes your incident.
The striking feature of this incident is not that one vendor was compromised. It is how many organisations that single compromise stopped.
Sector exposure of this kind is examined in cybersecurity in the financial sector, where the same concentration pattern appears. Shared platforms deliver real efficiency. Common-use check-in lets airlines share desks and gates instead of building parallel infrastructure, which is why the model spread.
The cost appears only in failure. When several competing organisations depend on one provider, a single incident becomes a sector event, and no individual customer’s risk register captures that. Each airport assessed its own vendor exposure. None of them owned the concentration.
Regulators are moving on this. NIS2 pushes supply chain security obligations onto essential and important entities across the EU, and DORA imposes parallel duties on the financial sector for critical ICT providers. Both require looking at dependencies rather than at contracts.
Written assurances are the easiest thing to obtain and the least useful. Six questions produce answers that matter.
Question 3 is the one most often skipped, and the one that would have surfaced this risk beforehand.
Contracts do not run during an outage. People do, and the manual fallback that airports invoked worked precisely because staff knew it existed.
Three things are worth rehearsing rather than documenting. The decision to invoke fallback, including who makes it and how quickly. The manual process itself, with people who have actually performed it. And the communication path to customers, which is where reputational damage gets decided.
There is also a human-layer exposure inside vendor risk that audits miss entirely. You can review a supplier’s certifications. You cannot audit their employees’ susceptibility to the social engineering that frequently opens these intrusions.
Threatcop’s TPIR shortens the reporting path on your own side, so a member of staff who notices something unusual reaches an analyst quickly rather than filing a ticket. Reporting culture sits in why employees stay silent about mistakes.
Vendor risk registers usually record assurance. These record exposure.
The last is the number a board grasps immediately. If the answer is four hours and a vendor incident runs four days, that gap is the risk.
Pick the supplier whose failure would stop your operations fastest, then ask how many other customers run on the same instance. Most contracts do not say, and most relationship managers have never been asked.
Next, check when you last ran the manual fallback with real staff rather than reviewing the document. If the answer is never, the plan is a description rather than a capability.
Finally, make it easy for your own people to raise something unusual, because in a vendor incident your staff often notice the symptoms before the supplier’s notification arrives.
On the evening of 19 September 2025, ransomware affected systems supporting Collins Aerospace’s ARINC vMUSE check-in platform, used by airlines to share desks and boarding gates. Automated passenger processing stopped at Heathrow, Brussels, Berlin Brandenburg, and Dublin, forcing manual check-in and causing hundreds of delays and cancellations across the weekend.
No. ENISA confirmed that ransomware caused the disruption, and RTX confirmed a ransomware incident in an SEC filing, but the specific family was never officially established. Researchers pointed to HardBit while other reporting suggested Loki. The UK National Crime Agency arrested a man in West Sussex under the Computer Misuse Act and later released him on conditional bail.
Because insurance transfers financial loss rather than operational disruption, and attackers may factor it in. HardBit became notable for pegging ransom demands to a victim’s cyber-insurance limits, which makes coverage an input to the attacker’s pricing rather than a defence. Insurance also cannot restore a service your customers depend on.
Move from assurance to evidence. Verify that the system you depend on falls inside the vendor’s certification scope, ask for patch state rather than policy, establish how many customers share the same platform instance, confirm when recovery was last tested, and rehearse your own manual fallback with the people who would run it.
Concentration risk arises when many organisations, often competitors, depend on one provider for a critical function. Each customer’s risk register records a single vendor relationship, while none captures that one incident becomes a sector-wide event. The September 2025 airport disruption illustrates it, since no individual airport was breached.
Pallavi Verma is a Partner Success Specialist at Threatcop, helping organizations strengthen their People Security Management programs. She works closely with clients and partners to reduce human-layer risk, improve security awareness, and ensure employees are equipped to make safer decisions every day. Pallavi is passionate about making cybersecurity practical, measurable, and people-friendly
Over 90% of employees who took unsafe actions knew the risk. See why the awareness-action gap is a design...
AI writes half of all code and fails security tests 44% of the time. See the failure profile, why...
AI-to-AI communication already runs on MCP and A2A, and neither mandates an audit trail. See how each fails, and...
