Digital identity in the United States is entering a new phase.
Mobile driver’s licenses (mDLs) and other verifiable digital credentials are moving from pilot programs toward real infrastructure used by governments, financial institutions, and online services. At the same time, the security assumptions behind many current identity verification systems are being challenged by generative AI, synthetic identities, and increasingly sophisticated fraud.
To explore how high-assurance digital credentials could work in practice, the National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards and Technology (NIST) launched a collaborative project to demonstrate how mobile driver’s licenses could be used in financial services. The result is a new practice guide describing a working architecture for accepting mDLs during online identity proofing and high-risk transaction authorization.
SpruceID participated in this effort alongside a consortium of financial institutions, technology providers, standards organizations, and state agencies. Together, we built and tested a reference architecture demonstrating how verifiable digital credentials can integrate with existing identity and banking systems.
This post shares a few lessons from that work.
What the Practice Guide Is
The new NIST practice guide documents a reference architecture for using mobile driver’s licenses in financial services. It focuses on a specific problem: how a financial institution could accept an mDL as evidence during online identity verification.
The guide walks through a demonstration environment that shows three key flows:
- Account opening. A customer applies for a financial account and presents an mDL to verify their identity.
- Digital enrollment. After approval, the customer enrolls a phishing-resistant authenticator such as a passkey.
- Step-up verification for high-risk transactions. When a sensitive transaction occurs, the bank can request the mDL again as an additional security signal.
The architecture was built using open standards and commercially available components, including digital wallets, verifiers, identity management systems, and banking services.
The goal was not to prescribe a single implementation pattern, but to demonstrate that standards-based digital credentials can work within real enterprise identity systems.
Why Financial Institutions Were Chosen
Financial institutions are one of the most demanding environments for digital identity.
Banks operate under strict regulatory requirements such as Customer Identification Program (CIP) rules. They must maintain a “reasonable belief” that a customer is who they claim to be. At the same time, they face constant pressure from fraud, identity theft, and synthetic identity attacks.
Traditional identity proofing methods (such as uploading photos of identity documents or answering knowledge-based verification questions) were not designed for the modern online threat landscape.
mDLs introduce a different model. Instead of verifying a photo of a credential, relying parties receive cryptographically signed data issued directly by a trusted authority, such as a state motor vehicle agency. This changes the trust model from document inspection to cryptographic verification.
Because financial institutions represent a high-assurance environment, solving the problem here provides confidence that the same architecture can support many other sectors as well.
What the Architecture Demonstrates
One of the core goals of the NCCoE project was to show how verifiable digital credentials fit into existing enterprise identity systems.
The demonstration architecture includes several key components:
Digital wallets: Applications controlled by the user that store the mobile driver’s license and allow the holder to consent to sharing specific attributes.
Verifiers: Services that request and validate verifiable presentations from the wallet, ensuring the credential was issued by a trusted authority and has not been altered.
Identity management systems (IDMS): Enterprise systems responsible for orchestrating account creation, identity proofing, authentication, and account recovery.
Relying parties: In this case, a banking system that relies on the verifier’s output to complete business processes such as account creation.
In practice, this creates a workflow where a customer can present their mobile driver’s license from their phone while interacting with a banking website on another device. The verifier confirms the authenticity of the credential, and the bank can incorporate those attributes into its existing identity verification processes.
The architecture demonstrates that mDL verification can function as a modular service within a bank’s identity infrastructure, rather than requiring a completely new system.
Lessons from the Build
Building and testing the architecture surfaced several important lessons about the current state of the ecosystem.
1. Integration matters as much as standards
The technical standards behind digital credentials (such as ISO 18013-5 and emerging web presentation protocols) provide a strong foundation. But real adoption depends on how easily these components integrate into existing enterprise identity systems.
Financial institutions are unlikely to redesign their identity stacks around a new credential type. Instead, digital credentials need to plug into systems like identity management platforms, fraud services, and core banking systems.
The NCCoE architecture reflects this reality by placing the verifier and credential workflows inside a centralized identity orchestration layer.
2. User experience is critical
Identity verification flows can easily introduce friction. Banks carefully optimize onboarding experiences because small increases in complexity can cause customers to abandon applications.
The demonstration architecture emphasizes minimizing manual input, clearly communicating what information is requested, and ensuring a smooth interaction between the banking website and the user’s wallet.
Technologies such as the Digital Credentials API are particularly important here, because they allow the browser to mediate interactions between websites and wallets in a consistent and understandable way.
3. mDLs complement existing identity signals
mDLs provide strong identity evidence, but they are not a complete identity verification system on their own.
Financial institutions still require additional attributes such as Social Security numbers or tax identification numbers to meet regulatory requirements. Fraud detection services, device signals, and other risk controls also remain important.
In practice, digital credentials become another trusted signal within a broader identity proofing process, not a replacement for every other mechanism.
What Still Needs to Be Solved
The project also highlighted areas where the ecosystem still needs to mature.
Trust frameworks
Relying parties need clear ways to determine which issuers, wallets, and verifiers they can trust. Establishing interoperable trust frameworks remains a key step toward large-scale adoption.
Standards consolidation
The standards landscape for digital credentials continues to evolve. As implementations move from pilots to production systems, the ecosystem will benefit from consolidation and stability around core protocols.
Wallet trust signals
Financial institutions also need better visibility into wallet security characteristics, such as how user authentication occurs on the device and how credentials are protected.
These are not technical blockers, but they are important areas where collaboration across governments, standards bodies, and technology providers will shape how the ecosystem develops.
From Pilot to Infrastructure
The NCCoE mDL project makes one thing clear: digital credentials have moved beyond theory and into real-world implementation.
Wallets, verifiers, and supporting standards are no longer speculative. They are actively being built, tested, and deployed. Governments are issuing credentials, and organizations across industries are starting to figure out how to incorporate them into actual workflows.
What comes next is less about invention and more about coordination. The focus now is on establishing interoperable trust frameworks, continuing to refine standards, and turning early deployments into something durable and widely usable.
That will require ongoing collaboration across the ecosystem, from issuers and wallet providers to relying parties and standards bodies. The foundation is already there, and the work now is making it cohesive and scalable.
The draft is now open for public comment, and feedback from implementers will play an important role in shaping how these patterns evolve. You can review the guide and submit comments here.
Building digital services that scale take the right foundation.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.