Mobile driver’s licenses are changing identity verification flows

At a glance

What this is: This is an analysis of the rise of mobile driver’s licenses and how standards-based mDLs change identity verification, data sharing, and onboarding flows.

Why it matters: It matters because IAM, KYC, and compliance teams need to treat mDL support as a workflow and policy problem, not just a new credential format, or they will build brittle identity checks that do not scale across wallets and jurisdictions.

By the numbers:

• As of July 2026, 21 states plus Puerto Rico issue a standards-based mDL, according to the American Association of Motor Vehicle Administrators.
• TSA accepts mDLs at more than 250 airport checkpoints.

👉 Read Incode's analysis of mobile driver’s license adoption and verification

Context

Mobile driver’s licenses are digital versions of state-issued IDs stored in a phone wallet, and they matter because they change how identity is presented, verified, and shared. For IAM and KYC teams, the core shift is that verification is increasingly standards-based, device-mediated, and selective rather than a simple image capture of a plastic card.

The governance gap is not the credential itself but the operating model around it. Coverage is fragmented across device wallets and state-issued apps, which means identity programmes must plan for inconsistent adoption, different presentation paths, and a growing need to map verification policy to wallet capability.

For security teams, this is a human identity problem with NHI-style control implications: the organisation must trust cryptographic assertions, device binding, and downstream policy enforcement at the same time. That makes mDL support a workflow design issue, not just a new identity document type.

Key questions

Q: How should security teams support mobile driver’s licenses in identity verification flows?

A: They should treat mDL support as a standards and policy integration task, not a wallet-specific exception. The key decisions are which states, wallets, and channels are accepted, what attributes are needed for each use case, and how the verification result flows into onboarding, risk, and audit systems without extra data capture.

Q: Why do mobile driver’s licenses change identity governance requirements?

A: They change governance because the credential itself can prove authenticity while also reducing the amount of data that needs to move through the business. That shifts control design toward selective disclosure, channel-specific acceptance rules, and retention discipline for verification evidence.

Q: What do organisations get wrong about mDL adoption?

A: The most common mistake is assuming one wallet or one implementation path will cover all users. In reality, adoption is fragmented across states, device wallets, and state-issued apps, so programmes that do not plan for variability create inconsistent assurance and unnecessary user friction.

Q: How do mDLs fit into existing onboarding and compliance processes?

A: They fit as a verification input inside the existing workflow, not as a separate process outside it. Organisations should route the result into the same onboarding, fraud, and compliance logic they already use, while reducing the amount of personal data captured and stored.

Technical breakdown

How mDL standards change identity verification

A mobile driver’s license is not just a digital picture of a card. It is a signed credential defined by ISO/IEC 18013-5 for in-person presentation and ISO/IEC 18013-7 for remote use. The verifier checks the issuer’s signature and the device presentation path, which means authenticity is established cryptographically rather than visually. That model is stronger than manual document inspection because it reduces editability, replay risk, and inconsistent human review. It also makes the verification logic more portable across wallets, because the credential format is standardised even when the wallet implementation differs.

Practical implication: design verification flows around standards compliance and signature validation, not around the look and feel of a wallet app.

Selective disclosure and data minimisation in mDL workflows

Selective disclosure lets a verifier request only the attributes needed for a specific check, such as confirming age without collecting address, document number, or date of birth. That changes the identity governance posture because the organisation no longer needs to store or process more identity data than the transaction requires. In practice, this aligns with data minimisation principles and reduces the amount of regulated personal data entering downstream systems. It also changes fraud and compliance design, because control logic must decide which fields are required for which use case and which fields should never be retained after verification.

Practical implication: map each verification step to the minimum attribute set required and avoid persisting unnecessary identity data.

Wallet fragmentation and online verification paths

The operational challenge is not mDL support in theory, but the reality that different wallets support different states and different presentation methods. Some wallets work through device-native approaches, others through state-issued apps, and online verification may follow separate standards from in-person checks. That creates policy fragmentation, because a business may accept one wallet in one flow and a different wallet in another, while still needing one consistent trust decision. Identity teams therefore need an orchestration layer that can route by wallet capability, channel, and jurisdiction without breaking the downstream result format.

Practical implication: build policy routing for wallet, channel, and state coverage rather than assuming one verification method fits all users.

NHI Mgmt Group analysis

