Organisations implement an mDL by defining which journeys will accept it, then integrating an identity verification flow that checks issuer trust, document validity, holder control, and transaction binding. They also need status checking, consented attribute requests, fallback paths for non-mobile users, and clear controls for retention, logging, and fraud review.
What organisations actually need to decide before accepting mDL
An mDL rollout is not just a technical integration. Organisations need a policy decision on where the credential fits in the customer journey, whether it is accepted as a standalone proof or only as one signal in a broader verification flow, and which assurance level is acceptable for each use case. That choice determines whether the implementation is a convenience feature, a regulated identity check, or both.
The practical implementation question is usually less about reading the credential and more about trust establishment. The relying party must be able to validate the issuer, verify the document has not been altered, and make sure the presentation is bound to the live holder and the current transaction. Mobile Driving Licence (mDL) Guide is the best starting point for the protocol and interoperability pieces, while the broader wallet model is explained in the Digital Identity, eID and Identity Wallets Guide.
That also means organisations must separate acceptance policy from technical support policy. If the journey cannot support NFC, QR, camera-based capture, wallet presence, or network conditions reliably, then the fallback path is part of the design, not an exception to fix later.
How the verification flow is typically implemented
A workable mDL flow usually starts with a request for only the attributes needed for the transaction. The verifier asks for the minimum data set, the wallet presents the credential, and the system validates issuer trust, status, and the presentation context before a decision is made. In practice, this is a trust-and-transaction workflow, not a static document check.
Organisations also need to decide where to perform status checking and how to handle freshness. If revocation, suspension, or document state cannot be checked reliably at the point of use, the acceptance policy should define whether the transaction is blocked, downgraded, or queued for manual review. That is especially important when the mDL is being used for higher-risk journeys such as age assurance, onboarding, or regulated access.
Implementation normally depends on the organisation’s existing identity stack. The verifier may need to align the mDL flow with customer identity proofing, fraud signals, audit logging, and consent handling. Where the platform already has strong API and session controls, the mDL layer should inherit those controls rather than create a parallel trust island. For control mapping and implementation patterns, the ISO/IEC 27002:2022 Information Security Controls and the NIST SP 800-53 Rev 5 Security and Privacy Controls are useful references for access control, logging, and configuration discipline.
Where mDL programmes tend to fail in practice
The most common failure is treating mDL as a one-time document scan rather than a governed identity transaction. If the organisation does not define which attributes are needed, what proof standard is acceptable, and what evidence must be retained, the result is inconsistent customer treatment and weak defensibility after an incident or complaint. Logging must be sufficient to explain the decision without storing more personal data than the use case requires.
Another weak point is overreliance on the wallet alone. A valid-looking presentation does not remove the need to check transaction binding, issuer authenticity, and whether the device interaction was actually with the intended holder. Fraud teams should know what abnormal presentation patterns look like, especially where the same credential is used repeatedly across unusual journeys or channels.
Privacy design also matters. Attribute minimisation, consented disclosure, and retention limits are not optional polish; they are part of whether the deployment is credible. If the organisation asks for more data than the journey requires, or keeps it longer than necessary, the mDL programme can create avoidable privacy and governance exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | mDL verification depends on authenticated access decisions and identity assurance. |
| AU-2 — Audit Events | mDL journeys need auditable evidence of presentation, acceptance, and review decisions. | |
| AC-6 — Least Privilege | mDL flows should request only the minimum attributes needed for each journey. | |
| Recommendation — Apply IA-2 to verify user identity before granting access or completing the transaction. Define audit events that record mDL presentation, verification outcome, and exception handling. Limit each mDL request to the minimum attributes required for the transaction. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | mDL acceptance is an access decision with policy and entitlement implications. |
| A.8.24 — Use of cryptography | mDL relies on cryptographic assurance for issuer trust and presentation integrity. | |
| Recommendation — Define access rules for when an mDL is sufficient evidence for a journey. Protect mDL verification data and trust material with appropriate cryptographic controls. | ||
Practitioner Guidance
What to verify: Confirm that each accepted journey has a written acceptance policy, a minimum attribute set, and a defined fallback for users who cannot present an mDL. If those three things are missing, the implementation is still a pilot, even if the wallet integration works.
Decision rule: If the use case affects onboarding, age assurance, or regulated access, treat issuer trust, status freshness, and transaction binding as gating checks rather than nice-to-have signals. If any of those checks cannot be performed, fall back to an alternative verification route.
What good looks like: The organisation can explain why it accepted or rejected an mDL presentation, what it retained, and how it limited the request to the minimum necessary attributes. That is the practical test of a mature deployment, not simply whether the QR code or wallet interaction succeeds.
Practitioner takeaway: Successful mDL implementation is mostly a policy and control design problem, with technology supporting a decision process that must stay minimal, verifiable, and defensible.