CRA para startups: cumplimiento lean con un ingeniero

Estás lanzando un producto conectado con un equipo pequeño, y el CRA lo va a cubrir. Sus obligaciones principales se aplican desde el 11 de diciembre de 2027, con la notificación de vulnerabilidades desde el 11 de septiembre de 2026, así que es un problema que hay que resolver ya, no dentro de unos años. Dos cosas atrapan a las startups: la obligación de soporte de seguridad plurianual que asumes en el momento en que introduces el producto en el mercado de la UE, y tener que hacerlo todo sin una persona dedicada a la seguridad.

Esta guía es para fundadores e ingenieros de las primeras etapas que necesitan cumplir el CRA sin gastar de más ni construir de más. Cubre qué puedes saltarte con seguridad, qué no, y cómo una sola persona puede responsabilizarse de todo.

¿Se aplica el CRA a tu startup?

Haz cuatro comprobaciones rápidas. El CRA cubre productos con elementos digitales que se conectan a una red o a otro dispositivo y se ponen a disposición en el mercado de la UE en el marco de una actividad comercial.

Si tu producto está dentro del ámbito, la siguiente pregunta es en qué categoría cae. Eso decide si te autoevalúas o necesitas un organismo notificado. Confírmalo con la guía de clasificación de productos antes de dedicar ni un día a cualquier otra cosa.

Tu única ventaja estructural: la autoevaluación

El mayor ahorro de costes para una startup es que un producto fuera de las categorías Importante y Crítica es un producto por defecto. Para esos, el CRA te permite autoevaluarte: haces tú mismo el trabajo de conformidad, firmas la declaración UE de conformidad y aplicas el marcado CE. Sin organismo externo, sin cuota por producto. Los detalles de cada vía están en la guía de evaluación de la conformidad. El punto clave para una startup es no pagar por una evaluación de terceros que no necesitas.

Las medidas de apoyo que el CRA reserva para las startups

El CRA incluye medidas de apoyo escritas específicamente para microempresas, pequeñas y medianas empresas y startups. Que te apliquen o no depende de tu tamaño, según la definición estándar de la UE: una microempresa tiene menos de 10 empleados y una facturación o balance igual o inferior a 2 millones de euros, y una pequeña empresa tiene menos de 50 empleados y una facturación o balance igual o inferior a 10 millones de euros.

Cuatro medidas de apoyo que una startup puede usar de verdad:

• Documentación simplificada: las microempresas y pequeñas empresas pueden presentar la documentación técnica en un formato simplificado que especifica la Comisión, y los organismos notificados deben aceptar ese formato.
• Cuotas de conformidad reducidas: cuando tu producto sí necesita un organismo notificado, deben tenerse en cuenta las necesidades específicas de las pymes, incluidas las startups, y las cuotas deben reducirse de forma proporcional.
• Sandboxes regulatorios: los Estados miembros pueden crear entornos controlados donde desarrollar y probar un producto innovador frente al CRA antes de introducirlo en el mercado, con acceso facilitado para las startups.
• Apoyo directo: cuando proceda, los Estados miembros organizan actividades de sensibilización y formación y un canal de asesoramiento dedicado para las empresas más pequeñas, y la Comisión señala la financiación disponible.

Cumplir con un solo ingeniero

No necesitas un equipo de seguridad. Necesitas un responsable único y una lista corta de cosas que funcionen en automático. Esa persona mantiene el expediente técnico, gestiona los informes de vulnerabilidades entrantes y firma la declaración de conformidad. Una sola persona puede ocupar el rol, pero sé honesto: la gestión continua de vulnerabilidades, la entrega de actualizaciones y la documentación son trabajo de ingeniería real. La guía de coste del cumplimiento CRA modela el esfuerzo y el presupuesto para un equipo pequeño, así que puedes planificar la plantilla con criterio.

Hay tres cosas que merece la pena automatizar primero. Cada una es un problema ya resuelto con herramientas gratuitas, y juntas cubren tus obligaciones tempranas más visibles. Son un punto de partida, no el cuadro completo.

• Genera un SBOM en CI: el CRA exige una lista de materiales de software que cubra al menos tus dependencias de primer nivel, y herramientas de código abierto como Syft y Trivy generan una en cada build. Cadena de herramientas completa en la guía de generación de SBOM.
• Monitoriza vulnerabilidades: escanea tus dependencias en cada build y actúa sobre los hallazgos según el riesgo antes de que lleguen a los clientes. Al CRA le importa que analices y corrijas, no qué escáner uses.
• Publica un contacto de seguridad: un archivo security.txt y una dirección de seguridad que funcione dan a los investigadores una vía para notificar. La guía de configuración de security.txt trae una plantilla lista.

