Mantenimiento de productos sanitarios conectados

Los servicios de ingeniería clínica planifican tradicionalmente el mantenimiento en función de los plazos de verificación, las indicaciones del fabricante y los costes de las averías. Para los equipos conectados ya no basta: un ecógrafo, un monitor de paciente o una bomba de infusión con conexión a la red contienen un sistema operativo, bibliotecas e interfaces cuya situación de seguridad cambia a diario, incluso cuando en el propio equipo no ocurre nada. Por eso, un equipo que supera todas las pruebas de seguridad eléctrica puede ser, al mismo tiempo, una puerta de entrada abierta.

El estudio ManiMed del BSI demostró hasta qué punto el problema es real: la Oficina Federal de Seguridad de la Información analizó diez productos sanitarios con capacidad de red de cinco categorías y, a lo largo del proyecto, notificó a los fabricantes más de 150 vulnerabilidades. El informe final se publicó en diciembre de 2020.

Qué significa la ciberresiliencia en la operación

La ciberresiliencia es la capacidad de seguir operando un equipo de forma segura pese a nuevas vulnerabilidades y ataques, o de restringir su uso de forma justificada. De ahí se derivan tareas que se suman al plan de mantenimiento:

• un inventario actualizado de todos los equipos, versiones de software y componentes de terceros,
• un panorama continuo de las nuevas vulnerabilidades y de los ataques activos,
• una evaluación que relacione la gravedad técnica con las consecuencias clínicas,
• actualizaciones y medidas alternativas tratadas como cambios documentados y aprobados,
• un canal para los avisos de vulnerabilidades procedentes del exterior,
• monitorización, gestión de incidentes y notificaciones en plazo.

Esta página resume el artículo técnico «Instandhaltung vernetzter Medizinprodukte» (mantenimiento de productos sanitarios conectados), publicado en alemán en mt|medizintechnik, número 4.2026, lo reorganiza y lo completa con la evolución hasta octubre de 2026.

Además de la confidencialidad, la integridad y la disponibilidad, en los productos sanitarios se plantea una cuarta pregunta: ¿puede un ataque afectar al funcionamiento previsto o causar daños a las personas? La guía MDCG 2019-16 subraya que, en los productos sanitarios, los riesgos de security no pueden analizarse al margen de los riesgos de safety.

Cómo una brecha informática se convierte en un riesgo clínico

• Integridad: valores medidos, imágenes o informes manipulados conducen a diagnósticos erróneos.
• Disponibilidad: un sistema cifrado por un atacante o caído retrasa exploraciones o intervenciones.
• Control: quien puede modificar parámetros terapéuticos o de alarma interviene directamente en el tratamiento.
• Confidencialidad: la fuga de datos de salud afecta a la protección de datos y a la confianza de los pacientes.

De ello se deriva una regla central para la evaluación en campo: la gravedad técnica por sí sola no determina la urgencia; lo decisivo es lo que un atacante podría provocar en el equipo concreto y en el proceso asistencial concreto.

Dos análisis de riesgos, un resultado

Los fabricantes gestionan sus riesgos conforme a ISO 14971, armonizada bajo el MDR como EN ISO 14971. Los riesgos de security suelen evaluarse en un análisis propio. Lo decisivo es la conexión entre ambos: todo escenario de security con posibles efectos sobre pacientes o usuarios debe figurar en el archivo de gestión del riesgo de safety, y toda medida de safety que dependa del software necesita un análisis de security. En campo, esta comprobación se repite con cada nueva vulnerabilidad y cada incidente, incluida la pregunta de si debe reevaluarse la relación beneficio-riesgo.

MDR: obligaciones del fabricante

El MDR se aplica desde el 26 de mayo de 2021. Exige software conforme al estado de la técnica, con una gestión de riesgos que incluya la seguridad de la información, protección contra el acceso no autorizado y requisitos mínimos para las redes informáticas en las instrucciones de uso. Tras la introducción en el mercado, los fabricantes mantienen un sistema de seguimiento poscomercialización (Post-Market Surveillance, PMS). A partir de la clase IIa, este incluye un informe periódico de seguridad actualizado (Periodic Safety Update Report, PSUR): al menos una vez al año para las clases IIb y III, y al menos cada dos años para la clase IIa.

MDCG 2019-16: responsabilidad conjunta

