Licencias de conducir móviles en 2026: Estado actual y proceso de verificación

Una mDL es una credencial de conducir emitida por el gobierno y almacenada en un teléfono en un formato de datos estandarizado y firmado.

Durante la verificación de la licencia de conducir, el dispositivo del titular comparte atributos específicos a través de una sesión con un lector. El lector valida lo que recibió y luego produce un resultado en el que un operador o un sistema backend puede confiar.

Por lo general, hay cuatro roles distintos que destacar en las implementaciones de mDL:

1. Emisor: La autoridad que crea la credencial y firma los datos (en EE. UU., normalmente un Departamento de Vehículos Motorizados estatal).

2. Titular: La persona cuya credencial reside en una aplicación del emisor o en la billetera de un dispositivo.

3. Verificador (parte confiante): La organización que solicita datos y toma una decisión.

4. Lector: El software y el hardware del verificador que ejecutan el protocolo y la lógica de validación.

Nota: En la práctica, un “lector” rara vez es una sola pantalla. Normalmente incluye un almacén de confianza (certificados del emisor y anclas de confianza), configuraciones predefinidas de solicitud que controlan qué se solicita, y un manejo de resultados que controla qué se muestra y qué se almacena.

Una licencia de conducir móvil puede contener un conjunto amplio de elementos de identidad y de credencial, pero el lector solo recibe los elementos específicos que solicita y que el titular aprueba, además del material criptográfico necesario para validarlos.

Los atributos típicos compartidos incluyen (pero no se limitan a):

• Atributos de identidad: Nombre (nombre y apellido), fecha de nacimiento, lugar de nacimiento (en algunos casos), elementos de dirección (cuando se necesitan y están disponibles), jurisdicción emisora e identificadores de la credencial (para vincular el registro con un emisor y respaldar las trazas de auditoría).

• Detalles de la credencial: Clase o categoría de licencia, restricciones y endosos, fechas de emisión y de vencimiento.

• Retrato e imágenes: La foto del titular, utilizada para una comparación posterior a la coincidencia por parte de un operador o para una verificación en el dispositivo.

La mayoría de las personas encuentran las licencias de conducir móviles en un entorno presencial, por ejemplo, durante un control de tráfico. Esto se denomina presentación por proximidad: el titular y el lector están físicamente cerca uno del otro, inician una sesión mediante QR o NFC, y la credencial se comparte dentro de esa sesión.

Luego está la presentación en línea, donde un sitio web o una aplicación solicita datos de la mDL a través de Internet. El formato de la credencial puede permanecer igual, y la idea de divulgación selectiva sigue siendo la misma, pero lo que cambia es el entorno. La solicitud ahora puede entregarse mediante un enlace, un código QR en una pantalla o un flujo mediado por el navegador.

Es importante señalar que estos dos métodos de presentación están regulados de manera diferente. Por ejemplo, la Organización Internacional de Normalización (ISO) ha establecido dos referencias separadas:

• ISO/IEC 18013-5 para la presentación por proximidad.

• ISO/IEC TS 18013-7:2025 para la presentación en línea.

Los diferentes métodos de presentación enfrentan distintos tipos de amenazas, por lo que estas normas se desarrollaron por separado para adaptarse a ellas.

La presentación por proximidad asume copresencia, lo que casi elimina los ataques remotos, pero no elimina la necesidad de un comportamiento estricto del lector. Los riesgos prácticos tienden a ser “locales”: aceptar una captura de pantalla o una animación grabada, omitir la comparación posterior a la coincidencia, o ejecutar un lector con material de confianza desactualizado.

La presentación en línea traslada las mismas credenciales a un flujo de trabajo remoto, añadiendo una mayor superficie de ataque. El reenvío de sesión (cuando un atacante inicia una transacción y persuade a un titular para que la complete en su nombre) y la suplantación de la parte confiante son las dos amenazas potenciales más comunes.

Para los fines de este artículo, nos centraremos en los casos de presentación por proximidad, ya que son, con diferencia, los más comunes.

Estados Unidos tiene, con diferencia, la mayor concentración de emisores activos y de partes confiantes de alta frecuencia. A su vez, esto impulsa una iteración rápida: los puntos de aceptación encuentran fallos, los proveedores de lectores los corrigen, y los emisores ajustan políticas y comunicaciones, todo en periodos cortos de tiempo.

Esta pregunta no tiene una respuesta sencilla. En primer lugar, el número crece casi cada mes.

