Mobile Driver's Licenses and Digital IDs: The Real State of Security, Adoption, and Verification

Trust Swiftly now supports all mobile driver's licenses (mDLs) and digital IDs. Users can present a state-issued credential from Apple Wallet, Google Wallet, Samsung Wallet, or a state wallet app, and we validate it cryptographically against the issuing authority — no photos of plastic cards, no glare, no manual review of hologram placement.

We are genuinely excited about this, and we think every identity team should be paying attention to mDLs. But we have also spent enough time implementing the standards, testing wallets in the wild, and watching how people actually use their phones to know the marketing around digital identity runs well ahead of the reality. So rather than publish another cheerleading post, we want to give the full picture: what the cryptography actually buys you, where the friction and failure modes live, why adoption is still a single-digit story in most states, and why we believe the endgame is hybrid rather than phone-only.

If you read our earlier piece on the downsides to decentralized identity and SSI, consider this the mDL-specific sequel — written now that the standards have matured and we have shipped support ourselves.

From Visual Inspection to Cryptographic Proof

Catching a fake driver's license used to be a physical craft. A verifier tilted the card under light, checked holograms, microprinting, and UV overlays, and made a judgment call. Sophisticated counterfeiters got good enough that a visual check alone stopped being reliable years ago — often the only way to definitively expose a high-quality fake was an authoritative-source lookup, the kind we covered in our guide to AAMVA verification and DMV database checks.

Digital IDs change the question entirely. Instead of asking "does this card look right," the verifier asks "does this data carry a valid signature from the issuing authority." An mDL is signed by the state DMV's issuing certificate, and that signature either validates or it does not. There is no judgment call, no lighting problem, and no such thing as a convincing forgery in the visual sense. The signature check is deterministic math.

That is the single biggest advance in identity documents in decades, and it deserves to be stated plainly before we spend the rest of this article on caveats.

The Standards Behind mDLs: ISO 18013-5 and 18013-7

The mDL ecosystem is built on the ISO/IEC 18013 series, and the two parts that matter for verification are worth understanding even if you never touch the underlying protocol.

In-person presentation: ISO 18013-5

ISO/IEC 18013-5, published in 2021, defines how an mDL is stored on a device and presented face to face. The holder's wallet transmits signed credential data to a verifier's reader over NFC or Bluetooth Low Energy, typically after a QR code or NFC tap establishes the session. The critical design property is that verification works offline: the verifier checks the credential's signature against issuing-authority public keys it already holds, so neither device needs an internet connection at the moment of presentation.

This offline model has a privacy benefit that is easy to miss: the DMV never learns where or when you presented your license. There is no phone-home event on every bar entry or traffic stop.

Remote presentation: ISO 18013-7

The newer ISO/IEC TS 18013-7 extends the same credential to unattended, over-the-internet presentation — proving your identity to a website or app without uploading a photo of a plastic card. The 2025 revision added support for the browser Digital Credentials API, which lets a web page request an mDL and have the operating system broker the presentation from the user's wallet. It leans on OpenID for Verifiable Presentations (OpenID4VP) for the protocol layer, and it is the piece that makes mDLs relevant to online onboarding, account recovery, and age verification rather than just TSA checkpoints.

Supporting all of this correctly is not a weekend project. The stack involves Mobile Security Objects (MSOs), CBOR encoding, session transcripts, ephemeral key agreement, and a public key infrastructure of issuing-authority certificates that must be curated and kept current per jurisdiction. This complexity is a real reason business adoption has lagged — rolling your own verifier is an error-prone undertaking, and a subtle mistake in signature or session-binding validation quietly destroys the security the standard promises. Absorbing that complexity for our customers is exactly why we built the capability into the platform.

Where Digital IDs Genuinely Win

Three advantages stand out from our testing and deployments.

Deterministic authenticity. A cryptographic signature either matches the issuer's key or it does not. Counterfeit detection stops being a probabilistic image-analysis problem and becomes a yes/no answer. For the fraud patterns we see daily — template fakes, altered fields, screenshot replays — this closes a whole category.

Better capture conditions, or rather, none. A surprising share of failed document verifications trace back to the camera: glare, blur, low light, cropped edges. An NFC tap or BLE transfer does not care that the user is standing outside a venue at night. The data arrives perfectly every time, which improves both pass rates and processing speed for legitimate users.

Selective disclosure. An mDL holder can prove they are over 21 without revealing their date of birth, address, or license number. The verifier requests specific claims, and the wallet shows the user exactly what will be shared before they approve. Plastic cards expose everything on their face to anyone who holds them; this is a real privacy improvement with a more complex physical-world equivalent typically involving a finger over a sensitive field or paper to hide information.

The Convenience Paradox: Real-World Friction and Edge Cases

