Who do you trust? IACAs, VICALs and the certificate chain behind every mDL check

An mDL reader connects, checks a credential, and shows a green tick. "Verified", it says. Verified against what, exactly?

Behind that tick sits a chain of certificates defined in ISO/IEC 18013-5. This article walks the chain from the issuing authority down to the signature on the phone. It also explains VICALs, the trusted lists that make the chain practical at scale.

We covered trusted lists briefly in our article on offline verification. This piece goes deeper, for people who evaluate readers or run verification programs.

What "verified" actually claims

A signature check proves two things. The data has not changed since signing. And the signing key chains up to a root certificate the reader already trusts. Nothing more.

So the real question is which roots the reader holds. Load the wrong roots, and a forged licence could pass. Miss a legitimate root, and a genuine licence fails. Every mDL check ultimately rests on that stored set.

The chain, in plain words

ISO/IEC 18013-5 defines a three-link chain. Each link has one job.

• IACA root: each issuing authority runs its own certificate authority, the IACA. Its root certificate anchors trust in everything that authority signs.
• Document signer: the IACA issues shorter-lived document signer certificates. These handle the day-to-day signing work of issuance.
• MSO signature: a document signer key signs the Mobile Security Object, or MSO, inside each credential. The MSO carries hashes of every data field, plus the device key.

At check time, the reader works upward. It validates the MSO signature, then the document signer certificate, then the IACA root. If any link fails, the credential fails.

The layering is deliberate. Document signer certificates are designed to rotate, so a leaked signing key has limited reach. The IACA root stays long-lived and closely guarded. Verifiers only need to track the roots.

The collection problem

Here is the catch. Every issuing authority operates its own IACA. Australia alone has eight licensing jurisdictions. North America has dozens more.

Collecting each root certificate individually does not scale. A verifier would need a secure channel to every single authority. It would then need to confirm each certificate is genuine, and track every change. One weak step in that process undermines every later check.

Enter the VICAL

The standard's answer is the VICAL, the Verified Issuer Certificate Authority List. It is an aggregated list of IACA certificates, plus metadata such as credential types and validity periods. The whole list is digitally signed by its publisher.

That signature matters. A reader can verify the list itself before trusting anything on it. Tampering in transit or storage becomes detectable. One vetted list replaces dozens of separate collection exercises.

In North America, AAMVA publishes a VICAL through its mDL Digital Trust Service. Relying parties can access it at no cost and load it into their readers. AAMVA says the list is updated continuously as issuing authorities join.

In Australia, Austroads operates the equivalent through its own Digital Trust Service. Austroads describes it as a trusted list of issuing authority public keys, aligned with ISO/IEC 18013-5. It is designed to cover credentials from Australian and New Zealand transport agencies. Pre-production testing through 2024 reported successful trials with local and international providers.

How a reader uses the list

The workflow is simple, and the timing is the point. A reader downloads the VICAL in advance, over any available connection. It verifies the list's signature, then stores the contents locally.

From then on, verification runs against that stored list. The credential arrives over Bluetooth Low Energy or NFC. The full chain check happens on the device, with no network call. Our offline verification article covers why that matters operationally.

Refresh happens periodically, on a schedule the operator controls. IACA roots change rarely, so daily or weekly refresh is often enough. The check itself never waits on the network.

Governance questions worth asking

The cryptography is standardised. The governance around it is not. Practices vary between suppliers, so these questions belong in any evaluation.

• Whose lists load? Which VICALs ship with the reader, and can you add or remove trust anchors yourself?
• How does refresh work? How often, over what channel, and what happens when a refresh fails or the list goes stale?
• What happens with an unknown issuer? A credential may chain to a root the list does not contain. That should fail or flag clearly, never pass quietly.
• How is compromise handled? If a certificate is revoked or removed from the list, how quickly does that reach your fleet?

None of these has a single right answer. Sensible defaults differ between a border gate and a bottle shop. What matters is that your supplier has considered them, and can demonstrate the behaviour.

Why lists beat per-check lookups

Some systems skip local trust and query a server for every check. That design trades away both resilience and privacy.

On trust: a signed list puts the anchors in your hands. Verification works the same with or without a network. No third-party service needs to be online, honest and fast at the moment of every check.

On privacy: a per-check lookup can tell a server where and when each ID was presented. A list-based reader sends nothing at check time. AAMVA states its trust service never receives or stores mDL holders' personal information. A list refresh reveals a schedule, not a person.

The honest trade-off is revocation freshness, which depends on your refresh cadence. For many operations, that window is manageable and worth the resilience gained.

Where this lands for buyers

Trust in an mDL program is not a feature you toggle on. It is a supply chain of certificates, lists and refresh discipline. Ask to see it working before you rely on it.

Our TENSAI mDL readers ship with trusted-list management handled: VICAL loading, scheduled refresh and clear unknown-issuer behaviour. See the TENSAI reader range for hardware options.