En segundo lugar, los estados pueden operar múltiples productos de credenciales móviles, algunos vinculados a los estándares ISO mdoc y otros no. Esta es una distinción importante, ya que un ISO mdoc es un formato de documento digital firmado, estrictamente definido en la mencionada norma ISO/IEC 18013 (más sobre esto más adelante).

A mediados de enero de 2026, la Asociación Estadounidense de Administradores de Vehículos Motorizados (AAMVA) enumera 21 estados de EE. UU. más Puerto Rico: Alaska, Arkansas, Arizona, California, Colorado, Delaware, Georgia, Hawái, Illinois, Iowa, Luisiana, Kentucky, Maryland, Montana, Nuevo México, Nueva York, Dakota del Norte, Ohio, Utah, Virginia y Virginia Occidental.

Sin embargo, este recuento se basa específicamente en las credenciales que la Administración de Seguridad en el Transporte (TSA) acepta para su uso en los controles de seguridad. No cubre todos los programas piloto ni todos los lugares con aceptación limitada.

En cuanto a cifras específicas de adopción, algunos estados han informado los siguientes datos:

• Nueva York informó más de 200.000 inscripciones en su Mobile ID a marzo de 2025 y destacó la aceptación en los controles de la TSA como un caso de uso principal.

• Georgia informó más de 500.000 usuarios de su licencia de conducir/ID digital en Apple Wallet, Google Wallet y la aplicación estatal a julio de 2025.

La emisión de licencias de conducir móviles en EE. UU. se describe mejor como multicanal: muchos estados emiten a través de una aplicación estatal, billeteras de dispositivos o ambas.

Aún más dualidad puede encontrarse al profundizar en los detalles: las mDL pueden presentarse en dos tipos. Ya sea un oficial de policía o un empleado en un mostrador, ambas se verán como una licencia en un teléfono y ofrecerán la misma experiencia de usuario, pero las pilas de verificación las tratarán como productos separados con diferentes flujos de lector:

1. mDL basada en estándares (presentación estilo ISO mdoc): Este es el modelo en el que se basa AAMVA: un mdoc es una credencial móvil presentada mediante un protocolo definido a un lector, con divulgación selectiva y validación criptográfica. AAMVA enmarca explícitamente las mDL en torno a la norma ISO/IEC 18013-5 (proximidad) y posiciona sus servicios de confianza en torno a la autenticación del emisor y la interoperabilidad.

2. Programas de “ID digital” basados en el teléfono que no son necesariamente un ISO mdoc: Algunas soluciones estatales se centran en una presentación visual más un código escaneable (a menudo un QR) que una aplicación verificadora puede validar. El modelo de verificación myColorado de Colorado es un ejemplo.

Esto plantea la pregunta: ¿son menos confiables las “licencias móviles” no ISO? No necesariamente.

Un ISO mdoc está diseñado para que un lector ejecute un protocolo estandarizado y obtenga un resultado respaldado por criptografía, mientras que un documento no ISO se basa en:

• Una vista visual de tarjeta con efectos animados u holográficos.

• Un código QR o de barras que un verificador escanea y luego comprueba contra un backend.

• Un token actualizado por el servidor (la aplicación se conecta al servidor y actualiza una marca de tiempo o un elemento gráfico).

• Un formato propietario de uso exclusivamente nacional que funciona solo con una aplicación verificadora o la infraestructura de un solo país.

En la práctica, esto no hace que los documentos no ISO sean inseguros, pero generalmente proporcionan garantías de verificación más débiles o menos estandarizadas, y son mucho más difíciles de escalar entre diferentes lectores, emisores y casos de uso transfronterizos.

Fuera de EE. UU., los programas más interesantes también tienden a encajar en las mismas dos categorías:

• Lugares que ya operan verificación estilo ISO mdoc, aunque sea solo para un caso de uso limitado.

• Lugares con adopción de “licencia digital oficial” a escala nacional, donde la verificación es sólida a nivel doméstico pero aún no constituye un ecosistema mDL ISO.

A continuación, hemos reunido tres de los ejemplos no estadounidenses más interesantes.

La adopción masiva temprana de Dinamarca

Dinamarca es uno de los mejores ejemplos de adopción a escala nacional de una aplicación móvil de licencia de conducir (con algunas salvedades). El lanzamiento tuvo lugar en 2020 y, a finales de 2025, 2,1 millones de ciudadanos han creado su licencia de conducir digital en la aplicación.

