Tu producto ante el Cyber Resilience Act: guía completa para fabricantes

Por Kike Gandia · Co-Fundador y CEO, OSCP

El Reglamento (UE) 2024/2847, el Cyber Resilience Act, no trata a todos los productos por igual: los reparte en cuatro niveles, y de ese reparto depende si puedes firmar tú mismo la conformidad o si necesitas un organismo externo. A día de hoy no hay ninguna norma armonizada del CRA citada en el Diario Oficial de la UE ni ningún organismo notificado designado bajo el reglamento — dos ceros que, combinados, dejan sin vía de autoevaluación abierta a buena parte del catálogo de productos importantes. Quedan 15 meses hasta la aplicación plena, el 11 de diciembre de 2027, pero una parte del reglamento ya es obligatoria desde el 11 de septiembre de 2026. Esta guía explica cómo se decide tu cajón, qué exige cada fecha y qué caminos siguen abiertos — que no son todos.

Ya es obligatorio: el artículo 14, desde el 11 de septiembre

Mientras el sector mira a diciembre de 2027, el artículo 14 entró en aplicación el 11 de septiembre de 2026 y obliga ya: veinticuatro horas para el aviso temprano de una vulnerabilidad explotada activamente o de un incidente grave, setenta y dos para la notificación, y catorce días para el informe final desde que existe parche. Lo que casi nadie ha asimilado es el alcance: por el artículo 69.3, esa obligación cubre todo el catálogo, incluidos los productos que llevan años en el mercado. No hay excepción por antigüedad ni por producto descatalogado.

La notificación se hace por la plataforma única de ENISA, operativa desde ese mismo día, que hoy funciona solo por navegador y sin API. Darse de alta después del incidente es incompatible con un reloj de veinticuatro horas: hazlo ahora, no cuando lo necesites.

¿Te aplica el CRA? El filtro previo

Antes de clasificar conviene descartar. El CRA cubre los productos con elementos digitales: software o hardware, y sus soluciones de tratamiento de datos a distancia, cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos, lógica o física, directa o indirecta, con un dispositivo o una red.

La definición es más ancha de lo que parece. El software vendido por su cuenta está dentro, sin necesidad de hardware que lo acompañe. Un componente que se comercializa por separado no es un accesorio del producto final: es un producto de pleno derecho, con su propio marcado y su propia declaración. Y una conexión «indirecta» basta, de modo que un módulo que solo habla con la placa que lo alberga, si esa placa se conecta, queda dentro.

Fuera quedan el software como servicio en sentido estricto —lo que se ejecuta en el servidor del proveedor y se consume por navegador no se «introduce en el mercado»—, la infraestructura interna del propio fabricante, y el software libre distribuido al margen de una actividad comercial, que nunca llega a comercializarse. También quedan fuera, por exclusión expresa, los sectores que ya tienen su propia regulación de ciberseguridad:

Qué queda fueraBase legalMatiz que suele fallar
Productos sanitarios y de diagnóstico in vitroart. 2.2 · Reglamentos 2017/745 y 2017/746Un software hospitalario que no se califica como producto sanitario sigue dentro del CRA
Vehículos de motorart. 2.2 · Reglamento 2019/2144
Aeronáutica civilart. 2.3 · Reglamento 2018/1139La exclusión es del producto certificado, no del sector entero
Equipos marinosart. 2.4 · Directiva 2014/90/UE
Recambios idénticosart. 2.6Doble condición: componente idéntico y mismas especificaciones. Un recambio mejorado es producto nuevo
Defensa, seguridad nacional e información clasificadaart. 2.7Dice «exclusivamente»: el uso dual no se acoge a la exclusión

Los cuatro cajones: cómo decide el CRA tu categoría

El CRA divide el universo en cuatro niveles: productos por defecto, importantes de clase I, importantes de clase II y productos críticos. El primero recoge a la inmensa mayoría —en torno al 90% del mercado—; los otros tres están tasados en listas cerradas, los anexos III y IV, que solo la Comisión Europea puede modificar por acto delegado.

La regla que decide el cajón es la funcionalidad principal del producto (art. 7.1), y esto es lo primero que hay que interiorizar porque corrige la intuición. Integrar un componente listado no arrastra al producto anfitrión a la lista: una aplicación de noticias que embebe un motor de navegador no es un navegador, y un teléfono que incorpora un sistema operativo y un gestor de contraseñas se clasifica por lo que es, no por lo que lleva dentro. La pregunta correcta no es «¿mi producto contiene algo de la lista?», sino «¿aquello para lo que existe mi producto está en la lista?».

