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

La pregunta útil no es si ENISA tiene más peso. Lo tiene. La pregunta que debería incomodar a cualquier CISO o responsable de cumplimiento en 2026 es otra: qué parte de tu programa sigue funcionando como si la certificación europea fuese un asunto opcional de marketing cuando ya se está convirtiendo en una pieza de arquitectura regulatoria.

Ese cambio no llega por un titular grandilocuente, sino por una combinación bastante europea de reglamentos, esquemas, coordinación institucional y obligaciones que, por separado, parecen manejables. Juntas, cambian el listón. El Cybersecurity Act, en sus artículos 46 y siguientes, dio a la UE un marco formal para crear esquemas europeos de certificación de ciberseguridad para productos, servicios y procesos TIC. ENISA quedó en el centro técnico de ese sistema: prepara, apoya, coordina, mantiene y promueve. No es un detalle administrativo. Es el mecanismo por el que Bruselas intenta evitar que cada Estado miembro juegue a su propio juego y que cada proveedor te venda “seguridad” como si fuese un adjetivo creativo.

Si además metes en la ecuación NIS2, que en su artículo 21 exige medidas de gestión de riesgos de ciberseguridad, y el Cyber Resilience Act, que este año ya condiciona de forma mucho más directa el desarrollo y mantenimiento de productos con elementos digitales, el mensaje es menos abstracto de lo que parece: la certificación ya no es una conversación aislada del equipo de procurement o del área de producto; empieza a ser una fuente de evidencia, una señal de diligencia debida y, en algunos casos, un filtro práctico para comprar, desplegar o justificar decisiones.

Y aquí aparece la ironía regulatoria de rigor: durante años, muchas organizaciones pidieron “alineación europea” para no lidiar con un mosaico de requisitos. Ya la tienen. Ahora toca vivir con ella.

Lo que hace ENISA y lo que no hace

Conviene limpiar una confusión bastante extendida. ENISA no actúa como una certificadora comercial que emite sellos uno a uno para tus productos o los de tus proveedores. Su papel, bajo el Reglamento (UE) 2019/881 —el Cybersecurity Act—, es bastante más estructural. Los artículos 47 a 49 le asignan tareas de preparación de candidatos a esquemas europeos de certificación, apoyo técnico a la Comisión y al European Cybersecurity Certification Group (ECCG), mantenimiento de información pública sobre esquemas y certificados, y labores de secretaría y coordinación.

Traducido a lenguaje de empresa: ENISA diseña el campo de juego, ayuda a definir las reglas y hace que el ecosistema tenga memoria institucional. Quien certifica serán organismos de evaluación de la conformidad y autoridades nacionales en función del esquema, del nivel de aseguramiento y de la arquitectura de supervisión aplicable. Pero el contenido técnico y la coherencia paneuropea no caen del cielo. Salen de ahí.

El artículo 46 del Cybersecurity Act es la base del marco europeo de certificación. A partir de ahí, los esquemas europeos deben especificar varios elementos concretos: categorías de productos, servicios o procesos TIC cubiertos; requisitos de ciberseguridad; criterios y métodos de evaluación; niveles de aseguramiento; reglas de vigilancia y, cuando proceda, duración y renovación del certificado. No es literatura. Es diseño regulatorio con consecuencias operativas.

Los niveles de aseguramiento “basic”, “substantial” y “high”, definidos en el reglamento, también importan más de lo que a veces se reconoce en comités internos. No son etiquetas decorativas. Marcan la intensidad esperada de la evaluación y la confianza razonable sobre si un producto, servicio o proceso cumple los requisitos del esquema. Si tu entidad compra tecnología para funciones críticas y acepta sin discusión productos posicionados en el extremo más bajo del aseguramiento cuando el riesgo operativo apunta a otra cosa, no tienes una política de terceros madura: tienes una preferencia presupuestaria disfrazada de enfoque basado en riesgo.

Por qué esta maquinaria pesa ahora más que hace tres años

La respuesta corta: porque en 2026 ya no se puede analizar el Cybersecurity Act como una pieza aislada. Hay que leerlo junto a tres movimientos regulatorios y de mercado.

