El mandato de ENISA bajo el Cybersecurity Act: cómo afecta de verdad a tu programa

La pregunta no es si vas a oír hablar más de certificación europea en 2026. La pregunta es si tu programa de seguridad la está tratando como un asunto de branding —error clásico— o como lo que ya es: una palanca regulatoria que afecta a compras, arquitectura, gestión de proveedores y, en algunos casos, acceso a mercado.

Ese giro tiene nombre institucional. ENISA. Y tiene base jurídica. El Reglamento (UE) 2019/881, más conocido como Cybersecurity Act, no convirtió a ENISA en un simple escaparate técnico de la UE; le dio un mandato estable y bastante más operativo en materia de certificación de ciberseguridad. Los artículos 46 y siguientes crean el marco europeo de certificación; el resto de piezas del tablero —NIS2, el Cyber Resilience Act y la contratación pública— están empujando para que ese marco deje de ser una curiosidad de Bruselas y se convierta en disciplina interna.

Si eres CISO o responsable de compliance, aquí está el quid: ENISA no te regula directamente como lo hace una autoridad nacional ni te impone una sanción como un supervisor sectorial. Pero su trabajo condiciona qué esquemas existen, cómo se diseñan, qué niveles de garantía se exigen y, por esa vía, qué te pedirá el mercado, tu cliente regulado o tu propio regulador cuando hable de “state of the art”, supply chain o seguridad por defecto. No es poca cosa.

Lo que cambió de verdad: ENISA pasó de actor técnico a pieza estructural del mercado

Conviene separar el ruido del cambio real. Antes del Cybersecurity Act, Europa llevaba años intentando ordenar una jungla de esquemas nacionales, certificaciones privadas y sellos de seguridad con valor muy desigual. El problema no era solo jurídico. Era económico. Un fabricante o proveedor podía encontrarse con requisitos distintos según el país, evaluaciones repetidas y clientes incapaces de comparar manzanas con manzanas.

El Reglamento (UE) 2019/881 atacó ese problema en dos capas. La primera fue reforzar el mandato permanente de ENISA a nivel europeo. La segunda, crear un European cybersecurity certification framework en su Título III. Ahí están los artículos que importan para tu programa. El art. 46 establece el marco europeo para esquemas de certificación de productos, servicios y procesos TIC. El art. 47 define los objetivos de esos esquemas, entre ellos demostrar que productos, servicios y procesos cumplen requisitos de seguridad concretos destinados a proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos, funciones o servicios.

Luego viene el detalle que muchos equipos leen deprisa y lamentan tarde: el reglamento no diseña una única certificación universal, sino un sistema de esquemas europeos específicos. Cada esquema puede aplicarse a determinadas categorías de productos, servicios o procesos TIC y establecer requisitos, métodos de evaluación y niveles de garantía propios. Traducido al lenguaje menos ceremonioso de la casa: no existe un “certificado UE de ciberseguridad” que te sirva para todo. Hay, o habrá, varios esquemas; y tendrás que entender cuál te afecta, en qué capacidad y con qué consecuencias operativas.

ENISA juega un papel central en esa maquinaria. El reglamento le asigna tareas de preparación, mantenimiento y apoyo técnico de los esquemas, así como la secretaría del Grupo Europeo de Certificación de la Ciberseguridad (ECCG). También interviene en la preparación de propuestas candidatas de esquemas europeos y en la revisión y evaluación general del funcionamiento del marco. Es un rol menos vistoso que publicar alertas sobre amenazas, pero para la industria es potencialmente más influyente: quien ayuda a definir el lenguaje de la certificación acaba influyendo en el lenguaje de la compra y del cumplimiento.

Los artículos que sí deberías tener abiertos en una pestaña

Si solo te vas a quedar con unas referencias legales, que sean las correctas. El Cybersecurity Act no es especialmente amable para la lectura rápida, pero hay varios artículos que marcan la conversación:

