El reloj del Cyber Resilience Act ya corre: junio y septiembre de 2026 dejan de ser fechas decorativas

Hay reglamentos europeos que se aprueban con ruido y se aplican con bostezo. Este no. El Cyber Resilience Act (CRA) tiene una peculiaridad que muchas empresas siguen infravalorando: no llega de una vez, sino por fases. Y las dos primeras fechas con dientes son junio y septiembre de 2026. Dicho de otra forma: quien haya interpretado que “2027 queda lejos” probablemente está leyendo el calendario con optimismo temerario.

La noticia que ha circulado estos días pone el foco precisamente ahí: la cuenta atrás ya no va hacia la aplicación general del reglamento, sino hacia los primeros hitos intermedios. Eso cambia la conversación. Ya no estamos discutiendo si el CRA afectará o no al negocio. Estamos discutiendo qué obligaciones empiezan antes, quién las asume dentro de la organización y qué evidencia habrá que poder enseñar cuando un regulador, un cliente o un distribuidor pregunte lo obvio: “¿cómo demuestras que tu producto cumple?”.

Conviene ordenar el terreno. El Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act, se publicó en el Diario Oficial de la Unión Europea el 20 de noviembre de 2024 y entró en vigor el 10 de diciembre de 2024. Su regla general es que la mayor parte de obligaciones serán aplicables a los 36 meses de su entrada en vigor, es decir, desde el 11 de diciembre de 2027. Pero hay excepciones. Y son las que importan ahora: las obligaciones de notificación relativas a vulnerabilidades explotadas activamente e incidentes graves empiezan antes; y las normas sobre organismos de evaluación de la conformidad también se adelantan.

Ese diseño no es un detalle técnico. Es una pista política y operativa. Bruselas está diciendo dos cosas al mercado a la vez. Primera: quiere capacidad temprana de visibilidad sobre fallos explotados en productos con elementos digitales. Segunda: quiere tener lista, antes de la aplicación plena, la maquinaria institucional que tendrá que certificar y evaluar conformidad en los casos en que no baste la autoevaluación. Traducido al castellano llano: antes de pedir cumplimiento total, la UE quiere que ya existan radar y árbitros.

Qué ocurre exactamente en 2026, y por qué no es una mera fase preparatoria

Las fechas importan. Mucho. Y aquí no conviene hablar en abstracto.

El CRA establece que determinadas disposiciones serán aplicables a los 21 meses desde la entrada en vigor. Si se toma como referencia el 10 de diciembre de 2024, ese umbral cae en septiembre de 2026. Entre ellas está el régimen de notificación de vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad del producto. El núcleo está en el artículo 14 del reglamento, que impone al fabricante la obligación de notificar la vulnerabilidad explotada activamente y el incidente grave a ENISA sin dilación indebida y dentro de los plazos fijados por la norma.

El otro hito se adelanta a los 18 meses desde la entrada en vigor, es decir, junio de 2026. Ahí empiezan a aplicar las disposiciones relativas a la notificación y designación de organismos de evaluación de la conformidad. No es la parte más mediática del reglamento, pero sí una de las más decisivas. Si tu producto cae en categorías que requieren intervención de tercero, no basta con tener voluntad de cumplimiento: hace falta que existan organismos notificados, criterios homogéneos y capacidad real para procesar expedientes. Quien haya seguido de cerca MDR, IVDR o incluso la historia europea de la certificación en ciberseguridad sabe que cuando la infraestructura de conformidad llega tarde, el atasco se convierte en política industrial por otros medios.

El resultado es bastante menos cómodo de lo que sugiere la lectura superficial de “aplicación general en 2027”. Para septiembre de 2026, algunos fabricantes ya tendrán que operar un circuito de detección, análisis y notificación con ENISA. Y para junio de 2026, el ecosistema institucional debería empezar a moverse para que haya capacidad de evaluación. Eso exige presupuesto, clasificación de producto, inventario de componentes, procesos internos y una relación mucho más adulta con el SBOM que la de muchas empresas que todavía lo tratan como una promesa de PowerPoint.

El gran error de lectura: creer que el CRA es solo un asunto de fabricantes de hardware

Uno de los malentendidos más persistentes con el CRA es pensar que va de routers, cámaras IP y electrodomésticos con wifi. Ese universo entra, desde luego. Pero quedarse ahí es no haber entendido el alcance del reglamento.