La descripción oficial de la aplicación Kørekort indica que es un complemento voluntario de la licencia física y que funciona como una licencia de conducir válida en Dinamarca, permitiendo a los usuarios dejar su tarjeta plástica en casa siempre que puedan mostrar la aplicación. Sin embargo, en sentido técnico, el caso de Dinamarca no se basa en ISO mdoc (al igual que algunos estados de EE. UU.).

Como tal, ha presentado un buen caso para los documentos no ISO. Dinamarca se centró primero en implementar un producto con buena experiencia de usuario y alto potencial de uso cotidiano, en lugar de una verificación mDL interoperable, y ha tenido éxito.

Verificación sin emisión en Nueva Zelanda

Nueva Zelanda es otro caso interesante, ya que no cuenta con un programa propio de emisión de mDL a nivel nacional, y aun así dispone de una aplicación verificadora diseñada para aceptar mDL internacionales basadas en ISO mdoc en flujos cotidianos relacionados con el turismo.

El Departamento de Asuntos Internos describe NZ Verify (también denominada Whakatūturu) como una herramienta para que empresas como arrendadoras de automóviles y hoteles puedan verificar determinadas licencias de conducir móviles internacionales utilizando únicamente un teléfono. Enumera explícitamente Queensland (Australia), además de un conjunto de emisores estatales de EE. UU. (y Puerto Rico), que la aplicación puede verificar.

El peculiar modelo híbrido de Austria

El caso de Austria involucra tanto documentos ISO como no ISO dentro de un mismo sistema, lo que lo hace bastante singular.

El titular utiliza la aplicación gubernamental eAusweise, y el acceso está vinculado a ID Austria (la identificación electrónica nacional). BRZ (el centro federal de informática de Austria) afirma que los datos de la credencial se almacenan en el dispositivo del usuario y que la aplicación eAusweise está diseñada para uso sin conexión, pudiendo utilizarse los datos de la licencia de conducir sin conexión hasta tres meses después de su recuperación.

Esto es importante porque abre la puerta a dos modelos de verificación separados:

1. Basado en ISO (verificación sin conexión por terceros): Los datos cifrados se transfieren entre dispositivos mediante Bluetooth Low Energy (BLE) y se verifican en el dispositivo del verificador, haciendo referencia explícita a la norma ISO 18013-5 para la verificación sin conexión.

2. No ISO (verificación en línea por la policía): Un oficial escanea un código QR y utiliza un identificador contenido en él para recuperar los datos de la licencia de conducir directamente del registro de licencias en el dispositivo del oficial a través de la aplicación policial. En muchos aspectos, esto se asemeja más a una verificación mediante consulta a un registro que a una presentación entre pares de un ISO mdoc.

Muchas implementaciones de verificadores mantienen una sola pila de lector tanto para credenciales móviles como para documentos físicos. Esto mantiene coherente la capacitación de los operadores y preserva una alternativa cuando una credencial en el teléfono no está disponible.

Una verificación ISO mdoc del lado del lector se entiende mejor como una secuencia breve que comienza antes de que el titular llegue:

Antes de cualquier transacción, el entorno del verificador se configura con:

• Capacidad de transporte: Las transacciones por proximidad se basan en Bluetooth, NFC o ambos. Las aplicaciones de lector necesitan permisos del sistema operativo y autorizaciones de la plataforma para estos radios.

• Un almacén de confianza: La validación sin conexión depende de que las anclas de confianza del emisor estén presentes localmente, además de cualquier certificado intermedio y material de revocación que el programa requiera.

• Configuraciones predefinidas de solicitud: Las implementaciones maduras definen plantillas de solicitud fijas vinculadas a ciertos escenarios, manteniendo la divulgación al mínimo.

• Intención de retención: Muchos sistemas de lector registran durante cuánto tiempo se pretende conservar campos específicos.

El caso estadounidense también apunta hacia la autenticación del lector para campos opcionales, señalando que el titular debería exigir la autenticación del lector antes de liberar elementos que no sean obligatorios en la tabla de conjunto de datos ISO mDL.

En modo de proximidad, la sesión comienza con la vinculación del dispositivo, normalmente mediante el escaneo de un código QR o el contacto a través de NFC. La vinculación comparte parámetros de sesión y opciones de transporte, no los atributos de la licencia en sí.

La vinculación asocia un dispositivo de titular específico con una sesión de lector específica y proporciona los elementos necesarios para generar las claves de sesión.

Después de la vinculación, el lector envía una solicitud que enumera los elementos de datos necesarios. Esto es divulgación selectiva en la práctica.

