Join our Newsletter — 33% off our NHI Course

mdoc

An mdoc is a mobile document format defined by ISO/IEC 18013 for storing and presenting identity data on a device. It is used in mobile driving licences and other digital credentials, where issuers sign data and verifiers check authenticity, integrity, and holder control before trusting the claim.

What mdoc Means in Practice

An mdoc is a device-held identity credential format, not just a file container. It standardises how identity data is encoded, signed, and later presented so a verifier can rely on the issuer’s integrity and the holder’s device-mediated presentation flow.

The practical importance of mdoc is that it turns a mobile device into a trust-bearing presentation channel. That changes the security conversation from “can a card be read?” to “can the relying party authenticate the issuer data, validate what was released, and trust the presentation context?”

How mdoc Supports Digital Identity Use Cases

mdoc is used where a credential must be presented from a phone with strong assurance around authenticity and holder control. Mobile driving licences are the most visible example, but the same pattern can support other regulated or high-assurance identity claims.

The format matters because it separates the credential content from the presentation event. In a well-designed flow, the issuer signs the data, the device stores it, and the verifier checks that the claim is authentic and that the person presenting it is in control of the device at the moment of disclosure.

That model supports privacy-oriented disclosure designs, including selective release of attributes, rather than exposing a full static identity record every time. The result is a credential that can be used in more contexts than a traditional plastic document, while still preserving an assurance boundary around the issuer and the holder.

Security Properties and Trust Boundaries

mdoc security depends on more than cryptography alone. The issuer signature protects integrity, but the verifier still has to trust the credential format, the device presentation process, and the policy used to decide which data elements are acceptable for a given transaction.

The main trust boundary is between stored identity data and presented identity data. A verifier is not simply reading a document, it is evaluating whether the device can present a genuine issuer-signed claim in a way that resists tampering, replay, or unauthorized disclosure.

That is why mdoc is often discussed alongside verifier authentication, device engagement, and presentation rules. Verifiable Credentials Guide is useful background for the broader issuer-holder-verifier model that mdoc fits into, while Mobile Driving Licence (mDL) Guide goes deeper into the mobile document and reader workflow.

Where mdoc Fits in the Credential Ecosystem

mdoc is part of a wider shift from centrally photocopied identity artefacts toward interoperable digital credentials. Its value is highest when an organisation needs portable identity data with defined presentation rules, rather than a bespoke app-specific token format.

Because it is specification-driven, mdoc also creates implementation discipline. Issuers, wallet providers, and verifiers have to align on data model, cryptographic trust, and presentation expectations. That makes interoperability possible, but it also means weak implementation choices can undermine the assurance the format is meant to provide.

For practitioners, the important distinction is that mdoc is a credential format with security consequences, not a generic mobile app feature. The format becomes trustworthy only when the surrounding issuance, storage, presentation, and verification controls are all implemented consistently.

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
NIST SP 800-53 Rev 5 IA-2 — Identification and Authentication (Organizational Users) mdoc presentations rely on authenticated verifier access decisions.
IA-5 — Authenticator Management mdoc ecosystems depend on protected keys, tokens, and credential material.
SC-12 — Cryptographic Key Establishment and Management Issuer trust for mdoc depends on sound cryptographic key handling.
Recommendation — Apply IA-2 to ensure verifiers and operators are strongly authenticated before trusting mdoc-based identity flows. Use IA-5 to manage the lifecycle and protection of credential material used in mdoc issuance and verification. Use SC-12 to govern the keys that sign and verify mdoc identity data.
ISO/IEC 27001:2022 A.8.24 — Use of cryptography mdoc authenticity and integrity are enforced through cryptographic controls.
Recommendation — Apply cryptographic use controls to sign, verify, and protect mdoc identity data.