El CRA aplica a los “productos con elementos digitales”, una categoría deliberadamente amplia que cubre tanto software como hardware y sus soluciones de procesamiento de datos a distancia cuando son esenciales para el funcionamiento del producto. Ahí caben sistemas operativos, aplicaciones empresariales, componentes embebidos, dispositivos conectados, plataformas industriales y un largo etcétera. La definición importa porque rompe una vieja comodidad del mercado: la idea de que la seguridad del software puede tratarse como servicio postventa o buena práctica voluntaria. Con el CRA, la seguridad pasa a ser requisito regulatorio ex ante para la comercialización.

El reglamento también distribuye obligaciones entre fabricantes, importadores y distribuidores. No todos hacen lo mismo, pero ninguno sale indemne. El fabricante carga con la parte más dura: diseñar y desarrollar conforme a requisitos esenciales de ciberseguridad, gestionar vulnerabilidades durante el ciclo de vida del producto, elaborar documentación técnica, realizar evaluación de conformidad, emitir declaración UE de conformidad y colocar el marcado CE. El importador no puede hacerse el sorprendido: debe verificar que el fabricante ha hecho lo suyo antes de introducir el producto en el mercado. El distribuidor tampoco actúa como simple estantería con IVA: tiene que comprobar que el producto lleva marcado CE y que va acompañado de la documentación e información exigidas.

Este reparto recuerda al Nuevo Marco Legislativo de la UE aplicado a seguridad de producto, pero con una novedad incómoda para muchos equipos jurídicos y de ingeniería: la ciberseguridad deja de ser un atributo técnico difuso y se convierte en condición de acceso al mercado interior. Ya no es “nos gustaría endurecer la gestión de vulnerabilidades”; es “si no lo haces, el producto no debería estar ahí”.

Y aquí aparece un segundo error habitual. Algunas empresas de software empresarial creen que, como venden B2B y no a consumidores, el impacto será menor. Mala lectura. El CRA no está construido como una norma de consumo masivo, sino como una regulación horizontal de seguridad para productos con elementos digitales introducidos en el mercado de la Unión. El canal de venta no te salva.

El artículo 14 no es un trámite: obliga a construir una capacidad de respuesta regulatoria

Si hubiera que elegir una disposición del CRA que va a separar a las compañías preparadas de las que improvisan, esa sería el artículo 14. No porque la obligación de notificar sea conceptualmente nueva. Eso ya existe en otros marcos. El problema es que aquí la obligación recae sobre el fabricante del producto y se vincula a vulnerabilidades explotadas activamente e incidentes graves con impacto en la seguridad del producto.

El reglamento prevé una notificación temprana a ENISA sin dilación indebida y, en principio, dentro de las 24 horas siguientes a tener conocimiento de la vulnerabilidad explotada activamente o del incidente grave. Después deben remitirse actualizaciones y un informe final en los plazos previstos. El detalle exacto del flujo no es un adorno burocrático; condiciona cómo debe organizarse internamente la empresa.

Para cumplir de verdad, hacen falta al menos cinco cosas.

La primera es saber qué productos tienes realmente en mercado y qué componentes críticos incorporan. Parece elemental, pero en empresas que han crecido a base de adquisiciones, líneas heredadas, OEMs o repositorios dispersos, la pregunta “¿qué versión exacta está desplegada en qué clientes?” puede producir silencios incómodos.

La segunda es contar con telemetría o canales de inteligencia suficientes para detectar explotación activa. No basta con conocer una CVE publicada. El artículo 14 no habla de cualquier vulnerabilidad, sino de una vulnerabilidad explotada activamente. Eso obliga a conectar gestión de producto, PSIRT, threat intelligence, soporte y, en algunos casos, datos que vienen de partners o clientes. Si hoy tu organización tarda tres semanas en confirmar si una explotación es real o te enteras por X cuando el exploit ya circula, septiembre de 2026 no será amable.

La tercera es tener criterios de clasificación. Qué se considera “incidente grave” a efectos del CRA no puede dejarse a una discusión improvisada entre legal, ingeniería y comunicación a las ocho de la tarde. Deben existir umbrales internos, responsables de decisión y una matriz clara para activar notificación. La ironía aquí es conocida: muchas organizaciones tienen runbooks impecables para caídas de servicio y un caos bastante artesanal para decidir si un fallo de seguridad es regulatoriamente notificable.

La cuarta es articular la relación con ENISA. El CRA concentra en ENISA la recepción inicial de estas notificaciones. Eso introduce una capa paneuropea que convivirá con otras obligaciones nacionales o sectoriales. La pregunta no es si tendrás que notificar solo una vez y dormir tranquilo. La pregunta real es cómo coordinarás CRA con NIS2, con DORA si eres proveedor o entidad sujeta, y con GDPR si el incidente implica datos personales. La superposición no es accidental. Es el paisaje.

