Cyber Resilience Act: requisitos para empresas de software que venden en Europa

Qué es el Cyber Resilience Act y por qué importa a las empresas de software

El Cyber Resilience Act (CRA) es el reglamento europeo que establece requisitos obligatorios de ciberseguridad para productos con elementos digitales que se comercializan en la Unión Europea. Su alcance incluye hardware y software, y su lógica es especialmente relevante para empresas tecnológicas: la seguridad deja de evaluarse únicamente como una característica del producto o una buena práctica de ingeniería y pasa a formar parte de las condiciones para colocarlo y mantenerlo en el mercado europeo.

Para una empresa latinoamericana, el punto importante no es dónde está constituida ni dónde trabaja su equipo de desarrollo. La primera pregunta es otra: ¿está comercializando en la Unión Europea un producto que entra dentro del alcance del CRA?

Esa distinción es importante porque evita dos errores frecuentes. El primero es asumir que cualquier empresa SaaS queda automáticamente alcanzada. El segundo es creer que una compañía ubicada fuera de Europa puede ignorar el reglamento. El análisis correcto depende del tipo de producto, de cómo se ofrece al mercado y del rol que ocupa la organización dentro de la cadena de valor.

La regulación entró en vigor en 2024, pero su aplicación es progresiva. Las obligaciones de reporte comienzan el 11 de septiembre de 2026 y la aplicación general del CRA llega el 11 de diciembre de 2027. Para las empresas alcanzadas, esto convierte 2026 en un año de preparación operativa, no solamente jurídica.

Qué empresas y productos pueden quedar alcanzados por el CRA

El CRA se aplica a productos con elementos digitales que se ponen a disposición en el mercado de la Unión Europea. La regulación utiliza una lógica de producto: busca que el hardware y el software cubiertos incorporen requisitos de ciberseguridad desde el diseño y mantengan esas condiciones durante su ciclo de vida.

En la práctica, una empresa de software debería empezar por construir un inventario de lo que efectivamente comercializa en Europa. No alcanza con mirar la razón social o la categoría general de la compañía. Hay que entender qué producto se entrega, cómo funciona, qué componentes incluye, qué servicios remotos son necesarios para su funcionamiento y qué responsabilidades conserva el fabricante después de la venta o distribución.

¿El Cyber Resilience Act aplica a SaaS?

No conviene responder esta pregunta con un sí o un no general. El CRA es una regulación de productos y, en términos generales, un servicio SaaS independiente no queda alcanzado simplemente por ser software utilizado desde Europa. Sin embargo, determinadas capacidades de procesamiento remoto pueden formar parte de un producto con elementos digitales cuando son necesarias para que ese producto cumpla su función.

Para una empresa SaaS o de producto digital, la decisión correcta es analizar la arquitectura y el modelo de comercialización, no la etiqueta comercial que utiliza la empresa. Un mismo negocio puede ofrecer servicios que queden fuera del alcance y, al mismo tiempo, comercializar otros componentes de software que requieran un análisis diferente.

Cuándo empieza a aplicar el Cyber Resilience Act

El calendario del CRA tiene dos fechas que conviene separar.

La primera es el 11 de septiembre de 2026. Desde ese momento comienzan a aplicar las obligaciones de reporte previstas para fabricantes alcanzados por el reglamento, particularmente en relación con vulnerabilidades explotadas activamente y determinados incidentes graves que afectan la seguridad de productos con elementos digitales.

La segunda es el 11 de diciembre de 2027, cuando comienza la aplicación general de las obligaciones del CRA.

Esta diferencia importa porque una empresa puede no estar todavía ante la totalidad de los requisitos de conformidad y, sin embargo, necesitar desde 2026 una capacidad real para detectar, analizar, escalar y reportar problemas de seguridad.

Prepararse únicamente leyendo la regulación unas semanas antes de cada fecha suele ser insuficiente. La dificultad no está en redactar un procedimiento, sino en lograr que producto, ingeniería, seguridad, legal y management puedan operar ese procedimiento cuando aparece una vulnerabilidad real.

Qué cambia el 11 de septiembre de 2026

Las obligaciones de reporte son una de las primeras partes del CRA que entran en aplicación. Para los fabricantes alcanzados, esto implica reportar vulnerabilidades explotadas activamente y determinados incidentes graves de seguridad dentro de plazos definidos por la regulación.

