Device binding ties a credential to a private key held inside the wallet’s secure cryptographic device or keystore. Presenting it requires proving control of that key, so a copied credential is useless to anybody else. ISO/IEC 18013-5 calls it mdoc authentication, SD-JWT VC calls it key binding.
ARF termReviewed 7 October 2026
Inside the wallet, which belongs to the user and is under their control.
Issuer
Signs credentials: a member state, university, bank or employer
Issuance
EUDI Wallet
Belongs to the user, who decides what to share
Presentation
Relying party
The service that requests and checks the data
Trust layer: who is allowed to sign, and is it still valid?
Rules: the law and technical framework behind it all
At issuance the wallet proves possession of a key and the issuer binds the credential to it. At presentation the wallet signs over the verifier’s nonce with that same key. A verifier checking this signature knows the presentation came from the device the credential was issued to.
This is what separates a credential from a document image. A photographed passport can be replayed by anyone who gets the file. A device-bound credential cannot, because the attacker does not have the key.
It is not uniformly mandatory. PIDs need it, because they sit at Level of Assurance High and that is unreachable without binding to a secure device. ISO/IEC 18013-5 attestations need it too. For SD-JWT VC attestations the ARF recommends rather than requires it, and OpenID4VP lets a verifier insist per request through the require_cryptographic_holder_binding parameter. Checking the signature is itself only recommended on the verifier side, so it is worth being deliberate about.
Do not confuse it with holder binding as the ARF uses that phrase. There, holder binding is a synonym for User binding, the separate question of whether the person presenting a credential is the person it was issued to. Device binding is a precondition for that check, not the check itself.
Defined in
ARF v3.0.0 sections 6.6.3.8 and 6.6.3.9, Annex 2 ISSU_17 and ISSU_27; OpenID4VP
Device binding is why wallet verification resists the attacks that beat document-upload KYC. If your verifier skips the key binding proof, you have thrown away most of the advantage.
