El mandato de ENISA bajo el Cybersecurity Act: lo que de verdad cambia para tu programa de ciberseguridad

La pregunta útil no es si tu organización va a oír más hablar de certificación europea. Eso ya ha pasado. La pregunta útil, en 2026, es otra: qué parte de tu programa de ciberseguridad, compras y cumplimiento depende ya de decisiones que no tomas tú, sino ENISA.

Porque el Cybersecurity Act convirtió a ENISA en bastante más que una agencia de buenas intenciones y documentos bien maquetados. El Reglamento (UE) 2019/881 le dio un mandato permanente y, sobre todo, le colocó en el centro del marco europeo de certificación de ciberseguridad. Ahí están los artículos 46 y siguientes: crean el European cybersecurity certification framework, fijan cómo se diseñan los esquemas y reparten papeles entre la Comisión, ENISA y las autoridades nacionales de certificación.

Si eres CISO o responsable de cumplimiento, aquí está el quid: la certificación ya no es solo una etiqueta comercial ni una conversación para fabricantes de hardware. Se está convirtiendo en una palanca regulatoria que impacta en contratación, diseño de producto, due diligence de terceros, preparación de auditorías y defensa ante el consejo. Y ese efecto se multiplica cuando cruzas el Cybersecurity Act con NIS2, el Cyber Resilience Act y, en el caso financiero, con DORA.

La ironía es que mucha empresa sigue tratando la certificación europea como si fuera un apéndice voluntario, un nice to have para folletos. Mal negocio. En 2026, el riesgo no es no tener un sello bonito. El riesgo es no entender cómo ese ecosistema de certificación redefine lo que se espera de tus productos, proveedores y evidencias.

Qué hace realmente ENISA bajo el Cybersecurity Act

El punto de partida jurídico está en el Reglamento (UE) 2019/881. Sus artículos 46 a 65 establecen el marco europeo de certificación de ciberseguridad para productos TIC, servicios TIC y procesos TIC. No es un detalle menor: la norma no habla solo de tecnología empaquetada. Habla también de servicios y procesos. Eso abre la puerta a un uso regulatorio mucho más amplio que la clásica evaluación de un dispositivo.

El artículo 46 crea formalmente el marco europeo de certificación. El artículo 47 define los objetivos de los esquemas europeos: demostrar que productos, servicios y procesos TIC cumplen requisitos de seguridad destinados a proteger la disponibilidad, autenticidad, integridad y confidencialidad de datos, funciones o servicios. Ahí ya está la pista de por qué este régimen conecta tan bien con NIS2 y con cualquier programa serio de resiliencia.

ENISA no emite sola certificados a diestro y siniestro. Su papel es más estructural y, por eso mismo, más influyente. La agencia:

Participa en la preparación de los esquemas candidatos; apoya técnicamente a la Comisión; da soporte al European Cybersecurity Certification Group (ECCG), donde se sientan las autoridades nacionales de certificación; mantiene información pública sobre esquemas y certificaciones; y actúa como nodo de coordinación para que la Unión no acabe con 27 interpretaciones creativas de lo que significa “seguro”.

También importa el artículo 49, que prevé que la Comisión pueda solicitar a ENISA que prepare un esquema candidato para productos, servicios o procesos específicos. Traducido a lenguaje de gestión: la agenda regulatoria de certificación no surge solo del mercado; puede ser empujada políticamente por prioridades europeas. Si Bruselas decide que una categoría concreta merece armonización, ENISA entra en cocina.

Luego está el artículo 51, que describe el contenido de los esquemas europeos de certificación: alcance, requisitos, criterios de evaluación, método de evaluación, nivel de aseguramiento, reglas de supervisión, condiciones de validez y, si procede, requisitos de vulnerabilidad y actualización. Esto último merece subrayado. La norma no se limita a comprobar cómo sale el producto de fábrica. Permite incorporar exigencias sobre cómo se mantiene vivo y razonablemente seguro.

Ese detalle es decisivo en 2026 porque encaja con la lógica de seguridad durante todo el ciclo de vida que también aparece en el Cyber Resilience Act. El mercado europeo está dejando atrás la vieja comodidad de evaluar una foto fija. La película completa empieza a importar más.