mDL adoption is turning identity verification into a standards-orchestration problem. The issue is no longer whether a state-issued digital ID can be verified, but whether the enterprise can accept it consistently across wallets, channels, and jurisdictions. That makes the control plane, not the credential format, the real governance surface. Practitioners should treat mDL support as an integration and policy design decision, not a point capability.

Selective disclosure creates a new identity governance baseline for human verification. Traditional onboarding patterns collect more data than the transaction needs, then rely on retention and access controls to manage the risk. mDLs invert that pattern by making minimal disclosure native to the credential flow. The implication is that data minimisation can move upstream into the verification event itself, which changes how IAM, KYC, and privacy teams define acceptable collection.

Wallet fragmentation will expose brittle identity programmes faster than user demand will. A business that hardcodes support for one wallet or one state will quickly create inconsistent user journeys and uneven assurance. This is especially visible where identity verification is tied to regulated decisions such as age checks, account opening, or travel screening. The mDL market is moving toward a portability test, and practitioners should expect policy inconsistency to become a service issue, not just a technical one.

Mobile identity verification is now part of broader identity lifecycle governance. mDLs do not remove the need for downstream verification logic, they shift where trust is established and what data is available for review. That means IAM and compliance teams need to align wallet acceptance, channel policy, and evidence retention with the same discipline they already apply to other identity signals. The next phase is governance of the verification flow, not just support for the credential.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That same control gap is why our Ultimate Guide to NHIs treats lifecycle visibility and revocation as operational controls, not paperwork.

What this signals

Selective disclosure: mDLs push identity teams toward a model where the verifier asks for less and proves more. That is a useful precedent for broader IAM and privacy programmes, because reducing data collection at the point of verification lowers downstream exposure without weakening assurance.

The operational test is whether your identity flow can accept a standards-based result and still preserve policy, auditability, and user experience. If it cannot, the problem is not mDL adoption itself, but an onboarding architecture that assumes every identity proof arrives as a scanned document.

For practitioners managing high-volume verification, the next step is to align wallet coverage, retention policy, and downstream decisioning to the same control framework. That is where mDLs stop being a feature request and become a governance design choice.

For practitioners

• Inventory wallet and jurisdiction support Map which states and wallet providers are supported in each verification flow, then identify where coverage gaps will affect onboarding, age assurance, or account opening. Use that inventory to decide where fallback document checks are still required.
• Define attribute-level verification policy Specify which mDL fields are allowed for each use case, which ones are required, and which must never be retained after verification. Tie those rules to business purpose so selective disclosure becomes a control, not just a feature.
• Validate downstream system handling Test how identity, fraud, and compliance systems consume a standards-based result rather than a photographed document image. Ensure the same result format can flow into onboarding, risk scoring, and audit logging without custom exceptions.
• Revisit data retention for identity evidence Review whether existing retention practices assume full document capture when the transaction only needs a yes-or-no assertion or a small attribute set. Reduce stored data where the verification purpose does not justify broader collection.

Key takeaways

• Mobile driver’s licenses are shifting identity verification from image-based review to standards-based cryptographic proof.
• The biggest implementation risk is fragmented wallet and jurisdiction coverage, not credential authenticity.
• Teams should govern mDLs as a policy and workflow problem, with selective disclosure and retention discipline built in.

Key terms

• Mobile Driver's License: A mobile driver’s license is a state-issued identity credential stored on a phone and presented digitally instead of as a plastic card. It is cryptographically signed by the issuing authority, which lets a verifier confirm authenticity without relying on a photo or manual inspection.
• Selective Disclosure: Selective disclosure is the ability to reveal only the identity attributes required for a specific transaction. In mDL workflows, that means a verifier can confirm age, licence status, or other fields without collecting unnecessary personal data, which reduces privacy exposure and downstream retention risk.
• Identity Orchestration: Identity orchestration is the coordination of multiple identity signals, checks, and policy decisions inside one verification flow. For mDLs, it means routing wallet, channel, and jurisdiction results into onboarding, fraud, and compliance logic without fragmenting the assurance model.

What's in the full article

Incode's full article covers the operational detail this post intentionally leaves for the source:

• Wallet-by-wallet support details for Apple Wallet, Google Wallet, Samsung Wallet, and the CA DMV Wallet
• The standards path for in-person versus remote mDL verification, including how the credential travels across channels
• Field-level handling of license class, restrictions, endorsements, and revocation states
• How Incode says mDL verification flows into its broader identity orchestration and decisioning process

👉 The full Incode article covers standards, wallet coverage, and the identity fields mDLs can return.

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 building or maturing an IAM or identity governance programme, it is worth exploring.