El marcado CE lleva décadas siendo cosa de fabricantes de juguetes, ascensores y electrodomésticos. Desde el Reglamento (UE) 2024/2847 —el Cyber Resilience Act, o CRA— también es cosa de quien hace software. Si tu empresa vende un producto que se conecta a algo, tarde o temprano tendrás que firmar una declaración UE de conformidad y poner un sello CE sobre él.
El CRA entró en vigor el 10 de diciembre de 2024 y se despliega por fases hasta finales de 2027. Es, con diferencia, la norma digital europea de la que menos se habla y la que más va a cambiar el día a día de un equipo de desarrollo: no regula lo que tu software hace —eso es el AI Act o el RGPD—, sino cómo se construye, se mantiene y se parchea.
Y arranca con una paradoja difícil de mejorar: el 11 de junio de 2026 empezó a aplicarse el capítulo que crea a los evaluadores independientes, y a día de hoy prácticamente no hay ninguno designado.
Qué es el CRA y a quién aplica de verdad
El CRA es un reglamento de producto, no de servicio. Sigue la lógica de la marca CE de una lavadora: hay requisitos esenciales, el fabricante demuestra que los cumple, firma una declaración y pone el sello. La diferencia es que aquí el "producto" puede ser una aplicación, un firmware o un sistema operativo.
Qué es un "producto con elementos digitales"
La definición es deliberadamente ancha: cualquier producto de software o hardware —y sus soluciones de tratamiento de datos a distancia— cuyo uso previsto implique una conexión lógica o física, directa o indirecta, a un dispositivo o a una red, comercializado en la UE. Traducido al mundo real, entra casi todo:
- Software comercial de escritorio, móvil o servidor que se descarga o se distribuye.
- Firmware y dispositivos conectados (IoT industrial, domótica, sensores, routers, cámaras).
- Componentes que se comercializan por separado: librerías de pago, SDKs, módulos.
- La parte de procesamiento remoto necesaria para que el producto funcione. Este matiz importa: un SaaS puro no es un producto con elementos digitales, pero el backend sin el cual tu dispositivo o tu app no arranca sí se arrastra al ámbito del reglamento.
Qué queda fuera
- Productos ya regulados por normativa sectorial específica: productos sanitarios, vehículos de motor o aviación civil, entre otros. No hay doble marcado CE por el mismo motivo.
- Servicios: el SaaS "de libro", donde el cliente consume una aplicación alojada y no recibe ningún producto, queda fuera del CRA (aunque no de NIS2 ni del RGPD).
- Software libre y de código abierto publicado fuera de una actividad comercial. Publicar un repositorio no convierte a nadie en fabricante.
El software libre: fuera, con letra pequeña
Este es uno de los puntos que más ruido genera. El código abierto publicado —sin actividad comercial detrás— no genera obligaciones de fabricante. Pero el reglamento crea una figura intermedia, el administrador de software libre (open-source steward): la persona jurídica que da soporte sostenido a software libre destinado a usos comerciales y vela por su viabilidad. Sus obligaciones son aligeradas, no nulas, sobre todo en política de seguridad y notificación.
Y sobre todo: si integras código abierto en un producto que comercializas, el fabricante eres tú. Toda la cadena de dependencias que metes en tu binario pasa a ser responsabilidad tuya a efectos del CRA. Ahí es donde el software libre deja de ser "gratis".
El error más común que vemos: asumir que "como usamos librerías de terceros, la responsabilidad es del que las mantiene". No lo es. Quien pone el producto en el mercado responde del conjunto, incluidas las dependencias transitivas que probablemente nadie de tu equipo ha auditado nunca.
¿Y si desarrollo software a medida para un cliente?
Aquí toca ser honesto: es la zona gris del CRA y depende del caso. El detonante de las obligaciones es la introducción en el mercado de un producto en el marco de una actividad comercial. Un desarrollo hecho en exclusiva para un único cliente, que no se distribuye a nadie más, encaja mal en esa lógica de "producto comercializado", y buena parte del análisis sectorial apunta a que no activa las obligaciones plenas de fabricante.
Pero el matiz se rompe en cuanto ese desarrollo se replica: el momento en que el proyecto a medida se convierte en un producto que vendes a un segundo y un tercer cliente es, en la práctica, el momento en que empiezas a comportarte como fabricante. Y cuenta con que tu cliente —si él sí comercializa el producto final— te trasladará las exigencias por contrato, esté o no obligado el proveedor.
Nadie puede decirte desde fuera "tu empresa está obligada" o "tu empresa no lo está": depende de qué comercializas, a quién y bajo qué marca. Lo que sí puede decirse es que el análisis hay que hacerlo producto a producto, y que el resultado suele sorprender: casi siempre hay algo en el catálogo que entra.
Las tres categorías de producto
El CRA no exige lo mismo a todo el mundo. Clasifica los productos en tres niveles de riesgo —por defecto, importante (subdividido en clase I y clase II) y crítico— y de esa clasificación depende quién certifica: tú mismo o un tercero.
| Categoría | Qué es | Evaluación de la conformidad |
|---|---|---|
| Por defecto | La inmensa mayoría del software y de los dispositivos conectados | Autoevaluación (control interno del fabricante) |
| Importante, clase I (Anexo III) | Gestores de contraseñas, VPN, gestores de arranque, routers domésticos, software antivirus, herramientas de gestión de red, asistentes de hogar inteligente | Autoevaluación solo si se aplican normas armonizadas; si no, interviene un organismo notificado |
| Importante, clase II (Anexo III) | Sistemas operativos, hipervisores, cortafuegos, sistemas de detección de intrusiones, microprocesadores y microcontroladores con elementos de seguridad | Organismo notificado obligatorio |
| Crítico (Anexo IV) | Dispositivos hardware con cajas de seguridad, pasarelas de contadores inteligentes, tarjetas inteligentes y elementos seguros | Organismo notificado obligatorio, con posibilidad de exigir certificación europea de ciberseguridad |
Los ejemplos son ilustrativos: las listas cerradas están en los Anexos III y IV del reglamento, y la Comisión precisó las descripciones técnicas de esas categorías mediante el Reglamento de Ejecución (UE) 2025/2392. Si tu producto está cerca de una frontera, ese es el texto que hay que leer, no un resumen.
La primera pregunta útil no es "¿qué obligaciones tengo?", sino "¿alguno de mis productos es importante o crítico?". Si la respuesta es no, todo el camino es autoevaluación y el problema pasa a ser de procesos internos. Si es sí, dependes de un tercero, y ese tercero —como vamos a ver— todavía no está designado.
Qué obligaciones trae realmente
Los requisitos esenciales están en el Anexo I y se dividen en dos bloques: propiedades del producto y gestión de vulnerabilidades. El segundo es el que de verdad cambia cómo trabaja un equipo.
1. Seguridad desde el diseño
El producto debe comercializarse sin vulnerabilidades explotables conocidas, con configuración segura por defecto, superficie de ataque minimizada y protección de la confidencialidad e integridad de los datos, a partir de una evaluación de riesgos de ciberseguridad documentada que acompaña a la documentación técnica.
En la práctica: cifrado en tránsito y en reposo donde toque, sin credenciales por defecto, mínimo privilegio, actualizaciones firmadas y registro de eventos de seguridad. Nada exótico. Lo exótico es tenerlo escrito.
2. Gestión de vulnerabilidades durante todo el periodo de soporte
Esta es la parte que la mayoría de las empresas subestima. El fabricante debe:
- Identificar y documentar las vulnerabilidades y los componentes del producto.
- Corregir sin demora las vulnerabilidades, incluida la distribución de actualizaciones de seguridad gratuitas.
- Aplicar pruebas y revisiones de seguridad periódicas.
- Publicar información sobre las vulnerabilidades una vez subsanadas.
- Mantener una política de divulgación coordinada de vulnerabilidades y un canal de contacto para recibir reportes.
Todo eso durante el periodo de soporte, que el fabricante declara y que debe ser de al menos cinco años, salvo que la vida útil prevista del producto sea inferior, en cuyo caso se ajusta a ella.
Cinco años de compromiso de parcheo sobre un producto que quizá vendiste una vez. Ese es el cambio real de modelo de negocio que trae el CRA, y por eso es lo que más tarda en implantarse: no se compra, se construye.
3. SBOM: la lista de ingredientes
El fabricante debe elaborar un SBOM (Software Bill of Materials) en formato legible por máquina, que cubra al menos las dependencias de nivel superior. La Comisión puede precisar por acto de ejecución el formato y los elementos exactos, así que el detalle fino sigue abierto; los formatos de mercado —CycloneDX y SPDX— son la apuesta razonable mientras tanto.
Además, las autoridades de vigilancia del mercado pueden pedirte el SBOM para evaluar dependencias críticas a escala europea, con especial atención a los componentes de código abierto.
El SBOM es la obligación con mejor relación esfuerzo/resultado del CRA: generarlo es añadir un paso al pipeline de build. Y una vez lo tienes, alimenta gratis la gestión de vulnerabilidades: cruzas el SBOM contra las bases de CVE y sabes qué te afecta el día que sale un fallo grave en una librería.
4. Notificación de vulnerabilidades e incidentes (artículo 14)
El fabricante debe notificar a través de la plataforma única de notificación las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto, con destino a ENISA y al CSIRT designado. Los plazos son agresivos:
| Hito | Plazo |
|---|---|
| Alerta temprana | 24 horas desde que se tiene conocimiento |
| Notificación principal (con medidas correctoras) | 72 horas |
| Informe final — vulnerabilidades explotadas activamente | 14 días |
| Informe final — incidentes graves | 1 mes |
Veinticuatro horas significa que necesitas un procedimiento y una persona de guardia, no buena voluntad. Si tu equipo se entera de una explotación activa un viernes por la tarde, el reloj corre igual.
5. Marcado CE y declaración UE de conformidad
Superada la evaluación de conformidad por la vía que corresponda a tu categoría, el fabricante redacta la declaración UE de conformidad, elabora la documentación técnica y coloca el marcado CE. A partir de ahí el producto circula por el mercado único. Sin eso, no.
El calendario real
Cinco hitos, y solo el último es el "cumplimiento pleno" que todo el mundo tiene en la cabeza.
| Fecha | Qué ocurre | A quién afecta |
|---|---|---|
| 10 de diciembre de 2024 | Entrada en vigor del Reglamento (UE) 2024/2847 | A nadie en obligaciones exigibles; arranca el reloj |
| 11 de junio de 2026 | Aplicación del Capítulo IV (arts. 35 a 51): régimen de organismos notificados | A Estados miembros y organismos de evaluación; primer hito operativo |
| 11 de septiembre de 2026 | Aplicación de las obligaciones de notificación del art. 14 | A todos los fabricantes en ámbito, sea cual sea la categoría |
| 11 de diciembre de 2026 | Fecha objetivo del art. 35.2 para que los Estados garanticen un número suficiente de organismos notificados | Indirectamente, a fabricantes de productos importantes y críticos |
| 11 de diciembre de 2027 | Aplicación plena del reglamento: requisitos esenciales, conformidad y marcado CE | A todos los fabricantes |
Ojo al orden: la obligación de notificar llega antes que la de certificar. Desde el 11 de septiembre de 2026 hay que reportar vulnerabilidades explotadas activamente en plazos de 24/72 horas, mucho antes de que nadie te exija un marcado CE. Es el hito que más empresas van a pasar por alto porque no viene acompañado de un sello visible.
La paradoja: la norma ya aplica, la infraestructura no existe
El 11 de junio de 2026 empezó a aplicarse el Capítulo IV del CRA, los artículos 35 a 51: el andamiaje jurídico completo de los organismos notificados, los evaluadores independientes por los que tiene que pasar obligatoriamente un producto importante de clase II o un producto crítico antes de comercializarse en la UE.
Según el seguimiento sectorial del reglamento, quince días después —a 26 de junio de 2026— la base de datos NANDO de la Comisión seguía sin ningún organismo notificado designado para el CRA. No he podido confirmarlo en una fuente institucional directa, porque NANDO no publica un histórico consultable de esa forma; el dato procede de un tracker especializado y es coherente con el calendario: el proceso formal de designación no pudo abrirse antes del 11 de junio, y las fases nacionales de acreditación van por detrás.
La consecuencia no es teórica. Un fabricante de un producto importante de clase II que quiera tener listo su marcado CE no puede completar la evaluación, porque no hay a quién encargársela. El propio reglamento fija el 11 de diciembre de 2026 como fecha objetivo para que los Estados garanticen capacidad suficiente y evitar exactamente ese cuello de botella.
Entre junio de 2026 y la aplicación plena de diciembre de 2027 queda año y medio para construir desde casi cero toda la capacidad europea de evaluación: acreditar organismos, formar auditores y absorber la demanda de miles de fabricantes que llegarán a la vez.
Hay un segundo frente igual de relevante: las normas armonizadas. Para los productos importantes de clase I, aplicarlas es lo que permite quedarse en autoevaluación en lugar de depender de un tercero. Mientras el catálogo del CRA no esté completo, esa vía de escape no está plenamente disponible.
Régimen sancionador
El artículo 64 fija el tramo más alto para el incumplimiento de los requisitos esenciales del Anexo I y de las obligaciones de los artículos 13 y 14: multas de hasta 15.000.000 de euros o, si el infractor es una empresa, hasta el 2,5 % del volumen de negocio anual mundial total del ejercicio anterior, lo que sea mayor.
Como en el AI Act, la cifra impresiona más de lo que probablemente se aplicará a una pyme. El riesgo realista para una empresa pequeña no es la multa: es quedarse fuera del mercado. Sin marcado CE no hay comercialización, y sin documentación de conformidad no hay forma de entrar en la cadena de suministro de un cliente grande, que te la exigirá por contrato mucho antes que ninguna autoridad.
Qué hacer ya
No hace falta un programa de cumplimiento completo en 2026. Hace falta empezar por lo que tarda.
1. Inventaria lo que comercializas (una semana)
Lista todo lo que tu empresa pone en el mercado y tenga algún tipo de conexión: software, firmware, dispositivos, componentes vendidos por separado, integraciones que distribuyes. Para cada uno anota qué es, bajo qué marca sale, a quién se vende, si es desarrollo exclusivo para un cliente o producto replicable, y qué backend necesita para funcionar. El objetivo es separar lo que es producto de lo que es servicio o proyecto. Suele haber sorpresas en ambos sentidos.
2. Clasifica (dos días)
Para cada producto, determina si es por defecto, importante clase I o II o crítico, contrastando con los Anexos III y IV y el Reglamento de Ejecución (UE) 2025/2392. Y determina tu rol: fabricante, importador o distribuidor.
Si todo te sale "por defecto", respira: tu camino es interno y controlable. Si algo cae en importante o crítico, ese producto pasa a ser la prioridad número uno, porque su plazo depende de terceros que aún no están operativos.
3. Genera el SBOM (una tarde por producto)
Añade la generación de SBOM al pipeline de build: formato legible por máquina, versionado junto al artefacto, guardado con cada release. Es la acción con mejor retorno inmediato, aunque la obligación formal no sea exigible hasta 2027.
4. Monta el proceso de gestión de vulnerabilidades (meses)
Este es el que hay que empezar ya, porque es cultura de equipo y no se improvisa:
- Un canal público de contacto para reportes de seguridad (
security.txt, buzón dedicado) y una política de divulgación coordinada publicada. - Escaneo continuo del SBOM contra bases de vulnerabilidades, integrado en CI.
- Un SLA interno de triaje y parcheo, con criterios de severidad.
- Un canal de actualización para distribuir parches a todos los usuarios de una versión, gratis y sin fricción. Si hoy no sabes decir "en qué versión está cada cliente", eso es lo primero a resolver.
- Un procedimiento de notificación con responsables y suplentes, dimensionado para responder en 24 horas.
5. Declara el periodo de soporte (decisión de negocio)
Ponerle fecha de fin al soporte no es una decisión técnica: define durante cuántos años te comprometes a parchear gratis. Cinco años como mínimo. Conviene tomarla en frío, con el equipo comercial delante, antes de que la tome el reglamento por ti.
Quedan poco más de dos meses para el 11 de septiembre: prioriza el canal de reportes y el procedimiento de notificación, que es lo único exigible entonces. Con el inventario, la clasificación y el SBOM resueltos antes de fin de año, y el proceso de parcheo rodado durante 2027, llegas a diciembre de 2027 sin sobresaltos. Lo que no se puede hacer es montar un proceso de parcheo continuo en el último trimestre.
Lo que todavía no se sabe
Conviene no sobreactuar. Hay partes del CRA que dependen de desarrollo normativo pendiente:
- Normas armonizadas: el catálogo no está completo, y de él depende que muchos productos importantes de clase I puedan quedarse en autoevaluación.
- Formato exacto del SBOM: la Comisión puede precisarlo por acto de ejecución.
- Capacidad de evaluación: cuántos organismos notificados habrá, dónde y con qué plazos de espera es hoy una incógnita.
- Fronteras de ámbito: la línea entre producto y servicio, y el tratamiento del desarrollo a medida, se irá afinando con guías de la Comisión y la práctica de las autoridades nacionales.
Nada de esto es excusa para no empezar. Pero sí es motivo para no comprar todavía certificación de un marcado CE que aún no puede emitirse, ni herramientas que prometen "cumplimiento CRA llave en mano" sobre un marco que sigue completándose.
Aviso legal: este artículo es informativo y refleja el estado del Reglamento (UE) 2024/2847 a 1 de julio de 2026. No sustituye al asesoramiento jurídico personalizado. Si tu producto está cerca de una frontera de clasificación, consulta el texto de los Anexos III y IV y a un especialista.
¿Necesitas ayuda con la parte técnica del CRA?
En Lin-ia ayudamos a empresas españolas con la parte de ingeniería del Cyber Resilience Act: inventario y clasificación de productos, generación de SBOM en el pipeline, escaneo continuo de dependencias, canales de actualización y procedimientos de gestión y notificación de vulnerabilidades. No emitimos certificaciones —eso corresponde a los organismos notificados—, pero preparamos el producto y la documentación técnica para que la evaluación no sea un muro.
Si quieres revisar dónde estás, escríbenos a info@lin-ia.es. También te puede interesar nuestra checklist del AI Act europeo, la guía sobre qué significa la Ley de IA en España y el papel de la AESIA o la comparativa entre software a medida, SaaS y low-code.
