What Is Device Binding, and How Does It Keep a Stolen Digital ID From Being Reused?

Imagine someone gains access to your phone’s storage and copies the file that holds your mobile driver’s license. They now have a perfect duplicate of the data. Why can’t they walk into a store, or log in to a government portal, and use it as you?

The answer is device binding. A verifiable digital credential is only as safe as its tie to the device that holds it, and device binding is the mechanism that makes the copy far less useful to an attacker.

What is device binding?

Device binding is the cryptographic link between a credential and a private key held in the secure hardware of a specific device. When a credential is issued, the wallet generates a key pair. The public key is embedded in the credential by the issuer; the matching private key is created inside the phone’s secure element or hardware-backed keystore and is designed never to leave it.

When you present the credential, the wallet must sign a fresh challenge with that private key. The verifier checks the signature against the public key that the issuer bound into the credential. If the signature is valid, the presenter controls the bound key, and the credential belongs to this holder. This is why the terms device-bound credentials and cryptographic credential binding describe the same property: proof of possession, not just possession of a file.

Device binding is distinct from device or wallet attestation. Attestation speaks to whether the device or app is trustworthy. Device binding proves the credential belongs to this holder’s key. Both matter, but they answer different questions. For the mechanics of how the underlying signatures work, see What Is a Digital Signature, and Why Does It Matter for Government Credentials?

Why does this defeat copy-and-replay attacks?

A copied credential is of little use without the private key. In the ISO/IEC 18013-5 standard for mobile driver’s licenses, the issuer signs a Mobile Security Object (MSO), a signed data structure that includes the device’s public key. At presentation, the wallet produces a DeviceAuth signature over the verifier’s session data using the device’s private key. The verifier validates that signature against the public key in the MSO.

This helps guard against two attacks at once. Cloning is defeated because only the device holding the private key can produce a valid signature, even if an attacker has the full credential. Replay is defeated because each presentation is signed over session-specific data tied to the transaction, so a captured signature is not intended to be reusable in a later transaction.

The same principle governs online presentation. Under OpenID for Verifiable Presentations (OpenID4VP), cryptographic holder binding requires the holder to prove control over the private key associated with the credential at the time of presentation. The verifier sends a fresh, verifier-generated nonce that the holder’s signature must be bound to, along with an identifier for the verifier, so the response cannot be replayed against a different verifier or a later session. Whether the credential is shown in person or across the web, a copy of the credential alone does not let an attacker impersonate the holder. For how online presentation fits the larger picture, see How Do Verifiable Digital Credentials Work? A Non-Technical Explanation.

How device binding raises assurance under NIST 800-63B

NIST Special Publication 800-63B describes authenticator binding as the establishment of “an association between a specific authenticator and a subscriber’s account.” A secure element digital ID relies on the same property the standard requires of a single-factor cryptographic device: an authenticator that encapsulates secret keys that “SHALL NOT be exportable,” meaning they cannot be removed from the device.

That non-exportability is the point. Because the private key is generated and used only inside tamper-resistant hardware, an attacker cannot lift it the way they might copy a password or a file. At the highest assurance level, AAL3, NIST requires cryptographic authenticators to be validated as hardware cryptographic modules that meet FIPS 140 requirements, with substantial physical security protections, in addition to a non-exportable private key and phishing resistance. Device binding is how a phone-based credential can reach higher tiers of authentication assurance, rather than relying solely on data.

What happens if you lose your phone?

This is the obvious follow-up, and it is a fair one. If the credential is bound to a key that never leaves your device, then losing the device means losing the key. That is by design: the person who finds your phone still faces the device’s lock screen and biometric protections, and the credential remains bound to a key they cannot extract or use.

Recovery does not weaken binding. Instead of moving the old key, the issuer revokes the lost credential and re-issues a new one bound to a fresh key in your new device’s secure hardware, after you re-authenticate. The binding is re-established from scratch rather than copied, which preserves the security property. We cover the full process in What Happens to Your Digital ID If You Lose Your Phone?

Security and control, held together

Device binding is a quiet piece of infrastructure, but it carries a lot of weight. It is what helps a verifiable digital credential resist copying and replay, what supports higher authentication assurance under NIST 800-63B, and what keeps a lost phone from becoming a stolen identity. Just as importantly, it keeps control with the holder: the key lives on your device, under your lock screen, used only when you choose to present. That balance, strong security paired with genuine user control, is what makes device-bound credentials well-suited to government use.

How SpruceID implements device binding for government credentials

SpruceID builds the wallet and verification software in which device binding is implemented, including the open-source mobile driver’s license infrastructure we developed with the California DMV and the credential systems we support for public-sector programs nationwide. If your agency is evaluating how device binding fits into a digital ID or mobile credential program, get in touch with our team.

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.