Qué debería entregar un servicio integral de cumplimiento del CRA

El cumplimiento del Reglamento de Ciberresiliencia de la UE (CRA) no consiste en una única prueba de penetración ni en obtener un certificado aislado. Para un fabricante, es un proceso de generación de evidencias y decisión de comercialización que conecta el alcance del producto, la evaluación de riesgos de ciberseguridad, los controles de ingeniería, la gestión de vulnerabilidades, la documentación técnica, la vía de evaluación de la conformidad aplicable, los controles de marcado CE/declaración UE de conformidad y las obligaciones posteriores a la comercialización.

A 7 de octubre de 2026, el CRA se encuentra en una fase transitoria: las obligaciones de notificación de los fabricantes previstas en el artículo 14 se aplican desde el 11 de septiembre de 2026, mientras que el Reglamento será aplicable con carácter general desde el 11 de diciembre de 2027. Por ello, un proyecto sólido se articula en dos líneas: un proceso operativo de notificación que funcione ya y un programa de preparación para el mercado que cierre las evidencias de producto y de proceso antes de la fecha de aplicación de 2027.

Qué debería entregar un servicio integral de cumplimiento del CRA

El servicio debería convertir los requisitos jurídicos en resultados de proyecto controlados. El entregable principal no es una opinión genérica, sino un expediente trazable que muestre qué producto y versión se evaluaron, qué riesgos y requisitos son aplicables, cómo se implementó o justificó cada requisito, qué ensayos respaldan la conclusión, qué vía de conformidad se utilizó y qué controles deben continuar después de la comercialización.

El fabricante sigue siendo responsable del producto y de la declaración UE de conformidad. Asesores externos, laboratorios y organismos de evaluación de la conformidad pueden aportar análisis o evidencias, pero las responsabilidades y los puntos de decisión deben asignarse dentro del propio proceso interno de aprobación del producto del fabricante.

Control inicial: fijar producto, operador, alcance y vía

Antes de encargar ensayos, hay que fijar el objeto regulatorio. Deben registrarse el fabricante, la familia de productos y las variantes exactas, las versiones de software y firmware, las dependencias de tratamiento remoto de datos, la finalidad prevista, el uso razonablemente previsible, los mercados, el modelo de distribución, los componentes de terceros y la entidad que controla las actualizaciones y la gestión de vulnerabilidades.

Después debe determinarse si el producto está dentro del ámbito del CRA y si se trata de otro producto, de un producto importante de clase I, de un producto importante de clase II o de un producto potencialmente crítico. Esta clasificación importa porque modifica la vía de evaluación de la conformidad permitida. Si el alcance o la clasificación son inciertos, deben tratarse como una decisión abierta, con evidencia y responsable asignado, y no ocultarse dentro de una orden de ensayo.

Flujo operativo desde el análisis inicial hasta la preparación para el mercado

Ensayos y evidencias: demostrar la evaluación de riesgos, no buscar una «prueba CRA» universal

El CRA no reduce el cumplimiento a una batería universal de ensayos. Los ensayos deberían derivarse de la evaluación de riesgos de ciberseguridad del producto y de los requisitos aplicables del anexo I. Según el producto, el plan de evidencias puede combinar revisión de arquitectura, revisión de configuración segura, pruebas de interfaces y autenticación, análisis de vulnerabilidades, análisis de dependencias/SBOM, pruebas de penetración, pruebas del mecanismo de actualización, casos de uso indebido o abuso y verificación de los procesos de gestión de vulnerabilidades.

Para cada ensayo deben registrarse la versión probada, configuración, entorno, método, criterio de aceptación, resultado, corrección y estado de repetición. Si se utiliza un laboratorio externo, debe conservarse el alcance del encargo y del ensayo para vincular el informe con el candidato exacto a comercialización. Un «aprobado» sobre una compilación no identificada u obsoleta constituye una evidencia débil de conformidad.

Documentación técnica y expediente de comercialización

El expediente técnico debería construirse mientras se generan las evidencias de ingeniería, no reconstruirse al final. Un expediente práctico de comercialización suele incluir:

