Use passkeys for everyday authentication and reserve mDL verification for higher-assurance events. The two controls solve different problems: passkeys reduce friction for routine access, while mDLs provide stronger evidence when the organisation needs to re-establish trust or confirm identity for a higher-risk decision.
How to choose the control based on the trust decision
Decide by the decision you are trying to make, not by the technology stack. Passkeys are the everyday sign-in control: they are designed to authenticate a returning user with phishing-resistant credentials and low friction. mDL verification is an identity proofing or re-verification step: it helps when the organisation needs stronger evidence about who the person is, not just that they can unlock a device or account.
The practical test is whether the transaction needs recurring access or higher assurance. If the goal is routine login, step-up authentication, or replacing passwords and OTPs, passkeys fit. If the goal is onboarding, recovery, age or eligibility checks, high-value approval, or a trust reset after a risky event, mDL verification is the better control because it answers a different question.
That separation matters because a control can be strong and still be the wrong tool. A passkey can tell you that the holder of the authenticator is probably the same person who registered it; an mDL can provide stronger evidence that the organisation should trust a claimed identity for a specific event. Treating them as substitutes usually creates either unnecessary friction or an under-assured process.
Where each control belongs in the authentication journey
For most organisations, passkeys sit in the primary access path and mDLs sit at the edge of the journey. Passkeys support continuous sign-in across apps, devices, and sessions. mDLs are better used where the workflow already justifies extra verification, such as account recovery, regulated service access, high-risk changes, or cases where the organisation must confirm a real-world identity before allowing the next step.
If you use both, do not collapse them into one generic “strong login” bucket. Passkeys are about authentication assurance and phishing resistance. mDL verification is about identity evidence and attribute confidence. In a well-designed flow, a user may authenticate with a passkey and later present an mDL only when the business decision requires that higher-assurance step.
That distinction also helps with user experience and control placement. Requiring mDL verification for every login would create avoidable burden and would not improve routine access much. Using passkeys for every trust-sensitive event would leave gaps where the organisation actually needs evidence, not just authentication.
How to avoid overusing either method
Teams often overuse the newer control because it feels stronger, or underuse it because the simpler control is already working. The better pattern is to tie the method to the assurance threshold. Passkeys should be the default when the risk is normal and the user is returning to an existing relationship. mDL verification should be reserved for cases where the decision has real consequences or the existing trust relationship has been weakened.
Useful policy questions are simple: Is this a routine access event, or a trust-establishment event? Are we verifying possession of an authenticator, or are we validating a claimed identity or attribute? Would a sign-in failure be acceptable friction, or would it block a legitimate high-value workflow? Those answers usually point to the right control faster than a feature comparison does.
For teams implementing passkeys, the main operational concern is recovery and enrollment quality. For teams implementing mDL verification, the main concern is what exactly the organisation is accepting as proof, how long that proof remains valid, and whether the workflow records the basis for the decision.
Risk and Threat Considerations
The main risk is mismatch: using passkeys where the business needs stronger identity evidence, or using mDL verification where routine authentication is sufficient. That mismatch can either weaken assurance, if the wrong control is treated as a substitute, or create unnecessary user friction that pushes teams toward unsafe workarounds.
Failure mechanism: A phishing-resistant authenticator proves access to an enrolled account, but it does not by itself re-establish a higher-confidence identity for a sensitive decision. Likewise, an identity document check does not replace an authentication control for day-to-day account access.
Impact: If the organisation collapses those two functions, attackers can exploit weak recovery or step-up paths, and legitimate users can be forced through overcomplicated processes that reduce adoption and increase support load.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys and mDLs both map to assurance and identity evidence decisions. |
| Recommendation — Use authenticator assurance and identity-proofing guidance to separate routine login from higher-assurance verification. | ||
| OWASP ASVS | V6 — Authentication | Passkeys are an authentication control and mDLs affect sign-in assurance flows. |
| V8 — Authorization | mDL checks often gate higher-risk actions that depend on access decisions, not just login. | |
| Recommendation — Verify phishing-resistant authentication requirements and recovery paths separately from identity proofing. Apply stronger authorization checks to high-risk actions that need re-verification beyond routine authentication. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Passkey-based sign-in is an organizational authentication control decision. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | mDL verification commonly supports external-user identity assurance and proofing flows. | |
| Recommendation — Implement phishing-resistant user authentication for routine access and recovery. Use stronger identity proofing when external-user trust must be re-established. | ||
Practitioner Guidance
Decision rule: Use passkeys as the default authentication standard, then add mDL verification only when the workflow needs identity evidence, attribute confirmation, or a trust reset after elevated risk.
What to verify: Confirm that your recovery, onboarding, and high-risk-change flows are explicitly separated from normal sign-in. If they are not, you will end up misusing whichever control is easiest to implement.
Common mistake: Treating “strong authentication” and “strong identity proofing” as the same requirement. They are related, but they answer different questions and belong at different points in the user journey.
Practitioner takeaway: The right choice is usually not one control over the other, but the right control at the right assurance threshold, with passkeys handling routine access and mDL verification reserved for decisions that materially raise trust requirements.
Related resources from NHI Mgmt Group
- How should teams decide between carrier verification, WhatsApp OTP, and passkeys?
- How should security teams decide between face verification and face recognition?
- How should security teams decide between hardware security keys and passkeys for different user groups?
- How should security teams decide between passkeys and magic links for modern sign-in flows?
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 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org