eIDAS 2.0 Architecture And Reference Framework (ARF)

How the eIDAS 2.0 Architecture and Reference Framework works

The ARF is the technical blueprint that turns the eIDAS 2.0 legal model into an interoperable digital identity system. It defines the common architecture, trust boundaries, message flows, and presentation patterns that allow wallets, identity providers, relying parties, and trust services to exchange identity data in a consistent way across regulated use cases.

Its main value is coordination. Instead of each ecosystem designing its own wallet interaction, the ARF provides a shared reference for how identity attributes are requested, issued, presented, and verified. That makes cross-border acceptance possible while keeping the design anchored to the regulatory rules set out in eIDAS 2.0 and its implementing acts. eIDAS 2.0 — EU Digital Identity Framework

Wallets, relying parties and trust services

The ARF is most useful when read as an interaction model rather than a product specification. Wallets hold and present credentials, relying parties consume those presentations, identity providers assert identity or attributes, and trust services support the assurance layer around signing, validation, and status checking. The framework exists so those actors can interoperate without inventing bilateral integrations for every relationship.

That interoperability also creates policy consistency. A relying party can evaluate a wallet presentation against a common set of trust assumptions, while issuers and wallet providers can design to the same baseline for registration, certificate handling, and credential presentation. For readers preparing an implementation, NHIMG’s eIDAS 2.0 and the European Digital Identity Framework Guide is the broader regulatory companion, while the EUDI Wallet Architecture and Reference Framework Guide is the more detailed architecture reference.

Assurance, authentication and credential presentation

The ARF matters because digital identity trust is not only about who issued a credential, but how much confidence the relying party can place in the full transaction. It therefore links assurance levels, authentication choices, wallet presentation, and verification logic into one operating model. In practice, that means the architecture has to preserve cryptographic integrity and provenance while also supporting selective disclosure and user-mediated presentation.

This is where implementation detail becomes security-critical. If authentication strength, issuer trust, or presentation verification are handled inconsistently, a wallet ecosystem can fragment into incompatible assurance interpretations, or allow weaker verification paths to be accepted as equivalent to stronger ones. The ARF exists to reduce that drift by standardising how these trust decisions are expressed and consumed.

NHIMG’s Identity reference architecture for workforce, customer and non-human identities is useful context for the broader trust-boundary model, and the AWS Multi-Account Security Reference Architecture Guide shows how reference architectures translate abstract trust decisions into operating controls.

Implementation boundaries and governance implications

The ARF is not the same thing as a wallet product, a national identity scheme, or a relying party onboarding process. It is the connective design layer that helps implementers keep those pieces aligned. That means architecture teams must treat it as a governance artefact as well as a technical one: it defines what must be consistent, where interoperability is expected, and which interfaces need to be stable enough for cross-ecosystem trust.

For practitioners, the key question is whether their implementation preserves the intended trust chain end to end, from issuance through presentation and verification. If one side of the ecosystem shortcuts the architecture, the result is often not a hard failure but a subtle trust mismatch, weaker assurance, or avoidable integration friction. That is why the ARF is best understood as the control plane for interoperability, not just a diagram set.

Risk and Threat Considerations

The main risk in an eIDAS 2.0 wallet ecosystem is trust failure at the boundary between issuance, presentation, and verification. If a wallet, relying party, or trust service implements the ARF inconsistently, attackers can exploit weak verification assumptions, downgrade assurance, or abuse inconsistent onboarding paths to obtain acceptance they should not have.

Failure mechanism: A relying party may trust a presentation format or assurance signal without validating the full chain of trust, including issuer authenticity, credential status, and the intended presentation rules. That creates room for forged, replayed, or improperly accepted identity assertions.

Impact: The outcome can be fraudulent account creation, improper access approval, identity spoofing, or cross-border trust breakdowns that are difficult to detect until abuse is already in progress.

Practitioner Guidance

Why practitioners should care: Treat the ARF as an interoperability contract, not a documentation exercise. The architecture only works when wallet, issuer, and relying-party teams interpret the same trust model in the same way.

Governance implication: Keep architecture, legal, identity, and trust-service owners aligned on which parts of the ecosystem are mandatory, which are optional, and which verification decisions must remain consistent across use cases.

Practitioner takeaway: The safest implementations are the ones that validate the whole trust path, not just the final credential presented by the wallet.

Related resources from NHI Mgmt Group

• Guide: Digital Identity, eID and Identity Wallets Guide
• Architecture and Reference Framework (ARF)
• eIDAS 2.0
• Why does Architecture and Reference Framework (ARF) matter for security teams?
• How do organisations implement an Architecture and Reference Framework (ARF)?