El art. 46 crea el marco europeo de certificación. El art. 47 fija los objetivos de los esquemas. El art. 48 aclara qué pueden cubrir: grupos de productos TIC, servicios TIC y procesos TIC. El art. 49 establece los niveles de garantía: basic, substantial y high. Ese escalado no es adorno semántico. Importa porque un proveedor puede tener certificación en un nivel insuficiente para tu caso de uso, y porque tus exigencias a terceros no deberían sonar igual para un servicio de bajo impacto que para un sistema que soporta funciones críticas.

El art. 51 enumera los elementos que debe contener un esquema europeo de certificación, incluidos alcance, criterios de evaluación, nivel de garantía, normas aplicables, tipo de evaluación y reglas de vigilancia. El art. 54 regula el certificado europeo de ciberseguridad y las declaraciones UE de conformidad. El art. 56 y los siguientes se mueven hacia evaluación de conformidad y organismos implicados. Y el art. 57 entra en un punto delicado: cuándo la evaluación puede basarse en autoevaluación. Ahí hay una trampa clásica de gobernanza. Mucha organización oye “declaración UE de conformidad” y lo interpreta como si fuera equivalente a una evaluación externa robusta. No siempre lo es.

El art. 49 merece un segundo vistazo porque condiciona la conversación con negocio y procurement. El nivel basic busca reducir riesgos conocidos y de baja capacidad o probabilidad. El nivel substantial está pensado para resistir actores con capacidades y recursos limitados. El nivel high exige resistencia frente a ataques con capacidades y recursos significativos. No son solo etiquetas de marketing. Son una forma de declarar, por diseño, contra qué tipo de amenaza se supone que aguanta un producto o servicio.

Tu programa ya trabaja con este tipo de lógica aunque no la llame así. Cuando clasificas activos, decides criticidad, pides hardening a un proveedor o defines requisitos de segmentación, estás decidiendo el “nivel de garantía” que esperas del entorno. El Cybersecurity Act no inventa esa realidad. La formaliza y la convierte en lenguaje regulatorio común.

Qué hace ENISA exactamente y por qué eso acaba aterrizando en tu mesa

La web de ENISA sobre certificación puede parecer, a primera vista, una página institucional más. No lo es. Refleja el papel de ENISA como nodo técnico y coordinador del ecosistema europeo de certificación. Eso se traduce en cuatro impactos muy concretos para las empresas.

Primero, ENISA participa en la elaboración técnica de esquemas europeos. Cuando un esquema madura, no estás ante una nota de prensa simpática, sino ante un documento que puede redefinir criterios de producto, métodos de evaluación, documentación exigible y expectativas de mercado. Si fabricas, integras o compras tecnología en la UE, no puedes enterarte de esto por un comercial a última hora.

Segundo, ENISA contribuye a dar coherencia entre certificación y políticas europeas más amplias. Y aquí entran NIS2 y el Cyber Resilience Act. No porque conviertan automáticamente la certificación en obligatoria para todo, sino porque ambos elevan el listón de seguridad por diseño, gestión de riesgos y seguridad de la cadena de suministro. En ese paisaje, los esquemas de certificación se vuelven una prueba útil —a veces imperfecta, pero útil— de que ciertas exigencias se han evaluado de manera reconocible y comparable.

Tercero, ENISA ayuda a reducir la fragmentación entre Estados miembros. Ese era uno de los objetivos políticos de origen del reglamento. Para una multinacional, la promesa es obvia: menos colisiones entre requisitos nacionales y más lenguaje común. Para una pyme tecnológica, la promesa también es obvia: evitar tener que pasar por un calvario distinto en cada mercado. La ironía europea habitual es que la armonización no elimina la complejidad; simplemente la redistribuye. Aun así, suele ser preferible a 27 interpretaciones incompatibles.

