THE TRUST CHAIN / A RELYING-PARTY REFERENCE
What every relying party must check when accepting the EU Digital Identity Wallet
A free, vendor-neutral guide to securing your EUDI Wallet integration. When your bank, PSP or platform starts accepting the wallet under eIDAS 2.0, these are the eight checks that decide whether a presentation can be trusted — and the exact questions to ask whoever built your verifier. Written by Trustwedge, the independent penetration-testing team for the identity path.
Illustrations of general vulnerability classes. Not a representation of any specific wallet, product or provider.
CITIZENWALLETVERIFIERBANK
The EU Digital Identity Wallet moves identity proofing from a document scan to a cryptographically signed credential presented over OpenID4VP, in SD-JWT VC or ISO/IEC 18013-5 mdoc format. That is a security win — but only if the relying party (the verifier) actually performs every trust check. The dangerous failures are rarely exotic exploits; they are checks that are designed into the standard yet shipped switched off, optional, or fail-open, so the verifier returns success while accepting a forged or untrusted credential. Below, each check explains what it is, what goes wrong when it is missing, and the question to put to your vendor.
The eight checks
01TRUST CHECK
1. Issuer trust and the trust list.
The verifier must confirm the credential was issued by an authority on a current, cryptographically signed trust list (LoTL/LoTE, trust anchors).
The risk:if the trust list itself is accepted unsigned or out of date, or if a missing configuration makes the verifier trust every issuer, an attacker-controlled issuer is accepted as genuine.
Ask your vendor:“How do you verify the trust list's own signature and freshness, and what happens if the trust service is unreachable or unconfigured — do you fail closed?”
02TRUST CHECK
2. Credential signature verification.
The verifier must cryptographically verify the issuer's signature over the credential — JWS/COSE over SD-JWT VC, or the Mobile Security Object (MSO) for mdoc.
The risk:if signature verification is skipped, commented out, or delegated to a service that may be disabled, any self-signed or tampered credential is accepted.
Ask your vendor:“Show me where the issuer signature is verified for each credential format, and what the verifier does when verification cannot be completed.”
03TRUST CHECK
3. Revocation and status.
A valid signature is not enough; the credential must not have been revoked or suspended (status list / token status).
The risk:without a revocation check, a stolen, withdrawn or reissued credential keeps working indefinitely.
Ask your vendor:“Which revocation mechanism do you check, how often, and do you accept a credential when the status cannot be retrieved?”
04TRUST CHECK
4. Nonce and audience binding (replay and misdelivery).
Each presentation must be bound to this specific request (a fresh nonce) and to this specific verifier (the audience).
The risk:without nonce and audience binding, a presentation captured elsewhere can be replayed against you, or a presentation intended for another verifier can be redirected to yours.
Ask your vendor:“How do you generate and validate the nonce and the audience for every presentation, and do you reject presentations that don't match?”
05TRUST CHECK
5. Holder (key) binding.
The verifier must confirm the party presenting the credential is the legitimate holder, via the key-binding proof — not merely that a valid credential exists.
The risk:without holder binding, a leaked or shared credential can be presented by someone who is not its subject.
Ask your vendor:“How do you verify key binding / holder binding, and could a valid-but-stolen credential pass without it?”
06TRUST CHECK
6. Selective disclosure integrity and over-asking.
SD-JWT and mdoc let the holder disclose only the claims you need; the verifier must check the integrity of disclosed claims and request the minimum.
The risk:accepting disclosed claims without verifying their digests breaks integrity, and over-asking for attributes creates privacy and AMLR/GDPR exposure.
Ask your vendor:“How do you verify the integrity of each disclosed claim, and how do you enforce data minimisation on what we request?”
07TRUST CHECK
7. Freshness, validity window and algorithms.
The verifier must honour issuance and expiry times, reject stale presentations, and accept only strong, expected cryptographic algorithms (no downgrade, no “none”).
The risk:expired credentials accepted, or an algorithm-confusion/downgrade attack slipping through.
Ask your vendor:“Which validity and algorithm checks are enforced, and are weak or ‘none’ algorithms explicitly rejected?”
08TRUST CHECK
8. Fail-closed configuration.
Every check above must fail closed — deny by default when a check cannot be performed — and the secure behaviour must be the default configuration, not an opt-in.
The risk:a single missing environment variable or a “warning” policy that logs but still accepts turns all the checks above into theatre.
Ask your vendor:“When any trust check cannot be completed, does the verifier deny by default, and is fail-closed the shipped default rather than something we must switch on?”
How to use this
Run these eight questions past whoever built or operates your EUDI Wallet verifier — an in-house team or a third-party platform. Any answer that is vague, or that describes a check as optional or configurable-off, is where an independent test should start. That is the work Trustwedge does: we verify each of these at the source, with file-and-line proof, and map the results to your AMLR and DORA obligations.
FAQ
Who is a “relying party” for the EUDI Wallet?
Any organisation that accepts the wallet to identify or authenticate a user — banks, PSPs, KYC/identity providers, platforms and public bodies. Under eIDAS 2.0, many regulated relying parties must accept the wallet by the end of 2027.
Is the EUDI Wallet secure by default?
The standards are strong, but security depends on the relying party's verifier implementing every check correctly. Most real-world risk is in configuration and fail-open defaults, not in the cryptography itself.
What is a fail-open trust check?
A trust check that, when it cannot be performed (a service is down, a setting is missing, a policy is set to “warn”), accepts the credential instead of rejecting it — while the system still reports success. Fail-closed is the safe opposite: deny by default.
What's the difference between OpenID4VP, SD-JWT VC and mdoc?
OpenID4VP is the protocol for presenting credentials; SD-JWT VC and ISO/IEC 18013-5 mdoc are two credential formats it carries. A verifier must handle the trust checks for whichever formats it accepts.
How does this relate to DORA and the AMLR?
DORA requires regulated firms to test the ICT systems behind critical functions, and the AMLR (applicable from July 2027) governs customer due diligence. A wallet verifier sits inside both, so its security needs independent, evidence-based testing.
Does Trustwedge build verifiers?
No. We only test them. We build no wallet, hub or verifier — that independence is what lets us assess anyone's, and sign an assurance our clients can rely on.