Los fabricantes afectados deben notificar vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad de productos con elementos digitales.
Los requisitos generales de ciberseguridad del Reglamento serán plenamente aplicables, incluyendo diseño seguro, gestión de vulnerabilidades y obligaciones durante el ciclo de vida.
Esperar a 2027 para empezar es llegar tarde a una obligación que ya está operativa.
El Reglamento (UE) 2024/2847 será plenamente aplicable a partir del 11 de diciembre de 2027, pero el artículo 14 —el que regula las obligaciones de notificación— ya se aplica desde el 11 de septiembre de 2026. Eso significa que determinadas organizaciones pueden tener que reportar hoy una vulnerabilidad activamente explotada o un incidente grave aunque muchos de los demás requisitos del CRA todavía estén en periodo de preparación.
La consecuencia práctica es importante: el proyecto CRA no debería empezar por el inventario de documentación para 2027. Debería empezar por comprobar si, ante un incidente mañana, la empresa sabría identificar si el producto está dentro de alcance, quién tiene autoridad para notificar, qué información puede reunir en 24 horas y cómo mantener actualizada la notificación durante los días siguientes.
El CRA no es solo para fabricantes de hardware: también alcanza a software y componentes puestos en el mercado de la UE.
La Comisión Europea define los “productos con elementos digitales” de forma amplia: productos de software o hardware y sus soluciones de procesamiento remoto de datos cuando forman parte de la funcionalidad del producto. El alcance incluye tanto productos finales como determinados componentes que se comercializan por separado.
Eso hace que la conversación sea relevante para fabricantes industriales conectados, desarrolladores de software comercial, proveedores de appliances, soluciones IoT, dispositivos, componentes, aplicaciones y organizaciones que comercializan productos digitales bajo su nombre o marca.
No todo servicio cloud ni todo desarrollo interno entra automáticamente en el mismo supuesto. El perímetro depende de cómo se comercializa el producto, de su función, de la conexión lógica o física con dispositivos o redes y de otras posibles exclusiones regulatorias. Antes de construir controles técnicos conviene resolver bien el alcance legal y de producto.
Sin un inventario claro de producto, versiones, componentes, responsables y soporte, cualquier proceso de notificación empieza con información incompleta.
El CRA distingue entre vulnerabilidades explotadas activamente e incidentes graves de seguridad.
La obligación de 2026 no consiste en informar cada vulnerabilidad descubierta ni cada alerta del SOC. El foco está en dos categorías que requieren evaluación rápida y documentada. El equipo debe saber cuándo un hallazgo cruza el umbral regulatorio y quién confirma esa clasificación.
No basta con que exista una CVE: importa que haya explotación real.
El proceso debe distinguir entre vulnerabilidades conocidas, vulnerabilidades críticas todavía no explotadas y aquellas para las que existe evidencia fiable de explotación maliciosa. Esa evaluación puede depender de threat intelligence, investigación interna, proveedores, comunidades de seguridad o información de terceros.
La organización necesita enlazar la vulnerabilidad con versiones de producto, clientes potencialmente afectados, exposición, mitigaciones y disponibilidad de una corrección.
El incidente debe afectar a la seguridad del producto con elementos digitales.
No todo incidente corporativo se convierte en una notificación CRA. Hay que analizar la relación con el producto, su seguridad y el impacto. Esa decisión exige colaboración entre seguridad, producto, ingeniería y legal, porque un evento puede parecer operativo en el SOC y tener implicaciones regulatorias sobre el producto.
La clasificación debe ser reproducible: criterios, evidencia, responsables y decisiones tienen que quedar documentados.
El punto crítico no es “detectar más”. Es convertir señales técnicas en una decisión regulatoria a tiempo.
Defender, Sentinel, EDR, repositorios de código, pipelines, soporte y telemetría pueden descubrir señales distintas. El CRA obliga a conectarlas con un proceso que determine si el evento afecta a un producto concreto, si entra en una categoría reportable y qué información puede entregarse dentro del plazo disponible.
24 horas, 72 horas y un informe final: la respuesta debe estar preparada antes de que ocurra el incidente.
La Comisión Europea resume el proceso en varias etapas. Tras tener conocimiento del evento reportable, el fabricante debe enviar una alerta temprana dentro de las primeras 24 horas y una notificación más completa dentro de las 72 horas. Después existe un informe final cuyo calendario depende de si se trata de una vulnerabilidad explotada activamente o de un incidente grave.
Alerta temprana
La prioridad es comunicar con rapidez que existe un evento reportable. No es razonable esperar a tener cerrada toda la investigación forense antes de iniciar la notificación.
Notificación completa
En este punto la organización debe haber consolidado mucho más contexto técnico y de impacto. El desafío es llegar con datos coherentes aunque la investigación siga abierta.
Vulnerabilidad explotada activamente
El informe final debe presentarse, como máximo, 14 días después de que esté disponible una medida correctora o de mitigación aplicable a la vulnerabilidad reportada.
Incidente grave
Para incidentes graves, la Comisión indica un informe final dentro del mes siguiente a la notificación de 72 horas, con la información y conclusiones disponibles.
La consecuencia operativa: si la empresa tarda dos días en decidir quién puede aprobar una notificación, ya ha consumido casi todo el plazo de 72 horas. El proceso debe definir previamente responsables, sustitutos, criterios de escalado, datos mínimos y canales de coordinación.
El fabricante reporta una vez y la plataforma distribuye la información a las autoridades competentes que corresponda.
La plataforma de ENISA simplifica el canal. No simplifica la investigación que hay detrás.
ENISA lanzó la capacidad operativa inicial de la Single Reporting Platform el 11 de septiembre de 2026. La plataforma está diseñada para que los fabricantes realicen una única notificación en lugar de tener que reportar por separado a múltiples autoridades nacionales.
El acceso para Assigned Representatives utiliza EU Login y requiere autenticación multifactor. La organización debe decidir quién actuará como representante autorizado para presentar y actualizar notificaciones, quién será backup y cómo se valida internamente que la información enviada es correcta.
La plataforma resuelve el mecanismo regulatorio de envío. El trabajo previo sigue siendo interno: correlacionar evidencias, identificar el producto, reconstruir la cronología, confirmar impacto, conocer versiones afectadas y decidir qué mitigación se ha aplicado o se prepara.
Producto, SOC, desarrollo, legal y negocio tienen que funcionar como un único proceso de respuesta.
La dificultad no está en añadir otra herramienta. Está en coordinar equipos que normalmente utilizan lenguajes, prioridades y sistemas diferentes. El SOC habla de indicadores, alertas y severidad. Desarrollo habla de repositorios, versiones y parches. Producto habla de clientes y releases. Legal habla de alcance y obligación. Dirección necesita impacto y decisión.
Seguridad / SOC
Detecta explotación, incidentes, indicadores y actividad anómala. Debe poder relacionar la señal con un producto, una versión y un contexto comercial.
Desarrollo / DevSecOps
Conoce componentes, librerías, ramas, dependencias, builds, SBOM y capacidad de corrección. Es esencial para determinar versiones afectadas y construir mitigaciones.
Producto
Sabe dónde está comercializado el producto, qué clientes dependen de él, qué versiones siguen soportadas y cómo se comunica un cambio o una actualización.
Legal / Compliance
Interpreta alcance, obligaciones, excepciones y relación con otras normas. No debería recibir el expediente por primera vez cuando faltan dos horas para el plazo.
Dirección necesita un único cuadro: producto, impacto, explotación, clientes, mitigación, plazo y decisión.
El diseño más maduro no obliga a la dirección a reconstruir el incidente leyendo cinco herramientas. La información crítica debe llegar consolidada con una recomendación clara sobre notificación, comunicación y acciones inmediatas.
Azure no “cumple el CRA” por ti. Puede darte la telemetría, gobierno y evidencia que el proceso necesita.
Una arquitectura Microsoft puede ayudar a detectar amenazas, correlacionar eventos, controlar identidades, gobernar configuraciones, almacenar evidencias y automatizar tareas. Pero ninguna plataforma decide por sí sola si un evento concreto constituye una notificación CRA. Esa decisión pertenece al proceso de gobierno de la empresa.
La ventaja aparece cuando los sistemas ya generan señales estructuradas. Microsoft Defender for Cloud puede aportar postura y detección sobre cargas cloud; Microsoft Sentinel puede correlacionar eventos y coordinar respuesta; Entra ID aporta contexto de identidad; Azure Policy ayuda a mantener configuraciones; DevOps y GitHub pueden aportar trazabilidad de código, builds y dependencias.
El objetivo debería ser que el proceso regulatorio reutilice información que ya existe en la operación de seguridad en lugar de crear una carpeta paralela que solo se actualiza durante una auditoría.
Una herramienta aislada puede detectar una señal. El cumplimiento exige entender qué significa esa señal para el producto que vendes.
Qué papel puede tener cada servicio Microsoft en un proceso preparado para CRA.
Postura y protección de cargas
Ayuda a identificar configuraciones inseguras, vulnerabilidades y amenazas en Azure y entornos multicloud. Puede aportar señales relevantes, pero deben conectarse con el inventario de producto.
Correlación e investigación
Centraliza eventos y permite correlacionar identidad, endpoints, cloud, aplicaciones y otros orígenes. Su valor aumenta cuando los playbooks incluyen criterios de escalado CRA.
Identidad y privilegios
Contextualiza accesos, cuentas y cambios de privilegios. Cuando una investigación implica credenciales comprometidas, el historial de identidad puede ser decisivo.
Configuración y gobierno
Permite imponer o auditar requisitos sobre recursos y reducir desviaciones. El control preventivo disminuye la probabilidad de incidentes causados por configuraciones inconsistentes.
Componentes, versiones y correcciones
Repositorios, pipelines, dependencias, SBOM y releases ayudan a determinar qué producto está afectado y cuándo estará disponible una corrección.
Evidencia verificable
En escenarios donde la empresa necesita demostrar que una evidencia no fue alterada, puede conservar hashes o registros críticos con receipts criptográficos verificables.
Una empresa puede estar afectada por más de un marco, pero las obligaciones no son intercambiables.
NIS2 se centra en la ciberseguridad y resiliencia de determinadas entidades y sectores. El Cyber Resilience Act se centra en productos con elementos digitales y en las responsabilidades de quienes los ponen en el mercado. Ambos pueden coincidir en una misma organización, pero responden a preguntas diferentes.
Un fabricante puede necesitar proteger su propia organización, cumplir requisitos sectoriales y, al mismo tiempo, responder por la seguridad del software o hardware que comercializa. Utilizar el mismo proceso de incident response como base puede ser eficiente, siempre que las rutas de decisión y notificación estén separadas donde corresponda.
La mala práctica sería asumir que “ya tenemos NIS2” y por tanto CRA está resuelto. El inventario, los responsables, los triggers y la información a reportar no son idénticos.
NIS2
¿Cómo protege y gestiona riesgos la entidad que presta un servicio esencial o importante?
CRA
¿Cómo diseña, mantiene y responde el fabricante por la ciberseguridad del producto digital que comercializa?
Punto común
Inventario, incident response, evidencias, identidad, gobierno, comunicación y capacidad de actuar bajo presión.
Diez controles operativos antes de descubrir una vulnerabilidad explotada un viernes por la tarde.
Productos, versiones, componentes, propietarios, soporte y países donde se comercializan.
Librerías, dependencias, firmware, servicios remotos y proveedores que forman parte del producto.
Cómo distinguir una vulnerabilidad conocida, una explotación activa y un incidente grave.
Quién debe ser avisado fuera de horario y quién sustituye a cada responsable.
Usuarios preparados para acceder a la plataforma de ENISA y presentar una notificación cuando sea necesario.
Qué información puede reunirse rápidamente aunque la investigación no esté terminada.
Investigación, impacto, versiones, clientes, mitigación y aprobación de la notificación ampliada.
Logs, imágenes, commits, builds, hashes, decisiones y pruebas necesarios para reconstruir el caso.
Mensajes, canales y responsables para informar cuando el impacto o la mitigación lo requieran.
Ejecutar un tabletop exercise realista para comprobar que la organización puede cumplir plazos y responsabilidades.
La preparación real se mide cuando alguien pone un cronómetro y obliga a producto, SOC, desarrollo y legal a decidir con información incompleta.
La mejor forma de saber si puedes notificar en 24 horas es intentar hacerlo antes de necesitarlo.
Un simulacro útil empieza con una situación plausible: un componente vulnerable, explotación confirmada, un producto distribuido en varios países y telemetría incompleta. El equipo recibe información por fases, como ocurriría en un incidente real, y debe decidir si existe obligación, qué producto está afectado, quién escala y qué información puede reportarse.
El objetivo no es aprobar o suspender a las personas. Es detectar dependencias invisibles: un inventario que nadie mantiene, una persona que concentra el conocimiento, un repositorio al que legal no tiene acceso, un proceso de aprobación que tarda demasiado o un cliente crítico cuyo contrato exige avisos adicionales.
El resultado debería ser un backlog concreto con responsables y fechas. Si el simulacro termina solo con una presentación de conclusiones, se pierde gran parte del valor. Las mejoras deben incorporarse a los playbooks, sistemas y responsabilidades que se utilizarán en el incidente real.
La notificación es la primera obligación visible. El proyecto completo es seguridad durante todo el ciclo de vida del producto.
El CRA será plenamente aplicable desde diciembre de 2027 y exige una visión mucho más amplia que incident reporting. Los fabricantes deberán abordar evaluación de riesgos, diseño seguro, configuraciones seguras por defecto, gestión de vulnerabilidades, actualizaciones, información al usuario y mantenimiento durante el periodo de soporte, entre otros requisitos.
Security by design
La seguridad debe entrar en requisitos, arquitectura y desarrollo, no añadirse al final como una prueba previa al lanzamiento.
Security by default
La configuración inicial debe reducir riesgo. El usuario no debería necesitar endurecer manualmente el producto para alcanzar un nivel razonable de seguridad.
Vulnerability handling
Detectar, priorizar, corregir y comunicar vulnerabilidades durante el periodo de soporte pasa a ser una disciplina central del producto.
Soporte y actualizaciones
El producto debe mantenerse durante el tiempo previsto de uso y disponer de mecanismos para corregir vulnerabilidades de forma adecuada.
La ventaja de empezar por reporting: obliga a descubrir las dependencias que necesitarás también para 2027.
Inventario, versiones, componentes, responsables, evidencias, clientes, soporte y capacidad de corregir un producto son necesarios para reportar un incidente y también para gestionar la seguridad durante todo el ciclo de vida. El trabajo de 2026 no se pierde: se convierte en cimiento del cumplimiento completo.
Cómo saber si la empresa está realmente preparada y no solo “trabajando en el CRA”.
El avance debería medirse con capacidades operativas. Tener una política aprobada es útil; poder ejecutar el proceso bajo presión es mucho más importante. Estos indicadores permiten convertir un programa regulatorio en resultados comprobables.
% de productos inventariados
No solo nombres comerciales: versión, propietario, soporte, componentes críticos, mercados y contacto técnico.
Tiempo hasta clasificación
Cuánto tarda la organización desde la primera señal hasta decidir si existe posible evento reportable y activar el equipo correspondiente.
Tiempo hasta versión afectada
Capacidad para relacionar una vulnerabilidad con builds, versiones y clientes sin revisar manualmente decenas de repositorios.
Cobertura de representantes
Personas con acceso y sustitución definida para operar la Single Reporting Platform en horario laboral y fuera de él.
Evidencia reproducible
Capacidad de reconstruir cronología, fuentes, decisiones y cambios sin depender de una única persona o de conversaciones de chat.
Simulacros superados
No basta con ejecutar el ejercicio: hay que cerrar los hallazgos y repetir hasta que los principales bloqueos desaparezcan.
Cuando aparece una vulnerabilidad crítica, la pregunta es inmediata: ¿qué productos, versiones y clientes están realmente afectados?
Ese análisis es mucho más difícil cuando la organización no mantiene una relación clara entre producto comercial, versión, build, componentes, librerías y dependencias. Una vulnerabilidad puede estar presente en una biblioteca utilizada por varios productos, pero no necesariamente en todas las versiones ni en todos los despliegues. Sin trazabilidad, cada incidente obliga a reconstruir manualmente el mapa desde repositorios, tickets y conocimiento informal.
El CRA refuerza la necesidad de tratar la seguridad de la cadena de suministro software como parte del ciclo de vida del producto. La empresa necesita conocer qué componentes incorpora, qué versiones mantiene, cuándo se introdujeron, qué producto depende de ellos y quién es responsable de evaluar y corregir una vulnerabilidad. Una Software Bill of Materials puede ser una pieza útil de este modelo, pero solo aporta valor si está conectada con producto, builds y procesos de actualización.
La preparación madura no consiste en generar un fichero SBOM para una auditoría. Consiste en poder responder con rapidez a una pregunta operacional: “esta librería vulnerable está explotándose activamente; dime en qué productos vendidos en Europa aparece, qué versiones siguen soportadas y cuándo puedo desplegar una corrección”.
Producto y versión
El inventario debe relacionar nombre comercial, versión soportada, build, fecha de publicación, mercados, propietarios y estado de mantenimiento. Sin esa relación, determinar alcance consume horas críticas.
Componentes y dependencias
Librerías open source, paquetes comerciales, firmware, imágenes de contenedor y otros componentes deben poder rastrearse hasta los productos que los incorporan.
Build y pipeline
La evidencia del pipeline ayuda a demostrar qué commit, dependencias, artefactos y controles produjeron una versión concreta. Esto acelera análisis y facilita una corrección reproducible.
Corrección y distribución
No basta con desarrollar un parche. Hay que conocer qué clientes deben recibirlo, qué canales de actualización existen y cómo comprobar que la medida correctora ha llegado a los entornos relevantes.
Una buena cadena de evidencia reduce dos tiempos a la vez: el de investigación y el de notificación.
Si producto, repositorio, build, componentes, telemetría y clientes están relacionados, el equipo puede acotar mucho antes el alcance real. Eso mejora la calidad de la respuesta técnica y evita comunicar de forma demasiado amplia o demasiado limitada durante las primeras 24 y 72 horas.
El comité no necesita cien indicadores técnicos. Necesita saber si la empresa puede actuar dentro del plazo sin improvisar.
La preparación CRA puede convertirse fácilmente en un proyecto documental que produce matrices, procedimientos y reuniones sin responder a la pregunta fundamental: ¿qué ocurrirá cuando aparezca una vulnerabilidad explotada activamente en un producto que tenemos en el mercado?
Dirección debería pedir una visión muy concreta: qué productos están dentro de alcance, qué porcentaje tiene responsable asignado, cuánto tardamos en conocer versiones afectadas, quién puede activar una notificación, si los representantes están registrados, qué fuentes de evidencia existen y cuándo fue el último simulacro.
Ese cuadro también ayuda a priorizar inversión. Si el principal riesgo está en inventario de componentes, la respuesta puede ser mejorar DevSecOps y SBOM. Si el bloqueo es investigación, habrá que reforzar observabilidad y SOC. Si el problema es gobierno, quizás lo urgente sea definir owners y escalados antes de adquirir nueva tecnología.
Alcance confirmado
Productos y versiones evaluados frente al Reglamento.
Tiempo de respuesta
Minutos u horas desde detección hasta clasificación y escalado.
Capacidad de notificación
Representantes disponibles, acceso probado y datos mínimos definidos.
Evidencia y simulación
Último ejercicio, hallazgos abiertos y trazabilidad de decisiones críticas.
Lo que conviene tener claro sobre el Cyber Resilience Act en octubre de 2026.
¿El CRA ya está aplicándose?
Sí parcialmente. El Reglamento será plenamente aplicable desde el 11 de diciembre de 2027, pero las obligaciones de notificación del artículo 14 se aplican desde el 11 de septiembre de 2026.
¿Qué debe notificarse ahora?
Los fabricantes afectados deben notificar vulnerabilidades explotadas activamente e incidentes graves que tengan impacto sobre la seguridad de productos con elementos digitales.
¿Cuál es el primer plazo?
La alerta temprana debe enviarse dentro de las 24 horas desde que el fabricante tiene conocimiento del evento que entra en la obligación de notificación.
¿Dónde se presentan las notificaciones?
A través de la Single Reporting Platform operada por ENISA, que entró en funcionamiento el 11 de septiembre de 2026 para las obligaciones CRA correspondientes.
¿Afecta solo a hardware?
No. El alcance incluye productos de hardware y software con elementos digitales comercializados en la UE, además de determinados componentes y soluciones de procesamiento remoto vinculadas al producto.
¿Todas las vulnerabilidades se notifican?
La obligación de 2026 se refiere específicamente a vulnerabilidades explotadas activamente, no a cualquier vulnerabilidad conocida. La organización necesita un proceso para distinguir ambos supuestos.
¿CRA y NIS2 son lo mismo?
No. NIS2 regula obligaciones de determinadas entidades y sectores; CRA establece requisitos para productos con elementos digitales y operadores económicos relacionados con ellos.
¿Microsoft Azure garantiza el cumplimiento?
No. Azure puede aportar controles, telemetría, identidad, evidencias y automatización, pero el cumplimiento depende del producto, los procesos del fabricante y la interpretación regulatoria aplicable.
¿Qué deberíamos hacer primero?
Confirmar alcance, inventariar productos, definir responsables, preparar Assigned Representatives, crear criterios de clasificación y ejecutar un simulacro de notificación de 24 y 72 horas.
¿Qué cambiará en 2027?
Desde el 11 de diciembre de 2027 se aplicará el grueso de los requisitos CRA sobre diseño seguro, gestión de vulnerabilidades, mantenimiento, información al usuario y ciclo de vida del producto.
Preparar CRA exige unir ciberseguridad, cloud, producto, desarrollo y operación.
Ayesa Digital combina capacidades en Microsoft Azure, seguridad, cloud, DevSecOps, datos, integración y operación. Ese enfoque transversal importa porque el CRA no se resuelve con un único servicio: requiere comprender cómo se construye el producto, cómo se monitoriza, cómo se corrige y cómo se preservan las evidencias.
Una primera evaluación puede centrarse en el escenario de 2026: alcance, productos, reporting, responsables, telemetría y simulacro. Después, el mismo mapa puede ampliarse hacia los requisitos de 2027: secure by design, vulnerabilidades, soporte, configuraciones y ciclo de vida.
El objetivo no es crear un proyecto regulatorio paralelo a la operación. Es conseguir que la seguridad diaria produzca la información, trazabilidad y capacidad de respuesta que el Reglamento exige.
Assessment de alcance
Productos, mercados, versiones, componentes, responsables y relaciones con otras obligaciones.
Incident reporting readiness
Procesos 24/72 horas, SRP, representantes, escalado, evidencias y aprobación.
Arquitectura de seguridad
Defender, Sentinel, Entra, Azure Policy, DevSecOps, observabilidad y evidencias.
Roadmap 2027
Diseño seguro, gestión de vulnerabilidades, soporte, documentación y ciclo de vida.
Comisión Europea · CRA
Información oficial sobre alcance, fabricantes, requisitos y calendario del Cyber Resilience Act.
ENISA · Single Reporting Platform
Guías, FAQs y documentación actualizada sobre registro, notificaciones y funcionamiento de la plataforma CRA.
Seguridad en Microsoft Azure
Defender for Cloud, Sentinel, Entra, Key Vault y gobierno de seguridad dentro de una arquitectura cloud coherente.
Azure Confidential Ledger
Cómo conservar evidencia crítica con integridad verificable cuando auditoría o investigación necesita demostrar que un registro no fue alterado.
¿Tu empresa podría clasificar y notificar un incidente CRA en menos de 24 horas?
Podemos ayudarte a revisar alcance, productos, responsables, reporting, evidencias y arquitectura de seguridad, y ejecutar un simulacro para detectar los bloqueos antes de que aparezca un incidente real.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)