ISO mdoc is a mobile document format used to hold digitally signed identity credentials on a device. It structures claim data for presentation and verification under ISO/IEC 18013-5, with cryptographic protection so a verifier can check authenticity and selectively read authorised fields.
What ISO mdoc Is Used For
ISO mdoc is a standards-based way to package identity claims inside a signed mobile document that can be presented from a device to a verifier. It is designed for selective disclosure, so the holder can reveal only the fields needed for a given transaction while the verifier checks that the data is authentic and unaltered.
That design matters because the security model is not just about storing a credential on a phone. It is about preserving issuer trust, controlling what the verifier can learn, and reducing unnecessary exposure of personal data during presentation.
How ISO mdoc Works in the Credential Exchange Flow
In practice, ISO mdoc sits inside a presentation and verification flow that involves an issuer, a holder device, and a relying party. The issuer signs the document, the holder presents it, and the verifier checks the cryptographic protections and the authorised data elements before accepting the result.
The format is tightly linked to mobile identity use cases such as digital driving credentials, age checks, and regulated access scenarios. The underlying value is that a verifier can validate authenticity without needing a full-copy credential dump, which is a major privacy and minimisation advantage. NHIMG’s Verifiable Credentials Guide places mdoc in the broader verifiable credential ecosystem, including selective disclosure and presentation patterns.
Security Properties and Trust Boundaries
ISO mdoc’s security value comes from signed claims, constrained disclosure, and a verifier workflow that is meant to confirm provenance rather than trust the device blindly. The trust boundary is between the issuer’s assertions, the holder’s presentation, and the verifier’s validation logic.
That means implementation details matter. If the verifier does not validate the right trust anchors, accepts weak presentation checks, or treats all device-supplied data as equally trustworthy, the security model collapses into simple attribute submission. NHIMG’s Mobile Driving Licence (mDL) Guide covers ISO 18013-5 and mdoc data, including device engagement and reader authentication, which are central to real-world deployments.
Because mdoc carries identity data, its protection also depends on the surrounding key and device trust assumptions. Compromise of the holder device, misuse of presentation channels, or poorly governed verifier access can all undermine the intended privacy and assurance properties.
Where ISO mdoc Fits in Modern Digital Identity
ISO mdoc is part of a broader shift toward portable credentials that can be presented across devices and channels. It is often discussed alongside verifiable credentials, wallet-based identity, and browser-mediated presentation flows, because organisations are trying to balance convenience, interoperability, and data minimisation.
For practitioners, the main architectural question is not whether the format can hold claims, but whether the complete ecosystem around it can verify them safely and consistently. That includes issuer trust, wallet behaviour, verifier policy, and how the presentation channel binds the credential to the transaction. When mdoc is used on the web, browser and wallet interaction details become part of the trust model, which is why implementation guidance around digital credential APIs is often relevant. NHIMG’s W3C Digital Credentials API Guide is useful context for understanding how web-based presentation flows interact with wallet and verifier expectations.
Risk and Threat Considerations
ISO mdoc reduces some identity-sprawl risks, but it also concentrates high-value identity material into a portable object that can be misused if issuance, storage, presentation, or verification is weak. The biggest risks are fraudulent presentation, excessive disclosure, verifier trust failures, and compromised wallet or device environments that expose signed identity data.
Failure mechanism: An attacker succeeds when a verifier accepts an unauthorised or poorly validated presentation path, or when a compromised device, wallet, or relying party workflow exposes data beyond the intended fields.
Impact: The result can be identity fraud, privacy leakage, false acceptance, or replay and misuse of credential data in downstream services that assume mdoc validation was performed correctly.
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 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | mdoc deployments depend on protected credential and key lifecycle handling |
| IA-2 — Identification and Authentication (Organizational Users) | verifier and issuer access must be strongly authenticated in mdoc workflows | |
| AC-6 — Least Privilege | selective disclosure and verifier access should expose only the minimum required claims | |
| Recommendation — Protect credential and key lifecycles so signed mobile credentials remain trustworthy. Authenticate issuer and verifier operators before allowing credential issuance or validation. Limit verifier access to only the claims required for each transaction. | ||
| NIST SP 800-63 | N/A — Digital Identity Guidelines | mdoc is part of digital identity assurance and identity proofing ecosystems |
| Recommendation — Align issuer, holder, and verifier assurance practices to digital identity guidance. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | mdoc requires controlled access to identity data and verification functions |
| Recommendation — Define and enforce access rules for mobile identity data and verifier systems. | ||
Practitioner Guidance
Why practitioners should care: ISO mdoc is not a standalone document type, it is a trust system. The operational question is whether your issuance, wallet, and verification processes all enforce the same policy on authenticity, disclosure, and transaction binding.
What to watch for: Weak verifier assumptions, over-broad data requests, inconsistent acceptance rules across relying parties, and gaps between the cryptographic design of mdoc and the actual user journey are the conditions that usually create problems.
Practitioner takeaway: Treat mdoc deployments as an end-to-end identity architecture, not a file format decision, and validate the trust chain wherever the credential is issued, stored, presented, or consumed.
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 November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org