Conformidad CRA: Lecciones del esquema EUDIW de ENISA [2026]

El 3 de abril de 2026, ENISA publicó el borrador v0.4.614 del esquema de certificación para la Cartera de Identidad Digital de la UE (EUDI Wallet): 110 páginas, una consulta pública abierta hasta el 30 de abril y un seminario web el 8 de abril. Este es el primer esquema de certificación de ciberseguridad para servicios TIC redactado bajo la Ley de Ciberseguridad de la UE. El EUCC ya cubre los productos TIC; este esquema abre un nuevo terreno al aplicar el mismo marco a los servicios. Se dirige a las carteras de identidad digital, no a los productos en general. Pero los estándares de evidencia, las obligaciones de cadena de suministro y la infraestructura de conformidad que establece darán forma a cómo funciona toda la certificación de ciberseguridad de la UE, incluidos los esquemas que eventualmente gobernarán los productos CRA. A continuación se detalla qué exige el esquema, dónde se referencia explícitamente al CRA y qué deben seguir de cerca los fabricantes de productos.

Por qué un esquema de cartera importa a los fabricantes de productos

El esquema EUDIW y el CRA operan sobre objetos jurídicos distintos. El CRA regula los productos con elementos digitales comercializados en la UE. El esquema de cartera regula un tipo específico de servicio: la solución EUDI Wallet. No son la misma regulación.

Pero comparten la misma base legal.

El artículo 24 y el artículo 27 del CRA hacen referencia a los esquemas de certificación de ciberseguridad de la UE en el marco de la Ley de Ciberseguridad como vía alternativa de conformidad. Un producto cubierto por un esquema CSA aplicable puede utilizar la certificación bajo ese esquema para demostrar la conformidad con los requisitos esenciales correspondientes del CRA. Aún no existe ningún esquema que cubra los productos CRA. El esquema EUDIW es el primero redactado, y las decisiones que tome ENISA aquí, sobre formatos de evidencia, requisitos de cadena de suministro y metodología de evaluación, tendrán continuidad en el futuro.

El esquema traza una línea jurisdiccional clara en la página 9. El texto es directo: el CRA "no se aplica directamente a las EUDI Wallets tal como se certifican en el contexto del presente esquema, ya que se certifican como servicios TIC, no como productos TIC". Para la mayoría de los participantes en EUDIW, el CRA no es una obligación paralela. El esquema tomó prestada selectivamente la metodología del CRA, pero ese préstamo no extiende el ámbito de aplicación del reglamento.

La excepción es el móvil. Cuando la instancia de cartera es una aplicación móvil comercializada por una entidad comercial, el CRA se aplica a esa aplicación como producto con elementos digitales. Para las empresas que distribuyen comercialmente una aplicación de cartera móvil, dos regímenes se aplican simultáneamente. El CRA cubre las obligaciones de conformidad previa a la comercialización y de gestión de vulnerabilidades posterior del producto. El esquema de cartera cubre la certificación continua del servicio. Se acumulan, pero únicamente en este escenario específico. Una organización que proporcione una solución de cartera puramente como servicio TIC no tiene obligación CRA a través de este esquema.

El marco compartido incluye la Ley de Ciberseguridad y el marco europeo de evaluación basado en Criterios Comunes (ECCF), CEN TS 18072 para los requisitos de servicio de cartera, y el EUCC (esquema europeo de certificación de ciberseguridad basado en Criterios Comunes) como base composicional para los componentes de hardware y plataforma. Ninguna de esa infraestructura se construyó exclusivamente para carteras. Es el esqueleto que usarán los futuros esquemas adyacentes al CRA.

Un límite adicional: el esquema establece que los certificados EUDIW "no serán adecuados para la presunción de conformidad" bajo el CRA (p.9). Incluso para las aplicaciones de cartera móvil en las que el CRA sí se aplica, el certificado EUDIW no satisface la conformidad con el CRA. Los dos caminos de cumplimiento son independientes y deben completarse por separado.

