The Architecture and Reference Framework, known throughout the ecosystem simply as the ARF, is the technical specification that translates the legal text of the revised eIDAS Regulation into implementable architecture: protocols, data formats, trust models and security requirements. If the regulation says what must be achieved, the ARF says how it is built — and every wallet, issuer and Relying Party integration ultimately traces back to it.
Where the ARF sits in the regulatory stack
The ARF is produced and maintained collaboratively by the Member States and the European Commission, informed by pilot programmes (the Large-Scale Pilots) that stress-tested early versions against real deployments. It sits between the eIDAS Regulation and its implementing acts on one side, and the actual wallet solutions and reference implementations on the other.
- eIDAS Regulation and implementing acts — the binding legal requirements.
- ARF — the technical architecture and specifications that satisfy those requirements.
- National wallet solutions and reference implementations — concrete software built to the ARF.
The main building blocks
For an integrator, the ARF is easiest to understand as a set of building blocks, each addressing one layer of the trust ecosystem.
- Wallet architecture — the wallet instance, wallet unit attestation, and device binding model that ensures a credential is tied to a specific, genuine wallet.
- Credential formats and protocols — mdoc (ISO/IEC 18013-5) and SD-JWT VC as the standardised presentation formats, exchanged over OpenID4VCI for issuance and OpenID4VP for presentation.
- Trust model — registration, certificate issuance and EU Trust Lists that let any participant verify that another participant is legitimately part of the ecosystem.
- Privacy and security requirements — selective disclosure, unlinkability considerations, and requirements around what issuers and Relying Parties may and may not retain.
- Governance — the processes by which Member States, the Commission and technical working groups propose, review and adopt changes.
The ARF is not a specification you implement once. It is a specification your integration has an ongoing relationship with.
How the ARF evolves
The ARF is versioned and published iteratively rather than frozen at a single release. Changes come from several directions at once: technical working groups refining protocol details, Member States reporting friction from real pilots, and the Commission aligning the framework with implementing acts as they are finalised.
- A change is proposed, often based on interoperability testing or pilot feedback.
- It is discussed and refined with Member State technical representatives and relevant working groups.
- A new ARF version is published, typically with notes on what changed and why.
- Reference implementations and national wallet solutions update to reflect the new version, on their own timelines.
- Relying Parties and issuers are expected to track and adopt changes relevant to their integration.
This means two wallets in production at the same time may be built against slightly different ARF revisions, especially during the current rollout period. A robust integration treats protocol and format flexibility as a first-class requirement, not an edge case.
Conformance: what it actually covers
Conformance in this ecosystem is not a single certificate you obtain once. It spans multiple layers: wallet solutions must pass conformance testing against the ARF's technical specifications, Relying Parties must meet registration and certificate requirements set by national frameworks derived from the ARF, and credential issuers must implement the issuance protocols and status mechanisms the ARF defines.
- Conformance testing typically involves interoperability test suites run against reference implementations and, in some cases, participation in coordinated testing events across Member States.
- Conformance is not permanent: a new ARF version can introduce requirements that an already-deployed integration no longer fully satisfies.
- National supervisory bodies interpret and enforce ARF-derived requirements within their own registration processes, which adds a layer of local variation on top of the shared technical baseline.
What a version change means for your integration
When the ARF moves to a new version, the practical impact for an integrator ranges from negligible to significant depending on what changed. Typical categories include:
- Clarifications — no code change needed, but worth reviewing against your implementation assumptions.
- New optional capabilities — you can adopt them opportunistically, often to improve UX or reduce data requested.
- Changes to mandatory formats, trust model details, or security requirements — these typically require code changes, re-testing, and sometimes re-certification within a defined transition period.
Tracking ARF changes is not a one-off compliance task; it is a recurring engineering input, similar to tracking TLS deprecations or OAuth security best practice updates, except the deadlines are set by regulatory process rather than by your own roadmap.
Reducing the maintenance burden
Organisations integrating directly typically assign a standing owner for ARF and implementing-act monitoring, because missing a mandatory change window can mean a wallet stops accepting your presentation requests without warning. The alternative is to integrate through an intermediary Relying Party that already tracks these changes across every Member State it operates in. This is the model Arkadiz provides: it maintains ARF conformance, format support and trust-model updates on your behalf, so a version change in the framework is absorbed upstream rather than becoming an emergency ticket on your engineering backlog.