--- title: "Un ciberataque a Collins expone la fragilidad del check-in automático en Europa: retrasos, cancelaciones y vuelta al papel" description: "Europa ha pasado el fin de semana contando colas, maletas y minutos. Un “incidente de ciberseguridad” en Collins Aerospace —proveedor clave de los sistemas automáticos de check-in y embarque— dejó fue..." url: https://revistacloud.com/un-ciberataque-a-collins-expone-la-fragilidad-del-check-in-automatico-en-europa-retrasos-cancelaciones-y-vuelta-al-papel/ date: 2025-09-22 modified: 2025-09-22 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2023/10/aeropuerto-espera-conectividad-unsplash.jpg categories: ["Noticias", "Seguridad"] tags: ["aeropuerto", "ciberataque"] type: post lang: es --- # Un ciberataque a Collins expone la fragilidad del check-in automático en Europa: retrasos, cancelaciones y vuelta al papel Europa ha pasado el fin de semana contando colas, maletas y minutos. Un “incidente de ciberseguridad” en **Collins Aerospace** —proveedor clave de los sistemas automáticos de **check-in** y embarque— dejó fuera de combate a **cMUSE**, su plataforma de uso común en la nube, y obligó a **desconectar quioscos**, **imprimir tarjetas a mano** y **recurrir a portátiles de respaldo** en varios de los principales aeropuertos del continente. La avería, convertida en **punto único de fallo**, encadenó **retrasos y cancelaciones** desde el viernes y seguía afectando a la operación el lunes, con especial incidencia en **Bruselas**, **Berlín** y **Londres-Heathrow**. El episodio llega a pocas semanas de que entre en vigor **NIS2**, la directiva europea que amplía el perímetro de “infraestructura crítica” a los **proveedores de TI** que sostienen servicios esenciales, justo el tipo de actor que ha fallado. --- ## Qué es cMUSE (y por qué su caída paraliza medio aeropuerto) El software afectado es **cMUSE**, la plataforma **common-use** de Collins que permite a **aerolíneas y aeropuertos** **compartir** los mismos **mostradores**, **quioscos** y **puertas de embarque** a través de un **backend centralizado**. En palabras del propio proveedor, cMUSE ofrece: - **Puestos de agente web**, - **flotas de quioscos**, - **puntos móviles de *check-in*** …todos **gestionados desde un plano de control común**. El enfoque **abarata costes**, **agiliza actualizaciones** y simplifica integraciones con los **DCS** (sistemas de control de salidas) de las aerolíneas. El reverso de la moneda es evidente: **si ese control central se apaga, todo el frente de *check-in* se resiente**. Y no sólo los mostradores: **impresoras de etiquetas**, **lectores biométricos** o **escáneres** suelen integrarse **directamente** con MUSE, por lo que tampoco son inmunes. Collins ha confirmado que se trató de un **“incidente relacionado con ciberseguridad”**, sin precisar el vector técnico. El síntoma operativo sí quedó claro: **caída del backend** y **pérdida de funcionalidad** en **quioscos y *workstations***, con aerolíneas y aeropuertos **regresando a procesos manuales** para sostener la operación. --- ## Cronología operativa: del viernes negro al lunes de recuperación desigual - **Viernes**: la interrupción golpea **grandes hubs europeos**. **Heathrow**, **Berlín** y **Bruselas** figuran entre los afectados, mientras otros aeropuertos del continente reportan **funcionamiento normal**. - **Fin de semana**: **Berlín** y **Heathrow** informan de **mejoría notable** el domingo, tras el despliegue de **medidas manuales** y **parches**. - **Lunes**: persisten **retrasos y cancelaciones** en varios puntos. - **Bruselas** es el **más castigado**: el domingo pidió a las aerolíneas **cancelar casi 140 salidas** del lunes ante la falta de una **versión segura** del sistema. A media mañana, el aeropuerto acumula **en torno a 60 vuelos cancelados**, con **Brussels Airlines** como la **más afectada** y *check-in* y embarque **sólo en modo manual**. **EasyJet** y **Vueling** suman **seis cancelaciones cada una**. - **Berlín** advierte de **largas esperas** y **demoras de alrededor de una hora** en salidas, agravadas por el **tirón de pasajeros** del **Maratón de Berlín**. - **Heathrow** mantiene un mensaje de **recuperación gradual**: “la **gran mayoría de vuelos** ha seguido operando”, pero se **pide comprobar el estado** antes de viajar y **no llegar** con más de **3 horas** para **larga distancia** o **2 horas** para **corto radio**. - **Dublín (T2)** alerta de **tiempos adicionales** en *check-in* y *bag drop* porque algunas aerolíneas continúan con **soluciones manuales**; **T1** opera con normalidad. En paralelo, Collins comunicó el lunes por la mañana que estaba en las **últimas fases de actualización** para **rectificar** el problema. --- ## Manual es igual a resiliente… pero no es “fallo elegante” Las **colas con formularios** y **tarjetas manuscritas** salvaron el fin de semana. Pero, como admite el personal de tierra, el **plan de contingencia** ha funcionado **por el músculo humano**, **no** porque los sistemas **fallaran con gracia**. En un entorno tan acoplado como el **proceso aeroportuario** —*check-in*, **etiquetado de equipaje**, **seguridad**, **embarque**, **conexión a DCS**—, **cada segundo** que el **backend** no responde **se multiplica** en ventanillas, cintas y puertas. **Las *apps* en la nube son flexibles**; **los cuellos de botella operativos, no**. El episodio ha dejado tres lecciones operativas: 1. **SPOF (Single Point Of Failure)**. Centralizar **datos y lógica** simplifica la vida… hasta que **uno** cae y **todo** cae. 2. ***Graceful degradation*** insuficiente. **Las alternativas** deberían **desengancharse** del backend central para **emitir tarjetas**, **etiquetas** y **embarcar** con **datos en *cache*** cuando sea seguro hacerlo. 3. **Capilaridad de la dependencia**. No sólo se pierde el quiosco: **impresoras**, **lectores** y **biometría** integrados con MUSE **también** sufren, encadenando la interrupción. --- ## Un contexto regulatorio que aprieta: NIS2 y EASA Part-IS El calendario no es casual. En **octubre** entra en vigor **NIS2**, la directiva europea que **amplía** la “infraestructura crítica” para abarcar **proveedores de TI** que prestan **servicios esenciales** a sectores como **aviación**. En paralelo, las **Part-IS** de **EASA** buscan trasladar prácticas **“aviation-grade”** de ciberseguridad —**gestión de riesgos**, **reporting**, **continuidad** y **seguridad de *supply chain***— a **plataformas compartidas**: **equipaje**, **check-in**, ***common use* en tierra**. ¿Qué implica esto para incidentes como el de cMUSE? - **Obligaciones de notificación** y **técnicas** más duras para **proveedores** (no sólo aerolíneas/aeropuertos). - **Evaluación de riesgos** que contemple **fallos de terceros** como **riesgo sistémico**. - **Planes de continuidad y recuperación** que **no dependan** de una única pieza en la nube. La **letra pequeña** de NIS2 y Part-IS encaja en el mapa del fin de semana: **fallo de un proveedor esencial** + **impacto paneuropeo** + **contingencia manual** = **resiliencia insuficiente**. --- ## Lo que sabemos (y lo que no) del ataque - **Confirmado**: Collins habla de **“incidente ciber-relacionado”**. - **No divulgado**: tipo de ataque, alcance en **infraestructura cMUSE** (nube y/o despliegues *on-prem*), número de **enlaces DCS** afectados, y si hubo **acceso o alteración de datos**. - **Constatado**: **interrupción** de la **capa de control** y **degradación** de **quioscos** y **puestos de agente**, con **interdependencias** en **impresoras** y **biometría**. - **Resultado operativo**: **vuelta al papel**, **ordenadores de respaldo** y **ajustes de slots** para sostener horarios. --- ## Qué pueden hacer (hoy) operadores y aerolíneas 1. **Reforzar escenarios de *graceful fail*** - **Impresión local** de tarjetas y etiquetas con **datos en *cache*** y **reconciliación posterior**. - **Embarque offline seguro**, con listas **sincronizadas** cuando vuelva la conectividad. - ***Bypass* local** para *bag drop* y biometría, con pistas de auditoría. 2. **Acordar RTO/RPO realistas con proveedores** - **Objetivos de recuperación** por **función** (quioscos, agentes, *self-bag drop*). - **Ensayos** que no se queden en papel: **simulacros** regulares de **corte de backend**. 3. **Reducir el SPOF** - **Arquitectura híbrida**: *on-prem* para funciones críticas + **nube** para elasticidad. - **Redundancias cruzadas** (regionales/proveedoras) donde los contratos lo permitan. 4. **Segmentación y mínimos privilegios** - Que un incidente en **plataforma común** no **arrastre** a **otros subsistemas** (equipaje, pasarelas, etc.). - **Telemetría y *rate-limits*** sobre integraciones DCS. 5. **Comunicación al pasajero** - **Mensajes proactivos**: *“llegue con X horas / haga check-in online / confirme vuelo antes de salir”*. - **Refuerzo de personal** en mostradores y **prioridad** a conexiones críticas. --- ## Impacto por aeropuerto (lo que trasladaron al público) - **Bruselas**: pidió **cancelar casi 140 salidas** del lunes el día previo; a primera hora acumulaba **~60 cancelaciones** y **operación manual** en varias aerolíneas, con **Brussels Airlines** como **principal afectada**. Mensaje a pasajeros: **comprueben su vuelo**, **acudan sólo si está confirmado** y **realicen *check-in* online**. - **Berlín-Brandenburgo**: “**por una caída en un proveedor** hay **mayores esperas**; usen **check-in online**, **quioscos** y ***fast bag drop***”. **Demoras promedio** en salidas de **~1 hora** con el **Maratón de Berlín** elevando la demanda. - **Londres-Heathrow**: “**la gran mayoría de vuelos ha seguido operando**; seguimos **resolviendo** y **recuperando**”. Recomendación: **verificar estado** antes de viajar y **no llegar** con más de **3 horas** (larga distancia) o **2 horas** (corto radio). - **Dublín (T2)**: algunas compañías **siguen con *workarounds* manuales**, por lo que *check-in* y *bag drop* **tardan más**; **T1** con **operativa normal**. Llegar con **2 horas** para corto y **3 horas** para largo; **añadir margen** si se **factura en T2**. --- ## ¿Incidente aislado o síntoma de una arquitectura frágil? El caso cMUSE no es el primer aviso. La **transformación digital** ha empujado a la **centralización** por **eficiencia**: un **backend en la nube** que todo lo orquesta. La **aviación** no es ajena a esta tendencia. El problema es que, sin **diseño de resiliencia**, una mejora en **coste** y **operación** se convierte en **fragilidad** sistémica. **Tres ideas** para el debate: - **Elasticidad ≠ resiliencia**: escalar estaciones web es útil, pero **degradar con seguridad** cuando la capa central cae **es igual de esencial**. - **Capas locales con autonomía**: **quioscos, impresoras y validadores** deberían operar en **modo degradado** **sin** dependencia constante del **control central**. - ***Supply-chain* como superficie de ataque**: NIS2 recordará que **el eslabón débil puede ser el proveedor**; hay que **auditar** y **ensayar** también **hacia fuera**. --- ## La respuesta de Collins y el día después Collins indicó el lunes que estaba en las **últimas fases** de las **actualizaciones** para **rectificar** el problema. La industria aguardará detalles técnicos que ayuden a **extraer lecciones**: vector, alcance (*cloud*/*on-prem*), medidas de **contención**, **teles de seguridad** activadas y **fechas** de **parches** de endurecimiento. Las autoridades —en el marco de **NIS2**— exigirán **claridad** en la **notificación**, **acciones correctoras** y **planes** para no repetir el patrón. --- ## Mensaje al pasajero: qué hacer si aún toca volar - **Revise el estado** de su vuelo en la **web/app** de su aerolínea o en el **aeropuerto** **antes** de salir de casa. - **Haga *check-in* online** y **lleve la tarjeta en el móvil** (y, si puede, **impresa** como respaldo). - **Vaya con tiempo**: - Heathrow: **máximo 3 horas** (larga) y **2 horas** (corta), **no antes**. - Berlín: **prevea esperas** de **~1 hora** en salidas. - Dublín T2: **añada margen** para *check-in/bag drop*. - **Equipaje**: si hay **autoentrega**, siga las indicaciones; si no, **prepare documentación** y **etiquetas** cuando se lo pidan. - **Paciencia**: parte del proceso **puede ser manual**; el personal en tierra está **sosteniendo** la operación de forma extraordinaria. --- ## Conclusión: una tormenta que acelera la agenda de ciberresiliencia El **ciberataque a Collins** no ha parado Europa, pero ha **estirado** la cuerda operativa y ha **expuesto** una **debilidad estructural**: **demasiado depende de un backend único**. La **recuperación** ha sido posible por el **oficio** de miles de profesionales en tierra… y por **papel y bolígrafo**. A corto plazo, el sector **parcheará**; a medio, **NIS2** y **EASA Part-IS** obligarán a **repensar** *fallbacks*, **contratos**, **ensayos** y **arquitecturas híbridas**. El pasajero querrá explicaciones; la industria, garantías. Y la próxima vez, cuando el control común vuelva a temblar, la operación debería **degradar con elegancia**, no **caer al vacío**. --- ## Preguntas frecuentes **¿Qué es cMUSE y por qué su fallo provoca largas colas?** **cMUSE** es la plataforma **common-use** de **Collins Aerospace** que **centraliza** *check-in*, **quioscos** y **embarque** para varias aerolíneas en un aeropuerto. Al **caer** su **backend**, **estaciones web** y **quioscos** dejaron de funcionar con normalidad y hubo que **pasar a procesos manuales**, ralentizando la operativa. **¿Qué aeropuertos siguen afectados y qué medidas recomiendan?** El lunes, **Bruselas** fue el **más impactado** (solicitó **cancelar casi 140 salidas** el día previo y acumulaba **~60 cancelaciones**). **Berlín** avisó de **esperas** y **demoras** de **~1 hora**; **Heathrow** mantuvo la **mayoría de vuelos** con **recuperación gradual**; **Dublín T2** pidió **tiempo extra** en *check-in/bag drop*. Todos recomiendan **verificar el estado del vuelo** y **hacer *check-in* online**. **¿Ha sido un ciberataque confirmado? ¿Hubo robo de datos?** Collins lo calificó de **“incidente ciber-relacionado”** y comunicó que estaba en las **últimas fases** de actualización para **rectificar**. **No** se ha divulgado públicamente **el vector** ni **indicios de exfiltración**; las investigaciones determinarán **alcance y medidas**. **¿Qué cambia con NIS2 para estos proveedores?** **NIS2** (octubre) **amplía** el concepto de **infraestructura crítica** a **proveedores de TI** que sostienen servicios esenciales. Impone **obligaciones** de **gestión de riesgos**, **notificación de incidentes** y **continuidad**. En aviación, casa con **EASA Part-IS**, que exige **ciberseguridad “de grado aeronáutico”** en **plataformas compartidas** como los **sistemas *common-use***. **¿Cómo puede un aeropuerto reducir la dependencia de un único backend?** Con **arquitecturas híbridas** (funciones críticas *on-prem* + elasticidad en la nube), **modos degradados** (*check-in* y embarque **offline seguros**), **redundancias regionales/proveedoras**, **segmentación** de subsistemas y **ensayos periódicos** de RTO/RPO. Todo ello debe reflejarse en **contratos** y **acuerdos de nivel de servicio** con proveedores. vía: [euronews](https://www.euronews.com/travel/2025/09/22/european-airports-face-fourth-day-of-disruption-on-monday-after-weekend-cyberattack)