ENISA ya no es un observador: por qué su mandato bajo el Cybersecurity Act afecta a tu programa de seguridad

Durante años, mucha certificación de ciberseguridad en Europa ha funcionado como una especie de ritual corporativo: útil para compras, vistoso para marketing y bastante desconectado del riesgo real. Ese tiempo se está acabando. El cambio no llega porque de repente Bruselas haya descubierto la ciberseguridad —eso lo lleva intentando una década—, sino porque el mandato de ENISA bajo el Cybersecurity Act ha convertido la certificación en una pieza estructural de la política digital europea.

La clave jurídica está en el Reglamento (UE) 2019/881, el llamado Cybersecurity Act. Sus artículos 46 y siguientes crean el marco europeo de certificación de ciberseguridad. No es un detalle técnico. Es la base legal para que productos, servicios y procesos TIC puedan evaluarse con esquemas comunes en toda la UE. Traducción para CISOs y responsables de cumplimiento: lo que antes era una conversación de laboratorio regulatorio ahora empieza a colarse en procurement, en due diligence de terceros, en arquitectura de producto y en la forma de demostrar diligencia ante supervisores.

Y aquí aparece ENISA con bastante más peso del que muchos equipos internos todavía le atribuyen. La agencia no certifica directamente a los fabricantes ni sustituye a las autoridades nacionales de certificación, pero sí desempeña un papel central en el diseño, mantenimiento y evolución de los esquemas europeos. Eso la coloca en una posición incómodamente relevante: no decide sola, pero condiciona el terreno de juego.

Si llevas NIS2, si te preocupa el Cyber Resilience Act, o si intentas ordenar un programa de third-party risk que ya va tarde, esto te afecta. Bastante.

Lo que de verdad hace ENISA bajo el Cybersecurity Act

Conviene despejar una confusión frecuente. ENISA no es un sello, ni una auditora paneuropea, ni el equivalente cibernético de una ITV comunitaria. Su mandato en certificación está más arriba en la cadena. El Cybersecurity Act establece un sistema en el que la Comisión Europea puede adoptar esquemas europeos de certificación mediante actos de ejecución, y ENISA actúa como motor técnico de ese proceso.

El punto de partida es el artículo 46 del Reglamento (UE) 2019/881, que crea el “marco europeo de certificación de la ciberseguridad”. A partir de ahí, los artículos siguientes dibujan la arquitectura institucional. El artículo 47 define el objetivo y alcance de los esquemas europeos; el artículo 48 describe su finalidad; el artículo 49 introduce los niveles de garantía “basic”, “substantial” y “high”; y el artículo 54 encarga a ENISA la preparación de esquemas candidatos de conformidad con el programa de trabajo evolutivo de la Unión.

Ese detalle importa más de lo que parece. Cuando ENISA redacta, consulta y madura un esquema, está influyendo en preguntas muy concretas: qué requisitos técnicos habrá que cumplir, qué vulnerabilidades habrá que gestionar, qué evidencia documental será aceptable, qué tipo de evaluación pedirá cada nivel de garantía y cómo se conectará todo eso con normas existentes, desde Common Criteria hasta estándares sectoriales.

El artículo 55 crea el European Cybersecurity Certification Group, formado por autoridades nacionales. El artículo 56 establece el Stakeholder Cybersecurity Certification Group. Dicho sin jerga: ENISA trabaja en un triángulo con la Comisión, los Estados miembros y la industria. No manda sola, pero tampoco se limita a tomar notas. En la práctica, hace algo más incómodo: convierte aspiraciones políticas amplias en requisitos técnicos que luego aterrizan en contratos, laboratorios de evaluación y expedientes regulatorios.

La mejor forma de entenderlo es esta: NIS2 dice que la alta dirección debe aprobar medidas de ciberseguridad y supervisar su ejecución; el CRA empuja a los fabricantes a entregar productos con requisitos de seguridad durante todo el ciclo de vida; ENISA ayuda a definir qué significa “seguro” cuando la UE decide certificarlo de forma homogénea. Es una cadena. Y cada eslabón reduce espacio para la ambigüedad, que era justo el refugio favorito de media industria.

El marco de certificación no obliga siempre, pero sería un error tratarlo como voluntario e irrelevante

