Ha pasado algo. ¿Cuándo tuvo conocimiento?

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. Cada paso con su artículo y el texto que lo explica.

¿A qué CSIRT notificar según el artículo 14 del CRA? Los 27 coordinadores, tal como ENISA los publica

Todas las guías sobre la obligación de notificación del Cyber Resilience Act dicen «notifique a su CSIRT nacional» y ahí se quedan. Desde el 10 de septiembre de 2026, ENISA publica el CSIRT designado como coordinador de cada uno de los 27 Estados miembros. Aquí está esa lista, la regla que determina el Estado, y los dos Estados donde el coordinador no es el CSIRT nacional.

Cómo presentar una notificación CRA en la plataforma única de ENISA, según su propio manual

La plataforma abrió el 11 de septiembre de 2026 en portal.cra-srp.enisa.europa.eu. Quién puede iniciar sesión, qué coordinador elegir, qué pide cada una de las tres presentaciones, qué calcula mal el contador de la propia plataforma y cuándo puede pedir que se retrase la difusión. Leído en las guías, las FAQ, el glosario y las condiciones de uso de ENISA, no en un resumen de ellos.

¿Cuándo empieza el reloj de 24 horas del CRA? «Tener conocimiento», según las orientaciones de la Comisión

Las 24 y las 72 horas corren desde el momento en que el fabricante «tiene conocimiento», y el Reglamento nunca dice qué significa eso. Las orientaciones de la Comisión del 27 de julio de 2026 sí lo dicen, en los apartados 211 a 218: un grado razonable de certeza, tras una evaluación inicial, tomado palabra por palabra del reglamento de ejecución de NIS2 y de las directrices sobre brechas de datos del RGPD. Qué convierte eso en un correo de un cliente, una alerta del escáner, una CVE listada en un componente, un zero-day de bug bounty y una vulnerabilidad que ya conocía antes del 11 de septiembre.

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. Los dos primeros corren desde el conocimiento. El tercero no, y para una vulnerabilidad su punto de anclaje es una fecha que puede no existir todavía. Aquí está lo que dice el Reglamento, apartado por apartado.

¿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. El software como servicio puro queda fuera y dentro de NIS2; el software instalado y descargable queda dentro; el tratamiento a distancia sin el que un producto no funciona vuelve a quedar dentro. La determinación es suya y debe dejarla por escrito. Aquí está el texto que la decide.

¿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. Para el software independiente, las orientaciones de la Comisión del 27 de julio de 2026 responden a ambas cosas en los apartados 13 a 21: una versión se introduce en el mercado una sola vez, al ofrecerse por primera vez, y cada descarga posterior cuenta desde ese día; las compilaciones por sistema operativo y los paquetes de funcionalidades son productos distintos; una aplicación web usada en un navegador no es un producto, una extensión de navegador o un cliente instalado sí. Qué significa eso para el 11 de diciembre de 2027, para las betas y para las versiones antiguas que deja en línea.

¿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. Las orientaciones de la Comisión del 27 de julio de 2026 convierten esa frase en dos pruebas acumulativas, una regla de delimitación, una lista de lo que nunca entra (CI/CD, RR. HH., CRM, telemetría, sitios web), los casos SaaS, PaaS e IaaS, y un ejemplo de banca móvil resuelto de principio a fin. Para una empresa de software con una app y una nube, esta es la línea.

¿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. El 11 de septiembre de 2026, el día en que empezó a aplicarse la obligación de notificación, siete Estados habían registrado una. Aquí está el registro, Estado por Estado, incluidos los veinte que no lo han hecho, y qué significa para un pequeño fabricante que se pregunta quién vendrá a llamar a su puerta.

¿Es su producto importante o crítico según el Reglamento de Ciberresiliencia? Los anexos III y IV completos

Una vez que un producto está en el ámbito del CRA, es por defecto, importante (clase I o II) o crítico, y el nivel decide si puede autoevaluarse o necesita un organismo notificado. Aquí están las 19, 4 y 3 categorías tal cual en el Diario Oficial, lo que cambia cada nivel según el artículo 32, y lo único que el nivel no cambia.

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. El Reglamento de Ejecución (UE) 2025/2392 de la Comisión, en vigor desde el 21 de diciembre de 2025, describe cada una técnicamente, y las orientaciones de la Comisión del 27 de julio de 2026 dicen cómo clasificar frente a ellas: por la funcionalidad principal del producto, no por lo que además hace ni por lo que integra. Las 26 descripciones literalmente, las seis reglas de las orientaciones con sus ejemplos (un SOAR no es un SIEM, un visor de registros no es un SIEM, un router con cortafuegos es un router), y qué cambia la clasificación.

