Categoría: Certificación

  • ¿Quién certificará la IA en España?

    ¿Quién certificará la IA en España?

    Desde junio se tramita en la Comisión de Economía del Congreso el Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial, que no regula la inteligencia artificial, cosa que ya hace el Reglamento europeo con eficacia directa, sino aquello que el Reglamento deja en manos de cada Estado: quién designará a los organismos que evaluarán la conformidad, quién vigilará el mercado y quién sancionará los incumplimientos. Nada dice, sin embargo, sobre quien tendrá la competencia para certificar los modelos de IA que así lo necesiten conforme el Reglamento comunitario. A este respecto, los sistemas de alto riesgo del Anexo III y que incluyen los de, por ejemplo, selección de personal, evaluación de solvencia, educación, seguros, migración o justicia (el catálogo definitivo se está analizando por la Comisión con el apoyo del AI Advisory Forum del que forma parte CerteIDAS), requieren de la implantación de un sistema de control interno documentador y un sistema de evaluación de primera parte, esto es, de autoevaluación con la excepción de los sistemas biométricos que podrán pasar a este sistema cuando aplique normas armonizadas.

    La evaluación de conformidad de tercera parte y su obligatoriedad aparece referida en el anexo I que se refiere a los modelos integrados en productos que ya eran objeto de certificación como  es el caso de los productos sanitarios, máquinas, ascensores o juguetes. En este supuesto, las mismas entidades de certificación que evaluaban estos productos serán las que lo hagan con las integraciones de IA.

    Por tanto, no hay obligación de certificar los modelos de alto riesgo conforme el reglamento aunque es más que probable que el mercado imponga esa revisión de las afirmaciones propias por un tercero, que es en lo que consiste un proceso de certificación.

    Que no exista obligación de certificar no significa, sin embargo, que estos sistemas queden fuera del control administrativo. El Reglamento impone al proveedor, y en determinados casos al responsable del despliegue, obligaciones de registro y de comunicación a las autoridades antes y después de la introducción en el mercado, y de esas autoridades se ocupa precisamente el Proyecto español, que distingue dos funciones: la vigilancia del mercado, que recibe las comunicaciones, inspecciona y sanciona, y la notificación de organismos, que designa a quienes evaluarán la conformidad cuando proceda. Las comunicaciones principales son las siguientes:

    ObligaciónQué se comunicaA quiénCuándo y base
    Registro del sistemaDatos del sistema y del proveedor (anexo VIII); también los responsables del despliegue que sean autoridades públicasBase de datos de la UE gestionada por la Comisión (art. 71), no una autoridad nacionalAntes de la introducción en el mercado o la puesta en servicio (art. 49)
    Incidente graveDescripción del incidente y del nexo causal, real o razonablemente probable, con el sistemaAutoridad de vigilancia del mercado del Estado donde se produceEn cuanto se establezca el nexo y, en todo caso, en 15 días; 10 si hay fallecimiento; 2 en caso de infracción generalizada o afectación a infraestructuras críticas (art. 73)
    Evaluación de impacto sobre derechos fundamentalesResultado de la evaluación realizada por el responsable del despliegue (organismos públicos, servicios esenciales, crédito y seguros)Autoridad de vigilancia del mercado competenteAntes del primer uso del sistema (art. 27)
    No conformidad y medidas correctorasNaturaleza de la no conformidad y medidas adoptadas: corrección, retirada, desactivación o recuperaciónAutoridad de vigilancia del mercado del Estado donde se comercializa y, en su caso, organismo notificadoEn cuanto el proveedor tenga motivos para considerar que el sistema no es conforme (art. 20)
    Riesgo o incidente detectado por quien despliegaRiesgo para la salud, la seguridad o los derechos fundamentales, o incidente graveProveedor y autoridad de vigilancia del mercadoSin demora indebida, con suspensión del uso (art. 26.5)
    Información requeridaDocumentación técnica, registros y acceso al sistemaAutoridad de vigilancia del mercadoA requerimiento (art. 74)

    El Proyecto reparte la vigilancia del mercado entre ocho autoridades, de modo que la primera tarea de cualquier operador es identificar cuál le corresponde por el ámbito de su sistema:

    Autoridad de vigilancia del mercadoÁmbito
    AESIACarácter general para el anexo III no atribuido a otra autoridad; transparencia del art. 50; punto de contacto único ante la Comisión; ventanilla de reclamaciones
    Agencia Española de Protección de Datos y autoridades autonómicas de protección de datosBiometría, migración, asilo y gestión de fronteras
    Consejo General del Poder JudicialSistemas destinados a la Administración de Justicia
    Banco de EspañaEvaluación de solvencia y calificación crediticia en su ámbito
    CNMVEvaluación de solvencia en su ámbito
    Dirección General de Seguros y Fondos de PensionesEvaluación de riesgos y fijación de precios en seguros de vida y salud
    Autoridades sectoriales de productoSistemas del anexo I integrados en productos con legislación armonizada (sanitarios, máquinas, juguetes, vehículos…)

    Queda por resolver quién podrá certificar cuando la evaluación de tercera parte sea obligatoria, como ocurre con los productos del anexo I y con los sistemas biométricos, o cuando el mercado la exija con valor oficial. El Reglamento reserva esa función a los organismos notificados, esto es, a organismos acreditados que cada Estado designa y comunica a la Comisión, y el Proyecto se limita a decir quién los designará en España: su artículo 4 atribuye la condición de autoridad notificante para el anexo III a la Dirección General de Inteligencia Artificial, dentro de la Secretaría de Estado de Digitalización e Inteligencia Artificial, con el apoyo de ENAC en la acreditación previa. Le corresponderá evaluar, designar y supervisar a esos organismos conforme al itinerario de acreditación, designación y notificación a la Comisión que ya siguen los que evaluamos prestadores de servicios de confianza bajo eIDAS, porque el Reglamento de IA no ha creado un modelo propio de evaluación de la conformidad sino que se apoya, como eIDAS, en el Nuevo Marco Legislativo (Reglamento 765/2008 para la acreditación y Decisión 768/2008 para los módulos), de modo que la infraestructura de un organismo ya acreditado, desde la relación con ENAC hasta la sistemática de auditoría y la supervisión de sus informes, es la misma y lo que cambia es el objeto evaluado. A fecha de hoy no existe en España ningún organismo notificado bajo el Reglamento de IA, ni puede existir hasta que la ley se apruebe y ENAC disponga de un esquema de acreditación específico. Queda además por determinar la norma de acreditación aplicable a esos organismos (ISO/IEC 17065, 17021 o 17029), decisión de la que dependerá qué entidades reúnen ya la estructura exigida y cuáles tendrán que crearla.

    Mientras ese circuito nacional no exista, la respuesta a quién certificará la ha dado, por vía indirecta, el Ómnibus Digital sobre IA, Reglamento (UE) 2026/1744, publicado el 24 de julio y en vigor desde el 27, seis días antes de la fecha prevista para la aplicación del régimen de alto riesgo. Su medida más conocida es el aplazamiento de dicha aplicación al 2 de diciembre de 2027 para el anexo III y al 2 de agosto de 2028 para el anexo I, justificado en que las normas armonizadas encargadas a CEN y CENELEC (petición M/593, enmendada por M/613) no estarán publicadas antes del último trimestre de 2026 y, sin ellas, no cabe invocar la presunción de conformidad, aunque el cumplimiento pueda demostrarse por otros medios. Pero incorpora otras dos que afectan a la pregunta de esta entrada: habilita transitoriamente, durante dieciocho meses, a los organismos notificados bajo los reglamentos de productos sanitarios para evaluar la conformidad de sistemas de IA en determinadas condiciones (artículo 43.3) y establece un procedimiento único de designación bajo ambos regímenes (artículo 28.8). En consecuencia, los primeros organismos que evalúen sistemas de IA en la Unión serán previsiblemente los ya designados en el ámbito sanitario, y quienes vengan de otros esquemas de acreditación tendrán que esperar a que su Estado ponga en marcha el suyo.

    El aplazamiento deja dieciséis meses que un proveedor del anexo III puede emplear en tres tareas sucesivas: clasificar el sistema y determinar si le basta la evaluación de primera parte o requiere la intervención de un tercero; identificar la autoridad de vigilancia competente y preparar los circuitos de comunicación con ella; y adaptar su sistema de gestión a los proyectos de norma en tramitación, en particular el prEN 18286 sobre sistema de gestión de la calidad, cuya publicación forma parte del conjunto previsto para el último trimestre de 2026 según el seguimiento que se realiza desde el Foro Consultivo del Reglamento (artículo 67), del que Certicar es miembro desde junio junto con CEN, CENELEC y ETSI como miembros permanentes, y en el que la representación corresponde a Paloma Llaneza, directora del esquema de confianza digital de CerteIDAS y editora de normas en ETSI ESI.

  • Proporcionalidad en la ETSI EN 319 401 v3.2.1 (II): el contexto regulatorio

    Proporcionalidad en la ETSI EN 319 401 v3.2.1 (II): el contexto regulatorio

    Este es el segundo de dos artículos dedicados al concepto de proporcionalidad en la norma ETSI EN 319 401 v3.2.1. En la primera entrega analizamos cómo la norma articula la proporcionalidad -cláusula 4.2, etiquetas [PRO] y lenguaje implícito de riesgos- y el análisis de riesgos como motor operativo. En esta segunda parte situamos ese mecanismo en su contexto regulatorio: el mandato de eIDAS2, la coherencia dentro de la familia de normas ETSI 319 y las diferencias con los enfoques de proporcionalidad de NIS2, el RGPD y la ISO 27001.

    El mecanismo de proporcionalidad descrito en la primera parte de esta serie -con su cláusula 4.2, sus etiquetas [PRO] y sus salvaguardas de efecto acumulativo- no es una creación autónoma de ETSI. Responde a un mandato legislativo concreto del Reglamento eIDAS2, se despliega de forma coordinada a través de un ecosistema de normas técnicas interrelacionadas, y dialoga con los enfoques de proporcionalidad de otros marcos regulatorios europeos. Entender este contexto es necesario para comprender por qué la norma dice lo que dice y, sobre todo, para aplicarla con criterio.

    El mandato legislativo: eIDAS2 y la proporcionalidad como principio rector

    El Reglamento (UE) 2024/1183 -el marco eIDAS2 que modifica el Reglamento 910/2014- incorpora la proporcionalidad en múltiples niveles de su arquitectura, creando el fundamento jurídico que la norma ETSI EN 319 401 concreta después.

    El artículo 19.1 proporciona el mandato central: los prestadores de servicios de confianza, cualificados y no cualificados, deben adoptar medidas técnicas y organizativas apropiadas para gestionar los riesgos para la seguridad de los servicios de confianza que prestan, garantizando que el nivel de seguridad sea proporcionado al grado de riesgo. Esta formulación es la que el REQ-5-02 de la EN 319 401 reproduce de forma casi literal, cerrando la cadena entre legislación y estándar técnico.

    Los considerandos del Reglamento amplían el principio en distintos ámbitos. El considerando 19 exige medidas de seguridad del monedero (wallet) proporcionadas a los riesgos planteados para los derechos y libertades de las personas físicas. El considerando 44 impone sanciones efectivas, proporcionadas y disuasorias, en las que el tamaño de las entidades afectadas, sus modelos de negocio y la gravedad de las infracciones deben tenerse debidamente en cuenta. El considerando 56 requiere que cualquier solicitud de datos por parte de las partes usuarias sea necesaria y proporcionada al uso previsto. Y el considerando 63 invoca expresamente el principio de proporcionalidad al determinar los efectos jurídicos de las firmas electrónicas, pidiendo a los Estados miembros que ponderen el valor jurídico del documento a firmar y el nivel de seguridad y coste que requiere una firma electrónica.

    Más allá de estos enunciados, el marco eIDAS2 incorpora la proporcionalidad de forma estructural a través de su modelo de confianza de dos niveles. Los TSP cualificados se enfrentan a evaluaciones de conformidad obligatorias cada 24 meses, inclusión en las listas de confianza nacionales, obligaciones reforzadas de verificación de identidad y requisitos de seguridad más estrictos. Los TSP no cualificados están sujetos a la seguridad de base del artículo 19 y a una supervisión ex post. Esta graduación es en sí misma un mecanismo de proporcionalidad: la carga de cumplimiento se escala con el nivel de confianza declarado. Dentro del nivel cualificado, las normas ETSI diferencian aún más mediante niveles de política: la EN 319 411-1 define políticas de certificados Lightweight (LCP), Normalized (NCP) y Extended Validation (EVCP), cada una con niveles de aseguramiento distintos y la correspondiente intensidad de requisitos.

    La familia ETSI 319: un modelo hub-and-spoke coherente

    El ecosistema de normas ETSI para servicios de confianza sigue una arquitectura clara de centro y radios (hub-and-spoke) para la proporcionalidad. La EN 319 401 actúa como centro, definiendo el marco de proporcionalidad que heredan todas las normas específicas por tipo de servicio.

    Las normas EN 319 411-1 (certificados, general) y EN 319 411-2 (certificados cualificados) referencian la EN 319 401 como su base de política general: todos los requisitos de la EN 319 401, incluidos los criterios de proporcionalidad de la cláusula 4.2, se aplican como capa base. La EN 319 411-1 añade después requisitos específicos de certificados mediante sus propios prefijos de nivel de política (GEN-, OVR-, LCP-, NCP-, EVCP-), mientras que la EN 319 411-2 incorpora requisitos de servicios cualificados que son intrínsecamente más estrictos, reduciendo la flexibilidad que la proporcionalidad ofrece para los servicios de mayor nivel de aseguramiento.

    La EN 319 421 (sellos de tiempo) sigue el mismo patrón de herencia, declarando explícitamente que se aplican los requisitos de la ETSI EN 319 401 para el análisis de riesgos. La EN 319 521 (entrega electrónica certificada) lista la EN 319 401 como su única referencia normativa. Normas adicionales como la ETSI TS 119 431-1 (componentes de servicio QSCD remoto), la ETSI TS 119 461 (prueba de identidad) y la ETSI TS 119 511 (servicios de preservación) se construyen todas sobre el mismo marco.

    Esta coherencia tiene una consecuencia práctica importante: un TSP que opera múltiples servicios de confianza se encuentra con la misma lógica de proporcionalidad independientemente del tipo de servicio. Solo cambian los requisitos obligatorios específicos del servicio. El enfoque también implica que cuando la EN 319 401 v3.2.1 introduce el mecanismo [PRO], todas las normas dependientes se benefician automáticamente del marco de proporcionalidad reforzado sin necesitar actualizaciones individuales.

    La EN 319 403-1 -la norma que regula los organismos de evaluación de la conformidad- apoya esta arquitectura exigiendo a los auditores competencia en análisis y gestión de riesgos. Sin embargo, es menos explícita que la EN 319 401 sobre cómo deben los auditores evaluar específicamente las decisiones de proporcionalidad, una laguna que organismos nacionales como el BSI alemán han abordado mediante manuales de evaluación suplementarios y que tiene implicaciones directas para la práctica de auditoría.

    Proporcionalidad en clave comparada: NIS2, RGPD e ISO 27001

    El concepto de proporcionalidad en ETSI/eIDAS comparte ADN con marcos regulatorios paralelos, pero difiere en aspectos estructurales que conviene conocer. Los cuatro grandes marcos -eIDAS/ETSI, NIS2, RGPD e ISO 27001- utilizan variantes de «apropiado al riesgo» como formulación central, exigen evaluación de proporcionalidad multifactorial, requieren revisión continua y anclan las medidas al estado del arte. Pero las diferencias en cómo instrumentan el principio son relevantes.

    La Directiva NIS2 (Directiva (UE) 2022/2555) es la más explícita en cuanto a los criterios de evaluación de proporcionalidad, exigiendo tener debidamente en cuenta cuatro factores: la exposición al riesgo de la entidad, su tamaño, la probabilidad y gravedad de los incidentes, y el impacto social y económico. Su artículo 21.1 exige medidas «apropiadas y proporcionadas», un lenguaje que sigue de cerca el artículo 19.1 de eIDAS. La conexión entre ambos marcos no es solo retórica: eIDAS2 sujeta explícitamente a los TSP a las obligaciones de gestión de riesgos de ciberseguridad de NIS2, de modo que la EN 319 401 v3.2.1 incorpora los requisitos de NIS2 directamente. Esto crea una arquitectura de proporcionalidad por capas donde los criterios de evaluación de NIS2 operan junto a los propios de eIDAS.

    El RGPD (artículo 32) articula la proporcionalidad a través de un conjunto más amplio de factores: el estado del arte, los costes de implementación, la naturaleza, alcance, contexto y fines del tratamiento, así como el riesgo de probabilidad y gravedad variables para los derechos y libertades de las personas físicas. Sus evaluaciones de impacto relativas a la protección de datos exigen explícitamente la valoración de la necesidad y proporcionalidad de las operaciones de tratamiento en relación con los fines. La proporcionalidad del RGPD opera en un espectro continuo, sin niveles formales predefinidos.

    ISO 27001:2022 adopta el enfoque más flexible: las organizaciones definen sus propios criterios de riesgo y aplican controles proporcionalmente a través de la Declaración de Aplicabilidad (SoA), que documenta cuáles de los 93 controles del Anexo A se implementan y cuáles se excluyen con justificación. El concepto de SoA es estructuralmente similar al requisito de documentación [PRO] de la EN 319 401 v3.2.1, aunque sin la salvaguarda de efecto acumulativo que esta última incorpora.

    La innovación distintiva de la ETSI EN 319 401 v3.2.1 es precisamente el mecanismo de etiquetado [PRO]: ningún otro marco marca explícitamente requisitos individuales como susceptibles de proporcionalidad exigiendo simultáneamente justificación documentada y prohibiendo la erosión acumulativa. Esto representa una concreción de la proporcionalidad más granular que la ofrecida por cualquier marco comparable.

    Hay además una diferencia estructural relevante en el mecanismo de graduación. eIDAS opera de forma única un sistema formal de dos niveles (cualificado vs. no cualificado) donde el nivel determina todo el régimen de cumplimiento. La distinción entre entidades esenciales e importantes de NIS2 es principalmente supervisora: distinta intensidad de supervisión, pero mismas medidas exigibles. RGPD e ISO 27001 carecen de clasificación formal de entidades. La graduación de eIDAS significa que la proporcionalidad opera dentro de carriles predefinidos: un TSP cualificado tiene menos flexibilidad de proporcionalidad que uno no cualificado, por diseño. La seguridad no se negocia al mismo nivel cuando lo que está en juego es la presunción legal de validez que acompaña al estatus cualificado.

    Hasta aquí el contexto regulatorio en el que se inserta el marco de proporcionalidad de la EN 319 401 v3.2.1: un mandato legislativo claro de eIDAS2, una arquitectura de normas ETSI coherente que propaga el principio de forma uniforme, y un diálogo con marcos paralelos que revela tanto convergencias como una innovación técnica propia -el etiquetado [PRO]- que no tiene equivalente directo.

  • Proporcionalidad en la ETSI EN 319 401 v3.2.1 (I): el mecanismo

    Proporcionalidad en la ETSI EN 319 401 v3.2.1 (I): el mecanismo

    Este es el primero de dos artículos dedicados al concepto de proporcionalidad en la norma ETSI EN 319 401 v3.2.1, publicada en enero de 2026. En esta primera entrega analizamos cómo la norma articula la proporcionalidad considerando el análisis de riesgos como motor operativo. En la segunda parte abordaremos el contexto regulatorio: eIDAS2, la familia ETSI 319 y la comparativa con NIS2, RGPD e ISO 27001.

    Hay una tensión estructural en los servicios de confianza que rara vez se aborda con la profundidad que merece. Una firma electrónica cualificada emitida por una empresa de dos personas tiene el mismo valor jurídico que la emitida por un proveedor multinacional. Así lo establece el Reglamento eIDAS, y así debe ser para que el sistema funcione. Pero exigir arquitecturas de seguridad idénticas a ambos haría inaccesible el mercado a los prestadores más pequeños sin que eso mejorase la confianza de forma significativa. El concepto de proporcionalidad existe precisamente para resolver esta tensión: permitir que las medidas de seguridad se escalen en función del riesgo real, sin que esa flexibilidad se convierta en una vía para rebajar la protección.

    La versión de enero de 2026 de la norma ETSI EN 319 401 introduce el marco de proporcionalidad más estructurado en la historia de la regulación europea de servicios de confianza. Su nueva cláusula 4.2 y el mecanismo de etiquetado [PRO] transforman la proporcionalidad de un principio implícito -encajado de forma difusa en el lenguaje de análisis de riesgos de versiones anteriores- en un sistema explícito, documentado y auditable con el que todo prestador de servicios de confianza (TSP) debe interactuar directamente.

    Cómo articula la norma la proporcionalidad

    La norma articula la proporcionalidad a través de varios mecanismos complementarios, algunos nuevos y otros heredados de versiones anteriores del estándar.

    En la capa superior se sitúa la cláusula 4.2, que declara que todos los requisitos de la norma están sujetos a los criterios de proporcionalidad establecidos en dicha cláusula. Esta declaración general significa que ningún requisito existe de forma aislada respecto al contexto específico del TSP.

    El REQ-4.2-01 obliga a los TSP a tener en cuenta factores como el tamaño y alcance de la organización, la naturaleza y grado del riesgo que plantean sus servicios de confianza, el tipo de servicio prestado y la criticidad de esos servicios. Se trata de un requisito con carácter de obligación (shall), no de orientación opcional. Todo TSP debe ponderar estos factores al implementar cualquier requisito de la norma.

    A continuación, la norma introduce la etiqueta [PRO], un marcador formal aplicado a requisitos específicos que son explícitamente susceptibles de implementación proporcionada. El REQ-4.2-02 establece que los requisitos marcados con [PRO] deben implementarse sobre la base de los criterios de proporcionalidad. Entre los requisitos etiquetados se encuentran el PRO-7.1.1-04, sobre roles de seguridad dedicados (que permite, según el tamaño del TSP, que la seguridad de redes y sistemas de información sea cubierta por roles dedicados o por funciones asumidas adicionalmente a roles existentes), y el PRO-7.2-10, sobre diferenciación en descripciones de puestos (que permite, cuando sea apropiado, distinguir entre funciones generales y funciones específicas del TSP). La norma proporciona ejemplos concretos: un micro-TSP puede implementar controles compensatorios como una supervisión reforzada por parte de la dirección cuando la segregación completa de funciones resulta inviable, y un TSP que preste servicios de menor criticidad puede aplicar intervalos menos frecuentes de pruebas de seguridad.

    Por último, la norma mantiene y refuerza la proporcionalidad implícita a través del lenguaje de análisis de riesgos: el enfoque heredado de la v2.3.1. Decenas de requisitos a lo largo de la cláusula 7 utilizan expresiones como «según sea apropiado para los servicios ofrecidos y el puesto» (REQ-7.2-01, sobre personal), «basado en el análisis de riesgos» (REQ-7.8-02, sobre segmentación de red), «dependiendo de la clasificación de los sistemas a los que se accede» (REQ-7.4.1-06, sobre autenticación) o «cuya seguridad sea crítica» (REQ-7.6-01, sobre acceso físico). Estas expresiones vinculan la intensidad de la implementación a los resultados del análisis de riesgos propio del TSP.

    Las salvaguardas: proporcionalidad no es discrecionalidad

    Lo que impide que este sistema se convierta en una vía de escape es un conjunto de cuatro requisitos de gobernanza que conviene conocer bien.

    El REQ-4.2-03 exige a los TSP documentar su análisis de proporcionalidad como parte de la documentación de análisis de riesgos. El REQ-4.2-04 obliga a mantener esa documentación actualizada y disponible para revisión en auditoría. El REQ-4.2-05 establece que los requisitos [PRO] no pueden descartarse sin justificación adecuada, independientemente del tamaño o alcance del TSP. Y, de forma especialmente relevante, el REQ-4.2-06 exige que el efecto acumulativo de los requisitos [PRO] no aplicados no comprometa la postura de seguridad global de los servicios ni socave los objetivos de la norma.

    Esta última salvaguarda -la de efecto acumulativo- es una decisión de diseño particularmente sofisticada. Impide que un TSP adopte múltiples decisiones de proporcionalidad individualmente defendibles que, sumadas, vacíen su seguridad. Dicho de otro modo: se puede justificar razonablemente no aplicar un requisito [PRO] concreto, pero no se pueden acumular excepciones hasta el punto de que el resultado final contradiga el propósito de la norma.

    El análisis de riesgos como motor de la proporcionalidad

    La cláusula 5 de la EN 319 401 v3.2.1 es el motor que alimenta la proporcionalidad en la práctica. El marco de análisis de riesgos determina qué cuenta como «proporcionado» para cada TSP, estableciendo la base fáctica sobre la que se calibran todas las medidas de seguridad.

    El REQ-5-02 contiene la declaración de proporcionalidad más directa de la norma: el plan de tratamiento de riesgos debe asegurar que el nivel de seguridad sea proporcionado al grado de riesgo. Este lenguaje refleja casi literalmente el artículo 19.1 de eIDAS y crea la cadena vinculante entre la legislación y los requisitos operativos. El análisis de riesgos en sí debe seguir un enfoque integral (all-hazards approach) bajo el REQ-5-06, cubriendo amenazas, probabilidad, impacto y nivel de riesgo, y teniendo en cuenta la inteligencia de ciberamenazas y las vulnerabilidades. Los TSP deben identificar el riesgo en relación con terceros y evaluar las posibles disrupciones a la disponibilidad, integridad, autenticidad y confidencialidad en todo el entorno físico.

    La v3.2.1 introduce en este ámbito varios elementos ausentes en las versiones anteriores. El concepto de apetito de riesgo aparece ahora de forma explícita, definido como la cantidad y tipo de riesgo que un TSP está dispuesto a aceptar en la consecución de sus objetivos de negocio. Un proceso obligatorio de gestión de riesgos de ciberseguridad debe integrarse en la gestión de riesgos global del TSP. Los órganos de dirección deben aprobar formalmente el marco de análisis de riesgos, incluido el plan de análisis y las medidas de gestión de riesgos de ciberseguridad (REQ-5-05). Y los análisis de riesgos deben revisarse al menos anualmente y actualizarse cuando se produzcan cambios significativos (REQ-5-04).

    La cadena práctica funciona así: el análisis de riesgos del TSP identifica su panorama de amenazas específico, la criticidad de sus activos y las características de sus servicios. El plan de tratamiento de riesgos selecciona entonces controles cuya intensidad se corresponde con los niveles de riesgo identificados. Para los requisitos etiquetados con [PRO], el TSP documenta si procede la implementación completa o si se justifican alternativas proporcionadas. Toda esta cadena debe estar documentada, mantenida y disponible para el escrutinio del auditor. El resultado es que dos TSP que presten el mismo tipo de servicio pueden legítimamente implementar intensidades de control diferentes, siempre que sus análisis de riesgos reflejen perfiles de riesgo genuinamente distintos y su documentación demuestre un razonamiento sólido.

    La proporcionalidad permea además dominios operativos específicos a lo largo de toda la norma. En seguridad del personal, el REQ-7.2-21 exige una verificación de antecedentes «en proporción a los requisitos de negocio, la clasificación de activos y los sistemas de redes e información a los que se accederá». En gestión de activos, el REQ-7.3.2-02 vincula los niveles de protección a los requisitos de confidencialidad, integridad, autenticidad y disponibilidad, indicando la protección requerida según su sensibilidad, criticidad, riesgo y requisitos de negocio. En continuidad de negocio, el REQ-7.11.2-01 exige copias de respaldo de acuerdo con el análisis de riesgos y el plan de continuidad de negocio. Incluso la retención de registros bajo el REQ-7.10-07 aplica proporcionalidad: los registros se conservan durante un período de tiempo «según sea apropiado».

    La norma ha pasado de asumir que la proporcionalidad se infiere del lenguaje de riesgos a convertirla en un sistema articulado con niveles, etiquetas y salvaguardas. Pero este mecanismo no opera en el vacío: responde a un mandato legislativo concreto del Reglamento eIDAS2, se despliega de forma coordinada a través de toda la familia de normas ETSI 319, y presenta paralelos y diferencias relevantes con los enfoques de proporcionalidad de NIS2, el RGPD y la ISO 27001. Todo eso es lo que abordaremos en la segunda entrega de esta serie.

  • Mayo de 2026 o agosto de 2027: cuándo es realmente obligatoria la certificación contra la ETSI TS 119 461 V2.1.1

    Mayo de 2026 o agosto de 2027: cuándo es realmente obligatoria la certificación contra la ETSI TS 119 461 V2.1.1

    Los servicios de verificación de identidad remota —identity proofing— se han convertido en infraestructura crítica para un espectro amplio de operadores: prestadores cualificados de servicios de confianza que emiten certificados de firma electrónica, entidades financieras sujetas a obligaciones de diligencia debida bajo la normativa de prevención de blanqueo de capitales, y en general cualquier organización que necesite identificar de manera robusta a sus clientes en entornos no presenciales. La certificación de estos servicios contra estándares reconocidos —la norma ETSI TS 119 461, los esquemas nacionales como el PVID francés o la Orden ETD/465/2021 española— proporciona a quienes los contratan la garantía de que el proceso de verificación cumple con los requisitos técnicos y de seguridad exigibles.

    La publicación en febrero de 2025 de la versión 2.1.1 de la ETSI TS 119 461, con requisitos significativamente más exigentes que sus predecesoras —incluida la evaluación de componentes de detección de ataques de inyección conforme a CEN/TS 18099—, ha abierto la pregunta inevitable: cuándo deben los proveedores de identity proofing migrar a esta nueva versión. Y aquí es donde ha surgido la confusión.

    La fecha del 21 de mayo de 2026 circula en el mercado como el deadline para tener completada esa certificación. La presión fluye en cascada: QTSPs que trasladan a sus proveedores de identity proofing la urgencia de recertificarse, calendarios de auditoría que se aceleran, decisiones de inversión que se adelantan. Todo ello sobre una premisa que, analizada con rigor, resulta ser incorrecta.

    De dónde sale la fecha de mayo de 2026

    El artículo 51(4) del Reglamento 2024/1183 —el eIDAS modificado— establece que los QTSPs que ya tenían condición de cualificados antes del 20 de mayo de 2024 deben presentar a su supervisor un informe de conformidad con el artículo 24 antes del 21 de mayo de 2026. Esta disposición transitoria concede dos años para adaptar los procesos de verificación de identidad a los requisitos reforzados del nuevo artículo 24 y acreditarlo ante el regulador.

    Aquí surge el malentendido: se ha asumido que este informe debe basarse en certificaciones contra la nueva ETSI TS 119 461 V2.1.1. No es así. El artículo 51(4) exige demostrar cumplimiento con los requisitos sustantivos del artículo 24, pero no prescribe qué estándar técnico debe utilizarse para ello.

    Y de dónde sale agosto de 2027

    El Reglamento de Ejecución (UE) 2025/1566, publicado el 30 de julio de 2025, designa la ETSI TS 119 461 V2.1.1 como estándar de referencia para la verificación de identidad bajo el artículo 24(1c). Pero su artículo 2 establece que será aplicable a partir del 19 de agosto de 2027.

    La consecuencia es directa: hasta esa fecha, la V2.1.1 no es el estándar de referencia obligatorio. Los operadores pueden seguir apoyándose en certificaciones contra versiones anteriores de la norma ETSI, en esquemas nacionales reconocidos, o en otros medios admitidos bajo el artículo 24(1)(d). Todos estos medios mantienen su validez hasta agosto de 2027.

    No hay contradicción entre las dos fechas. Son obligaciones distintas con calendarios sucesivos: mayo de 2026 marca cuándo los QTSPs deben acreditar conformidad con el artículo 24; agosto de 2027, cuándo un estándar técnico específico deviene obligatorio para demostrarla.

    Qué ocurre con los requisitos de CEN/TS 18099

    La V2.1.1 de la norma ETSI introduce la exigencia de que los componentes de detección de ataques de inyección biométrica (IAD) sean evaluados por laboratorio acreditado conforme a CEN/TS 18099 «antes del final de 2026». Esta fecha ha alimentado la confusión, interpretándose como un deadline regulatorio adicional.

    No lo es. Es un requisito interno de la norma técnica: aplica a quien decida certificarse contra la V2.1.1. Si un proveedor opta por obtener esa certificación antes de agosto de 2027, deberá cumplirlo. Pero la decisión de anticiparse es comercial, no una obligación derivada del Reglamento.

    Por qué se ha extendido la confusión

    Las razones son diversas. Interpretaciones conservadoras de equipos de cumplimiento que prefieren anticiparse a cualquier riesgo. Estrategias de posicionamiento de operadores que ya han invertido en la migración y quieren presentarse como early adopters. Recomendaciones de supervisores nacionales que, sin constituir exigencia formal, generan presión. Y, sobre todo, desconocimiento del contenido exacto del Implementing Regulation 2025/1566 y su fecha de aplicación.

    La respuesta  

    ¿Hay que certificarse contra la ETSI TS 119 461 V2.1.1 antes de mayo de 2026? No. Los QTSPs pueden presentar su informe de conformidad apoyándose en certificaciones vigentes de sus proveedores de identity proofing contra la versión anterior de la norma o contra esquemas nacionales. Exigir la V2.1.1 antes de esa fecha es una decisión de negocio, no una obligación.

    ¿Cuándo será obligatoria la V2.1.1? El 19 de agosto de 2027, fecha de aplicación del Implementing Regulation 2025/1566.

    ¿Qué deben hacer los proveedores de identity proofing? Sus certificados vigentes mantienen validez hasta su caducidad. La presión para anticipar la recertificación responde a dinámicas comerciales, no a imperativos normativos. Planificar la migración con tiempo es prudente; confundir prudencia con urgencia artificial, un error.


    CerteIDAS es un Organismo de Evaluación de la Conformidad acreditado por ENAC para la evaluación de Prestadores Cualificados de Servicios de Confianza conforme al Reglamento eIDAS. Para consultas sobre certificación y planificación de auditorías, contacte con nuestro equipo técnico.