Desde el 21 de diciembre de 2025 esa pregunta ya no se responde a ojo. El Reglamento de Ejecución (UE) 2025/2392 desarrolla la descripción técnica de cada una de las veintiséis categorías de los anexos III y IV, y hoy clasificar consiste en contrastar tu producto contra ese texto legal, no contra la etiqueta comercial que le hayas puesto. Es el documento que conviene tener abierto durante el ejercicio, y el que explica por qué buena parte de los artículos publicados en 2025 se quedaron cortos.

El orden de las cinco preguntas que deciden el cajón — la primera que se cumple cierra la clasificación:

  • ¿Tiene el producto conexión de datos, directa o indirecta, con una red o un equipo? Si no, queda fuera del ámbito del CRA.
  • ¿Está cubierto por una exclusión sectorial (sanitario, automoción, aviación, marino, defensa) o es un recambio idéntico? Si sí, fuera del ámbito, sujeto a su normativa sectorial.
  • ¿Su funcionalidad principal está en el anexo IV, productos críticos? Si sí: certificación europea cuando lo exija un acto delegado del art. 8.1; en su defecto, tercero obligatorio.
  • ¿Está en el anexo III, clase II (hipervisores, cortafuegos, IDS/IPS, chips resistentes a manipulación)? Si sí: módulo B+C, módulo H o certificación «sustancial» — nunca autoevaluación.
  • ¿Está en alguna de las 19 categorías del anexo III, clase I? Si sí: autoevaluación solo si hay normas armonizadas que cubran todos los requisitos aplicables — hoy no existen, así que el tercero es obligatorio también aquí. Si no está en ninguna lista: producto por defecto, autoevaluación con el módulo A, sin tercero.

Los requisitos esenciales del anexo I son los mismos en los cuatro cajones. Lo que cambia es quién está autorizado a certificar que se cumplen.

Las 19 categorías de clase I, y las 7 de clase II y críticos

Merece la pena leerlas enteras aunque creas que no te tocan, porque hay categorías que pillan por sorpresa a fabricantes que no se veían a sí mismos como empresas de seguridad: cualquier wearable con función de monitorización de salud que no sea producto sanitario, cualquier juguete conectado que hable o localice, cualquier microcontrolador con arranque seguro.

Anexo III, clase IEjemplo típico
Gestión de identidades y accesos privilegiados, incl. lectores biométricosGestor de identidades corporativo, lector biométrico de puerta
Navegadores autónomos y embebidosNavegador de escritorio, motor web embebido en un panel
Gestores de contraseñasBóveda de credenciales de escritorio o móvil
Software que busca, elimina o pone en cuarentena código maliciosoAntivirus, EDR
Productos con función de VPNCliente y concentrador VPN
Sistemas de gestión de redPlataforma NMS de supervisión y configuración
Sistemas SIEMCorrelador de eventos de seguridad
Gestores de arranqueCargador de arranque de un equipo o empotrado
Software de PKI y emisión de certificadosAutoridad de certificación interna
Interfaces de red físicas y virtualesTarjeta de red, conmutador virtual
Sistemas operativosSO de escritorio, distribución embebida, RTOS
Routers, módems de internet y conmutadoresRouter doméstico del operador, switch gestionable
Microprocesadores con funciones de seguridadCPU con entorno de ejecución de confianza
Microcontroladores con funciones de seguridadMCU con arranque seguro y almacén de claves
ASIC y FPGA con funciones de seguridadFPGA con cifrado de bitstream
Asistentes virtuales de uso general para el hogarAltavoz o pantalla inteligente
Hogar inteligente con funciones de seguridadCerradura conectada, cámara de vigilancia doméstica
Juguetes conectados con interacción social o localizaciónMuñeco parlante conectado, reloj infantil con GPS
Wearables de salud fuera del MDR/IVDR, o para menoresPulsera de actividad, reloj deportivo
NivelCategoríaEjemplo típico
Clase IIHipervisores y motores de contenedoresHipervisor de servidor, runtime de contenedores
Clase IICortafuegos e IDS/IPSNGFW, IDS/IPS de red
Clase IIMicroprocesadores resistentes a manipulaciónProcesador seguro de un HSM
Clase IIMicrocontroladores resistentes a manipulaciónSecure element con protección física
CríticoDispositivos con cajas de seguridadMódulo de seguridad hardware, terminal de pago
CríticoPasarelas de contador inteligente y criptoprocesamiento seguroGateway de telemedida eléctrica
CríticoTarjetas inteligentes y secure elementsTarjeta bancaria, SIM/eSIM, TPM