El cambio de fondo: de la certificación voluntaria a la certificación que condiciona mercado y cumplimiento

Formalmente, el marco del Cybersecurity Act nació con una lógica predominantemente voluntaria. El artículo 56 establece que la certificación europea será voluntaria salvo que el derecho de la Unión o de los Estados miembros disponga otra cosa para productos, servicios o procesos concretos. Esa frase, que algunos leyeron como un alivio, en realidad es la bisagra del sistema.

No todo será obligatorio por defecto. Pero cualquier obligación sectorial futura puede apoyarse en estos esquemas. Y aunque no exista obligación legal directa, la certificación puede convertirse en condición contractual, criterio de procurement o expectativa supervisora.

Eso ya se nota en tres planos.

Primero, en la contratación pública y privada. Cuando el comprador no tiene capacidad técnica para auditar a fondo un producto o servicio, necesita atajos creíbles. Una certificación reconocida a nivel de la UE funciona como un atajo imperfecto, pero útil. No sustituye a la due diligence. La simplifica y la ordena.

Segundo, en la responsabilidad del fabricante y del proveedor. Si el mercado converge hacia esquemas concretos, vender sin esa referencia será cada vez más costoso. No necesariamente ilegal, pero sí comercialmente torpe.

Tercero, en la conversación con reguladores. NIS2 no obliga a “tener certificación europea” para todo, pero sí exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas. Eso está en el artículo 21 de la Directiva (UE) 2022/2555. Cuando una autoridad o un auditor evalúe si tu selección de controles y proveedores es razonable, ignorar un esquema europeo maduro y aplicable puede salir caro en términos de explicación.

El matiz importa: la certificación no sustituye al cumplimiento, pero puede convertirse en evidencia muy persuasiva de diligencia. Y la diligencia, cuando llegan las preguntas incómodas tras un incidente, vale más que cualquier presentación en PowerPoint.

EUCC, EUCS y la batalla por definir qué significa “confianza”

Hablar del mandato de ENISA sin hablar de esquemas concretos sería quedarse en la teoría. El ejemplo más tangible es EUCC, el esquema europeo basado en Common Criteria. La Comisión adoptó el esquema europeo de certificación para productos TIC basado en Common Criteria mediante un acto de ejecución en 2024. En 2026, EUCC ya sirve como referencia clara de hacia dónde va el mercado: evaluaciones armonizadas, reconocimiento paneuropeo y un intento serio de evitar la fragmentación.

EUCC interesa especialmente a fabricantes y a compradores de productos con altas exigencias de seguridad, desde componentes críticos hasta equipos y software que deban demostrar propiedades verificables. No es un esquema pensado para resolver por arte de magia la gestión de riesgo de una empresa usuaria. Pero sí influye en la calidad de las decisiones de compra, sobre todo en sectores regulados.

El siguiente frente es EUCS, el futuro esquema para servicios en la nube. Aquí es donde la política industrial, la seguridad y la geopolítica se han mezclado con bastante entusiasmo. Durante años, el debate sobre EUCS se contaminó con discusiones sobre soberanía, inmunidad frente a leyes extraterritoriales y requisitos adicionales no siempre fáciles de encajar en un esquema de certificación puramente técnico.

Para un CISO, la conclusión no es seguir cada pelea de pasillo en Bruselas. La conclusión práctica es más sencilla: la nube ya no se evalúa solo con cuestionarios internos, SOC 2, ISO 27001 o promesas del proveedor. El impulso europeo va hacia marcos de evaluación más formalizados y comparables. Si tu estrategia cloud depende de proveedores críticos, deberías leer cualquier avance en EUCS como un anticipo de futuras exigencias de mercado, aunque el esquema tarde en asentarse del todo.

Y luego está el gran error de interpretación que conviene evitar: creer que la certificación europea va a generar una verdad absoluta sobre seguridad. No. Lo que genera es un lenguaje común sobre un conjunto concreto de requisitos y niveles de aseguramiento. Eso ya es mucho. Pero no exime de revisar arquitectura, exposición a terceros, capacidades de respuesta o dependencia operativa.

Los niveles de aseguramiento: básico, sustancial y alto no son marketing

