Mobile driver's license verification: Why digital IDs break plastic-first onboarding
Key Highlights
- Mobile driver's licenses are exposing a mismatch in remote KYC. They are cryptographically signed digital credentials, but most onboarding flows still expect users to photograph a physical driver's license.
- A genuine mDL can look like fraud to a plastic-first verification flow. Screen recapture, missing holograms, absent barcodes, and non-standard layouts can trigger the same controls designed to catch spoofing.
- Remote verification is the harder problem. ISO/IEC 18013-5 works well for in-person presentation, while ISO/IEC 18013-7 for remote presentation is published but still unevenly implemented across wallets and states.
- The immediate fix is to diagnose the funnel and layer verification. Segment capture failures by high-mDL states, validate license data against issuing sources, and avoid making document photography the only source of trust.
- Mobile driver's license adoption in the US
- Why mobile driver's licenses fail traditional document verification
- How remote mobile driver's license verification works
- Where mobile driver's license verification creates onboarding friction
- How to detect mobile driver's license failures in your onboarding funnel
- How to prepare your KYC flow for mobile driver's licenses
- FAQ
A driver in Phoenix signs up for a delivery platform. Her license lives in Apple Wallet. That stopped being unusual in Arizona some time ago: 1,227,833 Arizonans hold a mobile driver's license, a 21% conversion of the state's licensed drivers.
The signup flow asks her to photograph her driver's license. She now has two options. She can photograph her phone screen using a second device. Or she can find the plastic card she stopped carrying.
If she picks the first option, most fraud engines flag the image instantly. A photo of a screen is exactly what presentation attack detection is trained to reject. If she picks the second, a digital-first onboarding flow just sent a legitimate user to dig through a drawer.
Either way, the platform loses. And the platform's fraud dashboard records it as a win.
At Signzy, we verify driver's licenses for banks, fintechs, and delivery platforms across the US, which is exactly where this collision between wallet-based credentials and plastic-first capture shows up first.
Mobile driver's license adoption in the US
Mobile driver's licenses (mDLs) are state-issued credentials that live in Apple Wallet, Google Wallet, Samsung Wallet, or a state app. They follow the ISO/IEC 18013-5 standard, the same one TSA uses to accept them at airport checkpoints. As of mid-2026, 21 states plus Puerto Rico have live programs. TSA recognizes digital IDs from 20 states plus Puerto Rico.
Published enrollment figures show where this is concentrated:
| Jurisdiction | mDLs issued | Share of licensed drivers | Wallets supported |
|---|---|---|---|
| California | 3,298,298 | Growing since 2023 pilot | Apple, Google, Samsung, CA DMV Wallet |
| Arizona | 1,227,833 | 21% | Apple, Google, Samsung, state app |
| Colorado | 239,037 | 5% | Apple, Google, Samsung, myColorado |
| Arkansas | 48,823 | 2% | Apple, Google, Samsung, state app |
| Alaska | 4,256 | 1% | Alaska Mobile ID |
| US total (2025) | 4.5 million+ | ~2% of licensed drivers | Varies by state |
Sources: ITU presentation of state DMV figures (2026); GovTech national estimate (2025); state wallet announcements.
The full list of live programs: Alaska, Arizona, Arkansas, California, Colorado, Delaware, Georgia, Hawaii, Illinois, Iowa, Kentucky, Louisiana, Maryland, Montana, New Mexico, New York, North Dakota, Ohio, Utah, Virginia, West Virginia, and Puerto Rico.
Two percent nationally sounds ignorable. It is not, for two reasons. First, adoption is not evenly spread: in Arizona, one in five drivers already converted, and California added Samsung Wallet support in April 2026 to accelerate its 3.3 million. Second, the growth curve is steep. ABI Research forecasts 143 million US mDL holders by 2030. That is more than half of the country's licensed drivers, four years out.
If your onboarding volume includes Arizona, California, Colorado, or Maryland, mDL holders are already entering your funnel today.
Why mobile driver's licenses fail traditional document verification
Here is the mechanical problem, step by step.
Document-capture verification was built around one assumption: the user photographs a physical card. Every downstream check depends on that assumption.
| Verification step | What it checks on plastic | What happens with an mDL screen photo |
|---|---|---|
| Capture quality | Card edges, glare, focus | Detects a screen, not a card |
| Presentation attack detection | Is this a live document or a replay? | Flags screen recapture: classic spoof signal |
| Security features | Holograms, microprint, UV patterns | None exist on a screen render |
| PDF417 barcode parse | Decodes data from the physical barcode | Wallet UIs do not display a scannable barcode by default |
| Template match | Layout vs. known state design | Wallet rendering matches no plastic template |
Read that table from a fraud engine's point of view. A genuine, state-issued, cryptographically signed credential presents through a channel that scores like a fraud attempt on all five layers. The system is not malfunctioning. It is correctly rejecting the wrong object, because the right object was never designed to be photographed.
This is the part most teams have not internalized: an mDL is not a picture of a license on a phone. It is a signed data payload. The ISO 18013-5 standard defines how it is presented in person, over Bluetooth or NFC, to a reader that validates the state's cryptographic signature. Verified correctly, an mDL is stronger evidence than plastic, because forging it means defeating the issuing state's cryptography rather than a hologram.
Photographed off a screen, it is weaker than plastic. All the cryptography is stripped away, and what remains is an image with every spoof signal present.
How remote mobile driver's license verification works
In-person mDL verification is settled. ISO 18013-5 works, TSA uses it daily, and retail age checks are being piloted on it.
Remote verification, the kind onboarding flows need, is not settled. The relevant standard, ISO/IEC 18013-7, was published as a technical specification in October 2024 and defines how an mDL is presented over the internet to a verifier that is not in the room. The specification exists, interoperability events have run, and a next edition is in progress. But as of August 2026 it remains a moving target: NIST notes that its annexes depend on protocols still co-evolving, and wallet support for unattended presentation is inconsistent across states and platforms.
The practical consequence for anyone running remote onboarding:
| Scenario | Standard | Status in 2026 |
|---|---|---|
| Airport checkpoint, in person | ISO 18013-5 | Live, 20+ states |
| Age check at point of sale | ISO 18013-5 | Live pilots |
| Remote onboarding, web or app | ISO 18013-7 | Published, unevenly implemented |
| Photograph the wallet screen | None | Fails presentation attack detection, by design |
So a fintech, marketplace, or insurer verifying users remotely today sits in a gap: a growing share of applicants hold a credential that is cryptographically superior to plastic, and no photograph-based flow can accept it.
Where mobile driver's license verification creates onboarding friction
Gig and delivery onboarding. Driver supply is won and lost on activation speed. An applicant whose license is wallet-only either abandons signup or completes it days later with plastic. In Arizona, that friction now applies to one in five potential drivers. The platforms that onboard in minutes hold the supply advantage.
Age-restricted commerce. A 22-year-old buying online is the demographic most likely to have converted to a wallet credential and least likely to carry a physical card daily. A hard "photograph your ID" gate at checkout is a paid-traffic write-off for that segment.
Banking and fintech KYC. A rejected capture does not read as "unsupported credential type" to a compliance analyst. It reads as a failed document check, which routes to manual review. Each mDL holder pushed into the review queue costs analyst minutes and adds a day of onboarding delay for a customer who did nothing wrong.
Car rental and mobility. The person standing at the counter can present an mDL in person under 18013-5. The same person pre-registering through the app cannot. The channel with the lower fraud exposure gets the better credential; the channel with the higher exposure gets a photo.
How to detect mobile driver's license failures in your onboarding funnel
You do not need a new vendor to answer this. You need one query against your own capture logs. mDL holders hitting a plastic-only flow leave a recognizable signature:
| Signal in your data | What it suggests | Where to look |
|---|---|---|
| Screen-recapture rejections clustered in AZ, CA, CO, MD, LA | Real mDL holders photographing wallets | PAD rejection logs by state |
| Capture abandonment above baseline in high-mDL states | Users who gave up finding plastic | Funnel analytics, segment by issuing state |
| "Document not readable" errors on device-model spikes | Wallet screen renders confusing template match | Capture SDK error codes |
| Retry loops: 3+ capture attempts then drop | User trying angles on a screen photo | Session replay on failed captures |
| Manual review queue growth from the same five states | mDL failures routing to analysts | Review queue by state, last 90 days |
| Support tickets mentioning "digital license" or "Apple Wallet" | Users telling you directly | Ticket keyword search |
Run the state-level cut first. National averages will hide this: at 2% national adoption the signal drowns, but Arizona at 21% will show up clearly if it is happening.
One more reason this matters beyond conversion: the fraud asymmetry. Fraudsters do not photograph wallet screens; they submit AI-generated images of plastic licenses, which we have covered in depth in our fake ID detection and AI-generated fake ID analyses. So a plastic-only capture flow now faces the worst version of both worlds. Legitimate users increasingly hold a credential the flow cannot accept, while attackers submit exactly the artifact the flow was built to trust. The gap between what your verification accepts and what honest users carry is a gap fraud fills.
The near-term answer for most teams is layered rather than pure: extract and verify the plastic when it exists, validate the underlying record against issuing sources such as DMV-aligned databases, and match the face to the credential holder, so the verification does not stand or fall on the photograph alone. That is how driver's license verification works within a complete onboarding check today, alongside the rest of the US verification API stack, and the API documentation shows what is returned field by field. As 18013-7 implementations stabilize, native mDL presentation becomes another input into the same decision, not a rebuild.
How to prepare your KYC flow for mobile driver's licenses
Before the end of this week, pull ninety days of capture rejections and segment them by issuing state. If Arizona, California, Colorado, or Maryland over-index on presentation attack flags or capture abandonment, you are not looking at fraud. You are looking at your earliest mDL adopters failing to hand you a credential that is better than the one you asked for. Count them, cost them, and put a number on what "wait for the standard to settle" is worth against 143 million holders by 2030.
FAQ
What is a mobile driver's license (mDL)?
Which states have mobile driver's licenses in 2026?
Can a mobile driver's license be used for KYC?
How do you verify a mobile driver's license remotely?
Why does identity verification reject a photo of a digital license?
Are mobile driver's licenses accepted by TSA?
Will mobile driver's licenses replace physical licenses?
Does REAL ID affect mobile driver's licenses?

Gaurav Gupta
Gaurav Gupta is the Global Product Head at Signzy, leading the strategy and development of the company’s KYC, KYB, AML, and digital onboarding products used by banks, fintechs, and financial institutions across global markets. He specializes in building scalable compliance and verification platforms, transforming complex regulatory and risk workflows into seamless, automated product experiences. Gaurav works at the intersection of product, engineering, and AI.
Related Blogs
View allThe best in business
The global API marketplace for KYC, KYB, & AML
Explore the end-to-end verification stack trusted by 1,000 businesses.
Get in touch








