Organisations implement ISO/IEC 18013-7 by using the parts of the standard that support remote presentation and verification of mobile driving licences. They should confirm issuer trust, holder control, freshness, and status during the remote exchange, and design the process so only necessary attributes are disclosed and replay attempts are detected.
What implementation means for a remote mDL flow
Implementing ISO/IEC 18013-7 is less about treating the standard as a standalone product and more about building a remote presentation and verification workflow that preserves the trust properties of a mobile driving licence. That means the relying party must be able to validate issuer trust, bind the presentation to the holder, and assess whether the exchange is fresh and status-checked before accepting data.
The practical design choice is how much of the verification burden sits in the relying party process versus the wallet, holder device, or backend orchestration. A sound implementation keeps the exchange narrow: request only the attributes needed for the decision, keep the presentation steps understandable to the holder, and avoid adding extra identity proofing or profile data that the standard does not require for the transaction.
Because 18013-7 is about remote use, implementation also needs to account for how the verification event will be initiated, transported, logged, and interpreted. The point is not merely to move data over a network, but to preserve the assurance properties that make the mDL suitable for remote relying-party use in the first place. NHIMG’s Mobile Driving Licence (mDL) Guide is the most direct companion if you need the broader mDL model around ISO 18013-5 and 18013-7, including reader authentication and verification patterns.
What has to be true before you trust the result
A remote mDL implementation should verify four things at minimum: the issuer is trusted, the holder is in control of the wallet or device, the presentation is fresh, and the status of the licence or credential can be checked during the exchange. If any of those checks is weak, the result may still look technically successful while failing the assurance standard that the relying party actually needs.
Freshness matters because remote presentation creates more opportunities for replay, relay, and delayed reuse of captured data. Status matters because a credential can be structurally valid yet no longer acceptable for business or regulatory reasons. Holder control matters because the standard is designed for a live presentation by the person who is supposed to be making the claim, not for an artefact copied from somewhere else.
The privacy consequence is equally important: verification should disclose only the minimum attributes necessary for the use case. That is where implementation often fails in practice, not because the standard is unclear, but because teams expand the data request to make downstream checks easier. The result is more exposure than the relying party needs and a weaker privacy posture than the transaction requires.
How implementers usually get the architecture wrong
Most failures come from treating the standard as a document exchange problem instead of a trust and transaction problem. If the workflow does not bind the request, response, and holder interaction tightly enough, an attacker may replay a captured response, substitute an older presentation, or exploit a weak link in the status check path. The implementation should therefore be designed around the transaction, not around a single message format.
Teams also get into trouble when they assume that wallet UX alone solves assurance. It does not. The relying party still needs a deterministic way to decide whether the presentation came from a valid issuer, whether the returned claims are current, and whether the presentation context matches the intended remote interaction. Those checks are business-critical even when they are hidden behind a simple front-end flow.
Risk and Threat Considerations
Remote presentation expands the attack surface because it introduces network transport, session handling, and replay opportunities that are less prominent in a face-to-face verification flow. The main security risks are credential replay, relay of a legitimate presentation into an unintended context, excessive disclosure of personal data, and reliance on stale or unverified status information.
Failure mechanism: An attacker captures, forwards, or reuses a valid remote presentation, or the relying party accepts a presentation without adequately checking freshness, holder control, or current status.
Impact: The organisation may accept an impostor, approve a transaction on the basis of outdated or over-disclosed data, or create a privacy exposure that is larger than the use case justifies.
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 |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Remote mDL verification depends on controlled disclosure and trusted access decisions. |
| A.5.16 — Identity Management | The flow relies on trusted issuer and holder identity relationships during remote verification. | |
| A.5.17 — Authentication Information | Freshness, holder control, and replay resistance depend on protecting authentication material and assertions. | |
| Recommendation — Apply access-control rules to restrict mDL data disclosure to the minimum needed for each transaction. Define and govern the identities that can issue, present, and verify mDL data. Protect authentication material used in remote mDL exchanges against reuse and interception. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Verifier and operator identities must be authenticated before accepting remote mDL transactions. |
| IA-5 — Authenticator Management | Remote presentation depends on controlling the lifecycle of authenticators, tokens, and related secret material. | |
| IA-9 — Service Identification and Authentication | Remote mDL exchanges are system-to-system interactions that need mutual trust between services and wallets. | |
| Recommendation — Authenticate verifier and operator identities before they can process remote mDL assertions. Manage authenticators and related secrets so remote mDL sessions cannot be replayed or reused. Use service authentication to validate the entities exchanging remote mDL data. | ||
Practitioner Guidance
What to verify: Before going live, test the full remote flow end to end, not just the wallet or the verifier in isolation. Confirm that issuer trust, holder binding, freshness checks, and status validation all happen in the actual production sequence, and that failures are explicit rather than silently accepted.
What good looks like: The relying party asks for the minimum required attributes, the holder sees a clear consent step, the verification result is time-bound, and the implementation can distinguish a genuine live presentation from a reused or stale one. If the process cannot show those properties, it is not yet a dependable 18013-7 implementation.
Practitioner takeaway: Treat ISO/IEC 18013-7 as a trust workflow with privacy constraints, not as a transport feature, because the implementation succeeds only when verification, freshness, and minimal disclosure all hold at the same time.
Related resources from NHI Mgmt Group
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 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org