TL;DR: eIDAS 2.0 issuance now depends on proving both wallet app integrity and device-bound key custody, Procivis says. Wallet trust controls must separate runtime checks from hardware-backed key state before sensitive credentials are issued.
Editorial analysis by NHI Mgmt Group, based on content published by Procivis: “Wallet Instance and Wallet Unit Attestation (WIA & WUA) Explained”.
Key questions
Q: Why do hardware-bound wallet keys reduce credential risk?
A: Hardware-bound keys reduce risk because they cannot be exported or easily cloned for reuse on another device.
Q: What breaks when wallet attestation is treated as a single control?
A: You lose the distinction between short-lived software integrity and longer-lived key custody, which are different governance problems.
Q: How should issuers validate a digital wallet before issuing high-assurance credentials?
A: Issuers should require proof that the wallet app is authentic, running on a trusted device state, and backed by secure key storage before binding sensitive credentials.
Practitioner guidance
- Require attestation before issuance Make Wallet Instance Attestation and Wallet Unit Attestation mandatory checkpoints before any sensitive credential is issued to a wallet.
- Separate app and hardware trust decisions Write policy so software integrity, supported device state, and hardware-bound key custody are evaluated as distinct conditions instead of one combined trust score.
- Define revocation triggers for wallet trust Set explicit revocation handling for lost or compromised devices and align token status checks with the wallet unit’s trust lifetime.
Bottom line: The article shows that eIDAS 2.0 wallet issuance depends on explicit trust checks for both the app and the device-backed key store.
Glossary terms: Wallet Attestation, Wallet Unit Attestation, Hardware-Bound Key Custody, Issuance Assurance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Wallet attestation is an issuer-side trust control, not a wallet-side feature. The article makes clear that the issuer must validate both software integrity and device-bound key custody before issuing credentials. That is the correct governance framing because the risk sits at the boundary where a trusted credential is created, not where a user simply presents a request. Practitioners should treat attestation as part of issuance policy, not as optional assurance metadata.
A question worth separating out:
Q: What should identity teams do when a wallet device is lost or compromised?
A: They should revoke the wallet unit’s trust state and check whether any credentials bound to that hardware need to be invalidated. The point is to stop relying on a device once its integrity can no longer be assumed, rather than treating revocation as a generic afterthought.
👉 Read our full editorial: Wallet attestation raises the bar for eIDAS 2.0 issuance