Cuarto, ENISA influye en el debate sobre qué significa “seguridad suficiente” en Europa. Eso es decisivo para compliance. Muchas obligaciones legales —NIS2 art. 21 sobre medidas de gestión del riesgo de ciberseguridad, GDPR art. 32 sobre seguridad del tratamiento, DORA en su arquitectura de gestión del riesgo TIC— no te dicen exactamente qué producto comprar ni qué configuración adoptar. Te exigen resultados, proporcionalidad y controles adecuados. La certificación, cuando existe y es pertinente, puede convertirse en una evidencia fuerte de diligencia, aunque rara vez será la única ni te blindará por sí sola.

No confundas certificación con cumplimiento: se parecen, pero no se sustituyen

Este es probablemente el error más caro que veo en programas de seguridad: tratar una certificación como si cerrara, por contagio mágico, varias obligaciones regulatorias. No funciona así.

Un certificado europeo bajo un esquema del Cybersecurity Act puede demostrar que un producto, servicio o proceso TIC ha sido evaluado frente a requisitos definidos por ese esquema y en un nivel de garantía concreto. Eso no equivale a demostrar que tu organización cumple NIS2, ni mucho menos que ha desplegado correctamente sus controles, asignado responsabilidades de gestión o preparado procedimientos de notificación.

NIS2 es un buen ejemplo. El art. 21 obliga a entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información. La lista incluye políticas de análisis de riesgos, gestión de incidentes, continuidad de negocio y backup, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de eficacia de las medidas, higiene cibernética básica, formación, criptografía y, en ciertos casos, autenticación multifactor y comunicaciones seguras. Un producto certificado puede ayudarte con varias de esas áreas. Pero no va a escribirte la política, ni va a entrenar a tu comité de dirección, ni va a decidir qué incidentes escalan al CSIRT.

Lo mismo pasa con el GDPR. El art. 32 exige medidas técnicas y organizativas apropiadas atendiendo al estado de la técnica, costes, naturaleza del tratamiento y riesgos para derechos y libertades. Un servicio certificado puede apoyar tu argumento de “estado de la técnica”. Pero si lo despliegas mal, si no limitas accesos, si no revisas logs o si no segmentas entornos, el certificado del proveedor no te rescata. Y el art. 28 sobre encargados del tratamiento sigue exigiéndote diligencia contractual y selección adecuada del proveedor.

Con DORA la lección es todavía más nítida. El Reglamento (UE) 2022/2554 construye una disciplina de resiliencia operativa digital que va mucho más allá del sello del producto. El art. 6 y siguientes sobre el marco de gestión de riesgos TIC, el art. 17 y siguientes sobre gestión, clasificación y notificación de incidentes, y el art. 28 y siguientes sobre riesgo de terceros TIC te piden gobernanza, inventario, pruebas, contratos y supervisión continua. Un componente certificado puede ser una muy buena señal dentro de esa arquitectura. Pero sigue siendo solo un componente.

En otras palabras: la certificación sirve. Lo que no sirve es utilizarla como sustituto narrativo de un programa maduro. Ese truco queda muy bien en comité de compras. Hasta que llega la auditoría o el incidente.

Cómo encaja con NIS2: menos discurso, más cadena de suministro

NIS2 ha cambiado la conversación porque mete a la dirección en el problema y porque convierte la seguridad de proveedores en algo bastante menos voluntarista. El art. 20 atribuye al órgano de dirección la aprobación y supervisión de medidas de gestión del riesgo de ciberseguridad; el art. 21 obliga a considerar vulnerabilidades específicas de cada entidad y, entre otras cosas, la seguridad de la cadena de suministro y la relación con proveedores directos.

Aquí ENISA y el Cybersecurity Act entran por la puerta lateral, que a veces es la más efectiva. Un esquema europeo puede darte criterios comparables para evaluar determinadas categorías de tecnología utilizadas por entidades cubiertas por NIS2. Eso permite a procurement y a seguridad hablar un idioma común: no “parece seguro”, sino “ha sido evaluado bajo este esquema, con este alcance y este nivel de garantía”.