CRA anexo I: los 22 requisitos esenciales, como lista de verificación

El anexo I del Reglamento de Ciberresiliencia es lo que su producto debe cumplir desde el 11 de diciembre de 2027 y lo que la documentación técnica debe demostrar. La parte I son 14 requisitos del producto, 13 de ellos «cuando proceda» sobre la base de su evaluación de riesgos; la parte II son 8 requisitos de gestión de vulnerabilidades que se aplican siempre. Aquí están en una sola tabla, con lo que pide cada uno y si puede excluirlo.

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. El anexo VII dice qué contiene en ocho puntos. Aquí están, lo que cada uno pide realmente, los cuatro documentos que presupone la parte II del anexo I, y cuánto tiempo la conserva.

¿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. Va en la documentación técnica, no se publica, y una autoridad de vigilancia del mercado puede pedirla previa solicitud motivada. Las tres frases que lo deciden, y lo que dejan abierto.

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. El CRA hace al fabricante responsable del producto en su conjunto y le impone tres deberes hacia los componentes que contiene: diligencia debida según el artículo 13(5), notificar vulnerabilidades aguas arriba y compartir correcciones según el artículo 13(6), e introducir el producto en el mercado sin vulnerabilidades explotables conocidas. Las orientaciones de la Comisión del 27 de julio de 2026, secciones 3.4, 7.3 y 9.2, dicen qué exige cada uno y qué no: ni notificaciones duplicadas, ni obligación de que acepten su corrección, y una definición de «conocida» que incluye la base de datos CVE y la prensa.

¿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. Una empresa de software puede estar bajo una, la otra, ambas o ninguna, y la respuesta depende de dos preguntas: si introduce un producto en el mercado y si es una entidad mediana o mayor en un sector listado. Las fechas, los relojes de notificación, las multas y la tabla de decisión, a partir de los dos textos.

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'. Casi todo lo demás difiere: qué lo activa, quién lo recibe, en qué plataforma y qué cuenta. El artículo 23 de NIS2 y el Reglamento de Ejecución 2024/2690 para la empresa que opera un servicio en la nube; el artículo 14 del CRA para la empresa que entrega un producto; ambos para la empresa que hace las dos cosas. Los umbrales, criterio por criterio, y un solo procedimiento que satisface a los dos.

¿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. Para el software, el marcado va en la declaración UE de conformidad o en el sitio web que acompaña al producto, antes de introducirlo en el mercado. Qué afirma el marcado, quién puede colocarlo, cuándo se le añade el número de un organismo notificado y qué debe contener la declaración que lo sustenta.

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. Los ocho puntos del anexo V, la forma simplificada de una frase del anexo VI, las reglas que la rodean (lenguas, la declaración única, las familias de productos, 10 años de conservación), un ejemplo resuelto, y lo que cuesta una declaración ausente o incorrecta según el artículo 58 y el artículo 64.

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. Usan el módulo A, el procedimiento de control interno del anexo VIII, y «autoevaluación» es la palabra que todo el mundo emplea sin decir qué contiene. El anexo VIII, parte I, son cinco puntos; las FAQ de la Comisión añaden la lista de actividades, el hecho de que no se impone ninguna metodología de ensayo, dónde lleva un producto de software su marcado CE, las dos formas de la declaración de conformidad, y el calendario de las normas armonizadas que decide cuándo la autoevaluación deja de significar «directamente contra el anexo I».

Normas armonizadas para el CRA: qué pide la solicitud de normalización M/606, para cuándo, y qué tiene hoy un fabricante

El artículo 27 da una presunción de conformidad a los productos que siguen normas armonizadas citadas en el Diario Oficial. El 3 de febrero de 2025 la Comisión pidió 41 de ellas a CEN, CENELEC y ETSI, con plazos del 30 de agosto de 2026 al 30 de octubre de 2027; los tres aceptaron el 3 de abril de 2025. A 12 de septiembre de 2026, el índice de normas armonizadas de la Comisión sigue sin entrada para el Reglamento, lo que para un producto de clase I significa que no hay vía de autoevaluación con arreglo al artículo 32(2). Qué se pidió, las fechas, y contra qué construir mientras tanto.

