Wallet attestation raises the bar for eIDAS 2.0 issuance

At a glance

What this is: This article explains how Wallet Instance Attestation and Wallet Unit Attestation help eIDAS 2.0 issuers verify that a wallet app is genuine and that its keys are bound to trusted hardware.

Why it matters: It matters because issuers and identity teams need assurance controls that validate the issuing environment before binding high-value credentials to a wallet, rather than assuming the handset and app are trustworthy.

Context

eIDAS 2.0 wallet issuance depends on more than user authentication. Issuers need assurance that the wallet app is genuine, the device is in a trusted state, and the keys used for credential binding are not exportable or cloned.

Wallet Instance Attestation and Wallet Unit Attestation are the two controls used to provide that assurance in the EUDI architecture. They shift the trust decision from the user claim alone to the software integrity, device integrity, and key custody behind the wallet.

For identity programmes, this is a familiar pattern: trust the asserting environment before issuing something that later becomes a high-value identity artefact. The issue is not whether the wallet is convenient, but whether the issuer can safely rely on it.

Key questions

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. The control is not just authentication of the user. It is assurance that the wallet endpoint itself is trustworthy enough to hold the credential.

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. That means the credential remains tied to the original wallet unit, which lowers replay and substitution risk and makes compromise easier to contain if the device is lost or tampered with.

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. A wallet app can be genuine while the device state is still untrustworthy, or the hardware can be sound while the app runtime is compromised. Combining them hides failure modes.

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.

Technical breakdown

Wallet instance attestation and software integrity

Wallet Instance Attestation verifies that the wallet application is the authentic version provided by the wallet provider and has not been modified. It also indicates whether the app is running on a supported device and whether there is evidence of tampering. In practice, this is a software trust signal rather than a user identity signal. The issuer is not proving who the person is here. It is proving that the software endpoint receiving the credential request is a genuine wallet instance operating in a trusted runtime.

Practical implication: issuers should treat app integrity as a prerequisite for credential issuance, not as a post-issuance monitoring problem.

Wallet unit attestation and device-bound key custody

Wallet Unit Attestation goes beyond the app and binds the wallet’s cryptographic keys to certified key-storage hardware on the device. That means the keys cannot be freely exported or cloned, which reduces the risk that a credential can be replayed elsewhere. The attestation is longer-lived than WIA because the hardware binding is more stable than runtime software state. This is a custody control for the key material that underpins the wallet, and it is central to preventing the wallet from becoming a portable secret container.

Practical implication: teams issuing credentials should require evidence of hardware-bound key storage before trusting a wallet for durable identity binding.

Revocation, lifecycle, and trust duration

WIA is typically short-lived because it reflects real-time device and software integrity. WUA can last longer, but it still needs revocation if the device is lost or compromised, often through a token status mechanism. This creates a two-layer lifecycle: short-lived assurance for the app and longer-lived assurance for the hardware-backed wallet unit. The architectural point is that trust is not binary. It decays at different speeds depending on what is being attested, which is why lifecycle policy matters as much as the attestation itself.

Practical implication: issuers need separate expiry and revocation rules for runtime integrity and hardware-backed wallet trust.

NHI Mgmt Group 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.

Hardware binding changes the meaning of credential portability. When a key cannot be exported or cloned, the wallet stops behaving like a generic secret store and starts behaving like a controlled identity container. That matters for eIDAS 2.0 because credential assurance depends on where the key can live, not just on who requested the credential. Identity programmes that ignore the storage layer will overestimate the strength of the wallet trust model.

Short-lived and longer-lived attestation solve different governance problems. WIA answers whether the app is intact right now, while WUA answers whether the wallet unit remains tied to certified hardware over a longer period. Those are not interchangeable controls. The practical implication is that issuers need distinct policy logic for runtime integrity and for durable key custody, especially when credential value increases after issuance.

Ephemeral runtime trust, should be treated as a named control concept for the EUDI wallet model. WIA is about time-bounded software integrity, while WUA is about binding keys to a specific device and making them non-exportable. Together they show that wallet trust is layered, with one control protecting the session boundary and the other protecting the cryptographic anchor. Practitioners should design issuance governance around both layers, not one proxy for the other.

eIDAS wallet governance will increasingly look like high-assurance NHI lifecycle management. Once credentials are issued into a wallet, the issuer is relying on a managed identity container whose trust state must be continuously bounded. That is structurally similar to non-human identity governance, even though the subject here is a human wallet. The implication is that assurance, lifecycle, and revocation logic must be explicit before wallet-based identity scales.

What this signals

Ephemeral runtime trust: eIDAS 2.0 issuers now have to separate app integrity from key custody, because the wallet can only be trusted if both the software instance and the underlying storage boundary are sound. That distinction matters for any programme issuing high-assurance credentials into a managed wallet.

The practical pressure for identity teams is policy clarity. Issuance logic, revocation logic, and device trust logic cannot all be collapsed into one generic approval step if the wallet is going to carry credentials with lasting value.

For practitioners

• 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.
• Align issuance controls with credential value Classify which credentials require short-lived runtime verification and which require longer-lived hardware binding before they can be bound to a wallet.

Key takeaways

• The article shows that eIDAS 2.0 wallet issuance depends on explicit trust checks for both the app and the device-backed key store.
• The main governance lesson is that credential issuance should verify runtime integrity and hardware binding before a wallet receives sensitive credentials.
• Identity teams need separate lifecycle rules for wallet app trust, wallet unit trust, and revocation when devices are no longer reliable.

Key terms

• Wallet Attestation: Wallet Attestation is a statement from a trusted party that a wallet, device, or credential environment meets defined requirements. Verifiers use it to judge whether a presentation comes from an acceptable wallet, so teams should validate attester trust, freshness, and the scope of what the attestation actually covers.
• Wallet Unit Attestation: Wallet Unit Attestation is evidence that a wallet instance or wallet component is genuine and running on trusted hardware or in an approved environment. It helps a verifier distinguish an authentic wallet from a modified or emulated one. Defenders validate the attestation source, freshness, and scope to reduce fraud, cloning, and tampering.
• Hardware-Bound Key Custody: The practice of keeping identity keys inside trusted device hardware so they remain tied to one wallet unit. It reduces export and duplication risk and changes issuance governance because trust must extend to the device’s secure storage layer, not only the application layer.
• Issuance Assurance: The set of checks an issuer uses before binding a credential to a wallet or device. For wallet-based identity, it combines software integrity, device trust, and key-storage confidence so the issuer can avoid creating credentials inside an untrusted runtime.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.