El primero es NIS2. Su lógica no gira en torno a “tener un certificado”, sino a demostrar gobierno, gestión de riesgos y seguridad de la cadena de suministro. El artículo 21.2 enumera medidas mínimas que incluyen políticas de análisis de riesgos y seguridad de sistemas, gestión de incidentes, continuidad, seguridad de la cadena de suministro, desarrollo y mantenimiento seguros, evaluación de la eficacia de las medidas y prácticas básicas de ciberhigiene, entre otras. La certificación europea no sustituye esas obligaciones. Pero puede convertirse en una forma poderosa de estructurar evidencia, exigir niveles mínimos a proveedores y justificar decisiones ante reguladores y auditores.

El segundo es el Cyber Resilience Act. El CRA desplaza el foco desde la organización usuaria al fabricante y a toda la cadena del producto con elementos digitales. Exige requisitos esenciales de ciberseguridad y procesos de gestión de vulnerabilidades a lo largo del ciclo de vida. Aunque el régimen jurídico del CRA no es idéntico al de los esquemas del Cybersecurity Act, ambos mundos se tocan en la práctica: seguridad por diseño, pruebas, documentación técnica, gestión de vulnerabilidades, información a clientes y supervisión del mercado. Resultado: si compras software, dispositivos conectados, componentes OT o servicios TIC integrados, la conversación sobre certificación deja de ser estética y se convierte en una conversación sobre evidencia precontractual, due diligence técnica y sostenibilidad regulatoria del proveedor.

El tercero es el propio mercado. Grandes compradores europeos —incluidas entidades financieras, operadores esenciales, administraciones y grandes grupos industriales— están usando cada vez más referencias a certificaciones, evaluaciones de conformidad y esquemas armonizados en pliegos, RFP y modelos de homologación. A veces con criterio. A veces como ritual burocrático. Pero el efecto es el mismo: el proveedor que no pueda explicar con precisión su postura frente a esquemas europeos llega peor a la mesa.

Esto afecta especialmente a los responsables de seguridad que siguen separando artificialmente tres conversaciones: cumplimiento, arquitectura y compras. Ese modelo se agota. Si una entidad sujeta a NIS2, DORA o a exigencias sectoriales nacionales compra soluciones críticas sin una taxonomía clara de certificación, aseguramiento y evaluación independiente, el problema no es documental. Es de gobierno.

El artículo 46 no te obliga directamente a certificar todo. Eso no significa que puedas ignorarlo

Aquí conviene evitar la caricatura. El Cybersecurity Act no impone, por sí solo y de forma general, que todos los productos o servicios TIC deban estar certificados. El sistema europeo de certificación se diseñó en origen como un marco para esquemas que pueden ser voluntarios, salvo que otra norma de la UE o del derecho nacional establezca lo contrario para categorías concretas. Esa distinción sigue siendo relevante.

Pero sería un error bastante caro leer “voluntario” como “irrelevante”. En regulación tecnológica, lo voluntario suele convertirse en cuasi obligatorio por tres vías. Primera: contratación pública y privada. Segunda: supervisión sectorial, donde el certificado actúa como indicador de diligencia razonable aunque no exonere de responsabilidad. Tercera: litigio y gestión del incidente, donde la ausencia de estándares reconocidos complica defender por qué elegiste un producto, un servicio o una configuración concreta.

Piensa en un escenario muy realista para una entidad financiera europea. Tienes que renovar una plataforma de autenticación remota o un componente crítico de infraestructura. No hay una obligación expresa en tu norma sectorial que diga “compra solo productos bajo esquema X”. Aun así, tu función de riesgo tecnológico, tu auditoría interna y tu segunda línea te pedirán justificar cómo has evaluado seguridad, madurez del proveedor, robustez del desarrollo y capacidad de gestión de vulnerabilidades. Un producto alineado con un esquema europeo o con una evaluación reconocible reduce fricción interna y externa. No te resuelve todo. Pero te coloca en mejor posición que una ficha comercial llena de adjetivos heroicos.

