TL;DR: Mobile driver’s licenses are moving from pilots into everyday identity verification, with 21 U.S. states plus Puerto Rico issuing standards-based mDLs and California reporting 3.5 million applications, according to Incode. The security issue is no longer whether mDLs work, but how IAM, onboarding, and compliance flows adapt to fragmented wallet coverage and selective disclosure.
At a glance
What this is: This is an analysis of how mobile driver's licenses are changing identity verification, with the key finding that standards-based mDLs are becoming practical across onboarding, age assurance, and account-opening flows.
Why it matters: It matters because identity and access teams need to adapt verification logic, wallet coverage, and data-minimisation controls as digital credentials move into mainstream IAM and compliance workflows.
Context
Mobile driver's licenses are digital state IDs stored in a phone wallet and verified through cryptographic signatures rather than a photographed plastic card. That changes the identity assurance model because the verifier is no longer handling a static image, but a standards-based credential with selective disclosure and issuer validation built in.
For IAM, onboarding, and compliance teams, the governance question is not whether mDLs work in principle. It is how verification flows adapt when coverage is fragmented across wallets and states, while the credential can reveal only the attributes the check actually needs.
Key questions
Q: How should teams design verification flows for mobile driver's licenses?
A: Design the flow around issuer verification, wallet support, and the minimum attributes needed for the decision. Treat mDLs as standards-based credentials that can reduce document handling, then add fallback paths for unsupported wallets and jurisdictions so onboarding does not break as adoption expands.
Q: What happens when an mDL wallet is not supported by a verifier?
A: The credential may still be valid, but the business cannot complete the verification path for that wallet. Teams need routing, alternative checks, or a fallback identity-proofing method so unsupported wallets do not become failed onboarding events or inconsistent customer experiences.
Q: How can organisations use selective disclosure without weakening compliance?
A: Ask for only the attributes the business decision requires, then store the verification result rather than the full document where policy allows. That preserves compliance intent while reducing the amount of personal data exposed, retained, or replayed across downstream systems.
Q: Should identity teams replace physical ID capture with mDL verification?
A: Not everywhere, but mDLs should replace card scans wherever the legal, wallet, and issuer conditions are in place. The right decision is to segment journeys by risk and jurisdiction, then use mDLs to remove unnecessary friction and reduce data exposure in the supported paths.
Technical breakdown
How mDL cryptographic verification changes identity assurance
A mobile driver's license is a signed digital credential, not an image of a card. The verifier checks the issuing state's signature and the device-bound presentation signature before trusting the data, which makes copied or altered credentials fail validation. This shifts assurance away from visual inspection toward standards-based cryptographic verification, with ISO/IEC 18013-5 covering in-person presentation and ISO/IEC 18013-7 extending the model to remote use. The important design point is that the verifier consumes a structured credential, not an uploaded photo or manual transcription.
Practical implication: Treat mDL acceptance as a cryptographic verification flow, not a document-upload workflow.
Why selective disclosure changes data minimisation for KYC and age checks
Selective disclosure lets the holder prove only the attribute a verifier needs, such as being over 21, without exposing address, document number, or full birth date. That matters because the credential can reduce what the business stores, logs, and processes after verification. In governance terms, mDLs make data minimisation operational rather than aspirational, but only if downstream systems are designed to accept partial attributes instead of demanding full document capture. The verification outcome can be stronger while the data footprint is smaller.
Practical implication: Redesign onboarding logic so the minimum acceptable attribute set is enough to complete the check.
Why wallet fragmentation becomes an access and coverage problem
mDL adoption is not uniform across wallets or states, so a business cannot assume one consumer wallet covers the whole market. The article notes device wallets, such as Apple Wallet, Google Wallet, and Samsung Wallet, alongside state-issued wallet apps, each with different rollout patterns and protocol support. That creates a coverage management problem for identity teams because the same verification journey may need to accept several wallet types while preserving a consistent risk decision. The control issue is not just technical compatibility, but predictable assurance across a changing issuer and wallet ecosystem.
Practical implication: Build wallet routing and fallback logic into the verification journey before mDL volume grows.
NHI Mgmt Group analysis
Mobile driver's license adoption is turning identity verification into a standards and coverage problem, not a document-format problem. The article shows that the core question is no longer whether a digital license can be verified, but whether the organisation can support the issuer, wallet, and remote-presentation combinations that customers actually bring. That means identity programmes must be designed for interoperability and partial coverage from the start.
Selective disclosure is the part of mDLs that most directly changes IAM governance. Traditional verification flows often collect more data than the decision requires, then retain it in downstream systems. mDLs make it possible to verify age or identity attributes without copying the full credential, so the governance model shifts toward minimum necessary data by default.
mDLs expose a new verification boundary between credential trust and wallet trust. The credential may be standards-based, but assurance still depends on whether the wallet implementation and presentation path are supported in the business flow. Teams that treat all wallets as equivalent will create uneven user journeys and inconsistent acceptance logic.
The named concept here is wallet coverage drift: the gap between which mDL issuers exist in the market and which wallets a business can reliably verify today. That drift will shape adoption more than the standards themselves. Practitioners should expect verification policy, customer support, and fraud review to change as state rollout and wallet support evolve.
mDLs fit the direction of travel for modern identity, but they do not remove governance decisions. They move verification toward privacy-preserving, standards-based data exchange, which is useful only when the surrounding IAM process can consume it cleanly. The practical conclusion is that onboarding, age assurance, and KYC flows need policy decisions before they need code changes.
What this signals
Wallet coverage drift: mDL adoption will be limited less by the standard than by which issuers and wallets each business chooses to support. Identity teams should expect policy and product decisions to move together, because a credential that works in one wallet may still fail in another.
mDLs also pull verification closer to data minimisation goals because the verifier can request only the attributes needed for the transaction. For programmes that still rely on full document capture, the practical shift is to redesign both the decision logic and the evidence retained after verification.
For practitioners
- Map your mDL acceptance boundaries List which issuers, wallets, and verification channels you will support, then define the fallback path for wallets not yet covered.
- Minimise downstream data capture Use selective disclosure to stop collecting full document images when the decision only requires age, identity match, or licence validity.
- Separate credential trust from wallet coverage Document which controls validate the issuer signature, which validate device presentation, and which simply route the user into the right flow.
- Update onboarding and KYC rules Revise policy so digital licences can satisfy identity proofing where legally acceptable, without forcing legacy scan-and-upload steps.
- Test state-by-state acceptance paths Run verification tests across device wallets and state-issued wallet apps so support teams know which combinations succeed in production.
Key takeaways
- Mobile driver's licenses move identity verification toward standards-based credential checks, which changes how onboarding and age assurance flows are designed.
- The adoption challenge is coverage, not the existence of the standard, because wallet and jurisdiction support remain fragmented.
- Teams that support mDLs need explicit fallback paths, data-minimisation rules, and verification logic that can handle selective disclosure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | mDL verification depends on issuer and device-bound authentication of the credential. |
| NHI-02 — Secret Leakage | mDL flows should avoid collecting or retaining full identity data when only a subset is needed. | |
| Recommendation — Verify issuer signatures and device presentation paths before accepting an mDL in production. Reduce document capture and retention to the minimum attributes required for the transaction. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling who can satisfy identity verification conditions and with what credential. |
| Recommendation — Align verification rules to the attributes and assurance level actually required for each journey. | ||
| NIST SP 800-63 | SP 800-63A — Enrollment and Identity Proofing | mDLs are being used directly in identity proofing and onboarding flows. |
| Recommendation — Use mDL acceptance as part of the identity proofing policy for supported journeys. | ||
Key terms
- Mobile Driver's License: A mobile driver's license is a state-issued identity credential stored in a phone wallet instead of a plastic card. It carries digitally signed identity data that a verifier can validate cryptographically, which makes it suitable for remote or in-person proofing when the issuing standard and wallet are supported.
- Selective Disclosure: Selective disclosure is the practice of sharing only the identity attributes needed for a specific decision. In credential-based systems, it reduces oversharing, lowers retention burden, and limits exposure when a verifier does not need the full record to make a trustworthy judgment.
- Wallet Coverage Drift: Wallet coverage drift is the gap between where a credential standard exists and where a business can actually verify it in production. For mDLs, the drift shows up across states, OEM wallets, and state-issued wallets, creating inconsistent customer journeys unless verification policy is designed for partial adoption.
- Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org