The mDL Is Here. Now What? A Practical Guide to Accepting Mobile Driving Licenses

The mobile driving license has cleared its most important early hurdle. TSA began accepting mDLs at select airport security checkpoints in 2023, and the list of participating states has grown steadily since.

Apple Wallet and Google Wallet both support the credential. ISO 18013-5—the international standard governing mDL technical implementation—is published and actively referenced by state DMVs building their issuance infrastructure.

The technology is real, the standards are established, and consumer adoption is accelerating. What lags is organizational readiness on the acceptance side. For the businesses, financial institutions, and government agencies that need to verify identity as part of their operations, the practical question is no longer whether mDLs are coming—it’s whether your verification infrastructure can handle them when a customer presents one.

Most can’t. Here’s what that means and what to do about it.

What an mDL Is and How It’s Different from a Photo of an ID

An mDL is not a digital image of a physical license. That distinction matters more than it might seem.

A physical ID presented to a verifier is authenticated by examining the document itself—security features, holograms, machine-readable zones, and the visual match between the cardholder photo and the person standing in front of you. The document is the credential.

An mDL operates on a fundamentally different trust model. The credential lives in a secure element on the holder’s device, issued by a state DMV and cryptographically signed. When a holder presents their mDL, the verifier receives a signed data package—not a document image—and verifies the DMV’s cryptographic signature to confirm authenticity. The trust chain runs from the state issuing authority through the cryptographic infrastructure, not through visual inspection of a physical artifact.

This means accepting mDLs requires different infrastructure than accepting physical IDs. A verifier who asks a customer to “show their mDL” and receives a screenshot has not performed mDL verification; they’ve performed a visual check of an unverified image, which carries no more assurance than looking at a photocopy.

The ISO 18013-5 Standard and What Compliance Actually Requires

ISO 18013-5 specifies two presentation modes that organizations need to understand.

Proximity presentation uses Bluetooth Low Energy or NFC to transfer credentials directly from the holder’s device to a verifier’s reader device. This is the model TSA uses at airport checkpoints—a purpose-built reader device receives the signed credential package, verifies the issuing authority’s signature, and returns the result to the TSA officer. The holder’s phone never leaves their hand. The verifier never receives more data than was requested.

Remote presentation enables online identity verification flows where the mDL credential is presented through a digital channel—a website or application—rather than in person. This is the model relevant to financial services onboarding, age verification, and any identity check that happens without the customer physically present.

For organizations implementing acceptance, the compliance requirement is the same in both modes: the verification system must be able to retrieve and validate the issuing state’s public key certificate, verify the cryptographic signature on the credential package, and confirm that the data returned has not been tampered with in transit. Visual inspection of the mDL display screen does not satisfy this requirement.

4 Practical mDL Implementation Considerations

1. Start With Use Case Scoping

Not every identity check in your operation needs mDL-grade cryptographic verification. Map the verification touchpoints in your workflows, identify which ones involve regulated identity obligations (KYC, age verification, access control), and prioritize mDL acceptance infrastructure for those.

2. Evaluate Your Existing IDV Vendor’s mDL Roadmap

Most established identity document verification vendors are building or have built ISO 18013-5 compatible verification flows. Ask specifically whether they support cryptographic signature validation against state issuing authority certificates—not just optical character recognition of a displayed mDL screen.

3. Plan for Multi-State Variability

State mDL programs are not fully standardized in their implementation details despite the ISO framework. The data elements available, the issuing authority certificate infrastructure, and the wallet implementations vary by state. A verification system that works against one state’s mDL may require updates to work against another’s.

4. Do Not Treat Selective Disclosure as a Privacy Add-On

ISO 18013-5 supports selective disclosure—the holder can prove a specific attribute (age above a threshold, state of residence) without revealing the full credential.

This is a feature your verification flows should be designed to request properly, not something to implement later. Building verification requests that ask for more data than necessary creates unnecessary data liability from day one.

The Window Before It Becomes a Customer Experience Problem

mDL-equipped customers are already walking into financial institution branches, presenting at age-verified access points, and attempting digital onboarding flows with credentials their phones are ready to present.

Organizations that cannot accept what their customers are carrying will face the same friction problem that card networks faced in the early EMV transition—the infrastructure gap between issuer capability and merchant acceptance that creates a degraded experience for compliant users and an opening for fraud at the point of least resistance.

The mDL is here. The acceptance infrastructure is the remaining work.