Descripciones técnicas literales de las 26 categorías: Reglamento de Ejecución (UE) 2025/2392, anexo I (importantes) y anexo II (críticos), en vigor desde el 21 de diciembre de 2025.

Resultado según tu cajón: tabla de resultados

Un atajo a la conclusión práctica de las cinco preguntas anteriores — qué te toca hoy según dónde caigas:

Tu situaciónCajónRuta hoySiguiente paso
Sin conexión de datos, directa ni indirectaFuera del ámbitoNinguna obligación bajo el CRARevisa si un cambio futuro añade conectividad: eso te metería dentro
Exclusión sectorial o recambio idénticoFuera del ámbitoNinguna obligación bajo el CRAComprueba que la exclusión cubre el producto entero: accesorios y software auxiliar pueden seguir dentro
Software libre sin actividad comercialFuera del ámbitoNinguna obligación de fabricanteSi hay una persona jurídica que sostiene el desarrollo, revisa el régimen de administrador de software libre (art. 24), desde diciembre de 2027
Ninguna lista de los anexos III o IVPor defectoMódulo A, control interno. Sin terceroEl trabajo está en el proceso: gestión de vulnerabilidades, SBOM y período de soporte
Anexo III, clase IImportante · clase ISin normas armonizadas citadas ni organismos notificados: autoevaluación cerrada hoyPrepara el expediente como si fuera a auditoría externa; sigue la citación de EN 40000 y de la vertical ETSI de tu categoría
Anexo III, clase IIImportante · clase IIDepende de un organismo notificado que no existe todavíaEmpieza conversaciones con candidatos a organismo notificado
Anexo IV, críticoCríticoSin acto delegado adoptado ni organismos notificados designadosEstrategia de certificación desde ya, con vigilancia del esquema EUCC

Esta tabla no sustituye a un análisis de conformidad: contrasta siempre la funcionalidad principal de tu producto contra la descripción técnica literal del Reglamento de Ejecución (UE) 2025/2392 antes de darlo por bueno.

Qué cambia según el cajón: rutas de evaluación de la conformidad

Conviene deshacer un malentendido extendido: el cajón no cambia los requisitos. Los trece requisitos de producto del anexo I parte I y los ocho de gestión de vulnerabilidades de la parte II se exigen igual a un termostato que a un cortafuegos. Lo que cambia es quién está autorizado a firmar que se cumplen, y eso se traduce en dinero, en meses y en dependencia de terceros.

CajónRutas admitidas¿Organismo notificado?
Por defectoMódulo A (control interno), B+C, H, o certificación europeaNo
Clase I con normas armonizadas que cubran todos los requisitosCualquiera, incluido el módulo ANo
Clase I sin esas normas, o aplicadas en parteMódulo B+C o módulo H, respecto de los requisitos no cubiertos
Clase IIMódulo B+C, módulo H o certificación europea «sustancial»
Crítico (anexo IV)Certificación europea si lo exige un acto delegado; en su defecto, régimen de clase II

Hay un matiz del artículo 32.2 que vale dinero y que suele pasarse por alto: la regla opera requisito a requisito, no producto a producto. Si aplicas normas armonizadas que cubren once de los trece requisitos del anexo I parte I, al organismo notificado solo van los dos restantes. La aplicación parcial no manda el producto entero a auditoría, siempre que la evaluación de riesgos documente con precisión qué queda cubierto y qué no. Ese documento, el del artículo 13.2, deja de ser papeleo para convertirse en la bisagra de toda la estrategia: justifica qué requisitos son aplicables y cómo se han adaptado, es lo único que una autoridad de vigilancia podrá examinar si autoevaluaste, y es lo primero que abrirá el auditor si no lo hiciste.

El atasco de 2026 que nadie pone sobre la mesa

Dos hechos, comprobables por separado, que juntos producen un callejón sin salida.

Primero: a día de hoy no se ha citado en el Diario Oficial ni una sola norma armonizada del CRA. Las horizontales —la serie EN 40000, que desarrolla CEN-CENELEC JTC 13 WG 9— tienen tres partes con la encuesta pública cerrada y una cuarta todavía en redacción. Las verticales de ETSI, la serie EN 304 6xx, una por categoría del anexo III, abrieron encuesta pública el 13 de agosto y sus comentarios cierran de forma escalonada entre septiembre y noviembre. El mandato M/606 fijaba entrega en agosto y octubre de 2026; la Comisión circuló en julio un borrador que retrasa esos plazos dos meses, y ese borrador tampoco se ha publicado todavía. Ninguno de esos proyectos confiere hoy presunción de conformidad: aplicarlos es buena ingeniería y preparación anticipada, no cobertura jurídica.