Aquí está la trampa semántica. El Cybersecurity Act fue diseñado, en principio, sobre una lógica mayoritariamente voluntaria. El artículo 56 y el sistema en su conjunto no convierten cada esquema en una obligación automática para todos los operadores. De hecho, la certificación europea no nace como un régimen horizontal universalmente mandatorio.

Muchos departamentos legales se quedaron con esa idea y cerraron el asunto demasiado pronto: “si no es obligatorio, ya veremos”. Mala lectura.

Primero, porque el propio reglamento prevé que la Comisión evalúe periódicamente la efectividad y el uso de los esquemas, y abre la puerta a que normativa sectorial o futura legislación exija certificaciones específicas. Segundo, porque incluso cuando la ley no impone formalmente el certificado, el mercado puede hacerlo por la vía contractual. Tercero, porque NIS2 y el CRA cambian el contexto de forma radical: aunque no te obliguen a tener un certificado concreto hoy, sí elevan el coste de no poder demostrar, con evidencia sólida, que tu tecnología y tus proveedores cumplen un nivel de seguridad defendible.

NIS2 es el mejor ejemplo de esa presión indirecta. La Directiva (UE) 2022/2555, en su artículo 21, obliga a entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas. Entre ellas incluye gestión de riesgos, seguridad de la cadena de suministro, políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas, y uso de criptografía y cifrado cuando proceda. Nada de eso dice “compra solo tecnología certificada por la UE”. Cierto. Pero tampoco dice que valen promesas de PowerPoint del proveedor.

Cuando tengas que demostrar que tu proceso de selección y supervisión de tecnología ha sido diligente, una certificación europea puede convertirse en evidencia muy útil. No única. No suficiente por sí sola. Pero útil de verdad.

Con el Cyber Resilience Act la presión es aún más tangible. El Reglamento (UE) 2024/2847, publicado en noviembre de 2024, introduce requisitos horizontales de ciberseguridad para productos con elementos digitales. Exige, entre otras cosas, que se diseñen, desarrollen y fabriquen conforme a requisitos esenciales de ciberseguridad y que se gestionen vulnerabilidades durante el ciclo de vida del producto. El CRA usa mecanismos de evaluación de conformidad y, en determinados casos, remite a estándares armonizados o esquemas de certificación. Ahí el trabajo de ENISA deja de parecer una conversación académica y empieza a parecer lo que es: infraestructura regulatoria.

En otras palabras, “voluntario” en Bruselas muchas veces significa “todavía no te lo exijo por ley en todos los casos, pero te conviene actuar como si fuera a importarte pronto”. La historia regulatoria europea está llena de avisos de ese tipo. Luego llegan las compras públicas, las exigencias sectoriales, los pliegos de grandes clientes y las preguntas del supervisor. Y la voluntariedad se vuelve bastante filosófica.

EUCC fue la señal: Europa ya ha pasado de la teoría al esquema operativo

La mejor prueba de que esto va en serio llegó con el esquema europeo basado en Common Criteria. El European Common Criteria-based cybersecurity certification scheme, conocido como EUCC, fue adoptado por la Comisión mediante el Reglamento de Ejecución (UE) 2024/482, de 31 de enero de 2024. Entró en vigor a los 20 días de su publicación en el Diario Oficial y será aplicable tras un periodo transitorio previsto en el propio acto.

¿Por qué importa EUCC? Porque rompe una comodidad muy instalada: la idea de que el marco europeo de certificación siempre estaba “a punto de llegar” pero nunca aterrizaba del todo. EUCC ya existe como esquema formal de la UE y cubre productos TIC, como componentes hardware y software. Se apoya en Common Criteria, sí, pero dentro del paraguas del Cybersecurity Act y de una lógica europea de reconocimiento.

Operativamente, EUCC manda tres mensajes.

El primero: la UE no parte de cero. Aprovecha marcos preexistentes, los reordena y los convierte en política común. Si tu equipo pensaba que la certificación europea iba a ser un universo completamente nuevo, no exactamente. Si pensaba que seguiría siendo una nebulosa sin impacto, tampoco.

