The PACS Buyer’s Guide to Digital Identity: mDLs, ISO 18013-5, and What Matters
Mobile driver’s licenses are live in a growing number of US states. The EU is mandating digital identity wallets by 2026. Your employees are starting to carry government-verified digital credentials on their phones.
The physical access control industry hasn’t decided what to do about this yet. Most PACS vendors are still selling proprietary mobile credentials — vendor-issued tokens that cost $4–$17 per user per year. Meanwhile, government-issued digital IDs are free, already deployed, and cryptographically stronger than anything a PACS vendor issues.
This guide is for security directors evaluating how digital identity fits into their access control strategy.
What an mDL is (and isn’t)
A mobile driver’s license (mDL) is a cryptographically signed credential stored in a person’s phone. It’s issued by a government authority (the state DMV in the US) and contains identity attributes: name, date of birth, photo, address, and license number.
An mDL is not a mobile credential in the PACS sense. It’s not a badge replacement issued by the access control vendor. It’s a government-issued identity document — the same kind of document you verify when someone shows you a physical driver’s license, except it’s cryptographically verifiable instead of visually inspectable.
The distinction matters: a PACS mobile credential is a vendor-issued token that says “this person is authorized to enter this building.” An mDL is a government-issued identity that says “this person is who they claim to be.” The access authorization still lives in the PACS — where it belongs.
The ISO 18013-5 standard
ISO 18013-5 (formally ISO/IEC 18013-5:2021) defines how mobile driver’s licenses are stored, presented, and verified. It specifies the NFC protocol for in-person presentation, the cryptographic signature scheme for credential verification, and the selective disclosure mechanism that lets the holder share only the attributes the verifier needs.
For physical access, three properties matter:
NFC presentation. The employee holds their phone near an NFC reader, and the credential is presented via NFC — the same interaction as tapping a payment card. The NFC session includes a full ECDH P-256 key exchange, ensuring the session is encrypted and the credential can’t be intercepted.
Cryptographic verification. The verifier checks the credential’s digital signature against the issuing authority’s public key. If the signature is valid, the credential is genuine. No cloud call required — the verification is a local computation against cached issuing authority keys.
Selective disclosure. The employee can share only the attributes the verifier requests. Building access might require name, date of birth, and photo — but not address or license number. The employee’s phone shows a consent prompt listing exactly what will be shared.
How identity-based access works
The KeyShare architecture uses the mDL as the input to the access control decision — not as the access credential itself. The employee presents their mDL at the reader. The reader verifies the identity. The Panel Application on the Mercury controller derives a site-specific identifier from the verified identity and checks it against the access manifest. The PACS applies its existing access rules.
This is fundamentally different from proprietary mobile credentials, where the vendor issues a token and the reader validates the token against the vendor’s cloud. In the identity-based model, the credential is government-issued (free), the verification is local (no cloud dependency), and the PACS is unchanged (standard credential numbers).
What security directors should evaluate
Five criteria for evaluating identity-based access solutions:
- Does it work on your existing panels? The solution should deploy as software on your current Mercury controllers — not require panel replacement.
- Does it work with your existing PACS? The PACS should see standard credential numbers. No new APIs, no middleware, no proprietary protocol.
- Does it work offline? Access decisions should happen on the panel, not in the cloud. Doors must open during cloud outages.
- Does it eliminate per-user fees? The economic model should be per-station or per-site — not per-user.
- Does it use open standards? ISO 18013-5 for identity verification, OSDP v2.2 for reader communication. No proprietary lock-in.
