Relying party registration

Why the earlier date is the one that matters operationally

Most planning in this area is anchored on 24 December 2027, when private relying parties in scope must accept wallets. That is the obligation. But it is not the first thing you have to do, and treating it as the start of the timeline compresses the work into the wrong window.

Registration is a precondition, not a formality. An unregistered organisation cannot request attributes from a wallet at all. So the sequence is: register, then integrate, then accept — and registration opens twelve months before the duty lands.

Organisations that treat December 2027 as the whole timeline discover in mid 2027 that they need to register first, and that registration requires decisions they have not made.

What registration actually asks of you

The registration model is built around declaring in advance which attributes you intend to request. That is deliberate: it is the mechanism by which the framework enforces data minimisation, and it means a wallet can refuse to release attributes a relying party never declared.

The consequence is that registration is downstream of a design decision, not an administrative step you can complete while the design is open:

What do you actually need to know about this person? Not what would be convenient. Every attribute you declare is one you must justify, and the instinct to register broadly "in case" runs against the grain of the framework.

For which purpose? The same organisation may need different attribute sets for onboarding, for a high-value transaction and for a support interaction.

In which Member States? Registration is national. An organisation operating across the Union should establish early whether it registers once or several times — and that is a question worth putting to counsel rather than inferring.

How this interacts with what you already have

Wallet acceptance is an additional route, not a replacement. Article 5f(2) applies on the user's voluntary request, so existing identity flows continue.

Three practical implications that get missed:

Your current identity provider may or may not carry this for you. Worth asking now. If they intend to act as an intermediary, the registration and attribute-declaration questions become theirs, and you need to know which model they are building.

Attribute-based verification is a different shape from document verification. A wallet can assert "over 18" without disclosing a date of birth. Systems built to ingest a scanned document and extract fields may not have anywhere to put a cryptographic attestation of a single claim.

Evidence retention changes. If a transaction was authorised on the strength of a wallet-presented attribute, what you keep as evidence is an attestation rather than a document image. That is a records question with a longer tail than the integration.

A proportionate plan

Given genuine uncertainty about wallet availability — 24 of 27 Member States are reported as set to miss the December 2026 issuance deadline — the sensible posture is to complete the cheap items on the critical path and stage the expensive ones against real availability.

Now: establish whether you are in scope, and check the contractual limb of Article 5f(2), not only the statutory one. Many organisations requiring strong authentication do so under contract rather than law, and a law-only reading gives a falsely comfortable answer.

Now: decide your attribute sets by purpose. This is the long pole, it is internal, and it blocks registration.

Late 2026: register in your primary market once registers open.

2027: integrate, scaled to where wallets actually exist in the markets you serve.

What this avoids is the common failure in both directions — building a full wallet integration for a market with no wallets, or arriving in late 2027 unregistered and discovering that registration is not something you can complete in a fortnight.

Questions worth resolving before you register

Registration is quick once the answers exist. These are the answers, and none of them is a technology decision.

Which of our flows require strong user authentication, and why? The why matters more than the which, because Article 5f(2) turns on whether the requirement comes from law or from contract. Most organisations can list the flows and cannot immediately say which obligation drives each one.

What is the minimum we could ask for and still complete the transaction? Not what we ask for today. Document-based verification tends to collect everything on the document because the document is what arrives; attribute-based verification makes you choose. A wallet can assert "over 18" or "resident in Ireland" without disclosing the underlying data, and a declaration built by copying your current form fields wastes that.

Who owns this internally? It sits across legal, identity engineering and whoever owns the customer journey, which in practice means it often sits with nobody. The registration deadline is a useful forcing function for naming an owner.

What do we keep afterwards? If a transaction was authorised on a wallet-presented attestation, your evidence is that attestation rather than a scanned document. Retention schedules written around document images may not describe it, and this is a records question with a longer tail than the integration itself.

Does our identity provider intend to be a registered intermediary? A question for them, now, because the answer determines whether the registration work is yours at all — and the attribute decisions above remain yours either way.

Common questions about relying party registration

When does relying party registration open?

CIR (EU) 2025/848 states "It shall apply from the 24 December 2026." That is a year before the acceptance obligation on private relying parties, which falls on 24 December 2027.

Can we skip registration and just accept wallets?

No. Registration is what permits an organisation to request data from a wallet. Without it there is nothing to integrate against, which is why planning that starts at the 2027 acceptance date tends to run into trouble in mid-2027.

Do we register once for the whole EU?

Registration is organised nationally. Whether a cross-border organisation registers once or in several Member States is a question we would put to counsel rather than answer from the implementing regulation, and it is worth resolving early because it changes the shape of the work.

What if our identity provider handles this?

Then ask them now which model they are building and whether they intend to act as a registered intermediary. The attribute-declaration decisions may still be yours even if the registration is theirs, and those decisions are the part with the lead time.

Is this worth doing if wallets barely exist?

Registration and attribute design are cheap and on the critical path; integration is not. The proportionate answer is to complete the first two and stage the third against actual wallet availability in your markets. That way you are neither building for a market that does not exist nor starting from zero when it does.

Related references

• EUDI wallet acceptance — the December 2027 obligation this is a precondition for
• Identity verification for signers — where identity assurance meets signing
• Electronic signature audit trail — what evidence survives after the transaction