Artículo técnico en mt|medizintechnik 4.2026: por qué el mantenimiento de los productos sanitarios conectados incluye la ciberseguridad
19 de octubre de 2026
Publicado en mt|medizintechnik, Número 4.2026
Publicado en mt|medizintechnik, número 4.2026
En la revista especializada mt|medizintechnik, Valeri Milke explica por qué el mantenimiento de productos sanitarios conectados incluye hoy la ciberseguridad. Su artículo «Instandhaltung vernetzter Medizinprodukte» (mantenimiento de productos sanitarios conectados), con el antetítulo «Schwachstellen- und Patchmanagement sind Safety-relevant» (la gestión de vulnerabilidades y de parches afecta a la seguridad del paciente), aparece en el número 4.2026, publicado en agosto de 2026 con el mantenimiento como tema central. La revista la edita TÜV Media GmbH, con sede en Colonia. Autor: Valeri Milke, CEO de VamiSec GmbH, Lead Auditor de ISO/IEC 27001 e ISO/IEC 42001. Con cinco figuras y una tabla, el artículo (en alemán) esboza cómo fabricantes y operadores pueden organizar la explotación de los equipos conectados como un proceso continuo: desde el inventario de los componentes de software, pasando por la evaluación y la corrección de vulnerabilidades, hasta las obligaciones de notificación tras un incidente de seguridad. Esta noticia recoge sus ideas clave con palabras propias y las sitúa en el marco regulatorio de octubre de 2026.
La tesis central: que un equipo funcione no significa que sea seguro
El mantenimiento clásico sigue intervalos de servicio y comprueba si un equipo cumple su función. En los productos sanitarios conectados, esa mirada ya no basta: una bomba de infusión o un sistema de diagnóstico por imagen puede superar todas las pruebas funcionales y, aun así, entrañar un riesgo inaceptable, por ejemplo porque una vulnerabilidad publicada hace tiempo nunca se evaluó o porque un intruso actúa en la red sin ser detectado. El artículo parte de un principio de la guía europea MDCG 2019-16 (revisión 1, de julio de 2020): en el entorno clínico, los riesgos para la seguridad de la información (security) pueden traducirse directamente en riesgos para la seguridad del paciente (safety). Ejemplos típicos son parámetros terapéuticos alterados, alarmas suprimidas o resultados diagnósticos falseados. Por eso, la gestión de vulnerabilidades y de parches, la detección de ataques durante la operación, el seguimiento poscomercialización (Post-Market Surveillance, PMS) y la vigilancia deben integrarse en un proceso de gestión común, con funciones claramente repartidas entre fabricantes, integradores y hospitales.
Primero, transparencia: conocer los componentes y evaluar la situación
Quien no sabe qué bibliotecas, sistemas operativos y firmware contiene un equipo no puede determinar si una nueva vulnerabilidad le afecta. Por eso, el punto de partida es una lista de materiales de software (Software Bill of Materials, SBOM) legible por máquina, en formato SPDX (ISO/IEC 5962) o CycloneDX (ECMA-424), actualizada con cada versión. Las declaraciones del fabricante sobre la afectación (Vulnerability Exploitability eXchange, VEX) y los avisos de seguridad en el Common Security Advisory Framework (CSAF) la convierten en un panorama de riesgos útil. La priorización combina varias perspectivas: la gravedad técnica según el Common Vulnerability Scoring System (CVSS), la probabilidad de explotación en 30 días según el Exploit Prediction Scoring System (EPSS), la explotación comprobada según el catálogo KEV (Known Exploited Vulnerabilities) de la agencia estadounidense CISA y el contexto clínico. Una vulnerabilidad media en una plataforma terapéutica puede ser más urgente que una crítica en un equipo aislado. Log4Shell y XZ Utils muestran con qué rapidez los riesgos de la cadena de suministro llegan al producto.
El parche como cambio controlado, y qué hacer mientras no exista
Una actualización de seguridad reduce riesgos, pero puede alterar estados validados e interfaces. Por eso el artículo entiende la gestión de parches como un proceso de cambio regulado: identificar los componentes afectados mediante el inventario y la SBOM, evaluar las consecuencias para la security y la safety en la gestión de riesgos conforme a ISO 14971, probar en un entorno próximo al real, aprobar, desplegar, verificar la eficacia y documentar. Los operadores solo deberían instalar actualizaciones con instrucciones expresas del fabricante, como también prevé MDCG 2019-16. Si no hay parche —por ejemplo, ante una vulnerabilidad zero-day sin corregir—, ayudan las medidas alternativas preparadas: segmentación de red, desactivación de servicios vulnerables, supervisión estrecha y modos de funcionamiento de emergencia acordados con el personal clínico. También estas deben justificarse y documentarse. Para las actualizaciones remotas (Over-the-Air, OTA) se suman paquetes firmados, un arranque seguro (Secure Boot), una imagen de recuperación, protección frente a la reinstalación de versiones obsoletas y una distribución escalonada.
Recibir avisos de vulnerabilidades desde fuera: CVD y PSIRT
Muchas vulnerabilidades no las descubren los propios fabricantes, sino investigadores de seguridad, pentesters, integradores o usuarios. Para que esos avisos no se pierdan ni se hagan públicos de forma desordenada, el artículo aboga por un procedimiento regulado de divulgación coordinada de vulnerabilidades (Coordinated Vulnerability Disclosure, CVD). Sirven de referencia ISO/IEC 29147 para la recepción y la publicación, e ISO/IEC 30111 para la gestión interna. En la práctica, esto incluye un archivo security.txt según la RFC 9116, un buzón de notificación accesible de forma cifrada, plazos de respuesta declarados, una CVE Numbering Authority (CNA) propia o la colaboración con una existente, y avisos legibles por máquina en formato CSAF. Lo sostiene un equipo de respuesta a incidentes de seguridad de producto (Product Security Incident Response Team, PSIRT). Para los hospitales, la madurez de este proceso es un criterio de selección tangible en las compras: sin un historial de avisos trazable, queda en el aire con qué rapidez llegan al operador los avisos críticos.
Un incidente, tres vías de notificación: MDR, ley BSI y RGPD
¿Cuándo debe notificarse un ciberincidente? Los fabricantes están sujetos a las obligaciones de vigilancia del Reglamento de Productos Sanitarios (MDR): los incidentes graves se notifican sin demora, a más tardar 2 días después de tener conocimiento ante una amenaza grave para la salud pública, 10 días en caso de fallecimiento o de deterioro grave e imprevisto del estado de salud y 15 días en los demás casos. Los hospitales alemanes sujetos, como entidades esenciales o importantes, a la nueva ley BSI, que desde el 6 de diciembre de 2025 transpone la Directiva NIS2, notifican los incidentes significativos con una alerta temprana en 24 horas, una notificación con una primera evaluación en 72 horas y un informe final a más tardar un mes después de esta. Si el incidente afecta a datos personales, el Reglamento General de Protección de Datos (RGPD) exige por regla general informar a la autoridad de control, de ser posible en 72 horas. Un solo ataque puede activar las tres vías a la vez, en el fabricante y en el hospital. Por eso el artículo recomienda plazos registrados, responsabilidades claras y plantillas de notificación listas.
Por qué el tema apremia ahora y qué puede hacer usted
En diciembre de 2025, la Comisión Europea propuso completar el MDR y el IVDR con una notificación propia de las vulnerabilidades explotadas activamente y de los incidentes de seguridad graves, a través de EUDAMED a los CSIRT y a ENISA, a más tardar 30 días después de tener conocimiento. Al mismo tiempo, el plazo para los demás incidentes graves pasaría de 15 a 30 días; nada de ello está aprobado aún. Desde el 11 de septiembre de 2026 se aplican, además, las obligaciones de notificación del Cyber Resilience Act (CRA). El CRA excluye los productos sanitarios, pero puede aplicarse directamente a componentes de proveedores comercializados por separado como productos con elementos digitales. Se recomiendan cinco pasos: crear un inventario de equipos con versiones de software y SBOM; exigir por contrato a los proveedores SBOM, VEX y avisos CSAF; introducir un triaje que valore expresamente las consecuencias clínicas; ensayar los procedimientos zero-day con la TI hospitalaria, la ingeniería clínica y el área de asuntos regulatorios; y, por último, reunir las vías de notificación del MDR, la ley BSI y el RGPD en un procedimiento coordinado.
Nuevo en vamisec.com: la página de conocimiento sobre el tema
Nuevo en vamisec.com: la página de conocimiento «Mantenimiento de productos sanitarios conectados». Retoma las tesis del artículo, las actualiza a la situación de octubre de 2026 y las desarrolla a lo largo de todo el proceso de mantenimiento en campo: del inventario y la SBOM al panorama de riesgos, el triaje, el proceso de parches y OTA, la preparación ante vulnerabilidades zero-day y la CVD, hasta la monitorización, las vías de notificación paralelas y un modelo operativo de referencia, con preguntas frecuentes y fuentes verificadas. Encontrará la página en https://vamisec.com/es/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte y nuestra consultoría para proyectos MDR y para la ciberseguridad de productos sanitarios en https://vamisec.com/es/mdr y https://vamisec.com/es/medical-device-cybersecurity. Los requisitos generales del MDR se resumen en https://vamisec.com/es/wissen/grc/mdr-cybersecurity.
Todos los enlaces
Número 4.2026 de mt|medizintechnik: https://mt-medizintechnik.de/fokus-auf-instandhaltung/ · Página de conocimiento Mantenimiento de productos sanitarios conectados: https://vamisec.com/es/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte · Categoría Desarrollo seguro de software y de productos, sección Productos sanitarios: https://vamisec.com/es/wissen/secure-software-development#medizinprodukte · Ciberseguridad MDR en resumen: https://vamisec.com/es/wissen/grc/mdr-cybersecurity · Gestión de SBOM: https://vamisec.com/es/wissen/secure-software-development/sbom-management · Gestión de vulnerabilidades: https://vamisec.com/es/wissen/it-security/schwachstellenmanagement · Consultoría MDR: https://vamisec.com/es/mdr · Ciberseguridad de dispositivos médicos: https://vamisec.com/es/medical-device-cybersecurity
¿Tiene preguntas sobre la seguridad TI de su empresa?
Consulta inicial gratuita →