El artículo 52 del Cybersecurity Act define tres niveles de aseguramiento para los esquemas europeos: basic, substantial y high. Mucha gente los cita como si fueran una escala intuitiva. No lo son tanto. Tienen implicaciones de diseño, de coste y de uso.

El nivel basic está orientado a reducir riesgos conocidos básicos de incidentes y ciberataques. El nivel substantial busca reducir riesgos de ciberataques realizados por actores con capacidades y recursos limitados. El nivel high pretende resistir ataques realizados por actores con capacidades y recursos significativos.

Esto importa por dos razones.

La primera: no todos los activos ni todos los proveedores merecen el mismo nivel de exigencia. Pedir “high” por defecto para todo es una forma elegante de encarecer compras, bloquear proyectos y acabar negociando excepciones en masa. Un programa serio de seguridad usa estos niveles como una traducción práctica del apetito de riesgo y de la criticidad del servicio.

La segunda: si tu entidad no ha definido internamente cuándo espera un nivel básico, sustancial o alto, tu procurement está comprando a ciegas. Y comprar a ciegas en 2026 es una afición muy cara.

Un ejemplo operativo: una herramienta de colaboración de bajo impacto para procesos no sensibles puede encajar con exigencias equivalentes a un nivel básico o sustancial, siempre cruzadas con otros controles corporativos. Un componente de gestión de identidades, una pasarela de acceso remoto privilegiado o una plataforma de procesamiento de datos críticos seguramente exige una expectativa más cercana a “substantial” o “high”, aunque el mercado aún no ofrezca certificaciones maduras para cada categoría. La clave no es fingir precisión donde no la hay. La clave es documentar qué nivel de garantía consideras razonable y por qué.

Ese razonamiento, bien hecho, sirve luego para tres audiencias distintas: auditoría interna, regulador y comité de riesgos. Rara vez coinciden en estilo. Coinciden siempre en una pregunta: “¿por qué aceptaste este proveedor con este nivel de exposición?”. Tener una política de niveles de garantía basada en el lenguaje del Cybersecurity Act ayuda bastante más de lo que parece.

Cómo encaja todo esto con NIS2: menos folklore, más trazabilidad

NIS2 no gira alrededor de la certificación, pero ignorar la certificación dentro de NIS2 sería leer la directiva con un ojo cerrado. El artículo 21 exige medidas de gestión de riesgos de ciberseguridad adecuadas y proporcionadas. Entre ellas figuran políticas de análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, desarrollo y mantenimiento seguros, políticas para evaluar la eficacia de las medidas y formación.

La palabra que une NIS2 con el Cybersecurity Act es demostrabilidad. No basta con decir que gestionas riesgos de terceros o que has elegido tecnología segura. Debes poder explicar con criterios repetibles por qué has considerado suficientes determinadas salvaguardas.

Aquí la certificación europea aporta cuatro ventajas prácticas.

La primera es normalizar requisitos mínimos. Si un esquema europeo identifica controles, pruebas, métodos de evaluación y condiciones de validez, el comprador deja de depender exclusivamente del cuestionario del proveedor. Ya sabemos cómo acaban algunos cuestionarios: 250 preguntas, 230 respuestas ambiguas y una llamada comercial prometiendo “alineación total”.

La segunda es mejorar la comparabilidad entre proveedores. Esto es particularmente útil en concursos, renovaciones o decisiones de sustitución. No elimina el análisis de arquitectura ni el contractual. Pero evita que todo se reduzca a presentaciones de ventas adornadas con logotipos.

La tercera es reforzar la gestión de la cadena de suministro. NIS2 menciona explícitamente la seguridad de la cadena de suministro y la relación con proveedores de servicios directos en el artículo 21.2.d). Si tu mapa de terceros críticos no incorpora una vista sobre certificaciones aplicables, estás dejando fuera una capa de información objetiva que, en algunos casos, puede ser decisiva.

La cuarta es apoyar la supervisión interna. El artículo 20 de NIS2 hace a los órganos de dirección responsables de aprobar y supervisar las medidas de gestión de riesgos. Eso obliga a traducir la discusión técnica a lenguaje de gobierno. Las certificaciones no resuelven la supervisión del consejo, pero ayudan a convertir una discusión abstracta sobre ciberseguridad en criterios auditables y defendibles.