La quinta es documentarlo todo. Sin eso, no hay cumplimiento defendible. El día que un regulador o un cliente pida explicación sobre cuándo se tuvo conocimiento, qué análisis se hizo, por qué se clasificó o no como incidente grave y cuándo se notificó, la empresa necesitará evidencia trazable. No opiniones retrospectivas.

La colisión práctica con NIS2, DORA y GDPR: cuatro relojes, una sola crisis

El CRA no aterriza en un vacío normativo. Aterriza en una Unión Europea que ya ha desplegado NIS2, que aplica DORA desde el 17 de enero de 2025 para entidades financieras, y que lleva años conviviendo con el artículo 33 del GDPR sobre notificación de violaciones de datos personales a la autoridad de control en 72 horas. El problema operativo no es que existan varias normas. El problema es que un mismo evento puede activar varias a la vez, con destinatarios y criterios distintos.

Imagina un fabricante de software de autenticación o de gestión remota utilizado por bancos europeos. Se detecta una vulnerabilidad explotada activamente en una librería crítica. Algunos clientes informan de intrusiones, hay alteración del servicio y existe riesgo de acceso a datos personales. De repente, entran varios relojes en paralelo.

Por CRA, el fabricante debe notificar a ENISA la vulnerabilidad explotada activamente o el incidente grave conforme al artículo 14 y dentro de los plazos específicos, con esa primera referencia de 24 horas. Si el fabricante o un operador relacionado está sujeto a NIS2, el artículo 23 introduce un aviso temprano en 24 horas, una notificación de incidente en 72 horas y un informe final en el plazo de un mes. Si la brecha afecta a datos personales, el GDPR artículo 33 exige notificar a la autoridad competente sin dilación indebida y, si es posible, a más tardar en 72 horas desde que se tuvo constancia. Si el incidente repercute en una entidad financiera sujeta a DORA, esa entidad deberá gestionar su propia clasificación y notificación de incidentes graves de TIC conforme al Reglamento (UE) 2022/2554 y a la normativa técnica derivada.

No es teoría de compliance. Es un problema de arquitectura de respuesta. Si tu empresa separa de forma rígida producto, corporativo, privacidad y regulación sectorial, cada función verá un trozo del elefante y nadie controlará la estampida completa.

La buena noticia es que las organizaciones que ya han trabajado seriamente DORA o NIS2 parten con ventaja. Ambas normas han obligado a profesionalizar inventarios, cadena de suministro, gestión de incidentes y gobierno de terceros. La mala es que el CRA mete al producto en el centro del escenario y no todas las compañías tienen esa musculatura integrada. Muchas siguen operando con una línea divisoria artificial: “seguridad corporativa por un lado, seguridad del producto por otro”. El regulador europeo, bastante menos paciente que esa estructura, está diciendo que esa separación ya no le interesa.

Junio de 2026: los organismos de evaluación de la conformidad importan más de lo que parece

La parte adelantada de junio de 2026 puede parecer una cuestión administrativa entre Estados miembros y autoridades nacionales. Error. Si el ecosistema de evaluación de conformidad no está listo, el mercado lo notará.

El CRA combina, según el tipo de producto y el riesgo, distintos mecanismos de evaluación. En muchos casos, el fabricante podrá recurrir a procedimientos de autoevaluación de la conformidad sobre la base del control interno. Pero no siempre. Para determinadas categorías, en especial las que entren en clases de criticidad o requieran esquemas más exigentes, la intervención de un organismo notificado puede convertirse en el cuello de botella de toda la cadena.

Esto ya lo hemos visto antes en otras regulaciones europeas. El papel parece sencillo: designar organismos, acreditar capacidades, establecer procedimientos. Luego llega la realidad. Falta personal experto, se acumulan expedientes, las interpretaciones no son uniformes y el mercado descubre que el calendario normativo no garantiza capacidad operativa suficiente. En sectores con ciclos de producto rápidos, un retraso de meses en la evaluación no es un matiz: es una disrupción comercial.

Por eso junio de 2026 merece atención incluso para compañías que creen que todavía “solo están mirando”. Si tu producto puede acabar necesitando evaluación por tercero, la pregunta no es cuándo pedir cita en 2027. La pregunta es si has clasificado bien el producto, si entiendes qué normas armonizadas o especificaciones técnicas previsiblemente se aplicarán, y si tienes documentación técnica con un nivel de madurez que permita someterse a evaluación sin convertir cada aclaración en una excavación arqueológica del repositorio Git.

