mDLs are best treated as a proofing mechanism, not as everyday sign-in on their own. Once trust is established, organisations can provision a separate stronger authenticator such as passkeys for routine access. That keeps high-assurance identity verification distinct from ongoing authentication.
Why This Matters for Security Teams
mDLs fit awkwardly into passwordless programs because they solve a different problem: high-assurance identity proofing, not everyday authentication. A mobile driver’s licence can help an organisation verify that a person is who they claim to be during onboarding, account recovery, or step-up verification. It should not be confused with the ongoing authenticator that proves a user session later. That distinction matters because passwordless security depends on binding access to a durable authenticator, not repeating identity checks every time.
Security teams often get into trouble when they treat proofing evidence as if it were a login credential. Current guidance suggests separating identity proofing from authentication so that the access model remains consistent after the initial trust decision. NIST’s passwordless and identity guidance aligns with this separation, and the broader control model in the NIST Cybersecurity Framework 2.0 reinforces the need for clear access governance.
For NHI Management Group, the core issue is lifecycle: once a person or workload is trusted, the organisation still needs a resilient authenticator, a revocation path, and visibility into what was issued. That is why the Ultimate Guide to NHIs treats secrets, tokens, and credentials as governed assets rather than one-time proof points. In practice, many security teams encounter access sprawl only after proofing has been completed and no durable authentication design was put in place.
How It Works in Practice
The cleanest pattern is to use the mDL as an initial assurance signal, then issue a separate passwordless authenticator for routine access. That authenticator is usually a passkey or other phishing-resistant method tied to the user’s device and cryptographic keys. The mDL helps answer, “Should this account be created or recovered?” while the passkey answers, “Is this the same trusted user returning now?” Those are different security decisions, and combining them into one step usually creates weak policy and brittle user journeys.
In practice, organisations should define the trust workflow as follows:
- Use mDL verification during onboarding, recovery, or identity re-binding.
- Provision a separate authenticator for ongoing sign-in, preferably phishing-resistant and bound to the user’s device.
- Set explicit assurance rules for when an mDL is sufficient and when additional step-up verification is required.
- Log the proofing event separately from the authentication event so audits can distinguish initial identity vetting from session access.
This separation also reduces credential handling risk. The moment an organisation reuses proofing artifacts as login secrets, it creates a longer-lived trust token that is harder to revoke and easier to misuse. The NHI security baseline in the Ultimate Guide to NHIs is useful here because it emphasizes lifecycle control, visibility, and revocation discipline across all identities and secrets. For implementation guidance, the NIST Cybersecurity Framework 2.0 is a practical anchor for defining authentication, recovery, and monitoring responsibilities.
Where this breaks down is in environments that have no identity governance layer and try to use mDLs as a universal login substitute across consumer apps, internal portals, and regulated workflows, because assurance requirements and recovery controls vary too much across those contexts.
Common Variations and Edge Cases
Tighter proofing often increases user friction and operational overhead, so organisations need to balance stronger identity assurance against recovery complexity and support cost. That tradeoff is especially visible when mDL issuance coverage is uneven, when users carry multiple devices, or when legal and regional acceptance rules differ.
There is no universal standard for this yet. Best practice is evolving around three common patterns: mDL for proofing only, mDL plus passkey for passwordless sign-in, and mDL for high-risk step-up verification. The right choice depends on whether the organisation needs onboarding assurance, identity recovery, or continuous authentication. A government service may accept mDL for account creation but still require passkeys for future access. A financial or healthcare workflow may require stricter step-up checks before a passkey is re-bound.
One practical edge case is account recovery after device loss. If the mDL is treated as the only trust anchor, recovery becomes fragile when the card, wallet app, or issuer availability changes. Another edge case is shared service desks, where staff may be tempted to “verify once and reuse later.” That creates policy drift. The safer model is to treat the mDL as a high-confidence signal for one-time proofing and then rely on separate authentication factors for ongoing access. That distinction is consistent with the identity lifecycle and revocation focus in Ultimate Guide to NHIs.
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 NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | mDLs affect how identity is verified before access is granted. |
| NIST SP 800-63 | Digital identity guidance covers assurance, proofing, and authenticator binding. | |
| NIST AI RMF | GOVERN-1 | Identity decisions need defined governance and accountability. |
Use mDLs for identity proofing, then bind a phishing-resistant authenticator for ongoing sign-in.
