Apple Wallet Mobile IDs: What Businesses Need to Know

Apple’s current ID-in-Wallet list covers multiple U.S. jurisdictions and continues to change — which is the first thing worth saying about this topic.

Where to check availability

Apple’s own support page is the authoritative list, and it is the only source worth relying on: Add your driver’s license or state ID to Apple Wallet. It covers participating jurisdictions and the device and OS requirements.

We deliberately do not reproduce that list here. A copied list is accurate on the day it is written and becomes a false claim shortly afterwards, and vendor pages restating state lists are one of the more common sources of bad information in this market. Check the source.

How presentation works

For in-person checks, an ID in Apple Wallet is presented over the ISO/IEC 18013-5 flow: the phone and the reader establish a session, the reader requests specific data elements, and the phone releases only those, with the issuer’s signature attached.

Apple’s guidance to users describes the interaction from their side: the holder is shown what is being requested and authorises the release with Face ID or Touch ID. From the business’s side, that means the release is an explicit, authenticated act by the holder rather than something that happens passively in a pocket.

Apple documents the security architecture of IDs in Wallet in its platform security guide, including how the credential is provisioned and protected on device. It is worth a security reviewer’s time.

The four separate facts

This is where most confusion in the market comes from. Four things are commonly collapsed into one, and they are independent:

1. A state issues a mobile ID. An issuing-authority decision.
2. Apple Wallet carries that state’s mobile ID. A decision between Apple and the state.
3. A patron has actually added it to their phone. An individual decision, and the number is well below the eligible population.
4. A given verifier can accept it. A vendor’s engineering and validation result.

Fact 2 does not imply fact 4. A verification product’s support for a jurisdiction depends on whether it trusts that issuing authority’s material and whether it has physically validated the combination on the hardware you would deploy. Those are the vendor’s work, not Apple’s.

Any vendor page that lists Apple Wallet jurisdictions without distinguishing “the wallet carries this” from “we have validated this” is telling you something misleading, whether or not it intends to.

What to expect operationally

Adoption is partial. Even in a participating state, a large majority of customers will still present a physical card for the foreseeable future. Plan for a mixed door, not a transition date.

The phone stays with the holder. A presentation over NFC or BLE does not require handing a device over, and staff should be trained never to take one. This is both a security property and a customer-experience one.

A tap is an intentional act. Unlike a QR scan, engagement over NFC requires deliberate physical contact. In a queue, that removes a class of ambiguity about which device is presenting.

Requirements are device-dependent. Apple publishes minimum device and OS requirements per jurisdiction, and they vary. Staff will occasionally meet a customer who believes they have an ID in Wallet and does not.

Questions worth asking a verification vendor

• Which Apple Wallet jurisdictions have you physically validated, on which reader hardware, and when?
• What exactly does your reader request from the credential?
• What is your trust source, and what else does your reader accept as a trust anchor?
• What happens when a presentation cannot be completed — is there a distinct “cannot verify” outcome, or does it collapse into a pass or a fail?

LaurelID’s current position

Laurel’s own status, stated for clarity rather than as a claim about Apple.

Checked-in owner-attested evidence records Apple Wallet and Google Wallet physical interoperability on Elo M51. Current physical-evidence, trust-binding, promotion, and production status are derived from the reviewed registry on the compatibility matrix.

We publish a validation date, the hardware tested, and the known limitations for every row, including the ones that say we have done nothing yet. That is a deliberately unflattering way to present a compatibility page, and it is the only version we would defend to a reviewer.

Sources

1. Add your driver's license or state ID to Apple Wallet — Apple
2. Present your driver's license or state ID from Apple Wallet — Apple
3. IDs in Apple Wallet — Apple Platform Security — Apple