El segundo: la evaluación de garantías vuelve a primer plano. El artículo 49 del Cybersecurity Act distingue entre niveles “basic”, “substantial” y “high”, con expectativas diferentes respecto a resistencia frente a actores y ataques. No todas las tecnologías requieren el mismo nivel. Pero esa categorización obliga a abandonar la vieja costumbre de tratar “seguridad” como una casilla binaria. No basta con decir que un proveedor “cumple”. Hay que preguntar: ¿con qué alcance, frente a qué amenazas, bajo qué evaluación y con qué mantenimiento posterior?

El tercero: la certificación europea afecta a la conversación entre seguridad, compras y compliance. En demasiadas organizaciones esos tres mundos se siguen tolerando más que coordinarse. La seguridad quiere control técnico, compras quiere velocidad y precio, compliance quiere trazabilidad. Un esquema europeo bien entendido puede servir de lenguaje común. Uno mal entendido puede convertirse en un teatro burocrático. Depende de cómo lo uses.

Lo que un CISO debería leer entre líneas del artículo 49: “basic”, “substantial” y “high” no son etiquetas de marketing

El artículo 49 del Cybersecurity Act es fácil de citar y fácil de banalizar. Los tres niveles de garantía parecen simples. No lo son. Cada nivel refleja una expectativa distinta sobre la profundidad de la evaluación y sobre la confianza que puede depositarse en que un producto, servicio o proceso TIC cumple determinadas propiedades de ciberseguridad.

Para un CISO, la pregunta útil no es memorizar los niveles. La pregunta útil es cómo traducirlos a decisiones concretas.

Si compras una herramienta periférica con escaso impacto sobre procesos críticos, un nivel de garantía más bajo puede ser razonable, siempre que la arquitectura limite bien el radio de explosión. Si, en cambio, estás integrando una solución que toca identidad, acceso privilegiado, comunicaciones industriales, pagos, firmware, criptografía o gestión remota, el debate cambia. Ahí pedir más evidencia no es obsesión normativa; es higiene básica.

El problema es que muchas organizaciones no tienen una taxonomía interna capaz de mapear criticidad tecnológica con exigencia de aseguramiento. Hablan de “sistemas críticos”, pero no conectan esa categoría con requisitos verificables en licitación, evaluación o onboarding. Resultado: el mismo cuestionario de terceros sirve para una plataforma de marketing y para un componente que administra credenciales de administrador de dominio. Luego nos sorprendemos de que la cadena de suministro falle por donde siempre falla.

La aportación real del marco europeo no es solo el sello. Es forzar esa disciplina de clasificación. Si un esquema europeo existe para una familia tecnológica relevante, la empresa madura no pregunta simplemente si el proveedor lo tiene o no. Pregunta algo más útil: si no lo tiene, ¿qué evidencia equivalente ofrece?, ¿qué nivel de garantía necesitaríamos según el uso previsto?, ¿qué controles compensatorios vamos a imponer?, ¿quién asume el riesgo residual y con qué documentación?

Eso también protege frente a la moda inversa: pedir certificados por reflejo. Hay compradores que ya apuntan a la certificación como si fuera una varita mágica. No lo es. Un producto certificado puede seguir encajando mal en tu arquitectura, estar mal configurado, desplegarse sin hardening o no cubrir el caso de uso que realmente te preocupa. La certificación reduce incertidumbre en un alcance concreto. No elimina la necesidad de ingeniería, gobernanza y operación competente. Una pena para quienes confiaban en resolver la seguridad a golpe de PDF con logo europeo.

NIS2 no exige certificación general, pero sí hace mucho más caro ignorarla

NIS2 ha cambiado algo esencial: la conversación ya no gira solo en torno a “tener controles”, sino a poder justificar por qué esos controles son adecuados para el riesgo y cómo se gobiernan. El artículo 20 refuerza la responsabilidad de los órganos de dirección. El artículo 21 lista las medidas mínimas de gestión de riesgos de ciberseguridad. Y el artículo 23 endurece las obligaciones de notificación de incidentes, con una alerta temprana en 24 horas, notificación de incidente en 72 horas y un informe final, en principio, dentro del mes.

¿Dónde entra aquí ENISA y la certificación? En la calidad de la evidencia.