Now the other side of the ledger. In practice, presenting an ID from a phone introduces failure modes that plastic simply does not have.

The unlocked-phone problem

Handing over a physical license is a contained risk — the card proves identity and nothing else. A smartphone is the master key to someone's financial accounts, communications, and digital life. The secure presentation path keeps the phone locked: the wallet releases the credential through a tap while the device stays otherwise sealed. But watch how people actually do it. They unlock the phone fully with PIN or biometrics, open the wallet app, and navigate to the card — at which point a snatch-and-grab theft yields an unlocked device with everything on it. Some credentials are also unavailable until the first PIN unlock after a restart, which nudges users toward exactly the unlocked-in-hand state they should avoid. The technology's threat model and the user's behavior are not the same thing.

Throughput and environmental failures

Proponents lead with speed, but in high-throughput settings a plastic card that displays everything at a glance is often faster than a phone ceremony. Anyone who has watched a traveler wake their screen, re-authenticate, and hunt for the reader's sweet spot at an airport checkpoint has seen digital ID slow a line down. And the physical world intrudes in ways plastic ignores: thick cases and magnetic grip rings interfere with NFC coupling, shattered screens defeat QR scanning, and a wallet mid-update can refuse to present at all.

The dead battery problem, platform by platform

The most cited objection is the simplest: a phone with no power is an identity with no existence. The platforms have addressed this unevenly, and the differences matter if you are designing acceptance workflows:

A verification program that assumes every holder can always present is designing for the best case. The fallback — for dead batteries, broken screens, unsupported devices, and everyone who simply has not enrolled — is the physical credential, and it will be for a long time.

Platform Gatekeeping and Centralization Risk

Moving civic identity onto commercial mobile operating systems concentrates a lot of trust in a small number of companies, and we think the industry is too quiet about it.

Start with access. There is no easy way for an independent business to walk up and accept digital IDs. Apple and Google both gate the entitlements and API access required to request wallet credentials natively, with approval processes that favor large, established verifiers. That gatekeeping pushes everyone else toward aggregator and middleware services — which puts yet another party in the path of identity data. Even when a middleman genuinely never sees the credential claims, the network-level exhaust is unavoidable: IP addresses, device signals, and timestamped verification events accumulate somewhere, and "we don't store the ID data" is not the same as "we learn nothing."

The principle of least privilege cuts against the whole arrangement. A purpose-built identity document exposes identity and nothing more. A multi-purpose, internet-connected device presenting credentials through platform-brokered APIs creates correlation opportunities that a laminated card never could. And there is no structural guarantee the platforms' incentives stay aligned with users — business models change, and aggregated presentation telemetry is exactly the kind of data that eventually looks monetizable.

We have watched this movie before with mobile payments, where platform control over NFC and in-app purchases ultimately drew regulatory intervention in the EU and elsewhere. It would not surprise us if digital identity presentation follows the same arc: genuine innovation from the platforms first, then rules forcing the ecosystem open once the gatekeeping costs become visible.

None of this is a reason to avoid mDLs. It is a reason to keep issuance and acceptance standards-based and vendor-neutral, so no single company owns the rails your customers' identities ride on.

Revocation, Short-Lived Credentials, and the Airplane-Mode Problem

Offline verification creates an obvious question: what happens when a license is suspended or a phone is stolen? In the physical world, a suspended driver is supposed to surrender the card and usually does not. Digital credentials attempt to do better, but the mechanism has sharp edges.

The core defense is credential freshness. The issuing authority signs the mDL's Mobile Security Object with a short validity window — AAMVA's implementation guidance recommends on the order of 30 days — and wallets refresh the credential in the background. A verifier checks freshness at presentation; a stale MSO fails. This bounds the damage: a revoked or stolen credential keeps working offline only until its current signature expires.

Notice what that means in practice. A bad actor who puts an enrolled phone in airplane mode holds a working, cryptographically valid ID until the window closes — the issuer's remote-wipe command never arrives at a device that never connects. Verifiers with higher assurance needs should treat MSO freshness as a risk signal, not just a pass/fail bit, and pair offline checks with online status verification where the standard's mechanisms and jurisdiction support allow it.

The short-window design is also a double-edged sword operationally. Credential refresh depends on the issuer's infrastructure staying up and the holder's device periodically reaching it. A prolonged DMV outage, or a holder spending weeks somewhere without connectivity, produces expired credentials for entirely legitimate users. Plastic does not have an uptime dependency.

Social Engineering: The Attack That Ignores the Cryptography

Here is the uncomfortable truth about mDL fraud: nobody is forging these credentials, and nobody needs to.