Esas tres son victorias tempranas de automatización, no todo el trabajo. El diseño seguro, la evaluación de riesgos, la entrega de actualizaciones y los controles del producto van junto a ellas. Tu documentación técnica crece con el producto en lugar de improvisarse justo antes del lanzamiento, así que mantén notas de arquitectura y seguridad sobre la marcha. El contenido exigido está en la guía de documentación técnica.

Tu proceso de gestión de vulnerabilidades tiene que estar activo antes de que empiecen las obligaciones de notificación, el 11 de septiembre de 2026. Desde esa fecha, una vulnerabilidad explotada activamente o un incidente grave activan un plazo ajustado a través de la plataforma única de notificación de ENISA: una alerta temprana en 24 horas, y después una notificación más completa en 72 horas. El informe final varía según el caso. Para una vulnerabilidad explotada activamente, vence a los 14 días de que exista una medida correctiva o mitigadora disponible. Para un incidente grave, vence al mes de la notificación de las 72 horas. También debes informar a los usuarios afectados. Los detalles están en la guía de notificación de vulnerabilidades.

Puedes lanzar rápido sin recertificar cada versión

Iterar rápido no significa repetir la evaluación de conformidad en cada sprint. Solo revisas la conformidad después de una modificación sustancial, que es un cambio posterior al lanzamiento que afecta al cumplimiento de los requisitos esenciales del producto, o que cambia la finalidad prevista para la que se evaluó. Una actualización de seguridad que solo reduce el riesgo de ciberseguridad sin cambiar la finalidad prevista no es una modificación sustancial, y un cambio menor como añadir un idioma a la interfaz tampoco suele serlo. Una actualización de funcionalidad que amplía la superficie de ataque o cambia lo que hace el producto sí puede serlo. Así que los parches rutinarios y las actualizaciones pequeñas se lanzan sin reevaluación, y reevalúas cuando un cambio altera de verdad lo que es el producto o su perfil de riesgo.

Si construyes sobre código abierto o lo mantienes

Dos hechos sobre el código abierto importan para una startup. Primero, el software libre y de código abierto solo está dentro del ámbito cuando se suministra en el marco de una actividad comercial. El software que sus mantenedores no monetizan generalmente no es una actividad comercial, pero la monetización es más amplia que cobrar por el código, así que valora también la asistencia de pago y acuerdos similares. Contribuir código fuente a un proyecto que no está bajo tu responsabilidad no hace que el CRA se te aplique. Monetizar código abierto, o incluirlo dentro de un producto que vendes, mete a ese producto en el ámbito con normalidad.

Segundo, el CRA crea un rol más ligero llamado administrador de software de código abierto (open-source software steward) para una organización, distinta de un fabricante, que sostiene el desarrollo de software de código abierto destinado a uso comercial. Las obligaciones de un administrador se centran en una política de ciberseguridad documentada y en la cooperación con las autoridades. La notificación de vulnerabilidades se aplica en la medida en que el administrador esté involucrado en el desarrollo del producto, y la notificación de incidentes graves y el aviso a los usuarios se aplican cuando un incidente afecta a los sistemas que el administrador aporta para ese desarrollo. Estas obligaciones son más ligeras que el conjunto completo de obligaciones del fabricante. Si tu startup a la vez administra un proyecto y vende un producto, deja claro qué sombrero llevas puesto en cada actividad, porque las obligaciones son distintas.

La obligación de soporte de cinco años es un problema de modelo de negocio

Esta es la parte del CRA de la que una startup no puede escapar a base de herramientas. El periodo de soporte debe ser de al menos cinco años, y cuando se espera que el producto esté en uso menos de cinco años, el periodo se ajusta a ese uso esperado más corto. Durante ese periodo gestionas las vulnerabilidades según el riesgo, las corriges sin demora y entregas las actualizaciones a los clientes.

Para una empresa en fase temprana, eso es un compromiso real, no una casilla que marcar:

• La obligación sigue al producto: se activa cuando introduces el producto por primera vez en el mercado de la UE, y un pivote posterior no la termina para las unidades ya introducidas.
• Tiene que estar en el precio: si tu margen no cubre el periodo de soporte, el precio está mal calculado. Modela el coste de soporte en la economía unitaria antes del lanzamiento, y espera que baje a medida que el código se estabiliza.
• Planifica para diez años, no cinco: cada actualización de seguridad que publiques debe seguir disponible al menos 10 años tras su lanzamiento, o durante el resto del periodo de soporte, lo que sea más largo.
• Publica la fecha de fin: debes mostrar la fecha de fin del periodo de soporte, al menos el mes y el año, en el momento de la compra. Fíjala con intención, porque los clientes y compradores la van a leer.