• identificación del producto, arquitectura y línea base de versión/configuración;
• evaluación de riesgos de ciberseguridad, incluido el uso previsto y razonablemente previsible;
• correspondencia de los requisitos aplicables del anexo I con controles implementados y evidencias;
• información de diseño y desarrollo y evidencias pertinentes de componentes/dependencias;
• informes de ensayo, correcciones y registros de repetición;
• procesos de gestión de vulnerabilidades y divulgación coordinada, mecanismo de actualización y disposiciones de soporte de seguridad;
• justificación del período de soporte e información/instrucciones exigidas al usuario;
• registros de conformidad específicos de la vía, declaración UE de conformidad y evidencias relativas a la colocación del marcado CE cuando proceda.

Con arreglo al CRA, la documentación técnica debe prepararse antes de la introducción en el mercado y actualizarse, cuando proceda, durante el período de soporte. Los fabricantes deben mantener disponibles la documentación técnica y la declaración UE de conformidad durante al menos diez años desde la introducción en el mercado o durante el período de soporte, si este es más largo.

Vía de evaluación de la conformidad y entregas a terceros

La coordinación con proveedores debería tratarse como una entrega controlada. Antes de remitir un expediente a un organismo notificado u otro proveedor de evaluación, hay que confirmar que está autorizado para el alcance requerido, acordar el idioma y el paquete de presentación, fijar la versión evaluada y abrir un registro de consultas. En 2026, la infraestructura de evaluación de la conformidad y las normas CRA siguen desplegándose, por lo que el estado del proveedor y las normas aplicables deberían verificarse en tiempo real y no inferirse de material comercial antiguo.

Control de comercialización, notificación y gestión de cambios

La preparación para el mercado es una decisión de comercialización, no solo la finalización de los ensayos. El control debería confirmar que el producto aprobado para comercialización coincide con la línea base evaluada, que la documentación de conformidad exigida está aprobada, que la información al usuario y de soporte de seguridad está lista, que se ha determinado el período de soporte y que los responsables posteriores a la comercialización tienen acceso a los sistemas de recepción de notificaciones de vulnerabilidades, actualización y notificación.

Desde el 11 de septiembre de 2026, los fabricantes ya deben notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto a través de la Plataforma Única de Notificación (SRP) del CRA. La Comisión describe un aviso temprano en 24 horas y una notificación completa en 72 horas; el informe final correspondiente sigue los plazos del CRA para el tipo de evento. Este flujo debería ensayarse antes de que ocurra un incidente, definiendo quién puede presentar, quién aprueba los hechos y cómo se conservan las evidencias de ingeniería.

Después de la comercialización, los cambios en código, hardware, dependencias, criptografía, interfaces, procesamiento remoto, finalidad prevista, disposiciones de soporte o procesos de gestión de vulnerabilidades deberían someterse a una revisión documentada de impacto. La pregunta no es solo si cambió una función, sino si deben actualizarse la evaluación de riesgos, las evidencias, la información al usuario o la conclusión de conformidad.

Cuellos de botella habituales que retrasan la preparación para el CRA

• la clasificación sigue abierta cuando empiezan los ensayos y se presupuesta una vía de evaluación equivocada;
• las variantes del producto y las dependencias de nube o procesamiento remoto no están bajo control de configuración;
• la evaluación de riesgos, el inventario SBOM/dependencias y el alcance de ensayo describen versiones diferentes;
• faltan evidencias del proveedor para componentes críticos de seguridad o dependencias de actualización;
• los hallazgos se corrigen en el código, pero no se conserva la evidencia de corrección y repetición del ensayo;
• el período de soporte, la recepción de notificaciones de vulnerabilidades y la responsabilidad de notificación se deciden solo en el lanzamiento;
• se contrata una evaluación de terceros antes de que el expediente técnico sea internamente coherente.

Qué no sustituye esta página

Si la cuestión principal es cómo elegir asesor, estructurar la gobernanza u obtener un análisis estratégico de brechas, consulte la página sobre consultoría CRA. Si la cuestión principal es el presupuesto y los factores de coste, consulte la página sobre costes del CRA. Para la mecánica de comercialización CE en varios regímenes más allá del CRA, consulte los servicios de marcado CE. Esta página se centra en la cadena de ejecución y las entregas necesarias para convertir los requisitos del CRA en un expediente de evidencias listo para la comercialización.