Hay además una capa geopolítica discreta pero real. El CRA afecta a productos introducidos en el mercado de la UE, lo que incluye a fabricantes no europeos. Eso significa que proveedores globales tendrán que alinear sus prácticas de seguridad de producto para Europa, les guste o no. Si el ecosistema de evaluación europeo se congestiona, la presión sobre importadores, distribuidores y filiales europeas aumentará. Nadie quiere descubrir en 2027 que su ventaja comercial dependía de un expediente regulatorio que aún no tenía ventanilla.

Los requisitos esenciales del CRA cambian la conversación entre legal, ingeniería y compras

La parte visible del CRA son las fechas. La parte que va a doler de verdad es el contenido técnico y documental de los requisitos esenciales. El reglamento exige que los productos con elementos digitales se diseñen, desarrollen y produzcan de forma que garanticen un nivel adecuado de ciberseguridad basado en riesgos, y que se entreguen sin vulnerabilidades explotables conocidas, entre otras obligaciones. También impone que los fabricantes aborden vulnerabilidades con eficacia, incluyendo tratamiento, remediación y divulgación coordinada.

Esto tiene derivadas inmediatas para ingeniería. Ya no basta con decir que la seguridad se revisa “en el SDLC”. Habrá que demostrar controles concretos: gestión de identidades y autenticación, configuración segura por defecto, protección de la confidencialidad e integridad, minimización de superficie de ataque, logging pertinente, actualizaciones seguras, y procesos de gestión de vulnerabilidades durante el periodo de soporte. El Anexo I del CRA, con sus requisitos esenciales, no deja mucho espacio para la poesía.

También cambia la conversación con compras y con la cadena de suministro de software. Si una empresa integra componentes de terceros, software open source empaquetado, firmware OEM o servicios remotos esenciales, necesitará un grado de visibilidad contractual y técnica bastante superior al habitual. No para “hacer más compliance”, sino para sostener dos preguntas que van a llegar sí o sí: qué dependencias usa el producto y cómo se corrigen cuando aparece una vulnerabilidad. Eso es SBOM, sí. Pero SBOM de verdad, útil para respuesta y mantenimiento. No un PDF que se genera una vez para la auditoría y luego duerme en una carpeta llamada “final_definitivo_v3”.

Y legal tampoco puede quedarse en la retaguardia revisando cláusulas al final. El CRA obliga a que la información al usuario y la documentación acompañen al producto. Eso afecta a términos de soporte, duración prevista del periodo de seguridad, política de actualización, coordinación de divulgación y responsabilidades con importadores y distribuidores. El contrato deja de ser accesorio. Se convierte en una pieza de la trazabilidad regulatoria.

Qué deberían estar haciendo ya fabricantes, importadores y distribuidores

Si la empresa espera a que aparezcan guías secundarias para empezar, va a llegar tarde. El reglamento ya existe. Y aunque todavía falten normas armonizadas, actos de ejecución o práctica supervisora consolidada, hay trabajo que no depende de ninguna aclaración posterior.

Para fabricantes, la prioridad inmediata es clasificar el catálogo. Qué productos quedan dentro del ámbito del CRA, cuáles son meros servicios, qué soluciones remotas son esenciales para el funcionamiento del producto y qué componentes de terceros sustentan funciones críticas. Sin esa cartografía, cualquier plan de cumplimiento es teatro.

El segundo frente es el ciclo de vida de vulnerabilidades. Hace falta un PSIRT funcional, con canales de recepción, triage, validación, priorización, parcheo, divulgación y cierre. Si hoy la organización no puede demostrar tiempos medios de respuesta, criterios de severidad y responsabilidades claras, el artículo 14 se convertirá en una lotería.

El tercer frente es la documentación técnica. No porque un regulador adore el papel, sino porque la conformidad europea vive de la capacidad de demostrar. Arquitectura, requisitos de seguridad, resultados de pruebas, dependencias, proceso de actualizaciones, soporte, informes de evaluación, justificaciones de diseño. Todo eso debe existir de forma mantenible. El enemigo aquí no es solo el incumplimiento. Es el coste de reconstruir a posteriori decisiones técnicas que nadie documentó.