Para entidades esenciales e importantes bajo NIS2, el consejo práctico es simple: mapea dónde una certificación europea existente o previsible puede reforzar tus controles del artículo 21 y dónde no. Ambas partes importan. Lo peor es fingir que una certificación cubre más de lo que cubre.

El cruce con el Cyber Resilience Act: del “producto seguro” al “producto mantenido”

Si NIS2 presiona a los operadores, el Cyber Resilience Act presiona a fabricantes y distribuidores de productos con elementos digitales. El CRA, adoptado como Reglamento (UE) 2024/2847, introduce requisitos horizontales de ciberseguridad para productos con elementos digitales a lo largo de su ciclo de vida. Su lógica es conocida: seguridad por diseño, gestión de vulnerabilidades, actualizaciones de seguridad, documentación técnica, obligaciones de fabricantes, importadores y distribuidores, y un régimen específico para productos importantes y críticos.

La relación con el Cybersecurity Act no es cosmética. El CRA prevé el uso de normas armonizadas, especificaciones comunes y, para determinadas categorías, procedimientos de evaluación de conformidad que pueden convivir o apoyarse en marcos de certificación. No son piezas idénticas, pero hablan idiomas compatibles.

La implicación operativa es potente: la certificación europea puede convertirse en una ventaja competitiva y probatoria para fabricantes que, además, deben cumplir con obligaciones continuas de seguridad y reporte de vulnerabilidades. Y para los compradores, esa intersección ofrece una herramienta adicional para discriminar entre proveedores que han industrializado la seguridad y proveedores que siguen improvisando.

Hay otra derivada menos evidente. El CRA obliga a pensar en vulnerabilidades explotadas, parches y soporte durante periodos definidos. Si un esquema de certificación se queda demasiado atado a la foto inicial de un producto, quedará rápidamente desalineado con las exigencias del mercado y con el propio CRA. ENISA, al apoyar el desarrollo de esquemas, tiene por delante un reto nada menor: evitar que la certificación europea nazca antigua.

En otras palabras, la pregunta no es solo qué se evalúa. La pregunta es cómo se mantiene válida la confianza cuando el producto cambia, aparecen CVE nuevas y el proveedor lanza versiones cada pocas semanas. Si tu empresa compra software o dispositivos conectados a escala, ese problema ya no es teórico.

Para el sector financiero, esto también conversa con DORA aunque DORA no dependa de ENISA

DORA, el Reglamento (UE) 2022/2554, opera con su propia arquitectura y con el protagonismo de las Autoridades Europeas de Supervisión. No necesita a ENISA para justificar sus obligaciones sobre gestión del riesgo TIC, pruebas de resiliencia o terceros proveedores de servicios TIC. Pero sería un error analizar DORA en un silo.

El artículo 28 de DORA exige un marco sólido para gestionar el riesgo asociado a terceros proveedores de servicios TIC. Los artículos 30 y 31 detallan elementos contractuales y reglas para servicios que apoyan funciones críticas o importantes. Si el ecosistema europeo de certificación madura en categorías relevantes para software, cloud, identidad, conectividad o componentes críticos, los equipos de compras y TPRM del sector financiero tendrán una fuente adicional —no exclusiva, pero sí valiosa— para evaluar proveedores.

No sustituirá las obligaciones de DORA. No evitará tener que revisar subcontratación, localización de datos, concentración de riesgo, derechos de acceso, auditoría y salida. Pero sí puede elevar el suelo técnico mínimo de la conversación.

Para bancos, aseguradoras y fintech reguladas, la utilidad práctica está en cruzar tres capas de evidencia: certificaciones aplicables, controles contractuales DORA y resultados de evaluación interna. Si una de las tres falla, el cuadro queda cojo. Si las tres se refuerzan mutuamente, la capacidad de defensa mejora bastante.

Y hay un ángulo político nada menor. DORA empuja a una supervisión más dura sobre proveedores críticos de TIC designados a nivel de la UE. Paralelamente, el ecosistema de certificación puede contribuir a estandarizar expectativas sobre seguridad técnica. No es casualidad. Europa lleva años intentando dejar de depender solo de autoevaluaciones y de promesas de mercado. Con razón.