Para un CISO, eso tiene al menos tres implicaciones prácticas.

La primera es que tus cuestionarios a proveedores deberían dejar de preguntar de forma genérica si disponen de “certificaciones de seguridad” y empezar a pedir detalle. ¿Qué esquema? ¿Bajo qué reglamento? ¿Qué versión? ¿Qué alcance exacto? ¿Nivel basic, substantial o high según art. 49? ¿El resultado es certificado emitido por organismo de evaluación o declaración UE de conformidad? Si no haces esa distinción, compararás cosas que no son comparables.

La segunda es que debes vincular la criticidad del proveedor con el nivel de evidencia exigido. No tiene sentido exigir la misma prueba a una herramienta periférica que a un componente de identidad, una pasarela de comunicaciones industriales o una plataforma que soporta servicios esenciales. NIS2 no te pide uniformidad ciega; te pide proporcionalidad. Eso obliga a clasificar.

La tercera es que la certificación puede mejorar tu capacidad de demostrar diligencia, pero no sustituye el seguimiento continuo. El proveedor pudo estar correctamente evaluado en el momento de la certificación y deteriorarse después en soporte, parcheo, prácticas de desarrollo o dependencia de subprocesadores. Una fotografía no es una película. Tampoco en compliance.

Con el Cyber Resilience Act la cosa se pone más interesante

Si NIS2 presiona a las entidades usuarias, el Cyber Resilience Act aprieta a fabricantes y actores de la cadena de suministro de productos con elementos digitales. Y aquí la relación con los esquemas del Cybersecurity Act es más que conceptual.

El CRA introduce requisitos horizontales de ciberseguridad para productos con elementos digitales a lo largo de su ciclo de vida, incluidas obligaciones sobre diseño seguro, gestión de vulnerabilidades y soporte. Además, contempla el uso de normas armonizadas, especificaciones comunes y, en determinados escenarios, evaluación de conformidad. Ese ecosistema dialoga directamente con la lógica de certificación europea: cómo demostrar, con base reproducible, que un producto cumple requisitos de seguridad concretos.

Para fabricantes y proveedores, eso significa que la estrategia de certificación ya no puede vivir aislada en un rincón del departamento de calidad o de asuntos regulatorios. Debe conectarse con ingeniería, PSIRT, SBOM, política de divulgación coordinada de vulnerabilidades, gestión de componentes de terceros y soporte postventa. Un certificado conseguido a golpe de proyecto puntual se desinfla rápido si el ciclo de desarrollo sigue produciendo deuda de seguridad.

Para los compradores —incluidas entidades financieras, aseguradoras, operadores esenciales y grandes corporaciones— la combinación NIS2 + CRA + Cybersecurity Act crea algo parecido a una nueva línea base de exigencia. No siempre te dará una obligación literal de “comprar solo productos certificados”, pero sí reforzará la expectativa de que sepas justificar por qué eliges un producto, qué evidencia aceptas y cómo verificas que el nivel de seguridad declarado no es un eslogan.

La derivada incómoda es esta: durante años muchas organizaciones han externalizado la evaluación técnica profunda de productos a terceros, fiándose de SOC 2, ISO 27001 o cuestionarios autodeclarativos que, siendo útiles, no fueron diseñados para responder a todas las preguntas de seguridad de producto. Los esquemas europeos empujan hacia un escrutinio más específico. Más técnico. Y menos decorativo.

Los tres niveles de garantía no son teoría: deberían cambiar tus decisiones de compra

El art. 49 del Cybersecurity Act merece aterrizaje operativo, porque si no se queda en jerga regulatoria. Los niveles basic, substantial y high deberían influir en tu catálogo de requisitos mínimos.

Si adquieres tecnología de bajo impacto, un nivel basic puede ser razonable siempre que el producto no trate datos sensibles, no abra una ruta crítica a tu entorno y no soporte funciones reguladas. El error aquí es usarlo como si equivaliera a seguridad “suficiente para cualquier caso”. No lo hace. El propio reglamento reserva ese nivel para riesgos y actores de ataque relativamente modestos.

