La mayoría de los fabricantes de equipos originales (OEM) oyen hablar de «ciberseguridad de la FDA» y piensan inmediatamente en la SBOM. Ese es solo un elemento, pero no refleja el panorama completo.
El marco más amplio es la Guía de ciberseguridad previa a la comercialización de la FDA —Ciberseguridad en los productos sanitarios: consideraciones sobre el sistema de gestión de la calidad y contenido de las solicitudes previas a la comercialización —, que describe el enfoque actual de la FDA sobre el diseño de la ciberseguridad de los productos, el etiquetado y la documentación de ciberseguridad que la FDA recomienda incluir en las solicitudes previas a la comercialización. Abarca los dispositivos con riesgo de ciberseguridad, no solo los dispositivos conectados a la red.
La sección 524B de la Ley FD&C es la norma vinculante que otorga a la FDA la autoridad para exigir información de ciberseguridad para los «dispositivos cibernéticos». Pero la 524B es el mínimo legal, no el modelo completo de documentación de ciberseguridad. La Guía describe el conjunto de pruebas más amplio que los fabricantes deben preparar, y va mucho más allá de una SBOM.
Esto es importante para la selección del sistema operativo, ya que este alberga una parte significativa de la superficie de ataque del software. Pero el sistema operativo no es todo el dispositivo. La tarea del proveedor del sistema operativo es proporcionar pruebas técnicas estructuradas a nivel de la plataforma. El fabricante de equipos originales (OEM) es responsable de la presentación a nivel de dispositivo, la gestión de riesgos, la validación y las obligaciones posteriores a la comercialización.
Recomendaciones de la FDA para las solicitudes previas a la comercialización
La FDA publicó la guía definitiva actual el 3 de febrero de 2026, sustituyendo a la versión del 27 de junio de 2025. En ella se armoniza la terminología con el Reglamento sobre el Sistema de Gestión de la Calidad (QMSR), que entró en vigor el 2 de febrero de 2026 e incorpora la norma ISO 13485:2016 por referencia en el título 21 del CFR, parte 820.
La FDA recomienda que los fabricantes aborden la ciberseguridad como parte de la gestión de la seguridad y la calidad de los productos sanitarios. La guía identifica un Marco de Desarrollo Seguro de Productos (SPDF) como uno de los enfoques recomendados para gestionar los riesgos de ciberseguridad a lo largo del ciclo de vida del producto. Entre los enfoques comunes de modelización de amenazas se incluyen STRIDE, los árboles de ataque y las metodologías basadas en MITRE.
Para una solicitud previa a la comercialización, la FDA recomienda generalmente:
| Elemento de envío | Lo que recomienda la FDA |
|---|---|
| SPDF | Pruebas de que la ciberseguridad se aborda en el sistema de gestión de la calidad. La FDA señala el SPDF como uno de los enfoques recomendados |
| Modelo de amenazas | Modelo de amenazas específico para el dispositivo, con justificación metodológica, riesgos identificados, medidas de mitigación y análisis de riesgos residuales |
| Arquitectura de seguridad | Diagramas de arquitectura, diagramas de flujo de datos, límites de confianza e inventario de interfaces |
| SBOM | Inventario de todos los componentes de software con información sobre la versión. La sección 524B lo exige para los dispositivos cibernéticos |
| Pruebas de seguridad | Pruebas de ciberseguridad, que pueden incluir pruebas de penetración, análisis estáticos y dinámicos, pruebas de fuzzing y análisis de la superficie de ataque |
| Proceso CVD | Proceso documentado para la recepción, evaluación y comunicación de notificaciones de vulnerabilidades |
| Plan de seguimiento poscomercialización | Proceso para supervisar vulnerabilidades, aplicar parches y comunicarse con la FDA |
| Etiquetado de ciberseguridad | Medidas y procedimientos de seguridad documentados para los usuarios finales y los centros sanitarios |
No hay ninguna herramienta ni proveedor que cubra todo esto. Los distintos elementos son gestionados por diferentes departamentos de la organización.
524B frente a la guía completa
El artículo 524B se aplica a los «dispositivos cibernéticos», es decir, generalmente cualquier dispositivo que incluya software validado por el patrocinador, se conecte a Internet y presente características tecnológicas que lo hagan vulnerable a amenazas de ciberseguridad. Cuando la clasificación no esté clara, los fabricantes deben solicitar asesoramiento normativo.
| Artículo 524B | Guía de la FDA sobre ciberseguridad previa a la comercialización | |
|---|---|---|
| Qué es | Ley vinculante | Directrices de la FDA (reflejo de la opinión actual; por lo general, no son vinculantes por sí mismas) |
| Ámbito de aplicación | Solo dispositivos cibernéticos | Dispositivos que presentan riesgos de ciberseguridad, incluidos determinados dispositivos de software no conectados |
| Cobertura | Gestión de vulnerabilidades, actualizaciones y parches, SBOM, divulgación coordinada | SPDF, modelo de amenazas, arquitectura de seguridad, pruebas, SBOM, CVD, plan poscomercialización, etiquetado |
| Aplicación | La FDA podría rechazar determinadas solicitudes que no incluyan la información necesaria en materia de ciberseguridad | La FDA recomienda este marco para una evaluación coherente, adaptada al nivel de riesgo |
La guía describe recomendaciones de ciberseguridad para dispositivos que presentan riesgos de ciberseguridad, no solo para los dispositivos conectados a Internet. Si su dispositivo contiene software y presenta riesgos de ciberseguridad, la FDA recomienda abordar la ciberseguridad en su solicitud, independientemente de si está conectado o no. La SBOM por sí sola no es suficiente. (Para los dispositivos destinados al mercado de la UE, véase también «Cumplimiento de la normativa CRA para productos sanitarios: ¿qué está realmente exento?»)
Qué cambió en febrero de 2026: por qué las pruebas a nivel del sistema operativo cobran mayor importancia
La actualización de las directrices de la FDA de febrero de 2026 armonizó la terminología con la QMSR. Para los fabricantes de equipos originales (OEM), lo relevante desde el punto de vista práctico no es que el proveedor del sistema operativo pase a ser responsable del sistema de calidad. El OEM sigue siendo responsable de las presentaciones reglamentarias, la implementación del sistema de gestión de la calidad, la gestión de riesgos de ciberseguridad, la validación y las obligaciones posteriores a la comercialización.
El papel del proveedor del sistema operativo es más limitado, pero importante: proporcionar pruebas técnicas estructuradas que el fabricante de equipos originales pueda integrar en su propia documentación. La guía de la FDA establece que las vulnerabilidades conocidas deben evaluarse como riesgos razonablemente previsibles como parte de la gestión de riesgos de ciberseguridad. El programa de inspección actualizado de la FDA utiliza un enfoque basado en el riesgo. La documentación sobre ciberseguridad previa a la comercialización está recibiendo una gran atención. Las directrices de la FDA establecen que una información inadecuada sobre ciberseguridad puede afectar a la revisión, y la Sección 524B establece requisitos de presentación vinculantes para los dispositivos cibernéticos. Para los fabricantes de equipos originales (OEM), la cuestión práctica es sencilla: los artefactos de la capa del sistema operativo deben estar estructurados, ser trazables y utilizables en el paquete de pruebas a nivel de dispositivo.
Para un sistema operativo de dispositivos médicos, las pruebas estructuradas de la capa del sistema operativo incluyen:
- Artefactos SBOM para los componentes de la plataforma del sistema operativo
- Registros de supervisión y clasificación de vulnerabilidades
- Disponibilidad de parches y registros de actualizaciones
- Documentación sobre el arranque seguro
- Documentación sobre el mecanismo de actualización segura
- Elementos de la arquitectura de seguridad a nivel del sistema operativo
Ahí es donde una plataforma de sistema operativo de grado médico debería diferenciarse de una versión básica de Linux de uso general: no alegando por sí misma el cumplimiento normativo, sino generando artefactos de la capa del sistema operativo que sean trazables y estén listos para su revisión, y que el fabricante de equipos originales pueda integrar en sus procesos de gestión de riesgos, verificación, validación y poscomercialización a nivel de dispositivo.
Qué abarca MediTUX OS en la capa de plataforma
Generación de SBOM. MediTUX OS está diseñado para generar artefactos SBOM en tiempo de compilación para los componentes de la plataforma del sistema operativo incluidos en la compilación: el núcleo, el espacio de usuario, las bibliotecas y los componentes de firmware compatibles, cuando estén disponibles. En el caso de una distribución de Linux embebido, esto puede suponer cientos de componentes relacionados con el núcleo, el espacio de usuario, las bibliotecas, el tiempo de ejecución y el firmware, dependiendo del perfil de imagen y la plataforma de hardware seleccionados. Los fabricantes de equipos originales (OEM) siguen siendo responsables de los componentes de la capa de aplicación, específicos del dispositivo y de la nube en el SBOM completo del dispositivo.
Supervisión de vulnerabilidades. L4B opera MOON (MediTUX OS Operations Network), diseñado para dar soporte a la supervisión de vulnerabilidades en la capa del sistema operativo, la clasificación de riesgos, el seguimiento de la disponibilidad de parches y el soporte de actualizaciones para los componentes del sistema operativo MediTUX. De acuerdo con las directrices de ciberseguridad de QMSR y la FDA, estos resultados de la supervisión pueden respaldar los procesos del sistema de calidad del fabricante de equipos originales (OEM), ya que las vulnerabilidades conocidas deben evaluarse como riesgos razonablemente previsibles. Los fabricantes de equipos originales (OEM) siguen siendo responsables de la evaluación a nivel de dispositivo, la evaluación del impacto en la seguridad y las decisiones de implementación. Una coincidencia con un CVE no supone automáticamente un problema de seguridad del dispositivo. El fabricante sigue necesitando un análisis de explotabilidad en el contexto del dispositivo: si se incluye el componente vulnerable, si se puede acceder a la ruta de código afectada, si existen controles compensatorios y si la explotación podría afectar a la seguridad, la eficacia o la integridad de los datos.
Arranque seguro. MediTUX OS está diseñado para admitir flujos de trabajo de arranque seguro para las plataformas de hardware compatibles, incluyendo comprobaciones de integridad criptográfica en las fases de arranque, en función del hardware de destino y la arquitectura del sistema.
Actualizaciones seguras. MediTUX OS incluye sFOTA (firmware seguro por aire), diseñado para admitir flujos de trabajo de actualización de software seguros, incluyendo comprobaciones de integridad criptográfica y estrategias de actualización orientadas a la reversión, en función del hardware de destino, la arquitectura del sistema y la implementación del cliente.
Sus ingenieros deberían dedicarse a construir el dispositivo, no a mantener el sistema operativo.
MediTUX se encarga de la compilación de sistemas operativos, la aplicación de parches, el seguimiento de la lista de materiales de seguridad (SBOM) y la supervisión de vulnerabilidades CVE, para que tu equipo pueda centrarse en la innovación clínica.
Lo que el fabricante de equipos originales debe gestionar por separado
El sistema operativo se encarga de la capa de plataforma. El resto requiere conocimientos especializados a nivel de dispositivo.
| Elemento | ¿Quién se encarga de ello? |
|---|---|
| SBOM a nivel del sistema operativo, supervisión de CVE, arranque seguro, OTA | Proveedor de plataformas de sistemas operativos (MediTUX OS, MOON, sFOTA) |
| Modelo de amenazas a nivel de dispositivo | Fabricante de equipos originales (OEM) o consultoría de ciberseguridad |
| Pruebas de penetración | Fabricante de equipos originales o empresa de ensayos independiente |
| Proceso CVD | OEM (obligación del fabricante) |
| Arquitectura de seguridad completa | Fabricante de equipos originales (OEM), con aportaciones de la plataforma del sistema operativo |
| Etiquetado de ciberseguridad | Fabricante de equipos originales |
| Integración de SPDF en el sistema de gestión de la calidad | OEM, con compatibilidad con la plataforma del sistema operativo para los procesos de la capa del sistema operativo |
| Plan de vigilancia poscomercialización | OEM, con compatibilidad con plataformas de sistema operativo para la supervisión a nivel del sistema operativo |
Esa distinción es importante. Un proveedor de sistemas operativos creíble debería facilitar la documentación de la capa de la plataforma, en lugar de pretender ser el único propietario de todo el conjunto.
Por qué Linux de uso general complica las cosas
Los fabricantes de equipos originales (OEM) que utilizan distribuciones basadas en Ubuntu, Debian o Yocto se enfrentan al mismo trabajo a nivel de dispositivo —modelización de amenazas, pruebas de penetración, CVD—, pero además deben asumir toda la carga que supone la capa del sistema operativo. (Para profundizar en el motivo, véase «Por qué Linux de uso general no es suficiente para los dispositivos médicos»).
- La generación de listas de materiales de seguridad (SBOM) requiere herramientas personalizadas
- La supervisión de vulnerabilidades (CVE) en cientos de paquetes es un compromiso permanente
- Se debe compilar y validar el arranque seguro
- Es necesario desarrollar y mantener la infraestructura OTA
- La documentación sobre la arquitectura de seguridad a nivel del sistema operativo se elabora desde cero
- El mantenimiento a largo plazo del núcleo y los paquetes (más de 10 años) es responsabilidad del fabricante de equipos originales
- En virtud de la QMSR, los procesos de ciberseguridad pertinentes de la capa del sistema operativo deben integrarse en la documentación auditable del sistema de calidad cuando afecten a la seguridad de los productos sanitarios, los controles de diseño, la gestión de riesgos o la vigilancia poscomercialización.
Ese es precisamente el objetivo de una plataforma de sistema operativo de grado médico: reducir la carga que supone la capa del sistema operativo para que el equipo del fabricante de equipos originales pueda centrarse en los riesgos específicos del dispositivo, que solo ellos pueden evaluar.
Preguntas frecuentes
¿Exige la FDA una norma específica de ciberseguridad para el sistema operativo? No. La FDA no impone una norma específica de ciberseguridad para el propio sistema operativo. La Guía hace referencia a la norma IEC 81001-5-1 como norma consensuada reconocida, pero la solicitud debe demostrar cómo se gestiona el riesgo de ciberseguridad en el dispositivo concreto.
¿Es la Sección 524B el principal requisito de ciberseguridad? Es la disposición legal vinculante para los dispositivos cibernéticos. Pero no lo es todo. El marco más amplio que recomienda la FDA es la Guía de ciberseguridad previa a la comercialización, que abarca los dispositivos con riesgo de ciberseguridad, incluidos los que no están conectados a la red.
¿Cumple MediTUX OS todos los requisitos de ciberseguridad de la FDA? No, y ninguna plataforma de sistema operativo puedehacerlo. MediTUX OS da soporte a la capa de la plataforma del sistema operativo: generación de SBOM, monitorización de vulnerabilidades a través de MOON, arranque seguro para el hardware compatible y actualizaciones seguras a través de sFOTA. El modelado de amenazas, las pruebas de penetración, el CVD, la arquitectura de seguridad y el etiquetado requieren conocimientos especializados a nivel de dispositivo que el fabricante de equipos originales (OEM) proporciona directamente o a través de un socio especializado. (Véase también: Garantizar la seguridad de los dispositivos médicos con MediTUX OS.)
¿Qué es el SPDF? Marco de desarrollo seguro de productos. La FDA lo identifica como una de las formas recomendadas de gestionar los riesgos de ciberseguridad a lo largo del ciclo de vida del producto. La idea es que la ciberseguridad se integre en el proceso de desarrollo desde el principio, y no se añada a posteriori antes de la presentación.
¿Cómo afecta la QMSR a la ciberseguridad? La QMSR implica que las actividades relacionadas con la ciberseguridad que afecten a la seguridad de los dispositivos deben formar parte del sistema de gestión de la calidad, y no tratarse como un ejercicio independiente. Las directrices de la FDA establecen que las vulnerabilidades conocidas deben evaluarse como riesgos razonablemente previsibles. Para los fabricantes de equipos originales (OEM), esto significa que los artefactos de la capa del sistema operativo, como las SBOM, los registros de vulnerabilidades y los registros de actualizaciones, deben organizarse de modo que encajen en el sistema de gestión de la calidad, y no dejarse en un repositorio de ingeniería desconectado de los procesos del sistema de calidad.
¿Genera MediTUX OS artefactos SBOM para las solicitudes previas a la comercialización de la FDA? Sí, en la capa de la plataforma del sistema operativo. MediTUX OS está diseñado para generar artefactos SBOM en el momento de la compilación para los componentes del sistema operativo incluidos en la compilación. El SBOM completo del dispositivo —incluidos los componentes a nivel de aplicación, en la nube y otros componentes ajenos al sistema operativo— sigue siendo responsabilidad del fabricante de equipos originales (OEM).
¿Estás desarrollando un producto sanitario y necesitas pruebas de ciberseguridad a nivel del sistema operativo?
Generación de listas de materiales de seguridad (SBOM), supervisión de vulnerabilidades, arranque seguro y actualizaciones OTA: todo ello a través de MediTUX OS. Para el modelado de amenazas y las pruebas de penetración a nivel de dispositivo, L4B colabora con consultoras especializadas cuando se requiere asistencia a nivel de dispositivo.
RESERVAR UNA LLAMADA DE EVALUACIÓN →
Certificado según la norma ISO 13485 · Compatible con la norma IEC 62304 · Compatible con la norma FDA 524B · l4b-software.com
Descargo de responsabilidad: Este contenido tiene únicamente fines informativos y de marketing, y no constituye asesoramiento jurídico, normativo, de ciberseguridad, clínico ni sobre sistemas de calidad. Las directrices de la FDA reflejan, en general, la postura actual de la agencia y no son vinculantes a menos que estén vinculadas a requisitos legales o normativos. Los fabricantes de productos sanitarios siguen siendo responsables de determinar los requisitos aplicables, implementar su sistema de gestión de la calidad (SGC), gestionar los riesgos de ciberseguridad a nivel de los productos, preparar las solicitudes y cumplir con las obligaciones posteriores a la comercialización. MediTUX OS, MOON y sFOTA dan soporte a las actividades de ciberseguridad a nivel del sistema operativo, pero no sustituyen las responsabilidades del fabricante a nivel del dispositivo.
Debes iniciar sesión para publicar un comentario.