La Ley de Ciberresiliencia de la UE (CRA) lo cambia todo, y es probable que su enfoque actual no sea suficiente.
¿Recuerdas cuando «admin/admin» era una contraseña predeterminada aceptable?
Esos días han terminado oficialmente.
La Ley de Ciberresiliencia de la UE (CRA) entró en vigor en diciembre de 2024. Si envía IoT a Europa, esto no es opcional, es la ley.
Y esto es lo que la mayoría de los equipos están pasando por alto: es probable que sus tokens OAuth2, JWT y claves API no cumplan con los requisitos de conformidad.
El problema del que nadie habla
La CRA no solo prohíbe las contraseñas débiles. Prohíbe cualquier credencial compartida o codificada en toda su flota de dispositivos.
¿Ese secreto de cliente integrado en tu firmware? No cumple con los requisitos.
¿Esa clave API proporcionada a todos los dispositivos? No cumple con los requisitos.
¿Esa clave de firma JWT compartida en toda su línea de productos? No cumple con los requisitos.
La normativa exige que cada dispositivo tenga su propia identidad única y criptográficamente segura. Además, los propietarios deben poder revocar las credenciales si un dispositivo se ve comprometido.
Las infracciones conllevan sanciones de hasta 15 millones de euros o el 2,5 % de los ingresos globales.
El problema de las credenciales de Bootstrap
Esto es lo que los defensores de OAuth2 y JWT suelen pasar por alto: para obtener el token, primero se necesita una credencial codificada.
Piénsalo:
Flujo de credenciales de cliente OAuth2 requiere que su dispositivo almacene un client_id y client_secret para solicitar un token de acceso. Se trata de valores estáticos grabados en el firmware, precisamente lo que prohíbe la CRA.
La autenticación JWT requiere que el dispositivo posea una clave de firma privada para generar tokens. Esa clave debe proporcionarse de alguna manera. Si es la misma clave para toda su flota, ha infringido los requisitos de dispositivos únicos. Si está proporcionando claves únicas por dispositivo, enhorabuena: de todos modos, está creando una infraestructura PKI.
Las claves API y los PAT son cadenas estáticas integradas en el dispositivo por definición.
¿La incómoda verdad? Estos métodos solo sustituyen un secreto codificado (una contraseña) por otro secreto codificado (un secreto de cliente, una clave de firma o un token). No has resuelto el problema del cumplimiento de la CRA, solo lo has reempaquetado.
Por qué mTLS es fundamentalmente diferente
TLS mutuo TLS certificados X.509 resuelve por completo el problema del arranque.
Aquí está la idea clave: la clave privada se puede generar en el propio dispositivo y nunca es necesario que exista en ningún otro lugar.
Durante la fabricación, el dispositivo genera su propio par de claves internamente, idealmente dentro de un módulo hardware donde la clave privada es literalmente imposible de extraer. El dispositivo solo envía una solicitud de firma de certificado (que contiene la clave pública) a su CA. El certificado firmado le es devuelto. Listo.
Sin secretos compartidos. Sin credenciales que codificar. Sin transmisión de material confidencial durante el aprovisionamiento.
Compáralo con OAuth2, donde tu secreto de cliente debe crearse en el lado del servidor y luego transferirse de forma segura a todos los dispositivos de tu flota.
Lo que ofrece mTLS:
✅ Cada dispositivo obtiene un certificado único con su propio par de claves.
✅ Las claves privadas nunca salen del dispositivo, jamás.
✅ Sin secretos codificados en el firmware.
✅ Revocación de dispositivos individuales mediante listas de revocación de certificados.
✅ Autenticación mutua: el dispositivo verifica el servidor y el servidor verifica el dispositivo.
AWS IoT , Azure IoT y Google Cloud IoT recomiendan la autenticación mediante certificados X.509 precisamente por estas razones.
Qué significa esto para tu hoja de ruta
Para diciembre de 2027, sus dispositivos deben cumplir con la normativa. Parece lejano, pero considere lo siguiente:
-
Los ciclos Hardware duran entre 18 y 24 meses.
-
La infraestructura PKI requiere tiempo para diseñarse.
-
La fabricación necesita la integración del aprovisionamiento de certificados.
-
Tu backend necesita compatibilidad con mTLS.
Los equipos que empiecen ahora tendrán una ventaja competitiva. Los equipos que esperen tendrán que apresurarse a adaptar la seguridad a productos que nunca se diseñaron para ello.
Lo esencial
La CRA no le pide que elija una credencial codificada mejor. Le pide que elimine por completo las credenciales codificadas.
OAuth2 y JWT no fueron diseñados para este mundo. Resuelven los problemas de autenticación de usuarios de manera brillante. Pero en lo que respecta a la identidad de los dispositivos según los requisitos de la CRA, solo trasladan el incumplimiento normativo de un lugar a otro.
mTLS con certificados X.509 tiene una arquitectura diferente. Es el único enfoque en el que nunca es necesario compartir, transmitir ni codificar de forma fija las credenciales confidenciales.
Las empresas que comprendan esta distinción ahora fabricarán productos que cumplan con la normativa. Las que no lo hagan tendrán que adaptarse o salir del mercado de la UE.
No importa en qué punto del camino hacia la seguridad se encuentre, nuestros expertos están aquí para ayudarte. Reserve una demostración y cuéntenos más sobre su organización y sus objetivos.