Distribuidores de carteras móviles: dos caminos de cumplimiento independientes. Si es una entidad comercial que comercializa una aplicación de cartera móvil en el mercado de la UE, el CRA se aplica a esa aplicación como producto con elementos digitales. Necesita la evaluación de conformidad CRA para el producto y la certificación EUDIW para el servicio de cartera. Ninguna satisface a la otra. Ambas deben completarse de forma independiente y mantenerse bajo ciclos de vigilancia separados. Si proporciona la cartera puramente como servicio TIC sin ninguna aplicación móvil distribuida de forma independiente, el CRA no se le aplica a través de este esquema.

Si sus productos estarán eventualmente sujetos a un esquema de certificación CSA bajo la vía del artículo 27 del CRA, el esquema de cartera es el mejor anticipo disponible de cómo será esa evaluación. Las metodologías que aquí se validan son las metodologías a las que se enfrentará.

Consulte la guía de decisión sobre evaluación de conformidad para conocer las opciones actuales de módulos CRA mientras los esquemas CSA siguen pendientes.

La infraestructura de certificación hoy

El panorama de conformidad del CRA tiene actualmente cuatro niveles. Los productos predeterminados (la mayoría) pueden utilizar la autoevaluación del Módulo A. Los productos importantes de Clase I pueden usar el Módulo A si aplican estándares armonizados, o acudir a un Organismo Notificado. Los productos importantes de Clase II y los críticos requieren evaluación por terceros, y los productos críticos también necesitan un esquema CSA aplicable cuando exista.

La brecha: actualmente no existe ningún esquema CSA que cubra los requisitos esenciales del CRA. Eso significa que la vía del artículo 27, donde la certificación CSA activa la presunción de conformidad con el CRA, no es todavía transitable para ningún producto. Existe en el reglamento pero no en la práctica.

El esquema EUDIW no cubre esa brecha. Pero establece el modelo.

El esquema exige exclusivamente el nivel de garantía "alto", sin niveles inferiores permitidos. El razonamiento en el documento es directo: "todas las funciones proporcionadas por las carteras EUDI son funciones de seguridad, algunas de ellas de sensibilidad crítica" (p.17). El esquema determina que ninguna función de cartera es lo suficientemente poco crítica como para permitir la autoevaluación.

La autoevaluación no está simplemente desaconsejada. Está bloqueada: "Una autoevaluación de conformidad... no estará permitida" (p.18).

La lógica es paralela al enfoque del CRA para los productos importantes y críticos. Mayores riesgos justifican vías de conformidad más estrictas. El umbral específico difiere entre los regímenes, pero el principio es idéntico. Cuando ENISA redacte futuros esquemas CSA para categorías de productos CRA, cabe esperar el mismo razonamiento aplicado a los productos del Anexo III y IV.

Para conocer las reglas actuales de clasificación de productos bajo el CRA, consulte la guía de clasificación de productos.

Lo que el esquema exige a las empresas privadas

El esquema define un ciclo de vida de cuatro fases para los solicitantes.

La preparación abarca el ensamblaje de documentación, la evaluación de riesgos y la recopilación de evidencias de garantía para los componentes. Aquí es donde la evidencia de su cadena de suministro se convierte en una dependencia bloqueante, no en un complemento de mejores esfuerzos.

La primera evaluación implica la revisión del diseño y el análisis de dependencias. Un ITSEF (instalación de evaluación de seguridad de TI) revisa su arquitectura, su modelo de confianza y el estado de conformidad de cada componente del que depende su cartera.

La segunda evaluación implica pruebas funcionales, pruebas de penetración y evaluación de vulnerabilidades frente a las funciones de seguridad declaradas de la cartera. No es una revisión documental. Los evaluadores sondean activamente el sistema.

El mantenimiento continúa tras la emisión del certificado. Se requiere vigilancia anual, incluidas pruebas de penetración en cada aniversario. No es una casilla que marcar. Es un coste de evaluación recurrente integrado en el ciclo de vida del certificado.

El certificado tiene una validez de 5 años. El límite es estricto. El esquema establece que no es posible ninguna derogación (p.26). Cuando el certificado caduca, la cartera debe desactivarse. No hay período de gracia negociable.