En implementaciones reales, la solicitud rara vez se construye de forma ad hoc. Se obtiene de una configuración predefinida:

• Una configuración para ventas restringidas por edad puede solicitar un resultado de umbral de edad o el conjunto mínimo necesario para calcular la edad.

• Una configuración para verificación de identidad puede solicitar nombre, fecha de nacimiento y foto del titular.

• Una configuración para privilegios de conducción puede solicitar la clase y los elementos relacionados con restricciones.

Este diseño de solicitud es una de las decisiones operativas más importantes que toma una parte confiante. Define el impacto en la privacidad y el riesgo de interoperabilidad.

El titular revisa la solicitud y aprueba el intercambio; la mayoría de las billeteras condicionan la aprobación a una verificación local en el dispositivo, como un PIN o datos biométricos. Si el programa utiliza certificados de lector, este es también el momento en que la billetera puede validar que el lector está autorizado para solicitar ciertos elementos opcionales antes de que continúe la divulgación.

Tras el consentimiento, el dispositivo del titular devuelve los elementos solicitados junto con las estructuras firmadas necesarias para la validación mediante BLE o NFC.

La validación es donde las señales se convierten en información fiable para los verificadores. Los lectores generalmente evalúan cuatro aspectos:

1. Autenticidad del emisor: El lector valida las firmas del emisor y construye una cadena de certificados hasta una ancla de confianza, confirmando que el emisor es legítimo y que los datos firmados no han sido alterados desde su emisión.

2. Integridad de los elementos: La divulgación selectiva solo funciona si cada elemento divulgado está criptográficamente vinculado a lo que el emisor firmó. Esto se realiza comúnmente mediante el Mobile Security Object (MSO), descrito en la guía como el conjunto de datos estructurado que permite a un verificador autenticar otros elementos mDL recibidos durante la transacción.

3. Vinculación de sesión: El lector verifica que la respuesta pertenezca a la sesión creada durante la vinculación, lo que reduce el riesgo de repetición.

4. Ventanas de validez y expectativas de actualización: Los campos de tiempo como validFrom, validUntil y expectedUpdate se revisan para rechazar credenciales vencidas e interpretar las expectativas de actualización en flujos sin conexión.

Después de la validación, la pila de lector normalmente devuelve:

• Atributos de texto normalizados, mapeados a un esquema coherente para sistemas posteriores.

• Imágenes del retrato para comprobaciones presenciales posteriores a la coincidencia.

• Indicadores de estado explícitos, que comúnmente incluyen resultados derivados de verificación de edad.

Esta capa de presentación hace que las mDL sean utilizables en condiciones reales. Facilita indicaciones claras para el operador y motivos de fallo auditables, como “vencida”, “fallo en la autenticación del emisor”, “consentimiento rechazado” o “tiempo de espera de transporte agotado”.

Se espera que 2026 traiga un despliegue más amplio de mDL en EE. UU. y en el extranjero. A medida que crece la adopción, cada vez más verificadores buscarán una implementación de lector que cubra todo el flujo ISO mdoc de extremo a extremo y luego devuelva resultados en un formato que el personal y los sistemas backend puedan utilizar.

Estas implementaciones pueden estar impulsadas por Regula Document Reader SDK, que le proporcionará:

• Lectura de mDL basada en sesión: El SDK inicia y gestiona una sesión completa de verificación de mDL manejando la vinculación del dispositivo y luego ejecutando la recuperación de datos dentro de esa misma sesión.

• Recuperación flexible de datos mDL: El SDK admite la recuperación de datos mDL mediante BLE o NFC, para que las aplicaciones verificadoras puedan utilizar el transporte que se adapte a sus puntos de control y restricciones de dispositivos.

• Material de confianza como elemento clave de configuración: El SDK permite a los verificadores cargar el material de certificados confiables necesario para la autenticación del emisor (incluidos recursos CBOR PKD, con cadenas CSCA/DSC para acceso NFC y cadenas de certificados del emisor para recuperación por BLE).

• Solicitudes de datos controladas: El SDK permite a los verificadores solicitar únicamente los elementos de datos mDL necesarios mediante configuraciones predefinidas, al mismo tiempo que establece una intención de retención por campo.

• Resultados bien estructurados: El SDK devuelve resultados de texto e imagen normalizados junto con estados claros, incluida la validación general de la mDL y resultados integrados de verificación de edad.

¿Tiene más preguntas? Póngase en contacto con el equipo de Regula ahora mismo — ¡estamos aquí para ayudarle!