Imagina una entidad esencial que sufre un incidente vinculado a un componente de acceso remoto gestionado por un proveedor. Tras el incidente, el supervisor no solo va a preguntar qué parche faltaba. Va a examinar el proceso previo: evaluación del proveedor, condiciones contractuales, segmentación, monitorización, requisitos de seguridad exigidos, historial de vulnerabilidades, planes de contingencia. Si la organización seleccionó una tecnología sin certificación disponible, sin evaluación independiente equivalente y sin controles compensatorios claros, su posición defensiva empeora. No necesariamente porque incumpla una obligación explícita de certificación, sino porque su narrativa de diligencia se debilita justo cuando más la necesita.

NIS2 también mete presión sobre la cadena de suministro. El artículo 21, apartado 2, letra d), menciona expresamente la seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores directos o proveedores de servicios. Eso es munición regulatoria suficiente para que muchas organizaciones revisen sus criterios de adquisición. Si existe un esquema europeo relevante para una categoría tecnológica concreta y tu entidad ni siquiera se plantea incorporarlo como criterio de scoring, la pregunta no es si la ley te obliga hoy. La pregunta es si podrás defender mañana por qué no lo hiciste.

En sectores regulados, esta lógica se amplifica. Entidades financieras ya viven algo parecido con DORA y la gestión de terceros TIC. Aunque DORA no sea el eje de este artículo, merece la referencia: los artículos 28 a 30 del Reglamento (UE) 2022/2554 exigen un marco robusto de gestión de riesgos de terceros proveedores de servicios TIC, con due diligence previa, condiciones contractuales específicas, vigilancia continua y estrategias de salida. La certificación europea no sustituye esas obligaciones, pero puede reforzar la base probatoria de ciertas decisiones. Dicho de otro modo: no te exime de hacer el trabajo duro, pero te ayuda a justificar que no elegiste a ciegas.

El Cyber Resilience Act es el acelerador silencioso

Si NIS2 presiona a quienes operan sistemas, el CRA presiona a quienes fabrican o comercializan productos con elementos digitales. Juntos crean una pinza regulatoria. Uno exige gestionar el riesgo en explotación; el otro exige que el producto llegue al mercado con seguridad incorporada y con un proceso de gestión de vulnerabilidades que no sea pura decoración.

El CRA contiene requisitos esenciales de ciberseguridad y de gestión de vulnerabilidades que afectarán a fabricantes, importadores y distribuidores. También impone obligaciones de notificación para vulnerabilidades explotadas activamente e incidentes graves. El calendario es relevante: el reglamento entró en vigor el 10 de diciembre de 2024, mientras que la mayoría de obligaciones serán aplicables el 11 de diciembre de 2027, con disposiciones concretas adelantadas para notificación y designación de organismos. El mensaje es nítido: hay tiempo para prepararse, pero no para dormirse.

¿Por qué esto refuerza el mandato de ENISA? Porque el CRA necesita mecanismos de evaluación y un ecosistema de confianza técnica. Cuando la UE exige seguridad por diseño, mantenimiento de software, gestión de vulnerabilidades, documentación técnica y, en ciertos casos, evaluación por terceros, la certificación deja de ser un accesorio y pasa a ser parte del andamiaje. ENISA, que ya trabaja en esquemas europeos y en guías de certificación, queda mejor posicionada para influir en cómo se materializan esos requisitos en sectores y tecnologías específicas.

Para los proveedores, esto supone una transición incómoda. Muchos todavía venden “secure by design” como lema comercial, no como disciplina trazable. El CRA convierte esa vaguedad en riesgo regulatorio. Para los compradores, significa que la due diligence sobre producto deberá evolucionar. Ya no bastará con pedir un SOC 2, una ISO 27001 corporativa y una hoja de respuestas al SIG Lite. Harán falta preguntas sobre SBOM, política de vulnerabilidades, soporte de seguridad, plazos de parcheo, mecanismo de actualizaciones, diseño seguro y, cuando proceda, certificación o evaluación de conformidad aplicable.

Eso conecta directamente con ENISA porque la agencia, además de su papel en certificación, lleva años produciendo trabajo técnico sobre supply chain, cloud, 5G, vulnerability disclosure y esquemas específicos. No toda esa producción tiene fuerza vinculante. Pero ignorarla mientras la UE construye obligaciones cada vez más operativas es una forma bastante cara de ahorrar tiempo.