La Comisión Europea establece un esquema escalonado que comienza con una alerta temprana dentro de las primeras 24 horas desde que el fabricante toma conocimiento, seguida de información adicional dentro de las 72 horas y reportes posteriores según el tipo de evento.

El desafío operativo aparece antes del reporte. Una organización necesita saber cuándo una señal constituye una vulnerabilidad relevante, qué producto y versión afecta, si existe explotación activa, qué área debe intervenir, quién tiene autoridad para decidir y qué información puede respaldar cada conclusión.

Una empresa que gestiona vulnerabilidades mediante conversaciones dispersas, tickets sin criterios homogéneos y conocimiento concentrado en pocas personas puede tener buenas capacidades técnicas y, aun así, no estar preparada para una obligación regulatoria con plazos exigentes.

Principales requisitos del Cyber Resilience Act para software

El CRA introduce una visión de ciberseguridad durante todo el ciclo de vida del producto. Esto obliga a mirar de manera integrada actividades que muchas empresas ya realizan, pero que suelen estar separadas entre ingeniería, infraestructura, seguridad, soporte y compliance.

Seguridad desde el diseño y por defecto

La seguridad no debería agregarse al final del desarrollo. La empresa necesita incorporar decisiones de riesgo desde el diseño del producto, limitar superficies de ataque, utilizar configuraciones seguras y gestionar accesos, secretos, dependencias y cambios de manera consistente.

Esto no significa que todos los productos deban utilizar las mismas prácticas. Significa que la organización debe poder justificar qué riesgos identificó, qué decisiones tomó y qué mecanismos utiliza para mantener esas decisiones a medida que el producto evoluciona.

Gestión continua de vulnerabilidades

Encontrar vulnerabilidades es solamente una parte del problema. Una capacidad madura permite relacionar cada hallazgo con productos, versiones, componentes, criticidad, responsables y acciones de remediación.

Cuando aparece una vulnerabilidad crítica, la empresa debería poder responder rápidamente dónde está presente, qué exposición genera, quién la está analizando, qué tratamiento se decidió y cuándo quedó resuelta. Esa trazabilidad es relevante para el CRA, pero también para clientes enterprise, procesos de due diligence y security reviews.

Actualizaciones y soporte de seguridad

El ciclo de vida del producto no termina con el lanzamiento. Las empresas alcanzadas necesitan pensar cómo mantienen la seguridad, cómo distribuyen correcciones, durante cuánto tiempo soportan sus productos y cómo comunican información relevante a los usuarios.

Esta exigencia obliga a conectar decisiones comerciales y técnicas. Prometer años de soporte tiene impacto sobre ingeniería, mantenimiento de dependencias, capacidad de respuesta y costos futuros.

Software supply chain y componentes

La seguridad de un producto también depende de componentes que la empresa no desarrolló. Librerías, frameworks, paquetes y otras dependencias pueden introducir vulnerabilidades que afectan múltiples productos o versiones al mismo tiempo.

Por eso, mantener visibilidad sobre los componentes utilizados y poder relacionarlos con los productos que los incorporan se vuelve una capacidad importante. El valor de un inventario o de un SBOM no está en generar un archivo adicional, sino en reducir el tiempo necesario para responder una pregunta crítica: ¿dónde estamos expuestos cuando aparece una vulnerabilidad en un componente?

Evidencia y documentación técnica

Un sistema de seguridad que depende exclusivamente del conocimiento informal es difícil de sostener y aún más difícil de demostrar. El CRA aumenta la importancia de documentar evaluaciones, decisiones, pruebas, vulnerabilidades, correcciones y responsabilidades.

La documentación útil no consiste en producir papeles para una revisión futura. Debería ser el resultado de procesos que funcionan durante la operación normal de la empresa.

Qué evidencia debería empezar a ordenar una empresa

Una compañía que quiere prepararse para el CRA no necesita empezar creando una estructura de compliance paralela. Suele ser más efectivo identificar la información que ya existe, detectar los puntos donde se pierde trazabilidad y conectar las actividades existentes.

Una base razonable incluye inventario de productos y versiones, responsables, componentes y dependencias relevantes, evaluaciones de riesgo, pruebas de seguridad, vulnerabilidades, decisiones de remediación, incidentes, proveedores críticos, políticas de actualización, registros de cambios y evidencia de seguimiento.

La pregunta de control es simple: si mañana aparece una vulnerabilidad grave, ¿podemos reconstruir qué pasó desde la detección hasta la resolución?

