The airport was open. Check-in was not.

What happened

CERT-EU’s September 2025 brief describes a cyberattack affecting Collins Aerospace’s MUSE system, disrupting electronic check-in and baggage drop at Brussels, Heathrow and Berlin. Airports switched to manual processes. The UK National Crime Agency said the incident was reported on 19 September.

A manual fallback has a capacity of its own

A process can remain available while delivering much less than its usual throughput. Consider an illustrative airport team opening manual desks during a supplier outage. The relevant question is how many passengers can be handled with the staff, documents and equipment actually available. That needs a local operational assessment. It cannot be read directly from a supplier’s technical status or assumed from the fact that one desk has started working.

The resulting picture may differ by airline, terminal and stage of the journey. A queue report, an updated staffing decision and a flight-handling change describe related consequences rather than identical failures. Each needs an owner and a current observation time. When a fallback changes, partners need to know what has been confirmed and what remains provisional. The purpose of sharing that information is to support consistent decisions, without taking over the airport’s existing safety or passenger-processing systems.

One dependency, many operational consequences

The visible problem was at the desk. The operational problem extended to queues, staff assignments, flight decisions and passenger information. A supplier can work on recovery while each airport still has to decide what it can safely deliver now. The two conversations must stay connected.

This is a lesson about dependencies, not evidence that every airport system was compromised. Nor does the use of a manual process tell the crisis team how much capacity remains. That needs confirmation from the teams running it.

What the crisis room needs to know

• Which service is affected. Relate the supplier notice to the desks, processes and teams that depend on it.
• What still works. Ask operational owners to confirm fallback capacity and limitations, with a time for the next update.
• Who decides. Keep the technical recovery owner distinct from the person responsible for operational changes and passenger communication.
• What changed. Record decisions and updates on the same timeline. An old status should not circulate as a new confirmation.

With one shared picture

An illustrative Meridian workspace would put the supplier update beside verified local reports and assigned actions. It would support coordination between the airport and its authorised partners. It would not restore the compromised service, process passenger check-in or guarantee that a fallback has enough capacity.

Turn the supplier update into local questions

A dependency register is useful when it relates a named service to the processes that use it and the people who can verify their condition. If a supplier reports a partial restoration, an operational owner can check which local function is being discussed, whether a test is permitted and who must confirm the result. The original notice remains alongside that assessment. A general message should not silently become a claim that every affected function has recovered.

Imagine a terminal coordinator assigning a verification task to a participating airline, recording an agreed limitation and setting the next review time. Another partner sees the same update but only the information they are authorised to use. If local testing contradicts the supplier notice, the difference is retained for follow-up. Optional AI summaries could help navigate the incident messages, but decisions must remain grounded in the underlying reports. This workflow is an illustrative project scope, not a claim about the systems used in the September incident.

Recovery needs confirmation and an exercised handover

A focused Meridian pilot could use approved example notices, a limited dependency map and operational reports from a small set of teams. One exercise would follow an outage into a manual fallback. A second would introduce partial restoration and ask who can authorise the return to the normal process. Reviewers should be able to trace the decision, its supporting evidence and any remaining limitation without reconstructing separate conversations.

Acceptance should also test a delayed update, a shift change and loss of the coordination channel itself. Access enforcement, retention and audit requirements must be agreed and demonstrated. An operator-controlled deployment can help establish where the shared information is processed and maintained, but hosting location alone does not remove supplier dependence. The service still needs technical recovery, local verification and clear responsibility. The value of a common picture is that these different activities can be coordinated while their owners remain accountable for the decisions they make.

A supplier outage is not resolved for the operator when a status page turns green. The people running the service must confirm that operations can resume.