A Mobile Driving Licence (mDL) is a driving licence issued as a digital credential on a phone or other device. It lets a holder present only selected attributes to a verifier, while defenders need to check issuer trust, device binding, revocation status, and phishing-resistant presentation flows.
What a Mobile Driving Licence represents
A Mobile Driving Licence (mDL) is not just a digital image of a card. It is a digitally issued credential designed to support selective disclosure, so the holder can present only the attributes a verifier actually needs, rather than the full licence record.
That distinction matters because the security model is built around issuer trust, device binding, revocation awareness, and controlled presentation flows. An mDL therefore behaves like a governed digital identity credential, not a simple app feature or document scan.
How mDL presentation works
In practice, the holder uses a wallet or device interface to share a claim set with a verifier. The verifier must be able to trust that the credential came from the correct issuing authority, that the presentation is bound to the intended device, and that the interaction has not been downgraded into a copyable or replayable flow.
That is why standards-based mDL implementations usually distinguish between issuance, storage, presentation, and verification. The presentation step is where privacy is strongest when the flow is correctly designed, because the verifier receives only what is needed for the transaction.
For a broader explanation of how mDLs sit alongside digital identity wallets, see the Digital Identity, eID and Identity Wallets Guide.
Trust, privacy, and interoperability requirements
The practical value of an mDL depends on whether verifiers can establish trust in the issuer, validate the credential structure, and process the presentation in a way that preserves privacy. If any of those steps is weak, the mDL may still exist on a phone, but it will not function as a dependable identity instrument.
Interoperability is equally important. mDL ecosystems have to work across issuers, wallets, readers, and relying parties without turning every implementation into a one-off integration. That is why standards such as ISO 18013 and related verifier profiles matter so much to real-world adoption.
The operational mechanics, including reader authentication, device engagement, and online or proximity presentation patterns, are covered in the Mobile Driving Licence (mDL) Guide.
Why mDLs change security and identity handling
An mDL changes the security conversation because the verifier is no longer checking only a physical artefact. It is also depending on cryptographic trust, device posture, presentation integrity, and the lifecycle state of the credential itself.
That creates a tighter link between identity assurance and endpoint trust than many organisations expect. A lost, cloned, or fraudulently presented device can undermine the transaction even when the underlying issuance was legitimate, so the control surface extends beyond the wallet UI into revocation, binding, and anti-phishing design.
mDL programmes also force organisations to think carefully about what data they really need. Selective disclosure reduces unnecessary exposure, but only if the verifier system is built to accept minimal attributes and resist collecting more than the transaction requires.
For adjacent privacy and credential-leakage concerns in mobile environments, the iOS apps leaking hard-coded secrets article is a useful reminder that mobile trust failures often start with poor implementation, not with the credential format itself.
Risk and Threat Considerations
mDL risk concentrates around trust abuse, presentation fraud, and privacy leakage. If an attacker can intercept, replay, socially engineer, or coerce a weak verification flow, the organisation may accept a credential presentation that looks valid but does not represent the intended holder or the intended set of attributes.
Failure mechanism: Weak issuer validation, poor device binding, or a non-phishing-resistant verifier flow can let a fraudulent presentation succeed, or allow excessive data collection that defeats selective disclosure.
Impact: The result can be identity fraud, unauthorized access to a service, loss of privacy, and a false sense of assurance that the organisation verified a person when it actually verified only a copyable or manipulated presentation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | mDL assurance depends on phishing-resistant digital identity and verifier trust. |
| Recommendation — Align mDL verification with phishing-resistant authentication and issuer trust requirements. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | mDL verification relies on authenticated presentation exchanges and trusted digital credentials. |
| Recommendation — Use IA-9 to validate verifier and credential presentation trust paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | mDL use governs access decisions based on trusted digital identity assertions. |
| Recommendation — Define access decisions that accept only trusted mDL-based assertions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | mDL verifier flows can fail when authentication and presentation checks are weak. |
| Recommendation — Harden verifier endpoints against broken authentication and replay-style abuse. | ||
Practitioner Guidance
Why practitioners should care: mDL is only as strong as the verification workflow around it. Teams should treat issuer trust, revocation checking, and presentation design as first-class control decisions, not as implementation details left to the wallet vendor.
What to watch for: Any verifier process that accepts screenshots, unsupported manual checks, or overly broad data requests is weakening the mDL model. The safest deployments keep the transaction narrow, the presentation phishing-resistant, and the data request minimal.
Practitioner takeaway: An mDL programme succeeds when the organisation governs trust, not just technology, because the credential format alone does not guarantee trustworthy identity proofing.
Related resources from NHI Mgmt Group
- What is the difference between proving age with a digital ID and using a physical passport or driving licence?
- How should banks govern mobile driver's licence acceptance in KYC flows?
- What are the signs that a mobile loyalty program is actually driving revenue instead of just engagement?
- What are the signs that a mobile driver’s licence programme is not ready for broad adoption?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org