The cryptography is genuinely strong. Keys live in hardware-backed secure enclaves, signatures use elliptic-curve algorithms that are not practically forgeable, and there is no fake-mDL printing industry the way there is a fake-card industry. So attackers do what attackers always do — they route around the strongest control and attack the human.

The play is fraudulent provisioning: trick a legitimate person into enrolling their real license into a wallet the attacker controls, or walk a victim through "identity confirmation" steps that are actually the enrollment flow on the attacker's device. The victim supplies genuine documents and genuine biometrics, the issuance checks pass because everything presented is authentic, and the attacker ends up holding a mathematically perfect, state-signed digital identity belonging to someone else. Every subsequent verification of that credential will succeed, because the credential is real.

This is the same family of manipulation driving the account-takeover surge we track across our customer base, and the same pretexts work: fake bank fraud departments, fake employer onboarding, fake government agencies. The industry's deepfake problem compounds it — if remote issuance relies on a selfie match and liveness check, the same injection and deepfake tooling used against onboarding flows gets aimed at provisioning. We wrote about where that arms race is heading in countering AI-generated attacks, and mDL issuance is now squarely inside the blast radius.

The lesson for relying parties: a valid mDL proves the credential is genuine and unexpired. It does not prove the person holding the phone is its rightful subject, and it does not prove issuance happened to the right person. High-assurance flows should still bind the presenter to the credential — compare the mDL's signed portrait against a live, liveness-checked capture — rather than treating signature validation as the whole job.

Adoption Is Still Early — and Skewed

The numbers deserve honesty, because vendor marketing routinely implies mDLs are further along than they are.

As of early 2026, roughly 21 states plus Puerto Rico issue mDLs that TSA accepts at checkpoints, and wallet coverage is fragmented — about 15 states support Apple Wallet, 11 Google Wallet, and 9 Samsung Wallet, with a dozen more relying on standalone state apps. Offering is not using: across states with live programs, only around 4.5 million of 71.5 million licensed drivers have actually enrolled. That is single-digit adoption almost everywhere. Arizona is the standout at roughly a quarter of its drivers; most states with programs sit far below that.

The demographics skew exactly the way you would expect — early adopters with recent flagship hardware, comfortable with wallet apps and NFC. Any acceptance strategy built on the assumption that a general population can present digitally will exclude people on the wrong side of device cost, technical comfort, or simple preference. That is not a knock on the technology; it is a deployment reality that argues for digital ID as an additional method, not a replacement gate.

One more adoption note that gets little attention: the push toward fully remote, digital-only issuance quietly removes controls that mattered. Mailing a physical card to a verified residential address is a proofing event — it confirms a real-world delivery point and creates a paper trail. Issuance flows that never touch the physical world lean entirely on remote document and biometric checks at exactly the moment deepfakes are making those checks harder to trust. DMVs should keep a physical anchor in the issuance loop even as presentation goes digital.

The Missing Middle: Smart Physical IDs

There is a glaring omission in the current roadmap, and it is the card itself.

The friction, battery dependency, and platform gatekeeping problems above all share a root cause: we decided the only way to get cryptographic identity was to put it in a smartphone. But the payments industry solved this differently decades ago — EMV chips brought cryptographic verification to a passive plastic card, powered entirely by the reader. ePassports have done the same for border documents since the 2000s, with secure contactless chips that have proven durable, clonable-in-theory-only, and interoperable worldwide. The technology to make a driver's license cryptographically verifiable without a phone exists, is cheap, and was largely skipped.

Modern secure microcontrollers built for identity documents — the same class of chip used in ePassports and eID cards, with certified secure elements, hardened JavaCard operating systems, and physical unclonable functions that give each chip an unforgeable silicon fingerprint — can execute the full cryptographic ceremony in a second or two on harvested NFC power. A polycarbonate license with such a chip delivers the same deterministic, signature-based proof as an Apple Wallet mDL with no battery, no platform gatekeeper, no telemetry, and no five-hour reserve window.

We are not arguing against mDLs — we just shipped support for them. We are arguing that the issuance side of the ecosystem is leaving its best fallback on the table. A smart physical card and a wallet mDL sharing one PKI is a far more resilient system than a wallet mDL backed by a card that can only be checked by eyeball.

What Verifiers Need at the Door

A practical question we get from customers planning in-person acceptance: what hardware does this actually take?

Less than you might think, and it is getting cheaper:

• Software-upgraded existing readers. SDKs can turn NFC-capable readers and even camera-based barcode scanners already deployed at a counter into standards-compliant mDL verifiers, handling QR engagement and BLE data transfer without new terminals.
• Dedicated hybrid terminals. Purpose-built USB devices in the few-hundred-dollar range read NFC, QR, and BLE presentations, and suit high-throughput lanes where the reader runs all day.
• A phone as the reader. A standard smartphone's NFC antenna and camera are enough to act as the verifier side of an 18013-5 session, which is how mobile verifier apps for law enforcement and field use work.