La guía MDCG 2019-16, en su revisión de julio de 2020, traslada estos requisitos a todo el ciclo de vida. Aclara que la ciberseguridad forma parte del sistema de PMS y que abarca también los componentes de terceros. Al mismo tiempo, describe una responsabilidad conjunta: jurídicamente, el obligado es el fabricante; en la práctica, también proveedores, integradores, centros sanitarios y autoridades asumen responsabilidades. Las modificaciones del equipo, incluidos parches y software de terceros, solo están previstas sobre la base de instrucciones expresas y publicadas del fabricante.

Normas como estado de la técnica

Reglamento alemán de operadores: las actualizaciones son mantenimiento

Para los operadores en Alemania, el reglamento sobre operadores de productos sanitarios (Medizinprodukte-Betreiberverordnung, MPBetreibV), vigente en su nueva versión desde el 20 de febrero de 2025, concreta qué abarca el mantenimiento: además del mantenimiento preventivo, la inspección y la reparación, en el caso del software incluye expresamente la instalación de actualizaciones relevantes para la seguridad, conforme a las indicaciones del fabricante. Si una actualización modifica sustancialmente el manejo, el personal debe recibir nuevas instrucciones. Para el software clasificado como producto sanitario de las clases IIb o III, el reglamento exige además a los centros sanitarios, desde el 1 de agosto de 2025, verificaciones de seguridad informática conforme a las reglas técnicas reconocidas, como máximo cada dos años y con acta.

Ley BSI: obligaciones del hospital

Desde el 6 de diciembre de 2025, la nueva ley BSI (BSIG) transpone en Alemania la Directiva NIS2. Los hospitales pertenecen al sector sanitario. Por regla general, quedan sujetas las entidades a partir de 50 empleados o con más de 10 millones de euros de volumen de negocio y de balance; a partir de 250 empleados, o de más de 50 millones de euros de volumen de negocio y 43 millones de euros de balance, se consideran entidades particularmente importantes, y los hospitales con una instalación crítica —hasta ahora, a partir de 30.000 casos de hospitalización completa al año— lo son con independencia de su tamaño. Entre las obligaciones figuran expresamente la seguridad en la adquisición, el desarrollo y el mantenimiento, incluidas la gestión y la divulgación de vulnerabilidades, así como la seguridad de la cadena de suministro.

El Cyber Resilience Act y la FDA en el entorno

El Cyber Resilience Act (CRA) no se aplica a los productos sujetos al MDR o al IVDR. Aun así, repercute en la tecnología sanitaria: los proveedores que comercializan por separado componentes con elementos digitales están sujetos a sus obligaciones de notificación desde el 11 de septiembre de 2026 y a las obligaciones principales a partir del 11 de diciembre de 2027. A escala internacional, la FDA, la agencia estadounidense del medicamento, marca la pauta: para los llamados cyber devices exige en las solicitudes de comercialización, desde el 29 de marzo de 2023, entre otras cosas una SBOM, un plan de gestión de vulnerabilidades con divulgación coordinada y actualizaciones con una periodicidad justificada.

El día en que se publicó Log4Shell, el 10 de diciembre de 2021, muchas organizaciones se hicieron la misma pregunta: ¿en qué productos está la biblioteca afectada? En los productos sanitarios, esta incertidumbre es especialmente delicada, porque por regla general los hospitales no pueden escanear ni modificar los equipos por su cuenta si el fabricante no lo prevé.

Qué aporta una SBOM

La lista de materiales de software (Software Bill of Materials, SBOM) enumera en formato legible por máquina los componentes de software de un producto, con su denominación, versión, proveedor, suma de comprobación y dependencias. Se han impuesto dos formatos: CycloneDX, normalizado desde junio de 2024 como ECMA-424, y SPDX, cuya versión 2.2.1 está normalizada como ISO/IEC 5962:2021. En Alemania, la directriz técnica TR-03183-2 del BSI describe qué contenido mínimo debería tener una SBOM.

¿Obligación o expectativa?

En Estados Unidos, la SBOM forma parte de la solicitud de comercialización de los cyber devices. El derecho europeo de productos sanitarios no contempla una obligación expresa de SBOM; MDCG 2019-16 menciona la lista de materiales como ejemplo de información de seguridad para los operadores. En Europa, la expectativa se deriva del estado de la técnica según la IEC 81001-5-1. Para los componentes de proveedores sujetos al Cyber Resilience Act, la SBOM será obligatoria como parte de la documentación técnica a partir del 11 de diciembre de 2027.