Qué cambia en procurement, vendor risk y arquitectura: bastante más de lo que parece

La consecuencia más inmediata del mandato reforzado de ENISA no está en una sala de reuniones de Bruselas. Está en tus procesos internos. Sobre todo en tres frentes: compras, riesgo de terceros y diseño de arquitectura.

En compras, la pregunta deja de ser “¿tiene alguna certificación?” y pasa a ser “¿qué esquema, con qué alcance, para qué versión del producto y con qué nivel de garantía?”. Parece una sutileza; no lo es. Una certificación corporativa genérica del proveedor no equivale a certificación del producto. Una evaluación antigua puede no cubrir la release desplegada. Un sello para una funcionalidad concreta no se extiende mágicamente a todo el ecosistema de la plataforma. Esta confusión es tan común que muchos vendedores viven cómodamente dentro de ella.

En vendor risk, el marco europeo obliga a refinar criterios. Si trabajas con tecnologías cubiertas por esquemas europeos existentes o previsibles, puedes incorporar esos esquemas como parte del scoring de riesgo. No como requisito automático en todos los casos, sino como factor ponderado según criticidad, exposición, datos tratados, privilegios, conectividad y dependencia operativa. Eso permite algo muy útil frente a auditorías y supervisión: demostrar que la organización no toma decisiones arbitrarias, sino basadas en una metodología reproducible.

En arquitectura, la existencia o ausencia de certificación debería influir en el diseño de compensaciones. Si una solución crítica no cuenta con el nivel de aseguramiento deseable, la respuesta madura no es siempre descartarla. Puede ser segmentarla, reducir privilegios, aislarla mediante jump servers, reforzar logging, limitar integraciones, acotar flujos de datos o imponer controles contractuales y operativos más duros. La certificación no decide por sí sola, pero sí modifica la carga de prueba.

Este es un punto que a menudo se pierde: la regulación europea no obliga a comprar solo lo perfecto; obliga, cada vez más, a ser capaz de justificar por qué lo imperfecto sigue siendo aceptable bajo controles proporcionales. Y esa justificación se vuelve mucho más difícil cuando la empresa ni siquiera ha estructurado la conversación.

El error más común: tratar la certificación como un sustituto de la gestión de vulnerabilidades

Si hay una mala lectura peligrosa, es esta: pensar que un producto certificado queda, por así decirlo, “bendecido” frente a futuras debilidades. No. La certificación evalúa un alcance, en un momento, con unos requisitos. No congela el riesgo técnico ni detiene el descubrimiento de vulnerabilidades. Quien haya seguido la historia reciente del software ya sabe que eso sería casi entrañable de ingenuo.

El propio enfoque europeo apunta en la dirección contraria. NIS2 exige gestión continua del riesgo. El CRA obliga a gestionar vulnerabilidades durante el ciclo de vida del producto. El GDPR, si hay datos personales comprometidos, mantiene sus propias obligaciones de notificación en el artículo 33, dentro de las 72 horas desde que el responsable tenga constancia de la violación de seguridad. Ninguna de esas obligaciones desaparece porque exista un certificado.

Para un CISO, esto implica una regla práctica: usar la certificación como señal de aseguramiento ex ante, no como sustituto del control operativo ex post. Dicho sin eufemismos, si tu programa de third-party risk se tranquiliza demasiado cuando ve un sello, tienes un problema de diseño.

La pregunta correcta tras ver una certificación es: ¿cómo se mantiene esa seguridad en producción? ¿Qué SLA de parcheo tiene el proveedor? ¿Cómo comunica vulnerabilidades? ¿Existe VDP o PSIRT? ¿Qué ventana de soporte ofrece? ¿Hay telemetría suficiente para detectar abuso? ¿Qué dependencias críticas arrastra el producto? ¿Cómo afecta una vulnerabilidad a mi caso de uso concreto?

Esa disciplina es la que separa a un programa serio de uno ornamental.

Para entidades financieras europeas, esto no es teoría: encaja casi de forma natural con DORA

