Estado a 11 de agosto de 2026. El Reglamento (UE) 2024/2847 (Ley de Resiliencia Cibernética de la UE) establece requisitos de ciberseguridad para productos con elementos digitales comercializados en la Unión. La guía práctica de la Comisión se publicó el 27 de julio de 2026. Las obligaciones relacionadas con la notificación entran en vigor el 11 de septiembre de 2026; el conjunto principal de obligaciones de producto, el 11 de diciembre de 2027. Esta guía está dirigida a ingenieros de software de productos que podrían estar en el ámbito de aplicación, no a abogados de evaluación de conformidad.
Honestidad sobre el ámbito: la CRA no sustituye a SOC 2, ISO 27001 o el GDPR. No es "otra casilla de verificación de un bot de cumplimiento". Muchas obligaciones de la CRA son procesos de fabricantes, documentación y poscomercialización. Solo una parte puede erosionarse en una pull request normal de aplicación: actualización del inventario de dependencias y SBOM, rutas de divulgación de vulnerabilidades y controles de seguridad eliminados como código muerto. Si tu equipo legal o de producto no ha confirmado que la CRA aplica a lo que envías, detente aquí y pregúntales.
Qué entra en vigor y cuándo (calendario para desarrolladores)
A partir del 11 de septiembre de 2026, entran en vigor las obligaciones de notificación asociadas al régimen de notificación de vulnerabilidades e incidentes del Reglamento, según el cronograma establecido por el Reglamento y la guía de la Comisión para los fabricantes. A partir del 11 de diciembre de 2027, los requisitos principales de ciberseguridad de productos (incluyendo las expectativas de diseño seguro, procesos de gestión de vulnerabilidades y transparencia relacionada con SBOM para productos con elementos digitales) se aplican de manera más amplia. La clasificación exacta de tu producto (por defecto, importante, crítico) es una cuestión legal y de producto, no algo que decida una revisión de código.
Trata esas fechas como puntos de referencia para la planificación. Si las correcciones del Diario Oficial o guías adicionales las modifican, valida de nuevo esta página (consulta el registro de actualización de fechas).
Qué puede aparecer realmente en una pull request
Actualización de dependencias y SBOM: un cambio fija un componente obsoleto, elimina la generación del SBOM del CI o deja de publicar el inventario de componentes en el que se basa tu proceso de vulnerabilidades. Ruta de gestión de vulnerabilidades: un cambio elimina o codifica de forma fija un contacto de seguridad, un feed de avisos o un webhook de triaje de vulnerabilidades que tu proceso alineado con la CRA asume que existe. Erosión del diseño seguro: una PR de "limpieza" elimina la autenticación en un puerto de administración, desactiva las comprobaciones de actualización o deshabilita la verificación de integridad en los paquetes de actualización porque generaban ruido.
Esas son formas de ingeniería. No constituyen un expediente completo de conformidad con la CRA, una historia de marcado CE o una evaluación de organismo notificado.
Ejemplo práctico: el CI deja de emitir el inventario de componentes
Un equipo de plataforma acorta el CI en dos minutos eliminando un trabajo que ejecutaba syft (o equivalente) y subía un artefacto SBOM en cada etiqueta de versión. El Dockerfile y la aplicación siguen compilando. Las pruebas siguen en verde. Los comentarios de revisión tratan sobre el coste del pipeline. Semanas después, el equipo de seguridad no puede responder "qué versiones se enviaron en la 1.8.3" sin reconstruir a partir de las capas.
Si tu producto está en el ámbito de la CRA y tu proceso depende de ese inventario para la gestión de vulnerabilidades y la transparencia, la eliminación del trabajo no es una higiene neutral. Una revisión consciente del cumplimiento marca la pérdida del paso de inventario en la PR, para que el equipo de producto y seguridad pueda aceptar el riesgo formalmente o restaurar el trabajo. Que heygrc cite un control de marco aquí es una señal, no una determinación de que el producto sea no conforme.
Objetivos explícitamente no cubiertos
Esta guía no aborda módulos de evaluación de conformidad, marcado CE, registro de fabricantes, redacción de declaraciones de conformidad de la UE ni si tu producto es "importante" o "crítico" según el Reglamento. No afirma que heygrc haga que un producto cumpla con la CRA. No sustituye a tu PSIRT, revisión legal ni plan de respuesta de vigilancia de mercado.
Si solo necesitabas SOC 2 o ISO 27001 para clientes, la CRA puede seguir siendo irrelevante. No la fuerces a encajar.
Dónde encaja heygrc y el límite de la honestidad
heygrc está diseñado para mostrar cambios en pull requests relevantes para controles, en función de los marcos que actives. Para la higiene de ingeniería relacionada con la CRA, la superposición útil es la misma clase de hallazgos que el desarrollo seguro y la gestión de vulnerabilidades en otros marcos (por ejemplo, requisitos de software del NIS 2 Art. 21, controles de desarrollo seguro de ISO 27001): comprobaciones de integridad de actualización eliminadas, autenticación debilitada, trabajos de inventario suprimidos. Mapea con cuidado; no inventes números de artículo de la CRA en los hallazgos a menos que tu base de conocimientos activada los incluya.
Conserva SAST, escáneres de dependencias y tu revisor de código. La ley de productos CRA está mayormente fuera del diff. El diff solo detecta la parte que elimina silenciosamente lo que esos programas asumen que sigue funcionando.