Segundo: no consta ningún organismo notificado designado bajo el Reglamento 2024/2847. El capítulo IV, que habilita a los Estados a designarlos, se aplica desde el 11 de junio de 2026, y el propio reglamento les pide procurar un número suficiente antes del 11 de diciembre de este año.

Encadena ambos y el resultado es incómodo: sin normas armonizadas citadas, el artículo 32.2 empuja a toda la clase I hacia la rama que exige organismo notificado; la clase II ya estaba ahí por definición; los críticos también, a falta del acto delegado del artículo 8.1. Son veintiséis categorías de producto cuya evaluación de la conformidad depende hoy de una figura que no existe todavía, con quince meses por delante y un proceso de designación que tarda meses por entidad, al que hay que sumar después la capacidad de auditoría para atender a miles de fabricantes.

Los dos problemas están acoplados y se resuelven a la vez: si las horizontales se citan a tiempo, la clase I recupera la autoevaluación y la presión sobre los organismos notificados se desploma. Si no se citan, el sistema se bloquea para casi todo el anexo III. La consecuencia práctica para un fabricante de clase I es que su plan debe funcionar en los dos escenarios: preparar el expediente como si fuese a auditoría externa aunque se espere poder firmarlo uno mismo.

Queda la válvula de escape de la certificación europea. El esquema EUCC existe desde el Reglamento de Ejecución (UE) 2024/482 y ENISA publicó en febrero de 2025 un análisis de cómo podría servir al CRA. Pero el artículo 32 condiciona esa vía a que el esquema sea «aplicable conforme al artículo 27.9», y el acto delegado que debe declararlo no consta adoptado. A eso se suma una limitación material: EUCC evalúa producto, con metodología de Criterios Comunes, mientras que buena parte del anexo I parte II son requisitos de proceso organizativo —divulgación coordinada, SBOM, distribución segura de actualizaciones— que un esquema de producto no cubre por sí solo. Es la candidata natural a desatascar esto; hoy no es una salida sobre la que construir una estrategia.

«Ya tengo el marcado CE, ¿me vale?»

No. Y la razón conviene entenderla bien, porque de ella depende cuánto trabajo puedes reaprovechar y cuánto es estrictamente nuevo.

El marcado CE no es un sello genérico de calidad: se otorga por acto legislativo. Cada norma de armonización tiene sus propios requisitos esenciales, su propio procedimiento de evaluación y su propia declaración de conformidad. Un producto con CE bajo la Directiva de baja tensión, la de compatibilidad electromagnética o la de equipos radioeléctricos acredita exactamente lo que acredita esa norma, y nada más. No existe reconocimiento cruzado, ni cláusula de equivalencia, ni forma de que un expediente antiguo cubra un requisito que en ese expediente no se evaluó.

El único puente que el CRA tiende hacia atrás es el artículo 69.1, y es más estrecho de lo que parece: los certificados de examen UE de tipo y las decisiones de aprobación relativos a requisitos de ciberseguridad emitidos al amparo de otra legislación de armonización siguen siendo válidos hasta el 11 de junio de 2028. Seguir siendo válido no es lo mismo que dar presunción de conformidad con el CRA: es una cláusula de validez de certificados, no un puente de conformidad, y se agota seis meses después de la aplicación plena.

¿Hay que volver a ensayar? Depende del ensayo. Lo que se reutiliza es la evidencia; lo que no se reutiliza es la conformidad. Un informe de ensayo sigue siendo un hecho técnico verificable y entra en el expediente del CRA como prueba (el anexo VII lo prevé expresamente), pero el certificado que lo acompañaba no traslada su efecto jurídico.