La obligación de integridad de la información es más exigente que la mayoría de los marcos de cumplimiento. Proporcionar información incorrecta o incompleta al organismo de certificación se clasifica como incumplimiento, no como no conformidad (p.23-24). La distinción importa: la no conformidad activa un proceso de subsanación. El incumplimiento puede activar la suspensión o retirada por motivos diferentes.

Tras la notificación de una no conformidad, dispone de 30 días para evaluar si el hallazgo es material (p.38). Ese plazo no comienza cuando descubre el problema. Comienza cuando el organismo de certificación le notifica. Las organizaciones que no tienen procesos de recepción para las notificaciones de conformidad agotarán ese plazo antes de que nadie lea el correo electrónico.

La suspensión es pública. El esquema exige la divulgación pública obligatoria cuando se suspende un certificado (p.40). El período máximo de suspensión es de 42 días, ampliable a 1 año por la autoridad nacional de certificación de ciberseguridad (NCCA). No es un asunto interno. Sus clientes y partes que confían en el certificado lo verán.

La retención de documentos se extiende 5 años más allá del vencimiento del certificado, incluyendo muestras físicas del producto donde corresponda (p.49). Para productos de software con un certificado de 5 años, eso supone una cadena de evidencias mínima de 10 años.

El modelo CRA exige evaluación de conformidad previa a la comercialización y gestión de vulnerabilidades posterior. El esquema de cartera exige conformidad continua con pruebas de penetración anuales y vigilancia durante todo el ciclo de vida del certificado. Para las empresas sujetas a ambos, las obligaciones de post-certificación del esquema de cartera son más exigentes que las del CRA en alcance y frecuencia.

Su cadena de suministro ya está dentro de la cadena de certificación

El esquema de cartera utiliza un modelo de evaluación composicional con tres capas distintas.

La WSCA (aplicación criptográfica segura de cartera) y su plataforma de hardware subyacente se evalúan bajo EUCC, el esquema europeo de Criterios Comunes. Esto cubre los módulos de seguridad de hardware, los elementos seguros y los entornos de ejecución de confianza de los que depende la cartera.

La instancia de cartera (el software que se ejecuta en el dispositivo del usuario) se evalúa bajo FiTCEM, el método de evaluación funcional de TI común, que gestiona la evaluación de software donde la separación de hardware no es factible.

Los servicios de cartera (componentes del lado del servidor, emisión de identidad, interfaces de partes que confían) se evalúan frente a los requisitos de CEN TS 18072.

Cada capa tiene su propia vía de evaluación. Su certificado depende de los certificados que tiene por debajo.

El esquema es explícito sobre la carga que esto impone a los solicitantes: debe "reunir la documentación de garantía para sus componentes, lo que puede implicar que algunos de ellos estén certificados" (p.14). "Puede implicar" es una expresión suave. Si un componente carece de la documentación de garantía requerida, su evaluación no puede concluir.

La divulgación de subcontratistas es exhaustiva. Cada subcontratista debe figurar en la lista, junto con el alcance de la evaluación de conformidad aplicada a su contribución (p.78). No existe la categoría genérica "usamos proveedores reputados". Cada tercero tiene evidencia documentada de conformidad o no la tiene, y esa brecha es su problema en la evaluación.

Las notificaciones de vulnerabilidades ascendentes son obligatorias en ambas direcciones. Cuando una vulnerabilidad afecta a un producto TIC que subyace a un servicio TIC compuesto, el titular del certificado EUCC debe informar a los titulares de certificados EUDIW dependientes (p.43). Esta es una obligación específica vinculada a la divulgación de vulnerabilidades, no una notificación general para cada cambio de certificado. Si el proveedor de su componente identifica una vulnerabilidad y no se la comunica, incumple. Si se la comunica, dispone de un plazo de 30 días para evaluar la materialidad y responder.

La supervisión continua no se detiene en el límite de su organización. Cuando se actualiza o sustituye el certificado de un componente base, el CAB debe realizar un análisis diferencial de dependencias sobre los cambios (p.84). Una actualización significativa de una dependencia activa una evaluación formal del CAB sobre si el alcance de su certificación se ve afectado.