Lo que la certificación europea no va a resolver, aunque a veces se venda así

Conviene pinchar una ilusión antes de que se convierta en presupuesto mal gastado. La certificación europea no resuelve, por sí sola, ninguno de estos problemas:

No garantiza la ausencia de vulnerabilidades; no sustituye la gestión de parches; no evita configuraciones inseguras por parte del cliente; no elimina riesgo de concentración en cloud; no reemplaza pruebas de continuidad; no cubre toda la superficie operativa de un servicio complejo; y no convierte a un tercero en “aceptable” si tu contrato carece de derechos de auditoría, salida o notificación.

El artículo 54 del Cybersecurity Act exige que los certificados europeos indiquen, entre otras cosas, el alcance, el nivel de aseguramiento y el periodo de validez. Léelo con atención: alcance y validez. Dos palabras que suelen ser víctimas de la lectura selectiva.

En la práctica, los fallos más comunes son cuatro.

Uno: confundir certificación del producto con seguridad del despliegue. Un componente puede estar evaluado y luego implantarse de forma chapucera.

Dos: asumir que una certificación de una parte del servicio cubre el servicio completo. No siempre. De hecho, a menudo no.

Tres: usar el certificado como excusa para relajar monitorización o pruebas propias. Mala idea. El atacante no cancela sus planes porque tú tengas un PDF sellado.

Cuatro: no revisar la fecha de emisión, el alcance exacto y las condiciones de mantenimiento. Si el certificado depende de una versión concreta o de una configuración específica, ese detalle no es burocracia. Es el núcleo de su utilidad.

Un programa maduro usa la certificación como evidencia complementaria, no como sustituto de gobierno técnico.

Qué debería cambiar ya en tu programa si no quieres que esto te pille tarde

La mejor manera de integrar el mandato de ENISA en tu programa no es crear un “proyecto ENISA” con nombre pomposo. Es incrustar sus efectos en procesos que ya existen: arquitectura, procurement, TPRM, gestión de excepciones, cumplimiento y reporting al consejo.

1. Reescribe tu taxonomía interna de garantía

Si tus políticas distinguen solo entre “proveedores críticos” y “no críticos”, te falta una capa. Introduce una taxonomía de expectativa de garantía alineada con la lógica del artículo 52 del Cybersecurity Act. No necesitas copiar literalmente básico/sustancial/alto para cada caso, pero sí traducirlo a reglas operativas: qué tipos de activos, servicios o componentes requieren qué evidencia mínima.

Eso permite que compras, seguridad y negocio dejen de hablar dialectos distintos. Hoy muchas fricciones vienen de ahí, no del regulador.

2. Mete la certificación en el intake de proveedores, no al final

Si preguntas por certificaciones solo cuando el contrato está listo para firma, has llegado tarde. La cuestión debe entrar en la fase de scoping: ¿existe un esquema europeo aplicable? ¿el proveedor está certificado, en proceso o sin intención? ¿qué cubre exactamente? ¿qué huecos deja? Esa conversación temprana ahorra discusiones más dolorosas cuando el proyecto ya está políticamente comprometido.

3. Cruza certificación con SBOM, vulnerabilidades y soporte

El error clásico es tratar la certificación como un compartimento estanco. No lo es. Si compras software o productos conectados, tu revisión debe cruzar: certificación disponible, gestión de vulnerabilidades, política de divulgación, tiempos de parcheo, soporte y, cuando proceda, SBOM. El CRA ha reforzado esta lógica de ciclo de vida. Seguir evaluando en silos es una receta para las sorpresas desagradables.

4. Ajusta plantillas contractuales

Si una certificación es relevante para la prestación, el contrato debe reflejarlo. No con poesía jurídica, sino con cláusulas concretas sobre mantenimiento de la certificación cuando aplique, notificación de pérdida o cambio material, información sobre alcance, cooperación documental y tratamiento de hallazgos. Esto no sustituye obligaciones nucleares de seguridad. Las complementa.

5. Prepara a auditoría interna y al consejo

La dirección no necesita un seminario sobre ENISA. Necesita respuestas a tres preguntas: qué categorías de proveedores o productos estamos priorizando, qué evidencia exigimos y qué exposición aceptamos cuando no existe certificación aplicable. Si no puedes responder de forma compacta y trazable, tu programa todavía no ha digerido el cambio regulatorio.