Ese es el tipo de efecto silencioso que ENISA ayuda a producir. No impone de forma directa cada decisión de compra; hace que el mercado y los reguladores hablen un idioma más homogéneo cuando evalúan seguridad TIC.

EUCC, EUCS y el problema real: no la sigla, sino la utilidad

En torno a la certificación europea se ha generado un pequeño deporte de pasillo regulatorio: recitar siglas como si eso equivaliera a estrategia. No lo es. La pregunta útil para tu programa no es cuántos acrónimos puedes colocar en una diapositiva, sino qué esquema encaja con qué riesgo, qué evidencia produce y cómo lo integras en decisiones operativas.

En 2026, el referente más tangible es EUCC, el esquema europeo basado en principios del histórico SOG-IS para certificar productos TIC, especialmente con foco en componentes donde la evaluación de seguridad técnica y el aseguramiento tienen tradición más sólida. Su valor no está en la marca, sino en el tipo de rigor evaluador y lenguaje común que ofrece para determinados productos.

También sigue muy presente EUCS, el esquema europeo para servicios en la nube, por su enorme carga política y comercial. Porque la nube, sorpresa, no es ya un asunto solo técnico: es dependencia estratégica, concentración de mercado y soberanía industrial empaquetadas en contratos de adhesión. Precisamente por eso el debate alrededor de EUCS ha sido tan sensible. Cuando un esquema de certificación roza requisitos de localización, inmunidad frente a interferencias extraterritoriales o condiciones de control corporativo, deja de ser mera “ciberseguridad” y entra en geopolítica regulatoria con corbata.

Para el lector práctico, la lección no es apostar por una sigla concreta porque sí. La lección es esta: si tu organización depende de cloud para funciones críticas, y especialmente si opera bajo DORA o NIS2, necesitas una posición formal y escrita sobre qué peso das a certificaciones europeas, a attestations internacionales, a auditorías propias y a controles contractuales. Si no lo has hecho, alguien lo acabará improvisando en una negociación con el proveedor. Y ya sabemos cómo suele salir eso.

Cómo encaja todo esto con NIS2: certificación como evidencia, no como atajo

Hay una tentación muy humana en compliance: convertir cualquier sello en sustituto de pensamiento. Con NIS2 eso sería un error de libro.

La directiva exige medidas de gestión de riesgos “adecuadas y proporcionadas” en el artículo 21.1, y especifica áreas concretas en el artículo 21.2. Ninguna de esas obligaciones desaparece porque un proveedor presente un certificado europeo o una evaluación de conformidad. El certificado puede acreditar que el objeto evaluado cumple unos requisitos definidos en un esquema. No acredita, por sí mismo, que tu integración, tu configuración, tus privilegios, tu segmentación, tu gestión de identidades o tu respuesta a incidentes sean adecuados.

Aun así, despreciar la certificación sería igual de miope. Bien utilizada, sirve al menos para cinco cosas muy concretas dentro de un programa NIS2:

Primero, para segmentar el universo de terceros. No todos los proveedores TIC requieren el mismo nivel de escrutinio. Un esquema reconocido puede ayudarte a clasificar rápidamente productos y servicios que merecen una vía de evaluación simplificada frente a otros que exigen análisis profundo, pruebas adicionales o condiciones contractuales más agresivas.

Segundo, para reforzar criterios de homologación. Si tu procedimiento de alta de proveedores no contempla cómo se valora una certificación europea, estás dejando fuera una señal objetiva que el mercado regulado cada vez usa más.

Tercero, para soportar decisiones de compensación de controles. Imagina que un servicio no alcanza la madurez documental ideal, pero sí acredita evaluación sólida en determinadas funciones de seguridad. Eso no te obliga a aceptarlo, pero te permite diseñar controles compensatorios con mayor precisión.

Cuarto, para mejorar trazabilidad de evidencia ante supervisores. Cuando te pidan justificar por qué una tecnología fue aceptada para un proceso crítico, una referencia a un esquema europeo concreto es mucho más defendible que “el proveedor es líder del cuadrante”.