Los proveedores de nube no están exentos. El esquema clasifica la infraestructura "suministrada por el proveedor" (p.61) como un componente dentro del alcance para la evaluación de la cadena de suministro. Si su servicio de cartera se ejecuta en una plataforma en la nube, el estado de conformidad de esa plataforma forma parte de su paquete de evidencias.

La regla de propagación es relevante: si hay una corrección de no conformidad pendiente en el informe de certificación de un componente base, el CAB debe evaluar su impacto sobre el servicio TIC compuesto (p.84). Si ese impacto es material, la evaluación compuesta no puede concluir hasta que se resuelva la no conformidad. Esto no es automático; depende de si la no conformidad se considera material para su servicio. Pero una no conformidad grave abierta en el informe de certificación de su proveedor de WSCA puede impedir que su evaluación concluya.

Este no es un modelo hipotético futuro para el CRA. La obligación de SBOM del CRA (Anexo I Parte II) y los requisitos de vigilancia de vulnerabilidades (artículos 13 y 14) operan bajo el mismo principio. El esquema de cartera muestra cómo funcionan esas obligaciones en la práctica dentro de un marco de certificación formal: documentadas, bilaterales y bloqueantes.

Para conocer cómo interactuarán las obligaciones de cadena de suministro del CRA con los futuros esquemas de certificación CSA, consulte Cybersecurity Act 2. Para los aspectos prácticos de generación y mantenimiento de SBOM, consulte la guía de generación de SBOM.

Qué valen realmente sus certificaciones existentes

La mayoría de los fabricantes asumen que sus certificaciones existentes tienen peso en los nuevos esquemas. Para EUDIW, la respuesta depende enteramente de qué certificación posee y con qué rigor su auditor mapeó su alcance frente a los criterios del esquema.

El esquema aborda esto directamente en la sección 5.3. Permite que los CABs se apoyen en trabajo previo, pero las condiciones son estrictas. Se requiere una carta puente cuando existe una brecha entre el período de auditoría previo y la evaluación actual (p.85). La confianza parcial es habitual; la confianza plena es infrecuente.

El hallazgo sobre ISO 27001 merece atención directa. El esquema afirma claramente: "no proporciona, por sí solo, garantías suficientes de que los controles individuales seleccionados en la declaración de aplicabilidad están diseñados y funcionan con el nivel de rigor exigido por este esquema" (p.88).

La lógica aquí aplica más allá de EUDIW. La certificación de SGSI confirma la madurez del proceso y que existe un sistema de gestión. No confirma que los controles individuales funcionen al nivel de garantía que un esquema específico exige. El mismo razonamiento se aplicará bajo el CRA cuando se finalicen los estándares armonizados.

Si su auditoría SOC 2 Type II se definió sin tener en cuenta los criterios de ciberseguridad de la UE, no cumplirá los requisitos para la confianza condicional. Necesitaría un mapeo verificado de su auditor. Planifique esa conversación ahora, antes de estar en un calendario de certificación.

Para una comparación más detallada de lo que realmente cubre ISO 27001 frente a los requisitos del CRA, consulte nuestra guía comparativa de ISO 27001.

La gestión de vulnerabilidades va más allá del CRA

Los requisitos de gestión de vulnerabilidades del esquema EUDIW se nutren explícitamente del CRA. El esquema afirma: "esta sección... se nutre principalmente de otras regulaciones, como el artículo 55 de la Ley de Ciberseguridad... y también del CRA" (p.43). Ese linaje importa porque los requisitos comparten estructura pero divergen en los mecanismos.

Sobre el SBOM: el esquema exige formato legible por máquina (p.43), alineado con el Anexo I, Parte II del CRA. No es un concepto nuevo si ya sigue las obligaciones del CRA, pero confirma que el SBOM como artefacto técnico se está convirtiendo en una expectativa de referencia en todos los esquemas de la UE, no solo en los específicos del CRA.