Implicaciones para entidades financieras españolas

Para entidades financieras españolas, la conversación tiene un matiz particular. Por un lado, están sometidas a DORA desde 2025, con exigencias de gobierno, gestión de terceros y resiliencia operativa que ya no admiten mucha improvisación. Por otro, operan en un mercado europeo donde proveedores globales y locales competirán cada vez más con argumentos de certificación y conformidad.

Eso obliga a bancos, aseguradoras, EDE, EP, gestoras y fintech reguladas a evitar dos errores opuestos.

El primero es sobrevalorar la certificación europea y rebajar indebidamente pruebas internas, revisiones contractuales o escenarios de salida. Un proveedor certificado puede seguir siendo una dependencia excesiva, una mala opción geográfica o un riesgo de concentración.

El segundo es infravalorarla y seguir operando con matrices de terceros heredadas que apenas distinguen entre “tiene ISO” y “no tiene ISO”. En 2026, esa granularidad ya sabe a 2018.

Para entidades españolas supervisadas por Banco de España, CNMV o DGSFP, el valor práctico está en convertir la certificación europea en parte de la narrativa de control: cómo soporta la selección de terceros, cómo influye en clasificaciones de criticidad y cómo se integra con obligaciones de DORA, NIS2 cuando aplique y GDPR en entornos de tratamiento de datos personales. No hay una obligación general de exigir esquemas europeos en todos los casos. Sí hay una expectativa creciente de que sepas cuándo importan y por qué.

Además, España no opera en el vacío. Si grupos financieros con presencia en varios Estados miembros empiezan a homogeneizar sus criterios de compra en torno a esquemas europeos, las filiales nacionales acabarán adaptándose. A veces por regulación. A veces por puro gobierno corporativo. El resultado práctico es el mismo.

La pieza política que no conviene ignorar

Detrás del mandato de ENISA hay una apuesta política clara: reducir fragmentación, elevar el nivel medio de seguridad y dar a la UE una herramienta de confianza propia frente a estándares dispersos y dependencias externas. El problema es que toda herramienta política corre el riesgo de exagerar su capacidad transformadora.

La certificación europea será útil si cumple tres condiciones.

Primera, si los esquemas llegan a tiempo. Un esquema que aparece cuando el mercado ya ha cambiado de arquitectura o de modelo de servicio nace cansado.

Segunda, si el alcance es comprensible. Cuanto más opaco sea para compradores y auditores, menos valor práctico tendrá.

Tercera, si convive bien con marcos globales y con obligaciones sectoriales. Europa no puede aspirar a armonizar generando una nueva capa de complejidad inútil. Ya tenemos suficientes siglas. No hacen falta más si no resuelven un problema real.

ENISA juega aquí un papel delicado. Debe impulsar rigor técnico sin convertir cada esquema en un monumento al procedimiento. No es una tarea fácil. Pero es decisiva. Si la agencia y la Comisión aciertan, la certificación europea puede convertirse en una de las pocas piezas regulatorias que de verdad mejoren decisiones de compra y de diseño. Si fallan, acabaremos con certificados solemnes y poco operativos. Europa tiene cierta afición a ese género literario.

La pregunta que deberías hacer mañana por la mañana

No preguntes si “ya cumplimos con ENISA”. Esa frase no significa gran cosa y, además, revela que alguien ha mezclado agencia, reglamento y esquema en la misma coctelera.

Pregunta esto: en qué decisiones críticas de producto, cloud y terceros estamos usando —o ignorando— el marco europeo de certificación, y qué riesgo genera cada caso.

Si la respuesta es difusa, toca trabajo. Revisa tus categorías de proveedores, identifica dónde existen esquemas europeos o son previsibles, ajusta tus criterios de evaluación, forma a compras y documenta tu racional. No hace falta dramatizar. Hace falta madurar.

Porque ese es el cambio de fondo del mandato de ENISA bajo el Cybersecurity Act: no obliga a todas las empresas a correr detrás de un certificado. Obliga a las organizaciones serias a pensar la confianza tecnológica con más método, más evidencia y menos fe comercial.

Y francamente, ya era hora.