Apple Wallet driver’s licenses coming to two more states soon: report

"Apple Wallet driver's licenses aren't just about convenience-they're a case study in privacy-preserving identity credential exchange. "

According to a recent 9to5Mac report, two additional US states are expected to roll out support for digital driver's licenses (DDLs) in Apple Wallet within weeks. While the news itself is incremental, the engineering implications behind adding state-issued post-issuance credentials to a mobile wallet deserve a deep dive. Digital identity verification is a notoriously hard problem-balancing user privacy, government legacy systems, fraud prevention. And the frictionless user experience Apple demands.

As a technical audience, you've likely sat through identity proofing sessions involving document uploads, liveness checks. And manual review queues. Apple Wallet's approach, built on the ISO 18013-5 mobile driver's license (mDL) standard, flips the script: the phone becomes a verifiable credential container without exposing more data than necessary. In this post, we examine the underlying architecture, the state onboarding pipeline, and what senior engineers building identity platforms can learn from Apple's playbook.

Current State of Apple Wallet DDL Support

As of early 2025, Apple Wallet supports digital driver's licenses in Arizona, Colorado, Georgia, Maryland. And Ohio. At select TSA checkpoints and participating businesses, the credential can be presented via NFC without handing over the phone. The 9to5Mac report indicates Connecticut and Iowa are the next in line, having already completed internal piloting. This brings the total to seven states-still a fraction of the 50 states. But the adoption curve is accelerating.

For developers building similar credential management systems, the critical takeaway is that Apple doesn't store the actual license data in iCloud or sync it across devices. The encrypted credential resides solely in the Secure Enclave. Each state's issuing agency cryptographically signs the attestation. And the signature is verified by the verifier's terminal during transmission. This eliminates the need for a centralized database of biometrics.

The rollout pattern also reveals a preference for states with existing REAL ID compliance infrastructure. States that have already modernized their DMV backend to support electronic credential issuance can integrate with Apple's Identity Credentialing API (introduced in iOS 15. 7) more rapidly we're seeing a classic chicken-and-egg problem: until enough states adopt the standard, TSA and merchants have little incentive to deploy readers-but Apple's installed base is forcing the issue.

Understanding the ISO 18013‑5 Standard and mDL

ISO 18013‑5 is the international standard for mobile driver's licenses. It defines how a device (e, and g, smartphone) can present a digital credential over NFC or QR. And how the verifier can request specific data elements without seeing others. In production identity systems, we frequently rely on selective disclosure-a concept borrowed from verifiable credentials (VCs) in the W3C Decentralized Identifiers space. Apple's implementation supports the mDL data model exactly.

For example, when a TSA officer needs to verify your age, the terminal sends a request for "date of birth" only. The iphone then releases that attribute along with a cryptographic proof signed by the issuing DMV, without sharing your full license number, address, or photo. This is accomplished using a privacy-preserving protocol called "device engagement" (BLE/NFC handshake) followed by "request/response" where the mDL holder's Wallet app constructs a minimal disclosure.

Developers implementing mDL readers should pay close attention to the "Data Element Identifiers" (DEIs) defined in the standard. There are 22 possible data elements, from "Family Name" to "Vehicle Class. " The verifier must be coded to request only what is absolutely necessary-anything extra violates the spirit (and likely the future regulation) of the standard. We've seen early implementations where verifiers accidentally request the full set, defeating the privacy benefit. Apple enforces a strict minimum on the reader side via the NFC Data Exchange Format (NDEF) specification.

Security Architecture: Secure Enclave and Certificate Chains