El nivel substantial encaja mejor en muchos entornos empresariales porque asume adversarios con capacidades limitadas, un escenario más realista para gran parte del cibercrimen oportunista y de algunas amenazas dirigidas de baja sofisticación. Es, probablemente, el nivel donde procurement y seguridad tendrán más discusiones sanas durante los próximos años: coste adicional, tiempo de evaluación y cobertura frente a riesgo asumido.

El nivel high debería interesarte si el producto entra en infraestructura crítica, soporte de identidad, control industrial, servicios públicos esenciales o entornos donde un fallo puede tener impacto material en continuidad, seguridad física o obligaciones regulatorias graves. También si operas bajo un apetito de riesgo muy bajo por motivos sectoriales o contractuales. Eso sí: pedir high para todo es tan inútil como pedir auditoría “de Big Four” para cada SaaS secundario. Enc encarece, ralentiza y, en muchos casos, no añade seguridad proporcional.

La lección es simple y a menudo ignorada: tu política de compras tecnológicas debería mapear categorías de uso con expectativas de evidencia y niveles de garantía, no aplicar un requisito uniforme. Si esa política no existe, tu organización probablemente está comprando por inercia o por presión comercial. Mala mezcla.

Autodeclaración, evaluación externa y el arte de no engañarse solo

Uno de los aspectos más delicados del marco europeo es la coexistencia entre certificados emitidos tras evaluación de conformidad y declaraciones UE de conformidad basadas en autoevaluación cuando el esquema lo permita. Jurídicamente tiene sentido: no todos los productos o escenarios requieren la misma intensidad de evaluación. Operativamente, es terreno resbaladizo.

El problema no es la autoevaluación en sí. El problema es cómo la interpretan quienes compran. Un proveedor puede presentar una declaración de conformidad perfectamente válida dentro del esquema aplicable. Pero eso no equivale al mismo grado de aseguramiento que una evaluación independiente por un organismo acreditado, y tu proceso de due diligence no debería tratarlos como si fueran intercambiables.

La forma madura de manejar esto no es demonizar la autodeclaración, sino clasificarla correctamente en tu matriz de evidencias. Para activos o servicios de baja criticidad, puede ser una pieza suficiente dentro de un conjunto de controles. Para casos de alto impacto, seguramente necesitarás combinarla con resultados de pruebas, cláusulas contractuales reforzadas, derecho de auditoría, transparencia sobre el ciclo de desarrollo y, si aplica, evaluación externa o certificación en un nivel más alto.

Si tu equipo de compras sigue archivando cualquier PDF con la palabra “certification” como si tuviera el mismo peso probatorio, tienes un problema de gobernanza documental, no solo de seguridad.

Qué debería hacer un CISO europeo con todo esto en 2026

No un “roadmap” de consultora. Algo más útil: decisiones concretas que cambian tu programa.

La primera decisión es de inventario. Identifica qué categorías de tecnología en tu entorno podrían verse afectadas por esquemas europeos existentes o previsibles, y cuáles son críticas a efectos de NIS2, DORA, GDPR o continuidad operativa. Sin esa taxonomía, la conversación sobre certificación es abstracta y acaba secuestrada por marketing de proveedor.

La segunda es de procurement. Reescribe los requisitos de compra para diferenciar entre certificaciones organizativas generales, certificaciones de producto/servicio y declaraciones de conformidad. Pide alcance exacto, fecha de emisión, periodo de validez, organismo emisor cuando exista, nivel de garantía y exclusiones. Si una solución solo tiene una certificación corporativa generalista, no la vendas internamente como “producto certificado”. Parece obvio. No lo es tanto en la práctica.