Quinto, para articular revisiones periódicas. NIS2 no es fotografía; es gestión continuada. La existencia de un esquema, su renovación, sus condiciones y cualquier desviación declarada pueden integrarse en tu ciclo de reassessment de terceros.

La clave está en no sobredimensionar lo que la certificación prueba. Un certificado no compensa una mala arquitectura. Tampoco una monitorización floja. Ni una administración privilegiada caótica. Lo que sí hace es elevar el suelo de la conversación.

Y con el CRA: menos promesas de proveedor, más disciplina de producto

Si NIS2 te obliga a gestionar riesgo como operador o entidad, el CRA aprieta donde durante años hubo demasiado margen para la poesía comercial: el producto digital.

El reglamento exige, entre otras cosas, que los fabricantes de productos con elementos digitales diseñen, desarrollen y produzcan productos de acuerdo con requisitos esenciales de ciberseguridad, y que gestionen vulnerabilidades durante el ciclo de vida, incluida la notificación de vulnerabilidades explotadas activamente e incidentes graves a ENISA dentro de los plazos previstos por la norma. No todas las obligaciones del CRA se canalizan a través del Cybersecurity Act, pero la lógica es convergente: más verificabilidad, más trazabilidad técnica, menos “confíe usted en mi PDF corporativo”.

Para un CISO, eso se traduce en una oportunidad práctica. Cuando revises proveedores de software, dispositivos conectados, herramientas de administración remota, componentes de red o plataformas de seguridad, ya no basta con preguntar por ISO 27001 del entorno corporativo. Esa certificación sigue siendo útil, pero habla de un sistema de gestión; no necesariamente de la robustez del producto que vas a desplegar. Debes pedir evidencias alineadas con la lógica del CRA y, cuando existan o sean pertinentes, con esquemas europeos de certificación centrados en el producto o servicio específico.

La consecuencia es incómoda para muchas áreas de compras: la due diligence técnica deja de poder resolverse con un cuestionario genérico de 120 preguntas que nadie lee hasta el final. Si el proveedor vende un producto crítico, hay que entender arquitectura, superficie de ataque, proceso de parcheo, soporte de vulnerabilidades, SBOM si aplica, telemetría disponible, capacidades de endurecimiento y evidencia externa de evaluación.

ENISA, otra vez, aparece en el trasfondo. Su función en el ecosistema de certificación y en la coordinación de ciberseguridad europea hace que se convierta en referencia institucional para lo que “buena evidencia” empieza a significar en la UE. No es poca cosa.

Lo que un programa maduro debería cambiar este año

Si tu organización sigue tratando la certificación europea como un tema reservado al departamento jurídico o a un especialista de normas técnicas, hay trabajo pendiente. No hablo de redactar una política elegante. Hablo de rediseñar decisiones concretas.

1. Tu inventario de terceros necesita una capa de criticidad regulatoria

La mayoría de inventarios de proveedores TIC se quedan en categorías operativas: cloud, software, telecom, soporte, outsourcing. Eso ya no basta. Añade al menos cuatro campos nuevos: si el producto o servicio está cubierto por algún esquema europeo existente o previsto; nivel de aseguramiento relevante; relación con funciones críticas o importantes; y norma principal que condiciona tu evaluación (NIS2, DORA, CRA, normativa sectorial nacional).

Ese simple cambio obliga a ordenar conversaciones que hoy muchas organizaciones tienen fragmentadas entre seguridad, compras y compliance.

2. Procurement debe dejar de confundir certificado corporativo con evidencia de producto

Un proveedor puede exhibir ISO 27001, SOC 2, declaraciones de conformidad varias y aun así no ofrecer evidencia convincente sobre el componente exacto que vas a desplegar. La pregunta no es si tiene “certificaciones”, en plural y con brillo comercial. La pregunta es qué evaluación independiente cubre el producto, servicio o proceso TIC relevante, con qué alcance, bajo qué esquema y con qué nivel de aseguramiento.

Si tu pliego o tu modelo de contratación no distingue eso, estás comprando niebla.

3. Segunda línea y auditoría interna deben ajustar su lenguaje