Para importadores, la tarea menos glamurosa es revisar el onboarding de proveedores y fabricantes extracomunitarios. Si introduces en el mercado un producto con elementos digitales, no puedes actuar como si la responsabilidad se agotara en la factura. Debes verificar que el fabricante ha cumplido con la evaluación de conformidad, que existe la documentación requerida y que el producto va debidamente marcado e identificado. Eso exige listas de comprobación, cláusulas de acceso documental, derechos de auditoría y mecanismos de escalado cuando el proveedor responde con vaguedades. Spoiler: responder “estamos trabajando en ello” no será una categoría regulatoria válida.

Para distribuidores, el reto es menos profundo técnicamente pero igual de real comercialmente. Tendrán que validar señales básicas de conformidad antes de poner productos a disposición en el mercado, y retirar o no comercializar productos cuando sepan o deban presumir que no cumplen. Si un mayorista o plataforma de distribución cree que su papel es neutral, el CRA le va a recordar amablemente que la neutralidad regulatoria tiene límites bastante concretos.

Implicaciones para entidades financieras españolas: el CRA no es su norma principal, pero sí su próximo dolor de terceros

Para bancos, aseguradoras, gestoras, EDEs, EAFs y buena parte del perímetro financiero español, la norma principal de resiliencia digital ya tiene nombre propio: DORA. Desde el 17 de enero de 2025, el Reglamento (UE) 2022/2554 es plenamente aplicable. Entonces, ¿por qué deberían mirar con atención un reglamento pensado para productos con elementos digitales? Porque gran parte de su exposición tecnológica entra por ahí.

La relación es más estrecha de lo que parece. DORA dedica su capítulo V a la gestión del riesgo derivado de terceros proveedores de servicios TIC, y sus artículos 28 y siguientes exigen control contractual, estrategia de concentración, registro de información y supervisión. El CRA, por su parte, actúa aguas arriba: intenta mejorar la seguridad de los productos digitales que esas entidades compran, integran o dependen de ellos para operar.

Eso tiene tres consecuencias prácticas para el sector financiero español.

La primera es de due diligence. Las entidades sujetas a DORA deberían empezar a preguntar a sus proveedores de software, dispositivos y soluciones embebidas cuál es su estrategia de cumplimiento con el CRA, especialmente si venden productos que seguirán en el mercado a partir de 2026 y 2027. No porque DORA exija citar el CRA de memoria, sino porque la resiliencia del tercero se vuelve más evaluable si el tercero tiene que cumplir requisitos horizontales de seguridad de producto.

La segunda es contractual. Los contratos de aprovisionamiento tecnológico, mantenimiento y soporte probablemente necesitarán ajustes para reflejar plazos de notificación, coordinación de incidentes, suministro de información técnica, compromiso de actualización y asistencia ante vulnerabilidades explotadas activamente. Si una entidad financiera depende de un proveedor que tarda días en confirmar exposición, el problema no es solo técnico; es regulatorio para la entidad.

La tercera es de concentración y continuidad. El CRA puede actuar como filtro de mercado. Algunos proveedores lo gestionarán bien y otros no. Eso puede influir en decisiones de sustitución, retrasos de despliegue o dependencia de unos pocos actores con mayor madurez de cumplimiento. A ojos de DORA, esa concentración no es inocua. A ojos de negocio, tampoco.

España añade además un matiz supervisor. El Banco de España, la CNMV y la DGSFP ya están empujando a las entidades hacia un control más serio de terceros, inventarios y resiliencia. El CRA no les cambia el mandato, pero sí les ofrece un nuevo lenguaje para preguntar por la seguridad de producto de lo que sus entidades compran. Y cuando supervisor y regulación horizontal empiezan a hablar dialectos parecidos, el margen para la improvisación se reduce bastante.

El problema del open source: ni demonizarlo ni usarlo como coartada

Una de las discusiones más delicadas del CRA ha sido siempre su relación con el software libre y de código abierto. Durante la tramitación, la industria y la comunidad open source presionaron para evitar que la norma desincentivara el desarrollo colaborativo no comercial. El texto final intenta distinguir entre software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial y aquel que sí se comercializa en el mercado europeo como parte de un producto.

Eso no significa barra libre. Si una empresa integra componentes open source en un producto comercializado, la responsabilidad sobre la seguridad del producto no desaparece por arte de licencia. El fabricante no puede decir “la librería era de la comunidad” y dar la conversación por cerrada. Tendrá que gestionar dependencias, evaluar exposición, corregir vulnerabilidades y cumplir con las obligaciones de notificación y documentación cuando corresponda.