Las actualizaciones de seguridad deben entregarse por separado de las actualizaciones funcionales (p.43). Esto es operativamente significativo. Una versión combinada que parchea vulnerabilidades y añade funciones crea ambigüedad sobre lo que los usuarios están aceptando. El esquema las trata como obligaciones distintas.

Su política de CVD debe ser pública y estar alineada con EN ISO/IEC 29147 (p.47). No es un documento de política archivado en una carpeta de cumplimiento. Debe ser localizable, actual y estructurado según el estándar.

Sobre el análisis de impacto: las puntuaciones CVSS por sí solas son insuficientes. El esquema requiere un análisis específico del contexto (p.44). Un CVSS 9.8 en un contexto de despliegue puede ser un CVSS 4.0 en el suyo, pero necesita documentar ese razonamiento, no simplemente afirmarlo.

El requisito operativamente más significativo: una vulnerabilidad material sin vía de remediación activa la retirada del certificado (p.45). Esto crea un vínculo directo entre su cadencia de parches y su estado de certificación. El reloj no se detiene en la evaluación.

La comparación con el CRA importa aquí. El CRA exige la notificación a ENISA en 24 horas tras descubrir una vulnerabilidad explotada activamente. EUDIW usa "sin demora indebida" a través de la cadena CAB. Distinto reloj, distinto canal, intención similar. Si está construyendo procesos para uno, diséñelos para satisfacer ambos.

Para un desglose específico de la obligación de notificación en 24 horas, consulte nuestro artículo sobre notificación de vulnerabilidades a ENISA. Para un punto de partida en su política de CVD, consulte la plantilla de política CVD.

Lo que está confirmado frente a nuestro análisis

Cinco aspectos a vigilar

El esquema no es definitivo. El plazo de consulta del 30 de abril significa que los cambios son aún posibles. Estas son las áreas donde el resultado afecta materialmente a su planificación.

1. Requisitos de formato de evidencias: El esquema hace referencia a SBOMs legibles por máquina y a la estructura del expediente técnico, pero no estandariza completamente lo que "suficiente" significa en la práctica. Los CABs lo interpretarán. Hasta que lo hagan, oriente sus esfuerzos hacia el formato más estructurado que pueda defender.

2. Capacidad de los CABs: La autorización requiere tanto acreditación como aprobación de la NCCA, más la finalización de una evaluación piloto (p.30). El problema de arranque es real. Si los CABs cualificados son escasos cuando el esquema entre en vigor, los plazos se dilatan independientemente de lo preparado que esté. Esto no está dentro de su control, pero afecta a sus hipótesis de planificación.

3. Reconocimiento mutuo: El esquema no adopta las disposiciones de reconocimiento mutuo del EUCC para esquemas de terceros países (p.52). El reconocimiento mutuo con terceros países se deja explícitamente abierto para una fase posterior: "estas condiciones podrán añadirse en una fase posterior". La cuestión está sin resolver, no cerrada. No cuente con que sus certificaciones estadounidenses tengan validez aquí, pero se trata de una pregunta abierta activa, no de un rechazo definitivo.

4. Extinción de esquemas nacionales: Los esquemas nacionales existentes tienen un período de 12 meses tras la entrada en vigor para seguir siendo válidos (p.56). Si su certificación actual fue emitida bajo un esquema nacional, conozca cuándo cierra ese período.

5. Preguntas abiertas: La titularidad de las pruebas de penetración, los umbrales de nivel de potencial de ataque y los calificadores de profundidad para el análisis de vulnerabilidades siguen sin resolverse en el texto actual (p.97-98). No son vacíos editoriales. Afectan a cómo define el alcance y presupuesta las evaluaciones.

Lo que sabemos con certeza

• El CRA se cita explícitamente como fuente de los requisitos del esquema.
• El SBOM en formato legible por máquina es obligatorio.
• ISO 27001 por sí solo no satisface los requisitos de control organizativo.
• La autoevaluación no está disponible en ningún nivel de garantía para los componentes EUDIW.
• La validez del certificado está limitada a 5 años.

Nuestro análisis (no confirmado)