Lo que ya tienesEstatus en el CRAQué hacer
Ensayos de EMC, seguridad eléctrica, exposición a radiofrecuenciaAjeno al CRANi se reutilizan ni se repiten: el CRA no los exige
Ensayos EN 18031 de control de acceso, actualización segura, confidencialidad e integridadEvidencia reutilizableMapear cada caso de ensayo al requisito del anexo I parte I e incorporarlo al expediente
Pruebas de intrusión y análisis de vulnerabilidades recientesEvidencia reutilizableSirven como prueba de las pruebas periódicas del anexo I parte II. Conviértelas en rutina, no en hito
Gestión de configuración, control de versiones, firma de firmwareBase aprovechableDocumentar el mecanismo de distribución segura de actualizaciones sobre lo que ya funciona
Evaluación de riesgos de ciberseguridad del art. 13.2No existeSe redacta de cero. Es la pieza que sostiene todo lo demás
SBOM, política de divulgación coordinada, canal de reporteNo existeTrabajo nuevo, de proceso, no de producto
Período de soporte declarado y justificadoNo existeDecisión de negocio con consecuencias de una década
Procedimiento de notificación del art. 14No existeYa exigible. No espera a 2027

Sí habrá que ensayar de nuevo en dos supuestos: cuando te apoyes en una norma armonizada del CRA —cuando las haya— cuyos casos de ensayo no se solapen con los que ya pasaste, y cuando el producto sufra una modificación sustancial, que reabre la evaluación de la parte afectada o del conjunto si el cambio compromete la ciberseguridad general. Nota práctica: cuando un producto queda sujeto a varios actos de la Unión que exigen declaración de conformidad, el artículo 28 obliga a emitir una declaración única que los identifique todos — no son dos documentos que conviven, es uno que crece.

Qué se exige en cada fecha

El CRA no entra en vigor de golpe. Se despliega en tres tramos con destinatarios distintos, y confundirlos es la fuente habitual tanto de la alarma prematura como de la falsa calma:

FechaHitoObliga aQué exige
10-12-2024Entrada en vigorEmpieza a correr el reloj. Nada exigible aún al fabricante
11-06-2026Capítulo IVEstados miembrosYa pueden designar organismos notificados (arts. 35-51). El fabricante no hace nada
11-09-2026Artículo 14 vigenteFabricantesAviso en 24h, notificación en 72h, informe final en 14 días desde el parche. Alcanza a todo el catálogo, incluso productos antiguos
11-12-2027Aplicación plenaFabricantes, importadores, distribuidores, administradores de software libreAnexo I, evaluación de conformidad, marcado CE, declaración y período de soporte. Deroga el Reglamento Delegado 2022/30 del RED
11-06-2028Fin de prórrogaQuien se apoyara en certificados previosCaducan los certificados de examen UE de tipo conservados por el art. 69.1
2032 · 2042La cola largaFabricantesSoporte mínimo de 5 años y parches disponibles otros 10 años más

Los dos relojes del artículo 14 son secuencias paralelas con un punto de partida distinto, y confundirlas es la forma más fácil de incumplir un plazo mientras se cree estar cumpliendo. Ante una vulnerabilidad explotada activamente: 24h de aviso temprano y 72h de notificación desde que se tiene conocimiento; informe final 14 días después de que exista medida correctora, no desde el conocimiento. Ante un incidente grave: 24h y 72h desde el conocimiento; informe final un mes desde la notificación de las 72h. El umbral de «incidente grave» está redactado en clave de capacidad, no de daño consumado: basta con que el incidente pueda afectar a disponibilidad, autenticidad, integridad o confidencialidad, o pueda dar lugar a ejecución de código malicioso. La notificación se dirige simultáneamente al CSIRT coordinador y a ENISA.

La frontera del 11 de diciembre de 2027

De todo el reglamento, el artículo 69.2 es probablemente el que más dinero mueve, y casi nunca aparece en los resúmenes divulgativos.

Dice que los productos introducidos en el mercado antes del 11 de diciembre de 2027 solo quedan sujetos a los requisitos del CRA si, a partir de esa fecha, sufren una modificación sustancial. El criterio no es la fecha de diseño, ni la de fabricación, ni la del catálogo: es la fecha de la primera puesta a disposición en el mercado de la Unión de cada unidad concreta. Una unidad introducida el 10 de diciembre de 2027 queda exenta de los requisitos sustantivos de forma indefinida; la unidad siguiente, introducida el día 11, entra entera. Es un corte binario, y se aplica referencia a referencia y unidad a unidad.

De ahí se sigue algo muy concreto: documentar con precisión la fecha de introducción en el mercado de cada referencia tiene valor económico directo. Es la prueba de en qué lado de la frontera cae tu inventario, y quien no pueda acreditarla asumirá el régimen más gravoso.