La tercera es contractual. Si el proveedor invoca una certificación o declaración de conformidad como base de confianza, el contrato debería obligarle a notificar cambios materiales que afecten al alcance certificado, hallazgos relevantes, pérdida de certificación, vulnerabilidades graves que comprometan supuestos de seguridad o cambios de subproveedores críticos. Esto conecta con DORA art. 30 sobre elementos contractuales clave y con la lógica de seguimiento continuo exigida por NIS2 art. 21.

La cuarta es arquitectónica. Usa la certificación como una señal dentro de tu patrón de diseño, no como sustituto de controles de integración. Incluso un producto evaluado puede introducir riesgo si lo conectas sin segmentación, sin gestión de identidades, sin logs útiles o con APIs expuestas sin control. La seguridad del producto y la seguridad del despliegue no son la misma capa.

La quinta es de reporting. Informa a tu comité de riesgos o a la dirección con una vista clara de dónde la organización depende de afirmaciones de seguridad no verificadas, dónde ya dispone de evidencia más robusta y dónde sería eficiente exigir certificación o evaluación adicional en la próxima renovación. Si presentas esto bien, dejará de parecer una obsesión técnica y empezará a verse como gestión de riesgo de terceros. Que es exactamente lo que es.

Para compliance, el valor está en la trazabilidad, no en coleccionar sellos

Los responsables de cumplimiento tienen una tentación comprensible: convertir la certificación en una casilla binaria. Tiene sello, pasa; no tiene sello, no pasa. Es cómodo. Y regulatoriamente pobre.

El enfoque útil consiste en construir trazabilidad entre obligación legal, riesgo identificado, control interno y evidencia externa aportada por el proveedor o el producto. Por ejemplo: si tu obligación deriva de NIS2 art. 21 y se concreta internamente en un control de seguridad de adquisición y cadena de suministro, la evidencia puede incluir evaluación de producto, certificación bajo esquema europeo, revisión contractual, pruebas de integración y monitorización continua. La certificación es una pieza de evidencia. No el expediente completo.

Con GDPR ocurre igual. Si basas parte de tu evaluación del art. 32 en el uso de un servicio con determinadas garantías técnicas, documenta qué problema de riesgo resuelve esa tecnología, qué cobertura demuestra la certificación y qué controles compensatorios mantienes porque el alcance certificado no cubre toda tu realidad operativa. Eso te protege frente a la auditoría seria, que siempre termina haciendo la pregunta incómoda: “¿y cómo sabe su organización que esto se cumple en producción?”

También importa para CSRD y reporting de gobernanza si tu empresa ya está reportando riesgos materiales y controles de resiliencia. No porque una certificación tenga que aparecer en el informe de sostenibilidad por sí misma, sino porque la robustez de la gestión de ciber-riesgo y cadena de suministro empieza a cruzar departamentos que antes apenas se hablaban. Bienvenidos al placer administrativo de la convergencia regulatoria.

Lo que puede salir mal si interpretas mal el mandato de ENISA

Hay varios errores recurrentes. Todos evitables.

El primero es pensar que ENISA “certifica” directamente a los proveedores. No es así en ese sentido simplificado. Su papel bajo el Cybersecurity Act está en la arquitectura del marco, el apoyo técnico y la coordinación; la emisión y evaluación dependen de los mecanismos y organismos previstos en cada esquema y del ecosistema de acreditación y supervisión correspondiente. Si un proveedor presume de estar “certificado por ENISA”, toca pedir precisión quirúrgica.

El segundo es suponer que la existencia de un esquema europeo desplaza automáticamente cualquier otra evidencia o norma relevante. Tampoco. En muchas categorías seguirán conviviendo ISO/IEC, Common Criteria, auditorías específicas de cliente, requisitos sectoriales o especificaciones contractuales. La cuestión no es elegir una religión, sino combinar evidencias sin duplicar absurdamente el coste.

