What are the main failure modes when institutions accept mDLs without strong controls?

The main failures are weak fraud screening, unclear evidence requirements, and overconfidence that a digital credential alone proves trust. Those gaps can lead to accounts being opened or recovered on the basis of identity data that was never sufficiently validated.

Why This Matters for Security Teams

mDL acceptance changes the trust boundary at the point where an institution decides whether an identity proofing event is good enough to open an account, recover access, or pass a fraud check. The failure is rarely the credential format itself. It is the control stack around it, including how the credential is issued, how authenticity is verified, and whether the organisation still requires evidence that is stronger than possession of a phone and a valid-looking credential.

Teams get into trouble when they treat an mDL as a complete identity decision rather than one input to a broader verification process. That mistake can weaken onboarding, account recovery, and exception handling, especially where staff assume the digital presentation is inherently harder to forge than it actually is in their own workflow. Organisations that are already struggling with secrets and credential governance often recognise this pattern too late, because confidence in the control is high even when the control chain is thin. The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, which is a familiar sign that operational confidence can outrun real verification discipline. In practice, many security teams discover the weakness only after a fraud case or recovery abuse has already shown that the acceptance process was too permissive.

How It Works in Practice

Strong mDL controls do not start with the wallet presentation alone. They start with deciding what the institution is actually trusting: the document’s authenticity, the issuing authority, the binding between holder and device, and the business action that the mDL is allowed to support. A robust flow usually separates low-risk uses, such as age or attribute checks, from high-risk actions, such as account opening or password reset, because the evidence bar should rise with the consequence of failure.

Practically, the control stack should include:

verification that the mDL is valid and current, not merely displayable;
independent checks against fraud signals, account history, and step-up evidence;
clear rules for which decisions an mDL can support on its own and which require a second factor;
logging that captures who accepted the credential, what was checked, and what exception was used;
revocation or fallback handling for device loss, credential update, and disputed identity events.

Institutions also need evidence requirements that staff can apply consistently. If the policy says the mDL is only one proof source, then the workflow must force a second source before a high-impact action is completed. If the policy allows exceptions, those exceptions need explicit approval and later review, otherwise the exception path becomes the real policy. This is where many implementations break down, because a digital credential is easy to recognise but harder to govern once front-line staff are under pressure to move quickly. These controls tend to break down when acceptance is delegated to manual review teams without a tightly defined evidence standard, because speed pressure turns “verify” into “look plausible”.

Common Variations and Edge Cases

Tighter acceptance rules often increase friction, so institutions have to balance user convenience against the risk of false acceptance. That tradeoff is especially visible when mDLs are used for remote onboarding, high-value account recovery, or customers with thin file histories, because the same credential can be a useful signal in one context and an insufficient control in another.

Some programmes try to solve this by allowing mDLs only for low-risk scenarios, while others permit broader use but require stronger corroboration when the transaction is sensitive. Both approaches can work, but the decision should match the institution’s fraud tolerance and legal evidence expectations. There is no universal standard for this yet, so organisations should be explicit about what “accepted” means: accepted as a convenience signal, as an identity assurance input, or as a primary proof of identity. Those are not the same thing.

Edge cases also matter. Lost devices, refreshed credentials, roaming users, and cross-jurisdiction acceptance can all weaken confidence if the institution cannot confirm what the mDL was bound to at the time of presentation. Where the process relies on visual trust cues rather than verifiable checks, the system becomes more vulnerable to spoofing, social engineering, and staff overconfidence. The safest posture is to assume the mDL can reduce friction, but not replace evidence discipline unless the specific use case has been designed and tested for that level of reliance.

Risk and Threat Considerations

The main risk is control substitution, where an mDL is treated as stronger evidence than it really is in the institution’s operating model. That creates exposure in onboarding, recovery, and exception handling, because a compromised or inadequately verified identity path can be used to pass checks that were supposed to detect fraud.

Failure mechanism: Attackers or opportunistic fraudsters benefit when the institution accepts a presentable credential without verifying issuer trust, binding, freshness, and step-up evidence. If staff can open or recover accounts based on the mDL alone, the process can be abused through impersonation, device compromise, or policy gaps.

Impact: The likely consequence is unauthorised account opening, account takeover recovery, or weakly evidenced identity establishment that later cannot withstand dispute, audit, or fraud review. Once the acceptance rule becomes the de facto proof standard, downstream controls inherit the error.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	5 — Account Management	mDL acceptance affects how identities are admitted and recovered.
	6 — Access Control Management	Strong controls must limit what an mDL can authorise.
Recommendation — Define evidence thresholds for account opening and recovery decisions. Restrict mDL use to the lowest-risk actions your policy allows.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	mDLs are identity assertions that need controlled verification before trust.
	GV.RM — Risk Management Strategy	Institutions need explicit risk tolerance for mDL acceptance cases.
Recommendation — Validate issuer trust and step-up evidence before granting access or opening accounts. Set risk-based acceptance rules for low-risk and high-risk mDL use cases.
OWASP Non-Human Identity Top 10	NHI-01 — Improper Verification of Non-Human or Digital Credentials	Digital credential acceptance can fail when verification is too shallow.
	NHI-02 — Overprivileged Credential Use	An mDL can be over-trusted if it is allowed to authorise too much.
Recommendation — Require verifiable credential checks before trusting any presented digital identity. Limit mDL acceptance to the minimum assurance needed for the transaction.

Practitioner Guidance

What to prioritise: Define the exact business actions an mDL may support, then assign a separate evidence threshold for each one. Account opening and recovery should almost never inherit the same acceptance rule as a low-risk attribute check.

What to verify: Confirm that the workflow checks more than presentation, including issuer trust, freshness, and the binding between the credential and the person presenting it. If staff cannot explain what would cause rejection, the control is too vague to trust.

Decision rule: If the mDL is being used to approve a high-impact action, require an additional verification signal or supervised review. If the action is low impact, document that limitation so the credential is not quietly promoted beyond its design.

Practitioner takeaway: The strongest mDL programme is not the one that accepts the most credentials, it is the one that can prove exactly what each acceptance decision did and did not establish.