De la lista al panorama de riesgos

Una SBOM solo es eficaz cuando el fabricante la genera de nuevo con cada compilación y la contrasta continuamente con datos de vulnerabilidades. Como una biblioteca vulnerable no implica automáticamente un equipo vulnerable, el fabricante añade declaraciones sobre la afectación real (Vulnerability Exploitability eXchange, VEX). Estos avisos se intercambian en formato legible por máquina en el Common Security Advisory Framework (CSAF), estándar de OASIS en su versión 2.0 desde noviembre de 2022.

Qué deberían fijar los hospitales en las compras

• entrega de una SBOM legible por máquina con el equipo y actualización con cada versión de software,
• avisos de seguridad y declaraciones VEX a través de un canal fijo, preferiblemente en formato CSAF,
• información sobre el periodo de soporte de las actualizaciones de seguridad y sobre su forma de entrega,
• el formulario MDS2 cumplimentado y los requisitos mínimos del entorno de red,
• una persona de contacto designada para cuestiones de seguridad e incidentes.

Riesgos más allá del código propio

Ataques a la cadena de suministro como el sufrido por SolarWinds Orion a finales de 2020 o la puerta trasera en XZ Utils en marzo de 2024 muestran cómo el código malicioso penetra a través de fuentes de confianza. Las contramedidas son compilaciones verificables, artefactos firmados, pruebas de procedencia y dependencias elegidas con moderación; Supply-chain Levels for Software Artifacts (SLSA), actualmente en su versión 1.2, ofrece un marco escalonado.

Fuentes para el panorama de riesgos

• avisos de seguridad de los fabricantes de equipos y de los proveedores de componentes, idealmente en formato CSAF legible por máquina,
• el servicio de alertas e información de CERT-Bund, en el BSI,
• el catálogo Known Exploited Vulnerabilities (KEV) de la agencia estadounidense CISA,
• el intercambio en Health-ISAC, la red internacional de intercambio de información del sector sanitario,
• hallazgos propios procedentes de la monitorización de la red, los registros y los incidentes.

Tres señales técnicas

La clasificación técnica se apoya en tres señales: CVSS, en su versión 4.0 desde noviembre de 2023, para la gravedad; EPSS, para la previsión, actualizada a diario, de una explotación en los próximos 30 días; y el catálogo KEV, mantenido desde noviembre de 2021, para los ataques comprobados.

Las preguntas clínicas

• Accesibilidad: ¿se puede llegar al equipo desde la red del hospital, desde accesos de mantenimiento remoto o incluso desde internet?
• Contexto clínico: ¿controla o supervisa una terapia, genera resultados diagnósticos, está conectado al paciente?
• Consecuencias de una manipulación: ¿qué efecto tendría una pérdida de integridad o de disponibilidad sobre el diagnóstico y el tratamiento?
• Medidas de protección: ¿funcionan ya de forma demostrable la segmentación, las restricciones de acceso o la monitorización?
• Declaración del fabricante: ¿confirma una declaración VEX la afectación, o el componente no es accesible?

Clases de prioridad como lenguaje común

Fabricantes y hospitales se benefician de unas pocas clases de prioridad claramente descritas. La siguiente clasificación es una propuesta; cada organización fija los tiempos de respuesta concretos en función del producto.

Hay dos extremos arriesgados: instalar por reflejo cualquier actualización disponible o no tocar nunca la tecnología sanitaria. MDCG 2019-16 espera que los operadores dispongan de procesos de gestión de parches que permitan desplegar a tiempo las actualizaciones relevantes para la seguridad, y que el entorno operativo admita actualizaciones sin pérdida de compatibilidad. La guía prevé expresamente que las actualizaciones también se pongan a disposición fuera de una acción correctiva de seguridad en campo.

Del aviso a la actualización documentada

1. 1
   Determinar la afectación

   Contrastar el aviso con la SBOM, el inventario de equipos y las declaraciones VEX: ¿qué equipos, versiones de software y ubicaciones están realmente afectados?

2. 2
   Evaluar y clasificar

   Reunir las señales técnicas, el contexto clínico y las medidas de protección existentes, fijar la clase de prioridad y documentar la relación con la safety.