Si la respuesta requiere buscar mensajes antiguos, preguntarle a varias personas o reconstruir decisiones de memoria, el problema no es solamente documental. Falta un sistema de gestión que permita demostrar cómo opera la organización.

ISO 27001 ayuda, pero no equivale a cumplir el CRA

ISO 27001 puede aportar una base valiosa porque organiza capacidades de gestión de riesgos, responsabilidades, incidentes, proveedores, accesos, controles y mejora continua. Para empresas que ya trabajan con un sistema de gestión de seguridad de la información, parte de la disciplina organizativa necesaria para responder nuevas exigencias puede estar construida.

Sin embargo, tener ISO 27001 no implica cumplir automáticamente el Cyber Resilience Act.

ISO 27001 y el CRA tienen naturalezas, alcances y requisitos diferentes. La certificación puede ayudar a demostrar madurez en determinadas prácticas y reducir trabajo duplicado, pero una empresa debe analizar por separado las obligaciones específicas que correspondan a sus productos.

La ventaja real de un sistema de gestión maduro aparece cuando una nueva regulación no obliga a comenzar de cero. Los riesgos, responsables, controles y evidencias ya tienen una estructura sobre la cual trabajar.

Cómo prepararse para el Cyber Resilience Act durante 2026

Prepararse bien no significa intentar resolver todo el reglamento en un único proyecto. Conviene avanzar por capacidades.

El primer paso es determinar qué productos comercializados en Europa requieren análisis. Después, definir propietarios claros para cada producto y para los procesos de vulnerabilidades e incidentes. A partir de ahí, la empresa puede revisar cómo recibe hallazgos, cómo los clasifica, cómo determina exposición, cómo escala decisiones y cómo documenta la resolución.

También conviene probar el proceso antes de necesitarlo. Una simulación con una vulnerabilidad real o histórica puede revelar rápidamente si el inventario es suficiente, si las responsabilidades están claras y si los equipos pueden reunir la información necesaria dentro de los tiempos esperados.

Finalmente, la empresa debería evitar tratar el CRA como un proyecto aislado del resto de sus exigencias de confianza. Muchas de las mismas capacidades serán utilizadas para responder cuestionarios de seguridad, auditorías, evaluaciones de clientes, licitaciones o marcos como ISO 27001 y SOC 2.

Cómo ayuda Certenza a prepararse para el Cyber Resilience Act

Certenza no reemplaza el análisis jurídico del alcance del CRA ni las decisiones técnicas que deben tomar los equipos de producto y ciberseguridad. Su función es otra: ayudar a que riesgos, controles, responsables y evidencia puedan gestionarse de manera trazable y continua.

Para una empresa que vende software en Europa, esto permite evitar uno de los problemas más frecuentes del compliance tecnológico: tener políticas por un lado, hallazgos técnicos por otro, responsables en planillas y evidencia distribuida entre múltiples herramientas.

Con Certenza, la organización puede centralizar riesgos, controles, políticas, responsables y evidencia; automatizar parte de la recolección y el seguimiento; y mantener una historia verificable de cómo se gestionan las obligaciones de seguridad. Esa capa de trazabilidad es útil cuando una regulación, un auditor o un cliente enterprise necesita entender no solamente qué dice una política, sino qué ocurrió en la práctica.

El objetivo no es convertir el CRA en más documentación. Es construir una relación clara entre producto, riesgo, vulnerabilidad, responsable, acción, evidencia y revisión.

Esa misma estructura puede reutilizarse para otras exigencias de confianza. Cuando la organización ya puede demostrar cómo gestiona seguridad de manera continua, responder una nueva regulación o un security review deja de implicar reconstruir el funcionamiento de la empresa desde cero.

De obligación regulatoria a capacidad comercial

El Cyber Resilience Act es una regulación europea, pero su impacto para una empresa de software puede aparecer antes en una conversación comercial que en una inspección. Clientes, distribuidores, compradores corporativos y procesos de due diligence pueden empezar a trasladar expectativas de seguridad de producto a contratos y evaluaciones de proveedores antes de 2027.

Por eso, prepararse no debería verse únicamente como un costo de cumplimiento. Una empresa que conoce sus productos, gestiona vulnerabilidades con criterios consistentes y puede demostrar qué decisiones tomó reduce fricción cuando un tercero pregunta cómo protege el software que vende.

El resultado más valioso no es tener una carpeta llamada “CRA”. Es contar con una operación de seguridad que pueda sostener nuevas exigencias sin perder velocidad comercial.