Puedes hacer el compromiso más llevadero, pero ten claro qué lo libera de verdad:

• Elige dependencias estables: cada librería que cambia rápido y que incorporas son años de mantenimiento a los que te comprometes. Prefiere componentes aburridos y bien mantenidos.
• Versiona con intención: define generaciones de producto y planifica cómo se traspasa el soporte entre ellas, para no acabar manteniendo un conjunto ilimitado de versiones vivas.
• Las mitigaciones no liberan de la obligación: una transferencia de soporte por escrito a un adquirente, un acuerdo de escrow o abrir el código de los componentes críticos de seguridad pueden mantener las correcciones fluyendo, pero ninguna por sí sola elimina tu obligación.

Si cesas operaciones y ya no puedes cumplir, debes informar a las autoridades de vigilancia del mercado y, en la medida de lo posible, a tus usuarios antes de que el cese sea efectivo. Qué ocurre con la obligación residual una vez que la empresa deja de existir no está resuelto con claridad y depende de la jurisdicción. Planifica ahora la vía de cierre, mientras todavía puedes, y documéntala en el expediente técnico.

Convierte el cumplimiento en ventas y financiación

Para una startup, el trabajo de CRA puede cumplir doble función: abre el acceso al mercado de la UE y te da evidencia para entregar a un comprador enterprise o a un inversor.

Construye el paquete de due diligence una sola vez. Los equipos de compras de la UE pueden pedir, durante la incorporación de proveedores, un SBOM actualizado, una declaración de conformidad firmada y un proceso documentado de divulgación de vulnerabilidades con un plazo de respuesta. Es evidencia sólida, no prueba de cumplimiento completo, porque la preparación real depende de cumplir cada requisito esencial. Pero tenerlo reunido en un solo sitio te ahorra la carrera por recopilar evidencia más tarde, y es el mismo paquete que la diligencia técnica de un inversor puede pedir ver.

A los inversores les importa que puedas vender legalmente. Incumplir los requisitos esenciales o las obligaciones nucleares del fabricante conlleva multas administrativas de hasta 15 millones de euros o el 2,5 % de la facturación anual mundial total, la cifra que sea mayor. En términos más prácticos, un producto introducido en el mercado de la UE desde el 11 de diciembre de 2027 debe cumplir el CRA para poder venderse allí. Enmarcar el cumplimiento como acceso al mercado y entrada a la UE con menos riesgo funciona mejor ante un consejo que enmarcarlo como un coste.

Los programas públicos pueden financiar parte del trabajo. Instrumentos de la UE como Horizon Europe, el Programa Europa Digital y el EIC Accelerator apoyan la ciberseguridad y el desarrollo de productos seguros, y los programas nacionales añaden más. Los importes y los requisitos de elegibilidad varían, así que consulta con tu hub nacional de innovación digital qué está abierto. Enmarca la solicitud en torno a construir productos digitales seguros y de confianza, no en torno a marcar una casilla regulatoria.

Si las certificaciones de seguridad salen en ventas, conoce dónde se sitúa el CRA respecto a ellas. El solapamiento con un SGSI está cubierto en la guía CRA frente a ISO 27001, y los equipos de IoT de consumo deberían leer la guía de EN 303 645.

Errores habituales de las startups

• «Ya nos ocuparemos de seguridad después de la ronda»: con el runway limitado, añadir seguridad a posteriori quema el efectivo que acabas de levantar. Construye lo básico desde el primer sprint.
• «Pusimos precio al producto sin la obligación de soporte»: el mantenimiento de seguridad plurianual tiene que estar dentro de tu economía unitaria. Si no lo está, el precio está mal.
• «Nuestro responsable de cumplimiento se fue y nadie lo asumió»: si una sola persona tiene el expediente técnico y el proceso de notificación, su salida es un vacío de cumplimiento. Escribe quién es el responsable.
• «El adquirente simplemente asumirá la obligación»: un acuerdo puede asignar el trabajo de soporte, pero eso no te libera por sí solo de la obligación legal. Trátalo de forma explícita en los términos, y no des nada por hecho.
• «Añadiremos el CRA cuando nos expandamos a la UE»: si los usuarios de la UE ya pueden acceder a tu producto, ya estás suministrando el mercado de la UE, y añadir el cumplimiento después es una reconstrucción. Diseña desde el principio para las obligaciones de 2027.
• «Estamos demasiado en fase temprana para estar dentro del ámbito»: ser una startup te da derecho a medidas de apoyo, no a una exención. La obligación se activa en la primera introducción en el mercado sea cual sea tu fase.