¿Cuánto dura el período de soporte del CRA? Al menos cinco años, y otros tres relojes que dependen de él

El artículo 13, apartado 8, del Reglamento de Ciberresiliencia exige un período de soporte de al menos cinco años, o el tiempo de uso esperado si es menor, durante el cual se gestionan las vulnerabilidades. Su fecha de fin debe mostrarse en la compra, al menos el mes y el año. Las actualizaciones de seguridad deben seguir disponibles diez años o el período de soporte. Y la documentación técnica, la declaración y la información al usuario se conservan lo mismo. Los cuatro relojes, según el texto.

¿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. Las orientaciones de la Comisión del 27 de julio de 2026 dicen qué significa eso para una actualización de software en los apartados 103 a 113 y 122 a 124, con once ejemplos resueltos: un riesgo que no está en su evaluación de riesgos, no el tamaño del diff. Las actualizaciones de seguridad quedan en general fuera; una casilla de «recordarme» puede quedar dentro. Qué escribir en cada versión, y qué desencadena y qué no la primera modificación sustancial.

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. Una vulnerabilidad explotada activamente es aquella respecto de la cual existen pruebas fiables de que un agente malicioso la ha explotado en un sistema sin permiso del propietario (artículo 3, punto 42). Un incidente grave es el que afecta, o puede afectar, a la capacidad del producto de proteger datos o funciones sensibles, o el que conduce, o puede conducir, a código malicioso en el producto o en los sistemas de un usuario (artículo 14, apartado 5). Qué entra, qué no, y el deber de informar a los usuarios que acompaña a ambos.

¿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. Un proyecto no monetizado queda fuera. Una empresa que entrega un producto construido sobre componentes de código abierto es fabricante de ese producto. Y las fundaciones y empresas que sostienen productos de código abierto destinados a uso comercial son «administradores de software de código abierto» según el artículo 24: una política de ciberseguridad, cooperación con las autoridades y una obligación de notificación reducida, sin marcado CE ni documentación técnica. Los considerandos y el artículo, citados.

¿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. Las orientaciones de la Comisión del 27 de julio de 2026, sección 3, las convierten en siete pruebas: un precio, una edición de pago u open core, monetizar otros servicios o datos personales, servicios de soporte, donaciones, patrocinio y la condición sin ánimo de lucro, con 22 ejemplos. Dónde acaban un mantenedor, una empresa open core y una fundación, y en qué le convierte una pull request.

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. El artículo 21 le convierte en fabricante en cuanto vende bajo su propia marca o modifica sustancialmente el producto. Las obligaciones, según el texto.

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. Aquí está lo preparadas que estaban las instituciones de las que depende el 11 y el 12 de septiembre de 2026, leído en los propios registros de la Comisión: ningún organismo de evaluación de la conformidad notificado con arreglo al CRA, ninguna norma armonizada publicada en el Diario Oficial, siete Estados miembros con una autoridad de vigilancia del mercado registrada, trece con una autoridad notificante, y la lista de CSIRT coordinadores publicada la víspera, con dos Estados que nombran un organismo distinto de su CSIRT nacional. Qué significa para un fabricante con un producto de clase I, y qué registrar.

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. Debe analizar los riesgos a partir de la finalidad prevista, el uso previsible y las condiciones de uso durante el tiempo de uso esperado; decir si y cómo se aplica cada requisito del punto 2 de la parte I; decir cómo se aplican el punto 1 de la parte I y la parte II; estar documentada, mantenida al día durante el período de soporte e incluida en la documentación técnica, con una justificación clara de cada requisito excluido. Los cuatro apartados, y una estructura de una página que los satisface.

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 artículo 13, apartado 17, exige un punto de contacto único para las notificaciones, fácil de encontrar y no limitado a herramientas automatizadas; el anexo II, punto 2, exige el contacto y la ubicación de la política en la información al usuario; el anexo VII, punto 2, letra b), pone ambos en la documentación técnica. Qué pide cada disposición, qué debe decir una política y qué no debe prometer.