3. 3
   Elegir la medida

   Actualización, cambio de configuración o medida alternativa, como segmentación, bastionado, monitorización reforzada o restricción de uso, de acuerdo con las indicaciones del fabricante.

4. 4
   Probar y aprobar

   El fabricante verifica y valida la actualización; el hospital la prueba en un entorno próximo al real con sus interfaces y la aprueba según criterios definidos.

5. 5
   Desplegar de forma escalonada

   Primero los equipos piloto y después la flota, en ventanas de mantenimiento acordadas y con una vuelta atrás preparada en caso de fallos.

6. 6
   Verificar y documentar

   Comprobar el estado de instalación, confirmar el funcionamiento, registrar el riesgo residual y actualizar el inventario, la SBOM y el archivo de gestión del riesgo.

Las medidas alternativas se evalúan, aprueban, limitan en el tiempo y revisan igual que un parche. Desde el punto de vista del MDR, lo que cuenta es la evidencia de que una decisión se fundamentó, se probó y se documentó junto con su riesgo residual, no solo la instalación.

Actualizaciones a través de la red (OTA)

Las actualizaciones Over-the-Air llevan las correcciones más rápido a muchos equipos, pero crean un riesgo de concentración: en el peor de los casos, un paquete defectuoso o manipulado llega a toda la flota. La arquitectura de actualización de firmware del IETF, descrita en la RFC 9019 de abril de 2021, enumera los principios fundamentales:

• un manifiesto firmado que describe el origen, la compatibilidad y las sumas de comprobación del paquete,
• la verificación de la autenticidad y la integridad antes de la instalación y de nuevo en el arranque, mediante un cargador de arranque con ancla de confianza (Secure Boot),
• una imagen de recuperación en un área de memoria separada (principio A/B), para que una actualización fallida no inutilice el equipo,
• una protección contra downgrades mediante números de secuencia, para que los atacantes no puedan instalar una versión anterior vulnerable pero con firma válida,
• robustez frente a cortes de corriente o interrupciones de la conexión.

La imagen de recuperación y la protección contra downgrades resuelven problemas distintos: la primera garantiza la disponibilidad; la segunda impide un ataque. A ello se suman la transmisión cifrada, las oleadas de despliegue escalonadas y la telemetría sobre la tasa de éxito y, en el entorno clínico, además, ventanas de mantenimiento acordadas e información clara a los usuarios. Si una actualización modifica sustancialmente las características de seguridad o de funcionamiento, según la clasificación puede ser necesaria una nueva evaluación con participación del organismo notificado.

Preparados para el zero-day

Se considera zero-day una vulnerabilidad para la que no hay parche disponible en el momento en que se da a conocer. En los productos sanitarios, la situación es especialmente difícil: el equipo debe seguir prestando asistencia, falta una actualización aprobada y el hospital no puede intervenir por su cuenta. Han dado buenos resultados cuatro precauciones:

• una vía de escalado documentada que establezca quién decide en las primeras horas: responsables de producto, seguridad, TI hospitalaria, ingeniería clínica y asuntos regulatorios,
• medidas inmediatas acordadas de antemano, como la desconexión de la red, la desactivación de servicios innecesarios y la monitorización específica de indicios de ataque,
• configuraciones alternativas preparadas y validadas clínicamente para las clases de equipos críticas para la seguridad,
• plantillas de notas de seguridad para los usuarios (Field Safety Notice), técnicamente correctas y comprensibles desde el punto de vista clínico.

Según el MDR, una acción correctiva de seguridad en campo (Field Safety Corrective Action) debe notificarse, por regla general, a la autoridad antes de llevarla a cabo; solo en casos urgentes puede notificarse después. Si una vulnerabilidad ya se está explotando activamente, la situación se agrava aún más, tanto en lo técnico como en lo regulatorio.

Coordinated Vulnerability Disclosure

Muchas vulnerabilidades las descubren investigadores, pentesters, integradores o usuarios. Sin una vía de notificación visible, estos avisos quedan sin atender o se hacen públicos de forma descoordinada. La divulgación coordinada de vulnerabilidades (Coordinated Vulnerability Disclosure, CVD) ordena el proceso: el aviso se recibe, se analiza, se corrige y, a continuación, se publica de forma conjunta. El marco lo establecen ISO/IEC 29147:2018 para la recepción y la publicación, e ISO/IEC 30111:2019 para la gestión interna.