He visto demasiados informes internos que tratan cualquier certificación como una caja negra positiva. En 2026 eso ya es una mala práctica. Auditoría y compliance deberían preguntar: alcance exacto, fecha de emisión, fecha de expiración, organismo evaluador, limitaciones, supuestos de configuración, exclusiones y relación con el caso de uso real de la entidad.

No hace falta volverse críptico. Hace falta dejar de ser crédulo.

4. Arquitectura y seguridad deben conectar certificación con patrones de despliegue

Un mismo producto puede ofrecer garantías razonables en un patrón de uso y resultar insuficiente en otro. La certificación, cuando exista, debe dialogar con tus decisiones de segmentación, hardening, identity federation, logging, retención, administración remota y cifrado. Si esa conversación no existe, el certificado vive en una carpeta. Y las carpetas, por sí solas, no detienen incidentes.

Una tabla útil: dónde puede ayudarte la certificación y dónde no

El ángulo financiero: DORA no menciona ENISA en cada párrafo, pero te empuja hacia esta lógica

La pieza esté catalogada bajo NIS2, pero si trabajas en banca, seguros, pagos o mercados financieros, ignorar DORA sería un fallo editorial y práctico.

DORA exige una gestión mucho más disciplinada del riesgo TIC, incidentes, pruebas de resiliencia y, sobre todo, de terceros proveedores de servicios TIC. El artículo 28 y siguientes construyen un régimen detallado para la gestión del riesgo asociado a terceros, incluidos requisitos sobre estrategia, registro de información, evaluación previa a la contratación, contenido contractual y seguimiento. No te obliga automáticamente a exigir certificación europea en todos los casos. Pero sí te obliga a demostrar que entiendes el riesgo y que tus decisiones de externalización o adquisición no son arbitrarias.

Aquí la certificación europea puede actuar como multiplicador de calidad en tres frentes muy concretos para entidades financieras españolas y europeas.

Primero, en la fase precontractual. Si un proveedor soporta una función crítica o importante, la entidad debería valorar si dispone de evidencias independientes de seguridad del producto o servicio, y cómo encajan con el perfil de riesgo de la función. Un esquema europeo reconocido puede pesar mucho en esa evaluación.

Segundo, en la negociación contractual. La existencia de certificaciones, niveles de aseguramiento o compromisos de mantenimiento vinculados a estándares reconocibles facilita traducir exigencias técnicas a cláusulas verificables. Mucho mejor eso que discutir adjetivos como “robusto”, “líder” o “enterprise-grade”, que en contratos sirven básicamente para decorar PDFs.

Tercero, en la supervisión continuada. DORA no quiere un due diligence de bienvenida y una siesta de cinco años. Quiere gestión continuada. Si tu marco de seguimiento de terceros no integra renovaciones, cambios de alcance, hallazgos de evaluación o evolución de esquemas relevantes, la supervisión es coja.

Las entidades españolas, además, operan en un entorno donde Banco de España, CNMV y DGSFP observan con creciente atención la resiliencia tecnológica y la gobernanza de proveedores críticos. Nadie serio espera que una certificación sustituya el control interno. Pero cada vez resulta menos defendible no aprovechar marcos europeos cuando existen y son pertinentes.

Errores comunes que veo una y otra vez

Primer error: pedir certificación “europea” como casilla binaria sin saber qué esquema, qué alcance o qué nivel de aseguramiento sería relevante. Eso solo produce litigios con proveedores y falsa sensación de rigor.

Segundo error: suponer que cualquier evaluación externa sirve para cualquier riesgo. No es lo mismo una atestación del entorno de control del proveedor que una evaluación del producto. Parece obvio. En demasiadas mesas no lo es.

Tercer error: delegar por completo el criterio en compras. Procurement es indispensable, pero si lidera solo esta conversación, el resultado suele ser una mezcla de plazos imposibles, equivalencias dudosas y concesiones mal documentadas.

Cuarto error: no mantener un repositorio vivo de evidencias de terceros. Cuando llega una auditoría, una inspección o un incidente, la organización entra en modo arqueología. Mala señal.