¿Qué es una modificación sustancial? Un cambio que altere el nivel de riesgo de ciberseguridad de un modo que el fabricante no hubiera contemplado ya en su evaluación de riesgos. La guía de la Comisión de julio de 2026 precisa que un parche de seguridad no cuenta por sí solo, porque su finalidad es reducir el riesgo, siempre que no cambie la finalidad prevista ni introduzca riesgos nuevos. Una actualización funcional que sí altera el perfil de riesgo, en cambio, tira abajo la exención y arrastra al producto al régimen completo. La evaluación de riesgos, además de ser la bisagra de la conformidad, es el documento que determina si un cambio futuro te cuesta un ciclo de ingeniería o una evaluación de conformidad entera.

Dicho esto, no conviene convertir esto en una carrera por inundar el canal antes de la fecha. La exención cubre los requisitos sustantivos, no el artículo 14, que alcanza expresamente a todo lo introducido antes de esa fecha (art. 69.3). Y un catálogo heredado que nadie va a poder actualizar sigue siendo un pasivo técnico y reputacional aunque sea jurídicamente irreprochable. La frontera es una palanca de planificación, no una estrategia de cumplimiento.

Si vienes del RED: lo que EN 18031 te da y lo que no

Para un fabricante de equipo radioeléctrico conectado, el año pasado fue el de EN 18031 y el Reglamento Delegado 2022/30. La pregunta natural es si ese esfuerzo cuenta. Cuenta, pero menos de lo que se espera, y en un plano distinto del que se espera.

Primero, el dato que ordena el resto: el Reglamento Delegado (UE) 2026/339, de 16 de febrero de 2026, deroga el 2022/30 con efecto desde el 11 de diciembre de 2027, exactamente la fecha de aplicación plena del CRA. Los considerandos son claros: los requisitos esenciales del CRA incluyen todos los elementos de las letras d), e) y f) del artículo 3.3 de la Directiva de Equipos Radioeléctricos, y se busca evitar que un mismo equipo quede sometido a dos regímenes de ciberseguridad a la vez. Hasta el 10 de diciembre de 2027 ambos conviven y la vigilancia de mercado bajo el RED sigue activa; a partir del día siguiente solo queda el CRA.

Segundo, la parte incómoda: EN 18031 está citada en el Diario Oficial en apoyo de la RED, no del CRA. La presunción de conformidad es específica del instrumento para el que se cita una norma, así que EN 18031 presume conformidad con el artículo 3.3 d), e) y f) de la RED y con nada más. Cuando lleguen las normas armonizadas del CRA, esa presunción no se transfiere sola.

Y tercero, lo que de verdad importa para planificar: el trabajo que el CRA añade sobre un fabricante que ya cumple el RED es fundamentalmente de proceso, no de producto. Los requisitos técnicos del anexo I parte I se solapan de forma apreciable con lo que EN 18031 ya obliga a demostrar en control de acceso, actualización, confidencialidad e integridad. Lo que no tiene equivalente es todo lo demás: la gestión de vulnerabilidades como proceso vivo, el SBOM, la divulgación coordinada, el canal de reporte, el período de soporte declarado, la disponibilidad de parches durante una década y la notificación del artículo 14. Ninguna de esas piezas existía en el mundo RED, y ninguna se resuelve con un laboratorio.

La recomendación operativa se sigue sola: no montes dos expedientes. Estructura el actual de modo que cada evidencia EN 18031 esté mapeada al requisito del anexo I que satisface, de forma que cuando se cite la norma CRA la migración sea un ejercicio de trazabilidad y no una repetición de ensayos.

España: a quién notificas y quién te vigila

Un reglamento europeo es directamente aplicable, pero la ejecución es nacional. En España el cuadro está a medio montar, y conviene saber qué parte ya funciona y qué parte no.

Lo que ya funciona. España ha designado a INCIBE como CSIRT coordinador a efectos del CRA, y así figura en la lista publicada por ENISA. No es el CCN-CERT ni el ESPDEF-CERT, aunque la intuición lleve a pensarlo. Los veintisiete Estados miembros han completado su designación. La notificación, eso sí, no se hace por los canales nacionales de siempre: se hace por la plataforma única de ENISA, y a fecha de hoy INCIBE-CERT no ha publicado procedimiento nacional específico de CRA.

