Cyber Resilience Act: todas las herramientas y artículos
Ha pasado algo. ¿Cuándo tuvo conocimiento?
- A quién se aplica
- Un fabricante que ha tenido conocimiento de una vulnerabilidad explotada activamente o de un incidente grave en un producto que introduce en el mercado de la UE.
- Las fechas
- Un aviso inicial en 24 horas, una notificación en 72 horas y un informe final en 14 días desde que esté disponible una medida correctora o de mitigación.
- Lo único que hay que hacer
- Introduzca el momento en que tuvo conocimiento: esta página calcula los tres plazos en su zona horaria y nombra el CSIRT al que va el aviso.
24h
Alerta temprana
no se ha registrado la fecha en que tuvieron conocimiento.
72h
Notificación de la vulnerabilidad
no se ha registrado la fecha en que tuvieron conocimiento.
14días
Informe final
sin plazo hasta que haya una medida correctiva disponible.
Sus plazos de notificación del CRA
Desde el 11 de septiembre de 2026, tener conocimiento de una vulnerabilidad explotada activamente en un producto que usted introduce en el mercado de la UE pone en marcha un reloj de 24 horas. Esta página calcula los tres plazos, incluido el que la mayoría de los artículos describen mal.
Los tres relojes no comparten punto de partida
Los plazos de 24 y 72 horas corren ambos desde el momento en que tuvo conocimiento. El informe final no. Para una vulnerabilidad corre 14 días desde que esté disponible una medida correctiva o de mitigación, una fecha que puede no existir aún: una solución provisional documentada lo inicia, no solo una corrección. Para un incidente corre un mes desde la notificación de las 72 horas, así que no existe hasta que esa notificación se presenta. Donde no hay fecha, esta página dice qué anclaje falta en lugar de imprimir un número.
Pone en marcha los relojes de 24 y 72 horas.
Alerta temprana
Art. 14(2)(a)
no se ha registrado la fecha en que tuvieron conocimiento.
24 horas desde el conocimiento
Notificación de la vulnerabilidad
Art. 14(2)(b)
no se ha registrado la fecha en que tuvieron conocimiento.
72 horas desde el conocimiento
Informe final
Art. 14(2)(c)
sin plazo hasta que haya una medida correctiva disponible.
14 días después de que esté disponible una medida correctiva o de mitigación
Introduzca el momento en que tuvo conocimiento para poner en marcha los relojes.
A quién se aplica
A los fabricantes de productos con elementos digitales introducidos en el mercado de la UE, y a los administradores de software de código abierto. No hay umbral de tamaño ni exención para pymes en ningún lugar del CRA, y en virtud del artículo 69, apartado 3, la obligación de notificar alcanza a los productos que ya estaban en el mercado antes de la plena aplicación del Reglamento en diciembre de 2027.
El considerando 12 sitúa los modelos de servicios en la nube, incluido el software como servicio, fuera del CRA y dentro de NIS2, así que muchísimas empresas de software quedan por completo fuera del ámbito. Esa determinación depende de lo que usted introduce realmente en el mercado, y le corresponde a usted hacerla y registrarla. No la haremos por usted en una página de marketing.
¿Está su producto en el ámbito? Seis preguntas, una determinación por escritoLa obligación ya se aplica. Cinco cosas que tener listas hoy
Ninguna lleva mucho tiempo. Todas son imposibles de hacer bien en la primera hora de un incidente, que es cuando una empresa sin ellas descubre que las necesitaba.
- 1Decida si está dentro del ámbito, y deje la decisión por escrito. El software que se instala o descarga, las aplicaciones móviles y de escritorio, las bibliotecas y los dispositivos están dentro. El software como servicio puro está fuera. El procesamiento remoto sin el que un producto no puede funcionar vuelve a estar dentro. Una determinación registrada es lo que muestra si alguien pregunta por qué notificó o no.
- 2Localice su CSIRT. Las notificaciones van al CSIRT designado como coordinador en el Estado miembro de su establecimiento principal. Si su establecimiento principal está fuera de la UE, el artículo 14 elige el Estado miembro de su representante autorizado, luego el de su mayor importador, luego el de su mayor distribuidor, luego aquel donde están la mayoría de sus usuarios. Los coordinadores figuran abajo.
- 3Dé a la persona que va a notificar un EU Login con autenticación de dos factores. La plataforma única de notificación de ENISA exige una cuenta EU Login personal con la autenticación multifactor activada. Es una tarea de diez minutos en un día tranquilo y muy larga en la hora veintitrés.
- 4Nombre a esa persona, y a un suplente. El reloj de 24 horas no se detiene por las vacaciones.
- 5Acuerden qué significa "tener conocimiento" para ustedes. Ese momento pone en marcha el reloj, y un equipo que no ha decidido si el disparador es un correo de un cliente, una alerta del escáner o un exploit confirmado lo discutirá mientras corren las horas.
Adónde van las notificaciones
Al CSIRT designado como coordinador para su establecimiento principal, y a ENISA, ambos a través de la plataforma única de notificación de ENISA, que abrió el 11 de septiembre de 2026, el día en que empezó la obligación, y que según la FAQ de ENISA leída el 21 de septiembre de 2026 funciona solo en inglés, no tiene API y exige un EU Login personal con autenticación multifactor. Nada en esta página presenta nada; le dice cuándo tendría que hacerlo. La plataforma está en portal.cra-srp.enisa.europa.eu FAQ de ENISA
La tabla es la lista de CSIRT designados como coordinadores tal como ENISA la publicó el 10 de septiembre de 2026, el día antes de abrir la plataforma, leída el 12 de septiembre de 2026; el enlace es la primera página de contacto que ENISA da para cada Estado. En la mayoría de los Estados es el CSIRT nacional que el Estado designó para la red de CSIRT de la UE. Es un organismo distinto en Croacia (NCSC-HR), Chequia (NÚKIB). ENISA dice que una notificación presentada al coordinador equivocado puede ser invalidada y tener que presentarse de nuevo; la fila de su establecimiento principal es, por tanto, la que debe figurar en su procedimiento de incidentes. Lista de ENISA.
| Estado miembro | CSIRT designado como coordinador | Página de contacto |
|---|---|---|
| Austria | CERT.at · Computer Emergency Response Team Austria | www.cert.at |
| Bélgica | CCB · Centre for Cybersecurity Belgium | ccb.belgium.be |
| Bulgaria | CERT Bulgaria · CERT Bulgaria | www.govcert.bg |
| Croacia | NCSC-HR · National Cyber Security Centre of Croatia | ncsc.hr |
| Chipre | CSIRT-CY · National CSIRT-CY | www.csirt.cy |
| Chequia | NÚKIB · National Cyber and Information Security Agency | nukib.gov.cz |
| Dinamarca | FE DDIS · Danish Defence Intelligence Service, formerly CFCS | www.fe-ddis.dk |
| Estonia | CERT-EE · CERT Estonia | www.ria.ee |
| Finlandia | NCSC-FI · National Cyber Security Centre Finland | www.kyberturvallisuuskeskus.fi |
| Francia | CERT-FR · CERT-FR | www.cert.ssi.gouv.fr |
| Alemania | CERT-Bund · CERT-Bund at the BSI | www.bsi.bund.de |
| Grecia | EL-CSIRT · National Cyber Security Authority CSIRT | cyber.gov.gr |
| Hungría | NCSC Hungary · National Cyber Security Center of Hungary | ncsc.gov.hu |
| Irlanda | CSIRT-IE · National Cyber Security Centre Ireland | www.ncsc.gov.ie |
| Italia | CSIRT Italia · Computer Security Incident Response Team Italia | www.acn.gov.it |
| Letonia | CERT.LV · Information Technologies Security Incident Response Institution | cert.lv |
| Lituania | CERT-LT · National CERT of Lithuania | www.nksc.lt |
| Luxemburgo | CIRCL · Computer Incident Response Center Luxembourg | www.circl.lu |
| Malta | MT-CSIRT · MT-CSIRT | www.mita.gov.mt |
| Países Bajos | NCSC-NL · Nationaal Cyber Security Centrum | www.ncsc.nl |
| Polonia | CERT Polska · CERT Polska | cert.pl |
| Portugal | CERT.PT · CERT.PT at the CNCS | www.cncs.gov.pt |
| Rumanía | DNSC · Romanian National Cyber Security Directorate | www.dnsc.ro |
| Eslovaquia | SK-CERT · SK-CERT | www.sk-cert.sk |
| Eslovenia | SI-CERT · Slovenian Computer Emergency Response Team | www.cert.si |
| España | INCIBE-CERT · INCIBE-CERT | www.incibe.es |
| Suecia | CERT-SE · CERT-SE | cert.se |
Quién la aplica, Estado miembro por Estado miembro
Las multas las impone, a nivel nacional, la autoridad de vigilancia del mercado que cada Estado miembro designa conforme al artículo 52 y registra ante la Comisión. El 13 de octubre de 2026, 7 de 27 habían registrado una. El resto aparece como no registrado: es lo que contenía el registro de la Comisión ese día, no una afirmación de que el Estado carezca de plan. Los nombres figuran tal cual se registraron.
| Estado miembro | Autoridad de vigilancia del mercado (art. 52) | Autoridad notificante (art. 36) |
|---|---|---|
| Austria | no registrada | no registrada |
| Bélgica | Belgian Institute for Postal services and Telecommunications | CCB – Centre for Cybersecurity Belgium |
| Bulgaria | no registrada | no registrada |
| Croacia | no registrada | Information Systems Security Bureau |
| Chipre | Office of the Commissioner of Communications - Digital Security Authority (DSA) | Digital Security Authority - National Cybersecurity Certification Authority |
| Chequia | no registrada | no registrada |
| Dinamarca | no registrada | no registrada |
| Estonia | no registrada | Consumer Protection and Technical Regulatory Authority |
| Finlandia | Finnish Transport and Communications Agency (Traficom) | National Cyber Security Centre, Finnish Transport and Communications Agency Traficom |
| Francia | Agence Nationale des Fréquences | Agence nationale de la sécurité des systèmes d’information |
| Alemania | Bundesamt für Sicherheit in der Informationstechnik (BSI) | Bundesamt für Sicherheit in der Informationstechnik - Referat S 14 – Befugniserteilung und Aufsicht über Konformitätsbewertungsstellen |
| Grecia | no registrada | no registrada |
| Hungría | no registrada | Supervisory Authority for Regulatory Affairs |
| Irlanda | no registrada | National Cyber Security Centre |
| Italia | no registrada | no registrada |
| Letonia | Consumer Rights Protection Centre (Patērētāju tiesību aizsardzības centrs) | no registrada |
| Lituania | no registrada | Ministry of National Defence of the Republic of Lithuania |
| Luxemburgo | no registrada | no registrada |
| Malta | no registrada | Malta Digital Innovation Authority |
| Países Bajos | no registrada | Ministry of Economic Affairs – Dutch Authority for Digital Infrastructure |
| Polonia | no registrada | Ministry of Digital Affairs - Cybersecurity Department |
| Portugal | no registrada | no registrada |
| Rumanía | no registrada | no registrada |
| Eslovaquia | National Security Authority | Slovak Office of Standards, Metrology and Testing |
| Eslovenia | no registrada | no registrada |
| España | no registrada | no registrada |
| Suecia | no registrada | SWEDAC - Swedish Board for Accreditation and Conformity Assessment |
Siguiente: los plazos desde el momento de tener conocimiento, y la notificación redactada.
7 días gratis, sin tarjeta.
O el CRA Readiness Toolkit, 199 €, archivos por correo
O hecho con usted: Preparación para el CRA, 1500 €, 10 días laborables
Para diciembre de 2027 también necesita la documentación técnica
El artículo 13, apartado 12, exige documentación técnica para cada producto con elementos digitales antes de introducirlo en el mercado, conservada al menos diez años o durante el periodo de soporte, el que sea más largo, con el contenido que enumera el anexo VII. Cómprela para un producto y se redacta en su organización al pagar.
La documentación técnica, 2000 € pago únicoSi revende en lugar de fabricar, los artículos 19 a 21 le alcanzan igualmente
Un importador verifica que el fabricante hizo su parte antes de que el producto se introduzca en el mercado. Un distribuidor verifica el marcado CE y el cumplimiento del fabricante y del importador. Ponga su propia marca en un producto y el artículo 21 le convierte en su fabricante.
Obligaciones de importadores y distribuidores, 1200 €Lo que realmente vale una notificación omitida
El artículo 14 está en el nivel de sanción más alto del CRA, junto a los requisitos de seguridad del anexo I: hasta 15 000 000 EUR o el 2,5 % del volumen de negocios anual mundial. Hay tres niveles, las autoridades nacionales los aplican, y el Reglamento nombra dos veces a los pequeños fabricantes.
Los tres niveles de sanción, y quién los aplicaLas preguntas que plantea esta página, respondidas a fondo
El Reglamento de Ciberresiliencia para un pequeño fabricante de software, en doce pasos
Todo lo que una empresa de diez personas que entrega software instalado o un dispositivo tiene que hacer según el CRA, en el orden en que hacerlo: la determinación del ámbito, el nivel, el CSIRT y la autoridad de aplicación, el procedimiento de notificación que se aplica desde el 11 de septiembre de 2026, y después la documentación técnica, los 22 requisitos, la SBOM, el período de soporte, el marcado CE y la declaración, con plazo el 11 de diciembre de 2027.
¿A qué CSIRT notifica bajo el CRA? Al coordinador de su establecimiento principal, los 27 con nombre
El artículo 14 envía la notificación al CSIRT designado como coordinador por el Estado miembro de su establecimiento principal; ENISA publicó los 27 el 10 de septiembre de 2026.
Cómo presentar una notificación CRA en la plataforma de ENISA: un EU Login personal, un coordinador, tres pestañas, sin API
portal.cra-srp.enisa.europa.eu abrió el 11 de septiembre de 2026.
¿Cuándo empieza el reloj de 24 horas del CRA? Con un grado razonable de certeza tras una evaluación inicial rápida, según las directrices de la Comisión
El artículo 14 cuenta 24 y 72 horas desde 'tener conocimiento' y nunca lo define.
El reloj del informe final del CRA no empieza cuando usted tiene conocimiento
La mayoría de los textos sobre el artículo 14 del Reglamento de Ciberresiliencia dan tres plazos desde un único punto de partida: 24 horas, 72 horas, 14 días.
¿Está su producto en el ámbito del Reglamento de Ciberresiliencia? Dónde queda el SaaS
La pregunta más frecuente sobre el CRA no es cómo notificar, sino si el Reglamento se le aplica siquiera.
¿Cuándo se «introduce en el mercado» el software según el CRA, y cuál de sus builds es un producto? La regla de las orientaciones para el software independiente
Todo en el CRA pende de una fecha y de un sustantivo: la fecha en que un producto se introduce en el mercado, y si lo que usted entrega es siquiera un producto.
¿Qué partes de su backend están dentro del CRA? El tratamiento remoto de datos, según las orientaciones de la Comisión
Un producto con elementos digitales incluye sus soluciones de tratamiento remoto de datos, y el Reglamento las define en una frase.
¿Quién aplica el Reglamento de Ciberresiliencia en su Estado miembro? 7 de 27 lo han dicho
El CRA se aplica a nivel nacional, por una autoridad de vigilancia del mercado que cada Estado miembro designa y registra ante la Comisión.
¿Es su producto importante o crítico bajo el CRA? Por defecto, salvo que sea una de las 19, 4 o 3 categorías de los anexos III y IV
Estar en el ámbito del CRA significa por defecto, importante de clase I (19 categorías), importante de clase II (4) o crítico (3), y el nivel decide si se autoevalúa o necesita un organismo notificado según el artículo 32.
Por defecto, importante o crítico: las 26 descripciones técnicas del Reglamento de Ejecución 2025/2392, y la prueba de la funcionalidad principal
Los anexos III y IV del CRA nombran 26 categorías de productos en una línea cada una.
CRA anexo 1: los 22 requisitos esenciales como lista de comprobación, 14 requisitos del producto y 8 de gestión de vulnerabilidades
Lo que su producto debe cumplir desde el 11 de diciembre de 2027 y el expediente técnico debe demostrar: parte I, 14 requisitos del producto, 13 de ellos 'cuando proceda' sobre la base de su evaluación de riesgos; parte II, 8 requisitos de gestión de vulnerabilidades que se aplican siempre.
Qué contiene la documentación técnica del CRA: el anexo VII, punto por punto
Desde el 11 de diciembre de 2027, todo producto con elementos digitales introducido en el mercado de la UE necesita documentación técnica antes de introducirse, conservada diez años o durante el período de soporte, lo que sea más largo.
¿Exige el CRA una SBOM? Sí, y esto es exactamente lo que dice
El anexo I, parte II, punto 1 del Reglamento de Ciberresiliencia exige una lista de materiales de software en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel.
Qué le pide el CRA por sus dependencias: diligencia debida, notificación aguas arriba y vulnerabilidades explotables conocidas, según las orientaciones de la Comisión
Un producto de software es sobre todo código de otros.
¿CRA o NIS2? Cuál se aplica a una empresa de software, y si pueden ser las dos
El Reglamento de Ciberresiliencia regula productos introducidos en el mercado; NIS2 regula entidades que prestan servicios.
NIS2 o CRA: qué reloj de incidentes corre para una empresa de software, y qué hace 'significativo' un incidente
Ambas normas le dan 24 horas, 72 horas y un mes, y ambas ponen en marcha el reloj cuando usted 'tiene constancia'.
¿Necesita el software marcado CE según el CRA? Sí, y el artículo 30 dice dónde va
Desde el 11 de diciembre de 2027 se exige un marcado CE en todo producto con elementos digitales introducido en el mercado de la UE, software incluido.
La declaración UE de conformidad bajo el CRA: el anexo V punto por punto, la forma simplificada y un ejemplo resuelto
El artículo 28 obliga al fabricante a elaborar una declaración UE de conformidad antes de la introducción en el mercado, con la estructura tipo del anexo V, y el artículo 28(4) hace de su firma el acto por el que el fabricante asume la responsabilidad del producto.
La autoevaluación según el CRA: lo que el módulo A exige realmente, según el anexo VIII y las FAQ de la Comisión
La mayoría de los productos de software nunca verán un organismo notificado.
Normas armonizadas para el CRA: ninguna citada todavía, 41 solicitadas, las dos primeras vencían el 30 de agosto de 2026
La solicitud M/606 de 3 de febrero de 2025 pide a CEN, CENELEC y ETSI 41 normas: dos horizontales para el 30 de agosto de 2026, las verticales para los productos de los anexos III y IV para el 30 de octubre de 2026, los requisitos genéricos para el 30 de octubre de 2027.
¿Cuánto dura el periodo de soporte del CRA? Al menos cinco años, la fecha de fin indicada en la compra, cada actualización conservada diez años
Artículo 13, apartado 8, del Cyber Resilience Act: un periodo de soporte de al menos cinco años, o el tiempo de uso previsto si es menor; su fecha de fin, al menos mes y año, indicada en el momento de la compra; cada actualización de seguridad disponible diez años o el resto del periodo; el expediente técnico, la declaración y la información al usuario conservados diez años tras la introducción en el mercado o durante el periodo de soporte.
¿Qué actualización somete su software existente al CRA? Las modificaciones sustanciales, según las orientaciones de la Comisión
El software introducido en el mercado antes del 11 de diciembre de 2027 queda fuera de las obligaciones de diseño y conformidad del CRA hasta que se modifica sustancialmente.
Qué tiene que notificar según el CRA: los dos desencadenantes, tal como los define el Reglamento
El artículo 14 tiene dos desencadenantes y ambos están definidos en el texto.
¿Se aplica el CRA al software de código abierto? Tres casos, y el régimen ligero de los administradores
El Reglamento de Ciberresiliencia alcanza al software libre y de código abierto solo cuando se suministra en el marco de una actividad comercial.
¿Es su proyecto de código abierto «comercial» según el CRA? Las siete pruebas de la Comisión, con sus ejemplos
El CRA alcanza al software libre y de código abierto solo cuando se suministra en el marco de una actividad comercial, y el Reglamento deja «comercial» en manos de dos considerandos.
Qué pide el CRA a importadores y distribuidores, y cuándo los convierte en fabricante
Si revende software o dispositivos en la UE en lugar de construirlos, los artículos 19 y 20 del Reglamento de Ciberresiliencia le dan una lista de comprobación que recorrer antes de poner el producto a la venta, el deber de transmitir las vulnerabilidades al fabricante, el deber de informar a las autoridades de los riesgos significativos y diez años de conservación de registros.
La propia maquinaria del CRA de la UE, el día en que empezó la obligación: 0 organismos notificados, 0 normas armonizadas, 7 de 27 autoridades de aplicación
El Reglamento de Ciberresiliencia pide a los fabricantes que estén preparados.
La evaluación de riesgos de ciberseguridad del CRA: lo que el artículo 13 exige realmente, y el único resultado que debe producir
El artículo 13, apartados 2 a 4, del Reglamento de Ciberresiliencia convierte la evaluación de riesgos en el documento del que cuelga cualquier otra obligación del CRA.
La política de divulgación coordinada de vulnerabilidades que exige el CRA: tres disposiciones, y una política de una página que las cumple
El anexo I, parte II, punto 5, del Reglamento de Ciberresiliencia exige a todo fabricante en el ámbito establecer y aplicar una política de divulgación coordinada de vulnerabilidades.
El cálculo aquí es la misma función que ejecuta el producto, no una copia escrita para esta página, incluido el ajuste al mes natural, de modo que una notificación el 31 de enero se responde el 28 de febrero en lugar de pasar a marzo. Esto no es asesoramiento jurídico, y el artículo 14 es lo bastante corto para leerlo usted mismo: Reglamento (UE) 2024/2847.