Mobile driving licences (mDLs) are moving from pilots to production in the EU. Learn what mDLs can and cannot do, how proximity and online flows differ, and what car rentals, airlines, and other verifiers need to prepare.
A mobile driving licence (mDL) carries the same data as the plastic card. The difference is that instead of being a laminated document, it is a cryptographically signed credential presented from a phone. The user chooses which fields to share, the verifier gets a real-time authenticity check, and the credential cannot be easily faked like a scanned PDF or photo.
The EUDI Wallet framework treats the mDL as one of its high-priority use cases. The Architecture and Reference Framework (ARF) explicitly lists car rentals, roadside checks, and other in-person scenarios as target applications for mDLs based on ISO/IEC 18013-5.
However, an mDL is not a universal identity document, and it does not automatically replace existing processes. Understanding what it can and cannot do is critical for car rental companies, airlines, and any business that currently inspects physical licences.
An mDL formatted to ISO/IEC 18013-5 proves driving privileges but it doesn’t inherently prove general identity. It confirms that a valid licence exists, the licence categories held, the issue and expiry dates and the issuing authority and country.
It does not replace a national ID card or passport for purposes that legally require identity verification under eIDAS or national law. For those scenarios, the PID (Person Identification Data) credential in the EUDI Wallet is the appropriate credential.
From a technical perspective,
the underlying format is mso_mdoc (CBOR-encoded).
proximity flows use ISO/IEC 18013-5 directly.
online flows use OpenID4VP v1.0, with the mDL remaining an ISO/IEC 18013-5-compliant credential. ISO/IEC 18013-7 also defines additional mechanisms for presenting an mDL over the internet.
These are distinct integration paths with different reader infrastructure and protocol stacks.
The EUDI Wallet specification defines four main presentation flows: remote same-device, remote cross-device, proximity supervised, and proximity unsupervised. For mDLs, the two most relevant are proximity and remote (online).
In a proximity scenario, the user is physically close to the verifier. Typical examples include a rental counter, a police roadside check, or an automated kiosk.
The flow works roughly as follows:
Engagement
The user opens their wallet and selects the mDL. The wallet establishes a short-range channel with the reader device via NFC, Bluetooth Low Energy (BLE), or, QR codes in some implementations.
Request
The reader sends a request specifying the document type and the required attributes, such as licence category, expiry date, or age over 21.
Authentication and consent
The wallet authenticates the reader and then asks the user to approve the release of the requested attributes. The user sees exactly what is being requested and can decline.
Response
The wallet sends a signed response containing only the requested fields. Cryptographic verification is done locally against trusted issuer certificates. This can work offline, which is important for roadside checks and locations with poor connectivity.
The ARF distinguishes two proximity modes:
Supervised identification, where a human operator (e.g., rental agent, police officer) is present and may also perform a visual check;
Unsupervised identification, where the user interacts directly with a machine, such as a self-service kiosk for car key collection or an automated gate.
For online bookings, pre-check-in, or remote verification, the service sends a request via browser or app, and the user’s wallet responds over the internet using OpenID4VP. The result is verified server-side.
Key differences from proximity are as follows:
The protocol is OpenID4VP v1.0, not raw ISO 18013-5 device engagement.
The verifier is a remote verifier (backend service + UI), not a local reader app.
The same mDL credential can be presented, but the transport and session security model differ.
The ARF and mDL guides explicitly support both modes for the same credential: proximity for face-to-face checks, remote for online car rentals and other digital flows.
Car rental companies are explicitly named in EU mDL documentation as a primary use case. They must check a driver’s right to drive, and users will be able to share their mDL either in person or remotely in advance.
Typical data requirements are full name, date of birth, licence categories, issue and expiry dates and the issuing country.
Counter staff need a reader device capable of initiating an mDL request, registered as a relying party under the eIDAS 2.0 framework. For self-service kiosks, the unsupervised proximity flow is relevant where the user presents the mDL to the terminal, which verifies the credential and, if valid, releases the keys or completes the check-in.
Selective disclosure is a genuine GDPR advantage in this scenario. A rental company can request only the licence category and expiry without seeing the driver’s home address or other unnecessary attributes. That reduces data exposure while still meeting operational and legal requirements.
Online flows are equally important. A customer booking a car in another country can present their mDL during the digital check-in process. The rental company’s remote verifier uses OpenID4VP to request the necessary attributes and validate the signature and issuer trust.
For airlines and airports, there are two distinct needs.
Age checks are needed for duty-free alcohol and tobacco sales, lounge access where age restrictions apply, and for certain ancillary services.
Wallet-based selective disclosure can confirm “over 18” or “over 21” without revealing the passenger’s full date of birth, address, or other identity details. This is a classic privacy-preserving use case where the service needs only a threshold and not the passengers full identity profile.
For check-in, security, and boarding, airlines typically require identity documents that meet specific legal standards. The mDL alone is generally not sufficient for these purposes unless national law explicitly accepts it as a valid travel or identity document.
For identity verification in the EUDI Wallet, the PID credential is designed to carry core identity attributes (name, date of birth, nationality, etc.) and to be accepted by public and private services where identity proof is required.
Airlines should not design a check-in flow that accepts an mDL as a primary identity document unless their legal team confirms that the specific jurisdiction permits it. A more realistic near-term pattern is:
mDL for age-restricted services and some operational checks;
PID (or existing travel documents) for formal identity and border-related processes.
The ARF explicitly identifies traffic stops as an mDL use case. Police and other officials will be able to check a driver’s mDL when required, using a handheld or in-vehicle reader.
The proximity flow (offline-capable) fits the operational reality of a roadside check better than an online flow. Officers may not have reliable connectivity, and the interaction must be fast and robust. ISO/IEC 18013-5 proximity presentation is designed for exactly this scenario.
The ARF distinguishes:
Supervised proximity flows, where a human agent operates the reader (e.g., police officer, border guard);
Unsupervised flows, such as automated border control gates or self-service terminals.
Automated border control gates adding mDL reader capability is a Member State infrastructure decision, not something mandated uniformly at EU level. Some countries may integrate mDL checks into existing e-gates while others may limit mDL use to manual checks by officers.
For border agencies, the mDL is best seen as complementary to PID and existing travel documents and is not to be seen as a standalone border-control credential.
The mDL verifies credential authenticity cryptographically. But it does not, by itself, verify that the person holding the phone is the named credential holder. That is why supervised flows often combine a cryptographic verification of the mDL, a visual identity check (photo comparison), and, where available, biometric binding between the wallet user and the device.
Businesses should plan for a combined process without assuming the technology alone solves impersonation risk.
Proximity and online mDL verification use different protocols and different reader infrastructure:
Proximity: ISO/IEC 18013-5, local reader apps, NFC/BLE/QR, offline-capable.
Online: OpenID4VP, backend verifier services, browser/app integration.
These should be treated as separate roadmaps. A car rental company may need both, for instance, proximity readers at counters and kiosks, and a remote verifier for online bookings.
National rollout timelines vary, and cross-border recognition requires each licensing authority to connect to the trust infrastructure.
But relying party registration, reader devices, staff training, updated terms of service, and UX design all take time. Companies that prepare their flows now will be able to switch on mDL support as soon as their target markets issue credentials.
Ready or nearly ready:
ISO/IEC 18013-5:2021 is an established international standard, while a second edition is currently under development and the proximity flow specification is mature.
The mDL rulebook and verifier guides within the ARF define technical requirements for wallets, readers, and issuers and implementation continues to evolve.
EU Large-Scale Pilots have tested wallet implementations and mDL scenarios, including car rentals and roadside checks.
Remote verification via OpenID4VP is specified and implemented in reference stacks.
Still developing or varying by country:
National rollout timelines: Some Member States will issue mDLs earlier than others.
Cross-border recognition: Each licensing authority must connect to the trust infrastructure and ensure their mDLs are verifiable across borders.
Reader deployment: Police forces, rental companies, and airports must procure and configure reader devices and integrate them with back-office systems.
Legal acceptance: Not all jurisdictions will treat mDLs identically for all purposes, especially outside traffic enforcement.
The practical picture for the next few years is a hybrid environment consisting of physical licences, emerging mDLs, and gradual expansion of verifier infrastructure.
Authbound’s API and SDK handle wallet-presented credentials, including driving licence verification, without requiring your team to build the cryptographic verification layer from scratch.
For businesses that need mDL support, Authbound can help with the following.
Integrating wallet-based verification into online services
Supporting proximity-based verification where compatible reader infrastructure is required
Requesting only the attributes needed for a particular business process
Validating credential authenticity and the relevant issuer trust information.
Note that Authbound does not issue mDLs or act as a licensing authority. Its role is to make it easier for car rental companies, airlines, and other verifiers to connect to the EUDI Wallet ecosystem as relying parties, using a single integration layer for multiple credential types.
Reach out at [email protected] to discuss your specific integration flow and whether proximity, online, or a combination makes sense for your use case.
The mobile driving licence is one of the most tangible EUDI Wallet use cases for everyday life. It touches millions of drivers, thousands of rental locations, and countless ID checks every day.
For businesses, the opportunity is to redesign the existing process around selective disclosure, cryptographic trust, and lower data exposure. If done well, mDL integration can make checks faster, safer, and less intrusive for customers and verifiers alike.
Hiring across the EU means verifying identity, diplomas, and professional licenses from different countries. See how the EUDI Wallet and verifiable credentials can turn weeks of manual checks into minutes of cryptographic verification.
Erasmus+ students and universities face a paper-heavy credential process. See how EUDI Wallet-based verifiable credentials can make diploma and student-status verification instant, cross-border, and privacy-preserving.
How financial institutions can leverage the EU Digital Identity Wallet to streamline KYC/AML compliance, reduce fraud, and improve onboarding speed.