Lo que todavía no. El proyecto de real decreto que designa a la autoridad de vigilancia del mercado y a la autoridad notificante —Secretaría de Estado de Telecomunicaciones para la primera, Centro Criptológico Nacional para la segunda, con ENAC como organismo de acreditación e INCIBE como laboratorio técnico de apoyo— lleva desde finales de 2025 en tramitación; la CNMC evacuó su informe en mayo de 2026 y no consta publicación en el BOE. Y no hay régimen sancionador nacional, ni podría haberlo por real decreto: la reserva de ley en materia sancionadora obliga a norma con rango legal, y no se conoce ningún proyecto específico.

Que no exista todavía el cauce nacional para imponer multas no es una exención de nada. La obligación del artículo 14 es directamente aplicable y exigible desde el 11 de septiembre; lo que falta es la tubería administrativa, y las tuberías acaban montándose. Contar con ese desfase como estrategia es apostar a que el retraso dure más que la memoria del expediente.

Hay además un solape que en España está latente: NIS2 sigue sin transponer. Cuando se apruebe la Ley de Coordinación y Gobernanza de la Ciberseguridad, una empresa que sea a la vez fabricante de un producto con elementos digitales y entidad esencial o importante tendrá que notificar dos veces, por dos canales, ante un mismo suceso: el CRA mira al producto y va a la plataforma de ENISA; NIS2 mira a la entidad y va al canal nacional. No hay cláusula de no duplicación.

Sanciones: cuánto cuesta fallar

El artículo 64 fija tres tramos, y en cada uno se aplica el importe más alto de los dos:

TramoImporteQué lo activa
Máximo15 M€ o 2,5% del volumen anual mundialRequisitos esenciales del anexo I y obligaciones de los artículos 13 y 14
Intermedio10 M€ o 2%Obligaciones de operadores económicos, declaración, marcado CE, expediente técnico y procedimientos de conformidad
Información5 M€ o 1%Información incorrecta, incompleta o engañosa a un organismo notificado o a la autoridad de vigilancia

El dato que conviene subrayar: el artículo 14 está en el tramo superior, al mismo nivel que un fallo en los requisitos esenciales de ciberseguridad. No es una obligación formal de segundo orden; el legislador la colocó ahí a propósito. Hay dos atenuaciones: las microempresas y pequeñas empresas quedan exentas de multa por incumplir los plazos de notificación, y los administradores de software libre quedan exentos de multas administrativas en general.

Y no se agota en el dinero. La cadena completa es notificación al CSIRT, traslado a la autoridad de vigilancia, evaluación del producto, exigencia de medidas correctoras y, si no se atienden, prohibición, retirada o recuperación con efecto en los veintisiete Estados. Una notificación puede terminar en la retirada del propio producto notificado, lo que explica por qué el procedimiento interno de decisión no puede improvisarse a las tres de la mañana.

Qué hacer, y en qué orden

Ordenado por fecha de exigibilidad, no por dificultad. Las primeras acciones no admiten espera porque el artículo 14 ya está vigente; el resto marca el ritmo hasta diciembre de 2027.

Este mes

  • Alta en la plataforma de ENISA antes de necesitarla. Se entra con cuenta EU Login y doble factor, se designa un representante principal y hasta veinte secundarios por invitación, y esas invitaciones caducan a los siete días. Sin API y sin integración con el SOC, la notificación es manual: registrarse el día del incidente es materialmente incompatible con veinticuatro horas.
  • Define qué significa «tener conocimiento» en tu organización y quién arranca el reloj. Es el hecho que activa el plazo y el que tendrás que acreditar.
  • Monta dos temporizadores, no uno: el informe final de vulnerabilidad cuenta desde que existe el parche; el de incidente, desde la notificación de las 72 horas.
  • Prepara la plantilla de comunicación a usuarios del artículo 14.8. Es obligación autónoma y acumulativa: cumplir con el regulador no exime de informar a quien usa el producto.

Este trimestre

  • Clasifica cada referencia del catálogo contra el Reglamento de Ejecución 2025/2392, no contra la intuición, y deja constancia escrita del razonamiento de funcionalidad principal.
  • Levanta el registro de fechas de introducción en el mercado por referencia. Es lo que decide de qué lado de la frontera de 2027 cae cada unidad.
  • Redacta la evaluación de riesgos del artículo 13.2 para las familias principales. Sostiene la aplicabilidad de cada requisito, la aplicación parcial de normas y la futura calificación de las modificaciones como sustanciales o no.

