No. mDLs are better used as a higher-assurance verification method, while passkeys or similar methods remain more suitable for routine authentication. Mixing the two creates control confusion and can weaken the separation between identity proofing and session access.
Why This Matters for Security Teams
Mobile driver’s licenses can raise the assurance of who someone is, but they do not replace the need for a separate session authenticator. For institutions, the operational risk is control confusion: if the same credential is used to prove identity and to unlock ongoing access, teams lose a clean boundary between proofing, authentication, and privilege decisions. That creates weaker revocation logic, muddier audit trails, and more complicated user recovery.
Security teams also need to avoid overreading what an mDL actually proves. An mDL can support identity verification at onboarding, recovery, or step-up checks, but it does not by itself provide the ergonomic, repeatable, phishing-resistant login flow that passkeys are designed to deliver. ISO/IEC 27001:2022 Information Security Management is useful here because it separates access control, authentication, and privileged access as distinct control concerns, which is exactly the discipline this decision needs. In practice, many institutions only notice the difference after help desk recovery or account takeover paths have already become harder to govern.
How It Works in Practice
The cleanest model is to treat mDLs as a higher-assurance identity proofing signal and passkeys as the routine authenticator for day-to-day access. That means the mDL is used when the institution needs stronger confidence about the person, such as remote onboarding, age or eligibility checks, customer recovery, or high-risk step-up verification. The passkey then handles repeated logins, because it is tied to the session and the device in a way that is better suited to frequent authentication.
This separation matters because the two functions have different failure modes. Identity proofing is about whether the person is who they claim to be. Authentication is about whether the current claimant can re-enter an already established trust relationship. When institutions blur those tasks, they often create brittle workflows where a lost phone, a revoked licence, a device change, or a recovery event becomes a full trust reset.
- Use mDLs where the institution needs a stronger verification event, not as the everyday login factor.
- Use passkeys for normal access because they are designed for repeated, phishing-resistant authentication.
- Keep revocation and recovery paths separate so a change in identity evidence does not automatically break all session access.
- Retain an auditable record of when identity was proven versus when a session was authenticated.
OWASP Cheat Sheet Series is a useful implementation reference for keeping authentication and session management separate in practice. These controls tend to break down when institutions try to make one credential cover both regulated identity proofing and frictionless login, because recovery, revocation, and support processes no longer map cleanly to a single trust event.
Common Variations and Edge Cases
Tighter identity assurance often increases user friction and operational overhead, so institutions have to balance proofing strength against login simplicity. That trade-off becomes more visible in regulated onboarding, remote support, and recovery scenarios, where the strongest identity check is not always the best everyday authenticator.
There are edge cases where an mDL can participate in access decisions, but those cases should be narrow and deliberate. For example, an institution might use an mDL to re-verify a customer after account recovery, or to satisfy a specific compliance or eligibility requirement before permitting access to a sensitive service. That is different from making the mDL the primary mechanism for every login.
Current guidance suggests that institutions should preserve a layered model: proofing evidence, authenticator strength, and access policy should remain separable even if they are part of the same customer journey. The main exception is when the service is not really about routine authentication at all, but about a one-time verification workflow, such as regulated onboarding or age-gated access. In those cases, the mDL can be central to the decision without replacing the login stack.
What practitioners often underestimate is the recovery path, not the happy path. A design that works cleanly for the first login can become brittle when a device is replaced, a licence is updated, or a support desk must re-establish trust without opening a takeover route.
Risk and Threat Considerations
The main risk is trust-boundary collapse. If institutions treat mDLs as both identity proofing and session authentication, a compromise or failure in one control can spill into the other, expanding blast radius and making revocation slower and less precise.
Failure mechanism: An attacker, fraudulent claimant, or confused support workflow can exploit a merged design by using a stronger identity event to gain lasting session access, or by forcing a recovery path that is weaker than the login path. That creates opportunities for account takeover, bypassed step-up checks, and poor auditability around who was verified versus who was merely allowed back in.
Impact: Institutions can lose clear evidence of assurance, weaken incident response, and create support processes that are easier to abuse than the login flow they were meant to protect. Over time, the result is more difficult revocation, more ambiguous disputes, and higher exposure to fraud and unauthorized access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | A.5.7 — Threat Intelligence for AI Systems | Identity proofing and authentication workflows need clear trust boundaries and misuse awareness. |
| Recommendation — Define distinct proofing and login controls for each trust event. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The question hinges on separating proofed identity from routine access decisions. |
| Recommendation — Separate identity verification from session access and revocation paths. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | mDLs fit identity proofing, which is distinct from ongoing authentication assurance. |
| AAL — Authenticator Assurance Level | Passkeys align to authentication assurance for routine login. | |
| Recommendation — Use higher-assurance proofing only where the trust decision requires it. Use phishing-resistant authenticators for repeated sign-in. | ||
| CIS Controls v8 | 6 — Access Control Management | Institutions need separate control of verification, login, and revocation. |
| 8 — Audit Log Management | The answer depends on distinguishing proofing events from authentication events. | |
| Recommendation — Enforce least-privilege access and keep recovery separate from login. Log proofing and authentication as separate events for auditability. | ||
Practitioner Guidance
What to prioritise: Preserve the distinction between proofing and authentication in policy, user journeys, and logging. If a control answers “who is this person?”, do not also make it carry routine session access.
Decision rule: If the workflow is repeated access, choose passkeys or an equivalent authenticator. If the workflow is onboarding, recovery, eligibility, or step-up verification, mDLs can add value without becoming the primary login mechanism.
What good looks like: Support staff can revoke access, re-verify identity, and audit login events independently, with no single credential deciding all three outcomes.
Practitioner takeaway: The safest design is the one that keeps identity evidence strong, authentication simple, and recovery separately governable.