The encouraging part is that the same reader infrastructure that accepts a wallet mDL over NFC can, with the right software, also read a chip-equipped physical credential. Verifier hardware is not the bottleneck; issuance and adoption are.

How Trust Swiftly Verifies mDLs and Digital IDs

Our digital ID method treats the credential's cryptography as the starting point, not the finish line. A presentation to Trust Swiftly runs through the full chain:

1. Signature and trust chain validation. We verify the credential's issuer signature against curated issuing-authority (IACA) certificates for each participating jurisdiction, sourced from published trust lists, so a self-signed or wrong-issuer credential fails immediately.
2. Freshness and revocation. We check the Mobile Security Object's validity window and issuer revocation status rather than accepting any credential that merely parses.
3. Holder binding. For higher-assurance workflows, the signed portrait inside the credential is compared against a live, liveness-checked selfie — closing the fraudulent-provisioning and borrowed-phone gaps described above.
4. Audit evidence. Verification results, disclosed claims, and supporting evidence are retained in an audit-ready record, consistent with the rest of our verification methods.

For remote flows, users present their wallet credential in the browser through the Digital Credentials API path defined by ISO 18013-7 — no app install, no photographing a card. And because no single method fits every user, digital ID slots into the same configurable flows as our document, biometric, phone, and database checks, so the majority of users who do not yet carry an mDL fall back to strong alternatives instead of a dead end.

Integration is the same as any other Trust Swiftly method:

• REST API and webhooks for teams that want programmatic control — create a user, receive a magic link, get a webhook when verification completes. Typical setup runs a few days.
• No-code magic links for immediate use — share a hosted verification link over email, SMS, or chat and manage results from the dashboard, live in minutes.

Where This Leaves Us

Mobile driver's licenses are the most significant upgrade to identity documents since the photograph. Deterministic, signature-based authenticity ends the counterfeit arms race for anyone equipped to check it, and selective disclosure gives users privacy that plastic can never offer. We support them, we verify them, and we expect their role to keep growing.

But the honest assessment is that mDLs today are one strong method inside a layered program, not a replacement for one. Adoption is single-digit in most states. The battery, hardware, and behavioral edge cases are real. Platform gatekeeping deserves scrutiny before civic identity gets locked into two app stores. And the dominant fraud vector — social engineering the human — passes straight through the cryptography, which is why holder binding and layered signals still matter even when the math checks out.

The pragmatic strategy is hybrid: accept digital credentials where they raise assurance and cut friction, keep robust physical and biometric paths for everyone else, and push the ecosystem toward chip-equipped physical cards that extend cryptographic verification to holders without a compatible phone. That is the posture we have built into the platform, and it is the one we would recommend to any identity team evaluating mDLs this year.

Frequently Asked Questions

Does a valid mDL prove the person presenting it is the credential's owner?

No. Signature validation proves the credential is genuine, unaltered, and unexpired. It does not prove rightful possession — a fraudulently provisioned or borrowed credential validates identically. Binding the presenter to the credential requires comparing the signed portrait to a live capture or an equivalent control.

Can mDLs be verified without an internet connection?

Yes. ISO 18013-5 is designed for offline verification: the reader validates the credential's signature against issuing-authority public keys it already holds. The trade-off is that offline verifiers rely on the credential's built-in freshness window to catch revocations, so recently revoked credentials can validate offline until their current signature expires.

Which wallets can Trust Swiftly verify?

State-issued credentials presented from Apple Wallet, Google Wallet, and Samsung Wallet, along with ISO-compliant state wallet apps, presented in person via NFC/BLE readers or remotely in the browser through the ISO 18013-7 Digital Credentials API flow.

Are fake mobile driver's licenses a real problem?

Forged mDLs are not — the cryptography makes traditional counterfeiting impractical. The real risks are fraudulent provisioning (a genuine credential issued to or enrolled by the wrong person) and presentation of stolen devices, which is why issuance security and holder binding matter more than forgery detection in the mDL era.

Should we drop document photo verification once we accept mDLs?

Not yet. Enrollment across states with live mDL programs is still a small fraction of licensed drivers, and coverage varies by state and wallet. Digital ID works best as a fast path for enrolled users, with document, biometric, and database checks remaining for everyone else.

References

• ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application
• ISO/IEC TS 18013-7:2025 — mDL add-on functions (internet presentation)
• AAMVA — Mobile Driver's License implementation resources
• AAMVA special alert — ISO publishes mDL over-the-internet standard
• Government Technology — Where Are Mobile Driver's Licenses Taking Off? A Data Dive
• NIST SP 800-63A-4 — Identity Proofing and Enrollment