Según tu cajón

  • Por defecto: camino despejado, puedes avanzar sin depender de nadie. La prioridad es el proceso de gestión de vulnerabilidades, el SBOM y el período de soporte, que es donde está el trabajo real.
  • Clase I: prepara el expediente como si fuera a auditoría externa, aunque la apuesta sea firmarlo tú. Sigue la citación de las horizontales EN 40000 y de la vertical ETSI EN 304 de tu categoría, y participa en la encuesta pública si sigue abierta.
  • Clase II y críticos: el tercero es inevitable y no hay ninguno disponible todavía. Conviene estar en conversaciones con candidatos a organismo notificado antes de que lo esté todo el mercado, y evaluar si adelantar la introducción en el mercado de la generación actual antes del corte de 2027 compra el margen que falta.

Dónde encaja QuantumSec

Acompañamos a fabricantes en las piezas que no se resuelven con un laboratorio: la clasificación defendible, el expediente y el proceso que hay detrás.

  • Clasificación y análisis de aplicabilidad de cada referencia frente a los anexos III y IV y al Reglamento de Ejecución 2025/2392, con el razonamiento documentado.
  • Análisis de brechas contra los anexos I, II y VII, con reaprovechamiento explícito de la evidencia EN 18031 o de auditorías previas.
  • Evaluación de riesgos de ciberseguridad del artículo 13, redactada para sostener la aplicación parcial de normas y las decisiones futuras sobre modificación sustancial.
  • Procedimiento de notificación del artículo 14: alta en la plataforma, definición del umbral de conocimiento, relojes, plantillas y ensayo del proceso.
  • Pruebas de intrusión sobre IoT y hardware que generan evidencia utilizable en el expediente, no solo un informe.

FAQ

¿Quién asume las obligaciones de fabricante si yo no fabrico el producto?

Un importador o distribuidor que comercializa bajo su propia marca, o que modifica sustancialmente un producto ya en el mercado, asume las obligaciones del fabricante (art. 21). Cualquier otro tercero que haga una modificación sustancial y la comercialice, también (art. 22), aunque solo respecto de la parte afectada salvo que la modificación comprometa la ciberseguridad del conjunto. El representante autorizado (art. 18) actúa por mandato escrito, con obligaciones no delegables y conservación de expediente durante diez años.

¿Qué régimen aplica al software libre?

El administrador de software libre (art. 24) es la persona jurídica que sostiene de forma sistemática el desarrollo de un producto de código abierto destinado a actividad comercial. Su régimen es muy reducido —política de ciberseguridad documentada, cooperación con vigilancia de mercado y notificación limitada—, sin marcado CE ni evaluación de conformidad, y exento de multas administrativas. Sus obligaciones no nacen hasta el 11 de diciembre de 2027. Además, el software libre con documentación técnica pública recupera el módulo A de autoevaluación aunque sea producto importante (art. 32.5).

¿Qué módulos de evaluación de conformidad existen en el CRA?

Cuatro, en el anexo VIII. Módulo A (control interno): el fabricante elabora el expediente técnico, garantiza que diseño, desarrollo, producción y gestión de vulnerabilidades cumplen el anexo I, coloca el marcado y firma la declaración; conservación de diez años o el período de soporte, el más largo. Módulo B (examen UE de tipo): un organismo notificado examina el expediente, verifica los especímenes y emite el certificado. Módulo C (conformidad con el tipo): producción conforme al tipo aprobado en el módulo B, con control interno. Módulo H (aseguramiento de calidad completo): sistema de calidad aprobado y vigilado por un organismo notificado con auditoría in situ; el marcado CE lleva su número. Particularidad del CRA: los módulos B y H auditan explícitamente el proceso de gestión de vulnerabilidades, no solo el producto — un expediente impecable con un proceso inexistente no pasa.

¿Cómo funcionan exactamente los dos relojes del artículo 14?

Son dos secuencias paralelas con un punto de partida distinto. Para una vulnerabilidad explotada activamente: 24h de aviso temprano y 72h de notificación desde que se tiene conocimiento, e informe final 14 días después de que exista medida correctora o mitigadora (no desde el conocimiento). Para un incidente grave: 24h y 72h desde el conocimiento, e informe final un mes desde la notificación de las 72h. El umbral de "incidente grave" se define en clave de capacidad, no de daño consumado: basta con que el incidente pueda afectar a disponibilidad, autenticidad, integridad o confidencialidad, o pueda dar lugar a ejecución de código malicioso. La notificación va simultáneamente al CSIRT coordinador (INCIBE en España) y a ENISA.

Servicio relacionado

consultoría Cyber Resilience Act (CRA)

Contenido relacionado

Fuentes

Evaluar mi adecuación al CRA