01Qué diferencia la seguridad de producto de la seguridad TI corporativa
La seguridad TI corporativa protege la infraestructura propia y suele gestionarse mediante un SGSI conforme a ISO/IEC 27001. La seguridad de producto, en cambio, protege el producto en el campo: en el entorno del cliente, a menudo con acceso físico por parte de los atacantes y durante periodos que superan con creces los ciclos habituales de soporte TI. Una vulnerabilidad no afecta entonces a un único sistema, sino a toda la base instalada, y puede acarrear consecuencias de safety, retiradas de producto o la pérdida de la homologación de tipo. En el plano organizativo, la responsabilidad se desplaza así de la operación TI al desarrollo de producto, con sistemas de gestión propios (CSMS), procesos de desarrollo (Secure Development Lifecycle) y estructuras de respuesta (PSIRT).
02Automoción: ISO/SAE 21434, UN R155 y UN R156
ISO/SAE 21434:2021 define la ingeniería de ciberseguridad para vehículos de carretera a lo largo de todo el ciclo de vida, desde la fase de concepto hasta la retirada de servicio. Su pieza central es el Threat Analysis and Risk Assessment (TARA) según el capítulo 15: desde la identificación de activos, pasando por los escenarios de amenaza y el análisis de daños y de rutas de ataque, hasta la decisión de tratamiento del riesgo. Los reglamentos de la UNECE hacen el tema vinculante: UN R155 exige un sistema de gestión de la ciberseguridad (CSMS) certificado como requisito para la homologación de tipo, y UN R156 un sistema de gestión de actualizaciones de software (SUMS). En la UE, ambos se aplican a través del General Safety Regulation (EU) 2019/2144: desde julio de 2022 para los nuevos tipos de vehículo y desde julio de 2024 para todos los vehículos nuevos; ISO/SAE 21434 se considera el estado del arte reconocido para implementar los requisitos del CSMS.
03Componentes industriales: IEC 62443-4-1 y 62443-4-2
Para los componentes de sistemas de automatización industrial, la serie IEC 62443 separa los requisitos de proceso y de producto. IEC 62443-4-1:2018 describe un ciclo de desarrollo de producto seguro en ocho practices —desde la gestión de la seguridad y la especificación de requisitos, pasando por el diseño seguro y la implementación, hasta la verificación, la gestión de defectos y parches y las guías de seguridad para los usuarios— que se extiende expresamente hasta el fin de vida del producto y se evalúa mediante cuatro niveles de madurez. IEC 62443-4-2:2019 especifica los requisitos técnicos de los propios componentes: Component Requirements para cuatro tipos de componentes (embedded devices, host devices, componentes de red y aplicaciones de software), derivados de siete Foundational Requirements y escalonados en los Security Levels SL 1 a SL 4. Para los fabricantes, ambas partes se están convirtiendo cada vez más en criterio de compra, porque los operadores exigen de forma concreta evidencias y Security Levels.
04Equipos radioeléctricos: acto delegado de la RED y serie EN 18031
El Reglamento Delegado (UE) 2022/30 activa los requisitos de ciberseguridad del art. 3, apartado 3, letras d) a f) de la Directiva de Equipos Radioeléctricos (RED); desde el 1 de agosto de 2025 son un requisito vinculante para la introducción en el mercado de equipos radioeléctricos con conexión a Internet. Como normas armonizadas sirven EN 18031-1, -2 y -3 (edición 2024) para la protección de la red, la protección de los datos personales y la protección contra el fraude; la Comisión Europea las incluyó en el Diario Oficial en enero de 2025, aunque con restricciones. Si, por ejemplo, un producto permite prescindir de contraseña (secciones 6.2.5.1/6.2.5.2) o si, en el caso de EN 18031-2, falta un control parental garantizado (secciones 6.1.3–6.1.6), la presunción de conformidad no se aplica y debe intervenir un organismo notificado. Los fabricantes deberían, por tanto, examinar estas restricciones en una fase temprana del procedimiento de evaluación de la conformidad.
05PSIRT: respuesta organizada a las vulnerabilidades de producto
Un Product Security Incident Response Team (PSIRT) gestiona las vulnerabilidades de los propios productos, a diferencia del CSIRT, que atiende los incidentes en la propia infraestructura. El PSIRT Services Framework v1.1 de FIRST (2020) estructura las tareas en seis áreas de servicio —Stakeholder Ecosystem Management, Vulnerability Discovery, Triage, Remediation, Disclosure y Training y Education— y describe modelos organizativos distribuidos, centralizados e híbridos. A más tardar con el Cyber Resilience Act (Reglamento (UE) 2024/2847), esta capacidad se convierte en obligación: a partir del 11 de septiembre de 2026, los fabricantes deberán notificar las vulnerabilidades explotadas activamente conforme al art. 14, de forma escalonada, en plazos de 24 horas, 72 horas y 14 días, al CSIRT designado como coordinador y a ENISA; para los incidentes graves rige el mismo escalonamiento, con un mes para el informe final. Sin procesos PSIRT bien rodados, estos plazos son prácticamente inalcanzables.
06Seguridad a lo largo del ciclo de vida del producto, hasta el fin de vida
La seguridad de producto no termina con el lanzamiento al mercado: la gestión de vulnerabilidades, las actualizaciones de seguridad y la monitorización deben planificarse y financiarse durante toda la vida útil. El Cyber Resilience Act exige un periodo de soporte que refleje la vida útil esperada del producto y que, por regla general, sea de al menos cinco años (art. 13, apartado 8); las actualizaciones de seguridad deben proporcionarse de forma gratuita y el periodo de soporte debe comunicarse con transparencia antes de la compra. Las normas sectoriales también contemplan el fin de vida: IEC 62443-4-1 lo incluye expresamente en el ciclo de desarrollo y UN R156 exige actualizaciones de software gestionadas durante toda la vida del vehículo. Un fin de vida ordenado comprende el anuncio anticipado del fin del soporte, los últimos avisos de seguridad y rutas de migración para los clientes existentes.