Quinto error: tratar la certificación como sustituto de telemetría y validación continua. Un proveedor pudo pasar una evaluación ayer y aun así deteriorar su postura operativa hoy. La gestión de terceros madura combina evidencia ex ante con verificación continuada.

Qué preguntas debería hacer mañana mismo un CISO a su equipo

No hace falta montar un programa nuevo desde cero para detectar si vas tarde. Bastan unas cuantas preguntas incómodas.

¿Sabemos qué productos y servicios TIC soportan funciones críticas y si existe para ellos algún esquema europeo relevante bajo el Cybersecurity Act?

¿Nuestro proceso de homologación distingue entre certificación corporativa, evaluación de producto y evidencias ligadas al ciclo de vida seguro?

¿Podemos demostrar cómo usamos esa información para cumplir NIS2 art. 21 o, en el sector financiero, DORA art. 28 y siguientes?

¿Tenemos criterios escritos para aceptar equivalencias o compensaciones cuando no existe certificación europea aplicable?

¿Quién revisa expiraciones, cambios de alcance, hallazgos y renovaciones?

Si las respuestas dependen de cadenas de correo, memoria individual o una carpeta compartida con nombre “proveedores_final_final_v3”, ya tienes el diagnóstico.

El contraargumento razonable: cuidado con convertir la certificación en burocracia cara

También hay que decirlo: no toda crítica a la expansión de la certificación es pereza empresarial. Existe un argumento serio en contra de sobredimensionarla.

Los esquemas de certificación pueden ser lentos frente a ciclos tecnológicos rápidos. Pueden generar costes altos para fabricantes más pequeños. Pueden quedarse atrás respecto a arquitecturas cloud-native, modelos de entrega continua o composiciones complejas de software. Y pueden inducir a compradores a asumir que “certificado” equivale a “seguro en producción”, que no es verdad.

Ese argumento merece respeto. Si la UE quiere que su sistema de certificación tenga impacto real, los esquemas deben ser técnicamente útiles, actualizables y proporcionados. Si no, el mercado los bordeará o los convertirá en una formalidad pesada.

Pero de ahí no se deduce que las organizaciones deban esperar de brazos cruzados. Al contrario. Precisamente porque la certificación tiene límites, tu programa debe usarla con criterio: como evidencia estructurada dentro de una decisión más amplia, no como tótem regulatorio. Eso exige más madurez, no menos.

Mi lectura: ENISA está moldeando el estándar de diligencia razonable europeo

Si hay una idea que merece quedarse de esta pieza, es esta: el poder real de ENISA bajo el Cybersecurity Act no consiste en repartir certificados, sino en definir qué empieza a contar como diligencia razonable verificable en la ciberseguridad europea.

Eso importa porque los programas de seguridad maduros se construyen, en buena medida, sobre estándares de prueba. Qué tienes que demostrar. Ante quién. Con qué evidencia. En qué formato. Con qué nivel de independencia. El ecosistema de certificación europeo va estrechando ese espacio de ambigüedad.

Para algunos fabricantes, esto será una ventaja competitiva. Para otros, una molestia regulatoria. Para las entidades usuarias, especialmente las sujetas a NIS2 y DORA, debería ser una oportunidad para ordenar una zona del riesgo TIC que durante demasiado tiempo se ha gestionado con cuestionarios genéricos, promesas de proveedor y bastante fe.

La conclusión práctica no es “exige siempre certificación europea”. Sería demasiado simple y, en algunos casos, técnicamente pobre. La conclusión correcta es más exigente: integra ya el marco del Cybersecurity Act y el papel de ENISA en tu gobierno de terceros, en tu arquitectura de evidencia y en tus decisiones de producto. Quien espere a que cada obligación aparezca escrita con fluorescente en una norma sectorial llegará tarde. No dramáticamente tarde. Tarde de la forma más molesta: cuando ya no pueda justificar por qué siguió comprando y desplegando tecnología crítica con criterios de 2022.

Ese, al final, es el verdadero efecto del mandato reforzado de ENISA. No cambia solo la regulación. Cambia lo que en Europa empieza a considerarse una decisión de seguridad defendible.