• Los esquemas de evaluación de conformidad del CRA seguirán probablemente patrones similares en cuanto a requisitos de SBOM, política de CVD e insuficiencia de ISO 27001 de forma aislada. El esquema EUDIW ofrece una vista previa de cómo ENISA piensa estas obligaciones.
• La presión de certificación en la cadena de suministro aumentará. Los requisitos a nivel de componente de EUDIW sugieren que los fabricantes intermedios comenzarán a exigir a sus proveedores que posean certificaciones independientes, no solo autodeclaraciones.
• El mapeo de SOC 2 es una oportunidad real. Si involucra a su auditor ahora para estructurar el mapeo de criterios frente a los requisitos de ciberseguridad de la UE, puede posicionar su próximo SOC 2 Type II para una confianza condicional en lugar de empezar desde cero.

Lo que nadie sabe todavía

• Cuándo se publicará un esquema de certificación específico para el CRA y cómo será su calendario de consulta.
• Qué estándares armonizados se designarán bajo el CRA y qué umbrales de garantía establecerán.
• Cómo evolucionará la capacidad nacional de los CABs en relación con la demanda cuando varios esquemas estén activos simultáneamente.

Qué deben hacer los fabricantes ahora

La ventana de consulta y la publicación final del esquema le dan un período definido para prepararse. Estos son pasos concretos, no consejos genéricos.

• Comprenda su vía de evaluación de conformidad. Los niveles de garantía del esquema se corresponden con diferentes categorías de productos. Lo que le aplica no siempre es obvio. Use un proceso de decisión estructurado antes de asumir que conoce su camino. Comience con nuestra guía de decisión sobre evaluación de conformidad.

• Construya la evidencia ahora. Los SBOMs, las evaluaciones de riesgo, las políticas de divulgación de vulnerabilidades y los expedientes técnicos requieren tiempo para producirse correctamente. Empezar durante el período de consulta significa que puede iterar antes de que un CAB los solicite.

• No asuma que ISO 27001 le cubre. El esquema es explícito. Si su postura de cumplimiento se basa en ISO 27001 como sustituto de la garantía de ciberseguridad, tiene una brecha. Identifique qué controles necesitan verificación independiente.

• Estructure su próximo SOC 2 con el mapeo de criterios de la UE en mente. Si está próximo a una renovación de SOC 2, hable con su auditor antes de que comience la definición del alcance. El mapeo documentado de criterios frente a los requisitos de EUDIW (y eventualmente del CRA) es lo que convierte un Type II de confianza parcial a confianza condicional.

• Siga el proceso de consulta. El seminario web del 8 de abril y el plazo escrito del 30 de abril son los últimos puntos de aportación formal antes de que el esquema avance hacia su finalización. Si el esquema afecta a sus productos, presente comentarios o al menos monitoree qué cambia.

• Mapee su cadena de suministro. Identifique qué componentes ascendentes están cubiertos por el alcance del esquema. Si un proveedor no puede demostrar la certificación de un componente que usted integra, esa brecha se convierte en su problema en el momento de la evaluación.

Cómo ayuda CRA Evidence

CRA Evidence soporta la documentación y la infraestructura de procesos que requieren las evaluaciones de EUDIW y CRA:

• Gestión de SBOM: Genere, almacene y exporte SBOMs en formatos legibles por máquina alineados con los requisitos del Anexo I, Parte II del CRA.
• VDP con flujo CVD: Publique y gestione su política de divulgación de vulnerabilidades con un flujo estructurado de recepción y respuesta alineado con EN ISO/IEC 29147.
• Seguimiento de notificaciones a ENISA: Realice un seguimiento de los plazos de notificación de 24 horas, 72 horas y 14 días con registros listos para auditoría para cada notificación.
• Portal de proveedores: Gestione las notificaciones ascendentes y descendentes dentro de su cadena de suministro, con evidencia documentada de las comunicaciones para los expedientes técnicos.

Descubra lo que cubre CRA Evidence en craevidence.com.

Este artículo tiene carácter informativo únicamente y no constituye asesoramiento jurídico. Para orientación específica en materia de cumplimiento, consulte con asesores jurídicos cualificados.