Qué deberían comprobar los hospitales

Sin un proceso de CVD operativo, apenas es posible estimar la capacidad de respuesta de un fabricante. Son buenos indicadores una política publicada, un PSIRT accesible y un historial trazable de avisos de seguridad.

Monitorización más allá de la disponibilidad

Una monitorización que solo comprueba si un equipo responde no detecta ataques. Son significativos las conexiones inusuales, los intentos fallidos de inicio de sesión acumulados, los cambios de configuración inesperados y las comprobaciones de integridad fallidas. Como en muchos productos sanitarios no se puede instalar software adicional, es recomendable una monitorización pasiva de la red en zonas de equipos segmentadas.

Respuesta a incidentes más allá de la propia organización

Las anomalías deben traducirse en un procedimiento operativo, con roles, criterios de escalado e interfaces con ingeniería clínica, dirección del hospital, protección de datos y fabricante. MDCG 2019-16 espera expresamente que los operadores informen sin demora al fabricante de cualquier sospecha de incidente de seguridad. En el fabricante, el PSIRT concentra el análisis, la priorización y la corrección, y acompaña la comunicación con los CERT, las redes de intercambio de información y las autoridades.

Cuatro vías de notificación comparadas

Para la vigilancia MDR es indiferente que un evento se deba a un ataque, a una vulnerabilidad o a un error de software. Lo que importa es si la seguridad o el funcionamiento del producto se vieron o pudieron verse afectados. MDCG 2019-16 contiene ejemplos para distinguir entre incidente e incidente grave; para la codificación, el International Medical Device Regulators Forum (IMDRF) ofrece códigos de problema como «Software Security Vulnerability». En caso de duda sobre la obligación de notificar, debe notificarse en plazo; se admite una notificación inicial incompleta.

Qué cambiaría la propuesta de revisión

El 16 de diciembre de 2025, la Comisión propuso revisar el MDR y el IVDR. Según la propuesta, los fabricantes deberían notificar las vulnerabilidades explotadas activamente y los incidentes de seguridad graves en un plazo de 30 días, a través de la base de datos europea EUDAMED, a los CSIRT competentes y a ENISA; además, el plazo general de vigilancia para los demás incidentes graves pasaría de 15 a 30 días. La propuesta aún no se ha aprobado. Hasta entonces se aplican los plazos actuales.

El seguimiento poscomercialización, la gestión de vulnerabilidades y la gestión de incidentes se necesitan mutuamente: los nuevos riesgos solo se hacen visibles si el panorama de riesgos de seguridad alimenta el seguimiento poscomercialización; las prioridades solo son correctas si la evaluación de safety las acompaña; y los plazos solo se cumplen si asuntos regulatorios participa desde el principio. El modelo objetivo une estas líneas en un ciclo con responsables claros.

Plan de arranque para los primeros meses

• Inventario y responsables: registrar todos los productos sanitarios conectados con su versión de software, conexión de red, contacto del fabricante y fin del soporte.
• Cerrar las lagunas de información del fabricante: solicitar SBOM, MDS2, avisos de seguridad e instrucciones sobre parches, y anclarlos en los contratos.
• Definir clases de prioridad y tiempos de respuesta internos que combinen criterios técnicos y clínicos.
• Establecer un proceso de cambios para actualizaciones y medidas alternativas, con pasos de prueba, aprobación y documentación, y engranarlo con las obligaciones de mantenimiento y verificación del reglamento alemán de operadores.
• Elaborar y ensayar una matriz de notificación para la vigilancia MDR, la notificación del usuario, la ley BSI y la protección de datos, con plantillas, responsabilidades y suplencias.
• Introducir indicadores, como el porcentaje de equipos con SBOM actualizada, el tiempo de tramitación por clase de prioridad y el número de medidas alternativas temporales.

Quien conecta pronto estos elementos reacciona más rápido, puede fundamentar sus decisiones y refuerza la confianza en la tecnología sanitaria digital. Un equipo desarrollado de forma segura solo sigue siendo seguro si en campo se mantiene con el mismo cuidado.

La información de esta página no sustituye al asesoramiento jurídico. Las obligaciones aplicables en cada caso dependen de la clasificación, el rol y el tamaño de la organización.