La tentación de convertir el open source en chivo expiatorio sería además intelectualmente perezosa. El problema no es usar open source. El problema es usarlo sin visibilidad, sin mantenimiento real, sin gobierno de dependencias y sin capacidad de parcheo. Y ese pecado lo cometen tanto empresas cerradas como abiertas con una constancia casi entrañable.

El CRA, bien leído, no castiga el modelo open source. Castiga la irresponsabilidad industrial a la hora de empaquetarlo y ponerlo en el mercado como si la gestión de vulnerabilidades fuese una ocurrencia opcional.

Qué puede salir mal entre ahora y 2027

No todo está resuelto. Quedan piezas por aterrizar: normas armonizadas, posibles actos de ejecución, criterios interpretativos y capacidad real de supervisión. Eso abre varias zonas de fricción.

La primera es la clasificación de productos críticos o importantes y el encaje exacto de algunas categorías híbridas. En software complejo, no siempre será trivial determinar qué módulo, servicio remoto o componente funcional cae exactamente dentro del perímetro regulatorio y bajo qué procedimiento de conformidad.

La segunda es la capacidad industrial para cumplir. Muchas empresas medianas de software no tienen equipos de seguridad de producto maduros ni PSIRT formalizado. Adaptarse requerirá inversión sostenida, no un proyecto cosmético de compliance. Y sí, habrá consejos de administración que descubran con estupor que “cumplir regulación de producto” cuesta bastante más que actualizar una política interna.

La tercera es la coordinación regulatoria. Si ENISA recibe notificaciones bajo CRA mientras autoridades nacionales gestionan NIS2, autoridades de protección de datos reciben avisos GDPR y supervisores sectoriales exigen sus propios reportes, las empresas pedirán coherencia. Veremos hasta qué punto el ecosistema europeo logra reducir duplicidades o, al menos, no agravarlas.

La cuarta es el mercado. Los grandes proveedores globales probablemente absorberán mejor el coste de cumplimiento. Los actores pequeños, especialmente con productos heredados y deuda técnica seria, tendrán más dificultades. Eso no implica necesariamente expulsión, pero sí más consolidación, más presión en márgenes y más preguntas de clientes corporativos antes de renovar contratos.

Y luego está la posibilidad menos comentada pero muy real: que muchas empresas empiecen demasiado tarde porque creen que sin guías definitivas no merece la pena mover ficha. Es una apuesta arriesgada. La experiencia regulatoria europea enseña lo contrario. Los proyectos que más sufren no son los que arrancan con incertidumbre razonable, sino los que esperan a la certidumbre absoluta. Para entonces, el calendario ya ha hecho su trabajo sucio.

La lectura correcta del calendario: 2026 no es el preámbulo, es el examen de madurez

Si hubiera que resumir lo que significan junio y septiembre de 2026 en una sola idea, sería esta: el CRA va a evaluar antes la capacidad de reacción que la perfección documental. Primero quiere saber si el sistema puede detectar, clasificar y notificar vulnerabilidades e incidentes graves. Y si el ecosistema de evaluación de la conformidad empieza a estar operativo. La aplicación plena de diciembre de 2027 llegará después, sí, pero llegará sobre la base de ese test previo de madurez.

Eso debería cambiar la lista de prioridades de muchas empresas. Menos obsesión por el formulario final y más trabajo en inventario, PSIRT, trazabilidad, arquitectura de producto, documentación técnica viva y gestión de terceros. Menos discusión abstracta sobre “si nos aplica” y más análisis de catálogo, funciones remotas esenciales y canales de comercialización. Menos fe en que la autoevaluación resolverá todo y más atención a si ciertos productos acabarán requiriendo escrutinio de terceros.

La ironía final es que el CRA se presenta a veces como una futura obligación de compliance, cuando en realidad ya actúa como criterio de madurez industrial. Las organizaciones que hagan bien este trabajo no solo estarán mejor posicionadas ante el regulador; también gestionarán mejor vulnerabilidades, responderán más rápido a clientes y sufrirán menos en auditorías de terceros. Las que lo traten como una fecha lejana descubrirán demasiado tarde que el reloj europeo tiene una costumbre fea: no negocia con la deuda técnica.

Junio y septiembre de 2026, por tanto, no son hitos decorativos en una presentación de asuntos públicos. Son el inicio visible de un cambio bastante más serio: la UE quiere que la ciberseguridad del producto deje de depender de promesas comerciales y pase a depender de obligaciones verificables. Quien fabrique, importe o distribuya tecnología en Europa ya debería estar actuando como si eso fuese real. Porque, a estas alturas, lo es.