La pieza se ha planteado desde el Cybersecurity Act, NIS2 y el CRA, pero para banca, seguros, pagos y fintech hay una derivada evidente. DORA ha convertido la resiliencia operativa digital en un campo con expectativas mucho más precisas. Desde el 17 de enero de 2025, el Reglamento (UE) 2022/2554 es aplicable. Sus exigencias sobre gestión de riesgos TIC, pruebas, incidentes y terceros críticos no mencionan ENISA en cada párrafo, pero el ecosistema regulatorio converge.

Cuando DORA pide identificar, clasificar y documentar funciones, activos y dependencias TIC; cuando exige due diligence sobre terceros y condiciones contractuales más detalladas; cuando presiona sobre testing y sobre reporting de incidentes, una certificación europea bien usada puede convertirse en una pieza de evidencia de control, especialmente en adquisiciones de infraestructura, componentes de autenticación, módulos criptográficos, servicios críticos y herramientas con privilegios elevados.

Para entidades españolas supervisadas por Banco de España, CNMV o DGSFP, el punto práctico es claro: aunque la certificación europea no sustituya los marcos sectoriales ni las guías supervisoras, sí puede ayudar a elevar el estándar documental con el que se justifican decisiones tecnológicas. Y eso importa. Porque cuando el incidente llega, la institución no solo necesita recuperar servicios; necesita también explicar por qué tomó ciertas decisiones y con qué base razonable.

El supervisor suele ser mucho menos tolerante con la improvisación retrospectiva que con la incertidumbre prospectiva. Parece una obviedad, pero conviene recordarlo.

Lo que deberías hacer ahora si diriges seguridad o cumplimiento

No hace falta montar un programa paralelo de “certificación europea” como si fuera una religión nueva. Sí hace falta integrar este cambio en procesos existentes. La forma más sensata de hacerlo es convertirlo en criterios operativos, no en eslóganes.

Empieza por un inventario de categorías tecnológicas donde la certificación europea ya existe o previsiblemente tendrá relevancia: componentes de identidad, hardware seguro, productos con alto impacto en red, software de gestión privilegiada, dispositivos conectados, tecnología industrial o soluciones embebidas. Si tu organización no puede ni siquiera listar qué tipos de tecnología merecen más aseguramiento, el problema viene de antes de ENISA.

Después, revisa tus plantillas de procurement y vendor risk. Añade campos que obliguen a distinguir entre certificación del proveedor y del producto, entre certificación vigente y caducada, entre alcance completo y parcial, entre autoevaluación y evaluación independiente. Introduce además una lógica de escalado: cuando no exista certificación relevante, exige evidencia alternativa específica. No un “cumplimos buenas prácticas”, sino documentación verificable sobre arquitectura segura, hardening, gestión de vulnerabilidades, soporte y pruebas.

También conviene involucrar a arquitectura y a legal. A arquitectura, para definir controles compensatorios cuando el aseguramiento del producto sea menor al deseable. A legal, para traducir expectativas de seguridad en cláusulas exigibles: tiempos de notificación, colaboración en incidentes, acceso a evidencias, soporte de auditoría, gestión de subcontratistas y derechos de terminación si el riesgo se dispara.

Por último, forma a la dirección en una idea básica pero decisiva: certificación no equivale a seguridad absoluta, pero ausencia de certificación o de evidencia equivalente sí incrementa la carga de justificación. Esa frase, bien entendida, mejora muchas decisiones.

La pregunta incómoda que deja este marco

Europa está construyendo algo que durante años parecía improbable: un lenguaje regulatorio más coherente para hablar de confianza técnica. No perfecto, no siempre rápido y no inmune a la burocracia, pero bastante más serio que antes. ENISA es una pieza central de ese movimiento porque ayuda a convertir grandes principios políticos en esquemas utilizables.

La pregunta incómoda para las empresas no es si la certificación europea resolverá todos sus problemas. No lo hará. La pregunta es otra: cuando tus reguladores, tus clientes y tus auditores te pidan explicar por qué confías en una tecnología crítica, ¿vas a responder con una metodología defendible o con la fe habitual en el dossier comercial del proveedor?

Aquí está el quid. El mandato de ENISA bajo el Cybersecurity Act no importa porque cree más papeles. Importa porque reduce el espacio para fingir que la confianza en tecnología crítica puede seguir siendo informal. Y esa, para bastantes organizaciones, es una noticia menos cómoda de lo que admiten en público.