Credential pooling: when two people answer as one – a serious issue for every EUDI Wallet

Researchers at Sapienza University of Rome have shown a weakness that affects EU Digital Identity Wallets built to the Architecture and Reference Framework (ARF) as it stands today: two people can pool their genuine cards and appear to a service as one person. Nothing is forged, nothing is stolen, nothing is hacked – and the service cannot tell. They call it credential pooling and propose a countermeasure named CRESTA. All credit goes to them: Fooling Relying Parties of the EUDI Wallet Architecture: Credential Pooling Attacks and CRESTA (A. Rufini, I. Visconti, arXiv 2610.41655).

What the researchers found

1. 1One requestA service asks for two cards at once
2. 2Two phonesA relay passes the request to two people
3. 3Two genuine cardsEach phone answers with its own card
4. 4One “person”The service sees one person who does not exist

Imagine an employer’s service that asks for an ID card and a university degree in one request. Ben has no degree, Anna has one. Ben’s phone answers with his own ID card, Anna’s phone answers with her degree, and a small relay program passes both answers on as one. The employer sees a person with Ben’s name and Anna’s degree.

Every card is genuine and every signature is valid. Every key sits in the secure hardware of a real phone. The researchers showed it with two real phones; the extra delay was around a hundredth of a second – too small to notice.

Why it works: a side effect of privacy

EUDI wallets give every card its own keys, and often a fresh copy for every use. That is good for privacy: services cannot follow you from one card or one use to the next.

The side effect: nothing in a presentation of several cards proves that they come from the same phone or belong to the same person. Checks that a phone is genuine do not help – both phones are genuine. The ARF asks for cards to be cryptographically bound together, but does not yet say how.

Who is affected

Every service that combines cards to decide something about one person:

1. Hiring and licensing – ID card plus diploma, professional licence or certificate.
2. Know your customer – ID card plus proof of address or income.
3. Payments – ID card plus payment card or account.
4. Access and benefits – ID card plus membership, entitlement or age.

Services that ask for one card only are not affected. The fraud needs two people who knowingly cooperate – but then it is very hard to spot, because every document is real. That is what makes it serious: it undermines the one promise the EUDI Wallet makes to services – that the cards in front of them belong to the person in front of them.

Going live in December? Fix it first

Member states have to offer their wallets by the end of 2026, and many services are preparing to accept them. Our advice to every wallet provider and every service going live in December: treat credential pooling as a must-fix before go-live, not as a later improvement. Once wallets and cards are in people’s hands, closing the gap is far harder.

The researchers’ countermeasure, CRESTA, shows that it can be done with the standard formats and protocols of the ARF and without giving up privacy. Read the paper, decide how you close the gap, and test it on real phones – secure hardware differs from phone to phone.

What services can do now

1. Ask for all the cards you need in one request – never combine answers from separate sessions.
2. Compare name and date of birth across the cards you receive, and refuse when they do not match.
3. Ask your wallet provider how it binds a person’s cards together – and whether it has been tested against pooling.
4. Follow the ARF on cryptographic binding of cards and update when the rules change.

Privacy first: fixing pooling without giving up privacy

How a wallet closes the gap matters as much as closing it. The obvious routes cost privacy:

1. Attribute matching – name and date of birth are compared across all cards. Then every card has to disclose them in every combined request, even where the service does not need them. It also misses cards without identity data and trips over name variants.
2. Shared keys or identifiers – give all cards the same key or a fixed device ID and they clearly belong together. But every presentation becomes linkable: services could recognise users across services.
3. Everything in the cloud – with all keys held centrally, belonging together is easy to confirm. But the operator then also sees when and where cards are used.

CodeB Wallet puts privacy first. Its protection is designed so that it needs no extra disclosure of name or date of birth, also covers cards without identity data – age proofs, membership cards, tickets –, keeps presentations unlinkable, reports no usage data to a central service, covers the ID card and every other card together, and needs no setup. It is cryptographic, not organisational, and it starts in the phone’s secure hardware.

What we do at CodeB

We treat credential pooling as a go-live requirement for CodeB Wallet. CodeB’s own verification service does not accept cards of different people as one person, and CodeB Wallet has its own protection against pooling. How it works we keep to ourselves – security details are the last thing to hand to someone trying to get around them. What we can say: it uses only the standard formats and protocols of the ARF and keeps your privacy.

CodeB Wallet is built to the EUDI Wallet Architecture and Reference Framework – certification is ahead of us.

Questions about credential pooling

• The paper on arXiv (2610.41655)
• Privacy
• Key facts
• All features
• All articles

Back to the home page