El tercero es convertir la certificación en una barrera de entrada indiscriminada para pymes o startups cuando el riesgo no lo justifica. Eso puede empobrecer el mercado, reducir competencia y llevarte a una dependencia innecesaria de grandes proveedores capaces de absorber el coste de evaluación. El buen gobierno no consiste en pedir lo máximo a todos, sino lo adecuado a cada caso.

El cuarto es llegar tarde. Cuando un esquema europeo gana tracción, las organizaciones que no han adaptado su procurement, su lenguaje contractual y sus criterios de evaluación quedan a remolque. Primero improvisan excepciones. Luego crean un proceso de urgencia. Finalmente descubren que lo razonable habría sido preparar el terreno un año antes.

Implicaciones para entidades financieras españolas y europeas

En banca, seguros, pagos y mercados, este debate tiene un peso especial por una razón simple: el sector financiero ya vive en una superposición normativa que castiga la pereza documental. DORA obliga a elevar la disciplina sobre riesgo TIC y terceros; NIS2 alcanza a parte del ecosistema según actividad y tamaño; GDPR sigue marcando las expectativas sobre tratamiento seguro de datos; y los supervisores financieros esperan evidencias, no declaraciones inspiradoras.

Para una entidad financiera española, el impacto del mandato reforzado de ENISA bajo el Cybersecurity Act no es que mañana aparezca una nueva obligación aislada de “certificarse”. El impacto real es más sutil y más potente: el estándar de mercado para justificar la seguridad de tecnología crítica se vuelve más europeo, más estructurado y menos dependiente de afirmaciones locales o comerciales.

Eso afecta a varios frentes. A la selección de herramientas de autenticación, cifrado, monitorización o conectividad. A la validación de proveedores cloud y de software especializado. A la forma de documentar decisiones ante auditoría interna, funciones de control de segunda línea y, llegado el caso, supervisor. Y también a la negociación con terceros TIC, donde DORA art. 28 y siguientes ya han obligado a muchas entidades a revisar inventarios, contratos y estrategias de concentración.

Si el banco o la aseguradora opera en varios Estados miembros, además, la promesa de mayor armonización tiene valor económico directo. Menos dispersión probatoria significa menos fricción para desplegar tecnología a escala. La parte menos romántica, claro, es que esa armonización también eleva el listón para proveedores acostumbrados a vender sin someter su producto a evaluación seria.

Mi lectura: la certificación europea ya forma parte del programa, aunque algunos aún no se hayan enterado

La tesis de fondo es esta: el mandato de ENISA bajo el Cybersecurity Act importa menos por el simbolismo institucional y más por cómo está reordenando la relación entre regulación, producto y evidencia. La UE está intentando convertir la ciberseguridad evaluable en infraestructura de mercado. No siempre lo hará con la velocidad ni la limpieza que uno desearía. Bruselas nunca ha sido una startup. Pero la dirección es clara.

Para los equipos de seguridad, eso significa abandonar dos comodidades. La primera, pensar que toda certificación vale lo mismo. La segunda, seguir tratando la seguridad de producto como un anexo del due diligence general de proveedores. Ya no basta.

Para compliance, el mensaje es parecido: el valor no está en acumular PDFs de sellos, sino en saber qué obligación legal quieres soportar, qué evidencia te aporta el esquema europeo concreto y qué huecos siguen abiertos después. Esa trazabilidad será mucho más útil que cualquier diapositiva con logos.

Y para los proveedores, especialmente los que venden a sectores regulados, la época de la promesa vaga de “security-first” entra en declive. Tocará demostrar más, con más detalle y en un lenguaje que compradores y reguladores puedan verificar.

Si tuviera que resumirlo sin la liturgia comunitaria, diría esto: ENISA no va a gestionar tu programa, pero su mandato bajo el Cybersecurity Act ya está influyendo en las reglas del juego que tu programa debe entender. Ignorarlo hoy no te libra de trabajo. Solo te garantiza hacerlo peor y más deprisa cuando el cliente, el auditor o el regulador te pida pruebas concretas.