A partir del 11 de septiembre de 2026, el Cyber Resilience Act de la UE exige a los fabricantes de productos con elementos digitales notificar las vulnerabilidades activamente explotadas a su CSIRT nacional y a ENISA siguiendo un reloj de tres fases: una alerta temprana en un plazo de 24 horas, una notificación completa en 72 horas y un informe final en los 14 días posteriores a que exista una corrección disponible. Junto a esto, el reglamento obliga a contar con una política de divulgación coordinada de vulnerabilidades (CVD) y un punto de contacto público para que los investigadores puedan reportar fallos directamente. Si lo incumples, las multas alcanzan los 15.000.000 € o el 2,5 % de la facturación anual mundial, lo que sea mayor.

Si distribuyes software en la UE, la palabra «fabricante» casi con total seguridad te incluye, la fecha está más cerca de lo que crees y «todavía no tenemos un proceso para eso» ha dejado de ser una respuesta defendible. Esto es lo que la ley realmente exige, los dos plazos que todo el mundo confunde y la capa operativa mínima que un equipo pequeño necesita para estar listo.

## El reloj que no sabías que corría: 11 de septiembre de 2026

La fecha clave es el **11 de septiembre de 2026**, cuando entra en aplicación la obligación de notificación del CRA. A partir de ese día, los fabricantes deben notificar las vulnerabilidades activamente explotadas y los incidentes graves a través de la Plataforma Única de Notificación de ENISA. Este es el primer plazo sustantivo del [Reglamento (UE) 2024/2847](https://digital-strategy.ec.europa.eu/en/policies/cra-summary), por delante del resto del reglamento, y es el que más probabilidades tiene de pillar desprevenidos a los vendedores pequeños.

La mayor parte de la cobertura sobre el CRA apunta a los fabricantes de hardware empresarial y a los grandes equipos de seguridad de producto: SBOM, marcado CE, evaluación de la conformidad. Ese encuadre ha convencido a muchos fundadores de que el CRA es problema de otros. No lo es. El reloj de notificación arranca el mismo día para todos los que entran en su ámbito, y una empresa SaaS de 20 personas con un agente descargable está tan obligada como un fabricante de dispositivos.

La consecuencia práctica es incómoda. Si una vulnerabilidad de tu producto se explota activamente la semana siguiente al plazo, tienes 24 horas para presentar una alerta temprana. Si no tienes recepción de informes, ni triaje, ni la menor idea de quién en tu empresa se encarga de esa notificación, vas a descubrir todo eso bajo la peor presión de tiempo posible.

## ¿Eres «fabricante de un producto con elementos digitales»?

Probablemente sí. El CRA define un **producto con elementos digitales** como, en esencia, cualquier software o hardware que se conecta a un dispositivo o a una red, y deposita las obligaciones centrales en el **fabricante**, un término que incluye explícitamente a los desarrolladores de software que comercializan un producto.

Eso abarca mucho más que los gadgets conectados. Plantéate si alguna de estas situaciones te describe:

- Un producto SaaS con una app de escritorio descargable, una extensión de navegador o un agente local.
- Un dispositivo conectado o cualquier hardware con firmware.
- Una biblioteca de software comercial, un SDK o un producto autoalojado vendido o licenciado en la UE.
- Un fundador o mantenedor en solitario que *da soporte comercial* a software usado en la UE.

Los importadores y distribuidores cargan con deberes más ligeros, pero si construyes y vendes la cosa, eres el fabricante. El matiz del open source también importa aquí: el open source puramente no comercial suele quedar fuera de las obligaciones del fabricante, pero en el momento en que lo monetizas (soporte de pago, una edición comercial, una versión alojada) entras en el ámbito de aplicación.

El CRA no es un terreno donde puedas improvisar asesoría legal. Si tienes dudas sobre si un producto concreto está dentro del ámbito, esa es una conversación para tu abogado. Pero la suposición por defecto de una empresa de software que vende en la UE debería ser «dentro del ámbito mientras no se demuestre lo contrario», y no al revés.

## Qué exige realmente el CRA para la divulgación de vulnerabilidades

El Cyber Resilience Act de la UE obliga a los fabricantes a operar una política de divulgación coordinada de vulnerabilidades con un punto de contacto público y, a partir del 11 de septiembre de 2026, a notificar las vulnerabilidades activamente explotadas a su CSIRT y a ENISA en un plazo de 24 horas (alerta temprana), 72 horas (notificación completa) y 14 días (informe final una vez exista una corrección). Bajo ese resumen conviven dos obligaciones distintas, y provienen de dos artículos diferentes.

**La política de CVD y el punto de contacto (artículo 13).** El artículo 13(8) exige a los fabricantes «contar con políticas y procedimientos adecuados, incluidas políticas de divulgación coordinada de vulnerabilidades… para tratar y subsanar posibles vulnerabilidades… notificadas por fuentes internas o externas». El artículo 13(17) exige un **punto de contacto único** para que cualquiera, incluidos los investigadores de seguridad, pueda reportar una vulnerabilidad directamente. Y algo crucial: debe permitir que quien reporta elija su canal de comunicación; no puedes obligar a todo el mundo a pasar por una única herramienta automatizada.

**La obligación de notificación (artículo 14).** Este es el reloj de 24 / 72 / 14 hacia los reguladores, y es donde viven los plazos de horas fijas.

Aquí hay que matar un mito. Varios blogs de proveedores afirman que el CRA impone un **plazo de 48 horas para acusar recibo del informe de un investigador**. No es cierto. El texto legal del artículo 13 no contiene ningún plazo de horas fijas para el acuse de recibo. Los únicos relojes de horas fijas del reglamento son los de notificación a los reguladores del artículo 14. Trata un SLA de acuse de recibo como una buena práctica que tu política debería definir, no como una cifra que atribuir a la ley.

## La cadencia de notificación de 24 / 72 / 14, y qué la dispara

Para una vulnerabilidad activamente explotada o un incidente grave, la cadencia de notificación es un reloj de tres fases, todas medidas desde el momento en que tienes conocimiento:

| Fase | Plazo | Qué es |
|---|---|---|
| Alerta temprana | **24 horas** | Un primer aviso de que tienes una vulnerabilidad activamente explotada o un incidente grave. |
| Notificación completa | **72 horas** | Una imagen más completa: detalles, estado, y cualquier medida correctiva o de mitigación adoptada. |
| Informe final (vulnerabilidades) | **14 días** tras existir una corrección | El informe de cierre una vez existe una medida correctiva. |
| Informe final (incidentes graves) | **1 mes** | El informe de cierre para incidentes graves. |

Presentas una sola vez. La **Plataforma Única de Notificación**, establecida, gestionada y operada por [ENISA](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp), encamina tu notificación simultáneamente al CSIRT designado como coordinador en el Estado miembro de tu establecimiento principal y a ENISA. Ese CSIRT receptor la difunde después, sin demora, a los demás CSIRT nacionales pertinentes. La plataforma también acepta notificaciones voluntarias de vulnerabilidades, amenazas, incidentes y cuasiaccidentes de cualquier persona.

El disparador es estrecho, y acertar con esto importa tanto como los plazos. El reloj de 24 horas solo arranca para una **vulnerabilidad activamente explotada** —es decir, cuando hay pruebas fiables de que un actor malicioso la ha explotado— o para un **incidente grave** —es decir, un impacto grave en la disponibilidad, autenticidad, integridad o confidencialidad del producto—. No todos los fallos que reporta un investigador disparan el reloj del regulador. La mayoría no lo harán. Pero no puedes distinguir uno de otro sin un paso de triaje capaz de clasificar rápidamente lo que acaba de aterrizar en tu bandeja de entrada, que es precisamente la razón por la que un pipeline en marcha que vaya de la recepción al triaje es el núcleo operativo de estar listo para el CRA.

## Los dos plazos que la gente confunde: 2026 frente a 2027

Buena parte de la cobertura secundaria funde dos fechas en una, y esa confusión genera una falsa sensación de seguridad. Mantenlas separadas:

- **11 de septiembre de 2026** — se aplica la obligación de notificación (artículo 14). El reloj de 24 / 72 / 14 hacia ENISA y tu CSIRT está activo.
- **11 de diciembre de 2027** — la fecha principal de aplicación del CRA, cuando las obligaciones permanentes del fabricante, incluidas la política de CVD y el punto de contacto único del artículo 13, se aplican a los productos introducidos en el mercado.

Es tentador leer la fecha de 2027 y concluir que tienes dieciocho meses de respiro. No los tienes. El reloj de notificación arranca en 2026, y no puedes cumplir una obligación de notificar en 24 horas sin tener ya en su sitio la recepción, el triaje y la asignación de responsabilidad que describe la política de CVD. La obligación de 2027 formaliza el proceso; la de 2026 da por hecho que ya sabes ejecutarlo. En la práctica, eso significa que la infraestructura de divulgación tiene que existir este año.

## Qué debe contener un flujo de CVD conforme

Sintetizando la norma con la orientación de profesionales, incluida la [guía de preparación para el CRA de HackerOne](https://www.hackerone.com/blog/cyber-resilience-act-vdp-2026-reporting-readiness), un flujo de divulgación coordinada defendible tiene seis partes:

1. **Recepción pública y documentada.** Un punto de contacto único, en la práctica un archivo [`security.txt` según RFC 9116](https://www.rfc-editor.org/rfc/rfc9116) más una página de política publicada, para que un investigador que encuentre un fallo sepa exactamente adónde enviarlo.
2. **Alcance declarado.** Qué productos y versiones están cubiertos, qué queda explícitamente fuera de alcance y qué clases de vulnerabilidad no aceptas.
3. **Triaje y validación.** El paso que decide si un informe es una vulnerabilidad activamente explotada o un incidente grave, el disparador del reloj de 24 horas.
4. **Coordinación con quien reporta.** Un canal real de diálogo con el investigador antes de la divulgación pública.
5. **Subsanación sin demora indebida y un aviso público** una vez que se publica la corrección.
6. **Registros auditables.** Responsabilidad trazable y una cronología que puedas entregar a una autoridad de vigilancia del mercado cuando lo solicite.

Ese último punto es el que los equipos se saltan y luego lamentan. «Coordinamos de forma responsable» es una afirmación. Una cronología con marcas de tiempo que muestre cuándo llegó el informe, cuándo se hizo el triaje, cuándo se informó a quien reportó y cuándo se publicó la corrección es una prueba. Bajo un reglamento con multas escaladas según los ingresos, la diferencia entre una afirmación y una prueba lo es todo.

## El precio de equivocarse

El incumplimiento de los requisitos esenciales y de las obligaciones de los artículos 13 y 14 está sujeto a multas administrativas de **hasta 15.000.000 € o hasta el 2,5 % de la facturación anual mundial total del ejercicio anterior, lo que sea mayor**. Por debajo hay dos tramos menores:

| Infracción | Multa máxima |
|---|---|
| Incumplimiento de los requisitos esenciales y de las obligaciones de los artículos 13 y 14 | **15 M € o 2,5 % de la facturación mundial** |
| Otras obligaciones del reglamento | 10 M € o 2 % de la facturación |
| Suministrar información incorrecta o engañosa a las autoridades | 5 M € o 1 % de la facturación |

La construcción «lo que sea mayor» es la parte que los fundadores subestiman. Para una empresa pequeña, las cifras absolutas en euros parecen problemas de empresa grande, pero los tramos porcentuales escalan hacia abajo contigo, y la estructura del reglamento implica que los fallos de *proceso* (no tener política de CVD, una notificación omitida, una presentación engañosa) son justo los que resultan baratos de prevenir y caros de ignorar.

<div class="blog-inline-cta">
  <p><strong>Más cerca de lo que parece.</strong> El reloj de notificación arranca el 11 de septiembre de 2026, y no puedes cumplir un plazo de 24 horas sin tener ya en marcha la recepción, el triaje y el rastro de auditoría. El módulo CSIRT de Kit te da los tres listos para usar.</p>
  <p><a href="/users/sign_up">Empieza tu prueba gratuita</a></p>
</div>

## Construye con Kit un proceso de divulgación coordinada listo para el CRA

El CRA convierte la divulgación coordinada de vulnerabilidades de un lujo de madurez en una obligación legal con fecha límite firme y un coste escalado según los ingresos. Para la mayoría de fundadores, la brecha es operativa, no filosófica: necesitas una recepción, un proceso de triaje, un reloj de SLA, un canal de coordinación y un rastro de auditoría, y los necesitas antes de septiembre. Montar todo eso desde cero bajo presión de plazos es la trampa. La vertical CSIRT de Kit es esa capa operativa, y encaja casi uno a uno con lo que pide el reglamento.

- **Recepción pública del VDP.** Un portal de seguridad en vivo más un `security.txt` generado según RFC 9116 (con campos de contacto, política, agradecimientos y cifrado) te dan, de un solo movimiento, el punto de contacto único del artículo 13(17) y la política de CVD publicada. Es la misma base que cubrimos en [cómo montar un programa de divulgación de vulnerabilidades](/blog/how-to-set-up-vulnerability-disclosure-program), ahora con una fecha límite legal encima.
- **Validación del alcance.** Un alcance configurable (objetivos dentro de alcance, categorías fuera de alcance, tipos de vulnerabilidad excluidos) más la comprobación automática del alcance en la recepción te dan la política documentada que exige la norma y la base para validar los informes a medida que llegan.
- **Triaje de severidad.** La sugerencia de severidad, la evaluación y la detección de duplicados integradas son el paso de triaje que identifica una vulnerabilidad activamente explotada o un incidente grave, el disparador exacto del reloj del regulador.
- **Seguimiento de SLA.** Un temporizador en vivo con objetivos basados en la severidad y métricas de cumplimiento te dan el reloj y la prueba de que lo cumpliste. Los SLA por defecto de acuse de recibo y resolución de Kit hacen eco deliberadamente de la cadencia del regulador, aunque son una buena práctica, no las cifras de acuse de recibo que marca la ley.
- **Coordinación con investigadores.** La mensajería en hilos mantiene en un único lugar auditable el diálogo coordinado y previo a la publicación que pide la norma.
- **Cronología auditable del informe.** Una cronología exportable convierte «coordinamos de forma responsable» en el registro trazable que una autoridad de vigilancia del mercado puede solicitar.

El encuadre honesto importa. Kit hace operativa la capa de divulgación, coordinación y conservación de registros. No es asesoría legal, no presenta la notificación a la Plataforma Única de Notificación por ti y no cubre los deberes de seguridad de producto y conformidad del CRA, como los SBOM y el marcado CE. Para eso, habla con tu abogado. Lo que Kit te da es la columna vertebral de la CVD: el proceso en marcha que hace que, cuando un investigador encuentre un fallo, o una vulnerabilidad resulte estar siendo explotada, puedas recibirlo, hacer el triaje, coordinarlo y producir la cronología, en lugar de descubrir el 11 de septiembre de 2026 que no tienes ningún proceso el mismo día en que arranca el reloj de un regulador.

La divulgación coordinada siempre fue lo correcto hacia los investigadores que encuentran tus fallos. El CRA simplemente la convirtió en lo defendible para tu negocio. El flujo que te hace un buen actor frente a los investigadores es el mismo flujo que te hace cumplidor, y el momento más barato para construirlo es antes del plazo, no después del primer fallo explotado. [Empieza tu prueba gratuita](/users/sign_up) y monta un proceso de divulgación listo para el CRA mientras todavía hay holgura en el reloj.