The security of Apple Wallet credentials relies on a multi-layered trust model. First, the issuing DMV generates a public-private key pair for the resident's digital license. The private key is securely injected into the iPhone's Secure Enclave during the initial enrollment (usually via a secure WebRTC or UDP session with the state's identity server). The public key is stored in the DMV's certificate authority (CA).

When the credential is presented, the Wallet app signs a random challenge from the verifier using the stored private key. The verifier then validates that the signature matches the public key in the DMV's certificate chain, which is anchored by a root certificate stored in the trusted security infrastructure of the TSA or other authorized third party. This is analogous to the TLS certificate pinning pattern. But applied to identity attestations.

One often-overlooked detail is the revocation mechanism. If a license is suspended or reported stolen, the DMV can update the "Credential Status List" (CSL) in a distributed hash table or via REST endpoints that the iPhone checks periodically. Apple's approach uses a push notification to trigger a status check. The revocation URL is embedded in the mDL certificate extension. Engineers designing such systems should note the trade-off between latency (immediate revocation vs. And offline caching) and privacy (avoiding central tracking)

State Onboarding: The Integration Pipeline

For a state to support Apple Wallet DDL, it must deploy a secure issuance portal, integrate with Apple's Identity Credentialing API. And undergo a security audit by Apple. The credentialing API is a relatively lightweight REST/JSON interface that allows the DMV to request the creation of a wallet pass, attach the signed mDL payload, and specify the validity period.

From a software engineering perspective, the biggest challenge isn't the API itself but the backend transformation. Most state DMVs run on legacy mainframes or COBOL systems. Getting those systems to produce a cryptographically verifiable payload in real-time is a heavy lift. Apple provides sample SDKs for Swift and Node js. But the real complexity lies in bridging to the state's existing identity management system (e g, and, AAMVA's DLA template)

A concrete example: Colorado's DMV reportedly took 18 months from pilot to full availability because they needed to upgrade their database schema to include the newly required cryptographic material. Connecticut and Iowa have likely benefited from Colorado's open‑source integration toolkit-several state IT departments have shared their API mapping documents on GitHub. This collaborative pattern mirrors what we saw with mobile PIV smartcard initiation in federal agencies.

Developer Tooling: Identity Verification and the Wallet SDK

If you're building a mobile app that needs to verify age or identity without collecting sensitive data, Apple's Wallet SDK (part of the PassKit framework) exposes a reliable pathway. The PKPass class now includes a method to read the available secure elements after user consent. Developers must request entitlement from Apple to integrate DDL verification; it's not available to every app on the App Store (for now).

For server-side verification, the typical flow works like this: your app initiates a BLE communication with the wallet, requests the needed attributes, receives a signed JWT-like structure (the mDL response). And forwards it to your backend. Your backend then validates the payload against the issuer's certificate chain, which can be obtained via the IssuerAuthorityJSON endpoint. Apple recommends using the Common Security Services Manager (CSSM) on macOS or the Security framework on iOS to verify the signatures.

One pitfall we encounter frequently is incorrect handling of the "document signer certificate" chain. The mDL response includes multiple X. 509 certificates; your verification logic must parse them in the correct order and reject any that are expired or revoked. We suggest storing a local cache of trusted root certificates for the participating states and refreshing them daily via a cron job. The AAMVA ID Program page provides the base certificates for validation.

Privacy Implications for Users and Developers

While Apple's selective disclosure is a major privacy win, it's not without caveats. The TSA reader sends a request that includes a "transaction identifier" logged by the airport. That identifier can be correlated with your flight record if the TSA chooses to link data. As an engineer, you should build systems that never log the actual disclosed attributes-only the fact that a valid credential was presented. This is standard data minimization but often forgotten.

Additionally, the current implementation requires an internet connection for the initial credential issuance. In regions with poor connectivity, users may be unable to download their digital license. The mDL standard does allow offline issuance via staged certificates. But Apple hasn't yet enabled that path. Future versions should support Bluetooth-based two-way authentication with zero internet dependency, similar to the device engagement step already in place.

For developers, an interesting technical challenge is building a verifier that works without a network connection. The mDL response can be verified offline if the verifier has a cached copy of the issuer's certificate. This is critical for use cases like law enforcement traffic stops or stadium entry where cellular coverage is unreliable we're experimenting with a variant that uses a Merkle tree of trust anchors synced via periodic updates-borrowing from certificate transparency logs.

Future Implications: REAL ID Interoperability and Cross‑Border Standards

The push for Apple Wallet DDLs intersects with the REAL ID deadline enforcement. By May 2025, all travelers must present a REAL‑ID compliant license. Apple's digital version qualifies as REAL ID in the six supporting states. This creates a powerful incentive for other states to accelerate integration. From a policy engineering perspective, the REAL ID framework specifies the physical card security features, but the digital sibling requires equivalent Liveness Detection and Presentation Attack Detection (PAD).

Apple integrates Face ID and a brief video selfie during enrollment to satisfy the NIST SP 800‑63‑3 Identity Assurance Level 2 (IAL2) requirement. The biometric match is done on-device, never transmitted. Developers building remote identity proofing should study Apple's implementation of the "Hold Still" phase: it captures a sequence of frames while the user rotates their head, checking for spoofing via depth map data. This is detailed in Apple's LocalAuthentication documentation

Looking further ahead, interoperability between Apple Wallet and other digital ID wallets (e g., Google Wallet, Samsung Pass) may depend on the European eIDAS 2. 0 framework which mandates a common European Digital Identity Wallet. Apple's mDL format is aligned with the ISO standard. So cross-platform acceptance is architectural feasible-though competitive pressures may delay adoption. For senior engineers, the key is to build your identity stack against the ISO standard, not against Apple's proprietary extensions.

Frequently Asked Questions

• Will Apple Wallet driver's licenses replace physical cards?
  Not yet. The physical card remains required by law in most states. The digital version is accepted only at designated TSA checkpoints and participating merchants. You should still carry your plastic license for non‑compliant verifiers.
• Which new states are adding support soon?
  Based on the 9to5Mac report, Connecticut and Iowa are finalizing their deployments. No official announcement has been made, but internal testing is complete. Other states like Florida and Texas have issued RFPs but haven't publicly committed.
• How is the data protected if my iPhone is stolen?
  The digital license is stored in the Secure Enclave and can't be accessed without Face ID or the device passcode. Additionally, the biometric data used for enrollment never leaves the device. If you remotely wipe the iPhone via Find My, the credential is destroyed.
• Does the system work offline at airport TSA kiosks?
  Yes, the NFC verification is completed locally on the verifier terminal. However, the terminal itself may need to sync its certificate database periodically. Apple's mDL implementation caches the issuer certificates for a limited window, allowing offline verification for up to seven days.
• Can third-party apps read my data without permission.
  NoThe iPhone displays a consent dialog every time an app attempts to read from the Wallet credential. The app must also be entitled by Apple to request specific data elements, and no read‑only background scanning is possible

Conclusion and Call to Action

Apple Wallet's expansion of digital driver's licenses to Connecticut and Iowa represents a real, incremental step toward a verifiable credential ecosystem. For engineers, the maturity of the ISO 18013‑5 standard paired with Apple's Secure Enclave architecture offers a production‑grade template for building privacy‑preserving identity systems. Whether you're architecting a state DMV integration, a TSA reader. Or a ride‑share age verification flow, the underlying principles of selective disclosure, cryptographic attestation. And offline resilience are directly applicable,

Start exploring the PassKit framework and experiment with the mDL response format using the Apple-provided sample code. If you're building a verifier, ensure your certificate chain validation is robust against revocations and expiration. And if your organization operates in a state considering mDL adoption, push for open‑source tooling and API documentation to reduce integration friction.

What do you think?

How should states handle the trade‑off between issuing digital IDs for convenience and maintaining a strict REVOKed-list update mechanism that doesn't leak user activity?

Did Apple miss an opportunity by not supporting cross‑platform mDL sharing with Android devices via QR or NFC? Would a common trust registry improve adoption or create new attack surfaces?

As a developer, would you rather build your own mDL verification stack or rely on a third‑party SDK like Veriff or Jumio that abstracts the ISO 18013‑5 implementation detail?