What does eIDAS 2.0 mean for municipalities?
← Back to Knowledge Base

What does eIDAS 2.0 mean for municipalities?

• Yivi Team 13 min read
eIDAS EUDI Wallet municipality digital identity authentic source relying party BRP base registers privacy by design open standards

A practical guide to European digital identity, the EUDI wallet, and what concretely lands on the desks of municipalities, including the literal legal articles.

With the eIDAS 2.0 regulation, officially Regulation (EU) 2024/1183, every European gains the right to a European Digital Identity Wallet (the EUDI wallet). The regulation entered into force on 20 May 2024 and amends the original eIDAS regulation (910/2014). Every member state must make at least one certified wallet available to anyone who requests it by the end of 2026 at the latest.

For municipalities this is not an abstract Brussels file. As a service provider and as an authentic-source holder, municipalities sit at several points in the chain. This article sets out what the regulation concretely asks of municipalities, with the relevant articles included, and where the real choices and risks lie.

The core: municipalities in two roles

The regulation affects municipalities in roughly two roles: as a relying party that accepts wallets and requests data, and as an issuer that delivers verified attributes from an authentic source. The first is a hard obligation; the second depends heavily on the national implementation and on choices still to be made.

1. Relying party: accepting the wallet and requesting data

This is the firmest obligation. For online services that today require login at the substantial or high assurance level (think DigiD), a municipality will soon also have to accept the EUDI wallet if a citizen wants to use it. Recognized identity means from other EU member states may not be refused either.

The VNG (Association of Netherlands Municipalities) and Dutch service providers assume in their planning that this acceptance obligation for (semi-)public service providers will start to apply around 20 November 2026, alongside the existing means DigiD and eHerkenning. The exact date depends on the European implementing acts, but the direction is clear: acceptance becomes mandatory, not optional.

This role comes with a condition: a municipality may not simply request data from a wallet. As a relying party you must register in advance and state which attributes you need. The regulation thereby enforces data minimization: you ask only for what you genuinely need, and the citizen sees and confirms it. The VNG is currently studying what this relying party register should look like for Dutch governments.

2. Issuer: authentic source for attributes

This role is the most underestimated. Some data that citizens want to share via their wallet must be verifiable against the authentic source. For a large part of that data, the municipality is that source, and therefore the party behind the attestations issued about it.

What is an “authentic source”? The definition from the law

The regulation defines the term in Article 3. The text reads:

"‘authentic source’ means a repository or system, held under the responsibility of a public sector body or private entity, that contains and provides attributes about a natural or legal person or object and that is considered to be a primary source of that information or recognised as authentic in accordance with Union or national law, including administrative practice."

— Article 3, Regulation (EU) 2024/1183

Two things stand out here. First, an authentic source does not have to be a formal base register: it is enough that the system counts as a primary source or is recognized as authentic, explicitly “including administrative practice”. Second, a repository or system is required: a permit that exists only as a loose paper decision is not yet an authentic source in itself.

The obligation: making attributes verifiable

The pivot of the issuer role lies in the provisions on electronic attestation of attributes (Article 45e, with Annex VI). The regulation obliges member states to ensure that authentic data from public sources can be electronically verified:

Member States shall ensure, within 24 months of the date of entry into force of the implementing acts referred to in Articles 5a(23) and 5c(6), that, at least for the attributes listed in Annex VI, wherever those attributes rely on authentic sources within the public sector, measures are taken to allow qualified trust service providers of electronic attestations of attributes to verify those attributes by electronic means at the request of the user, in accordance with Union or national law.

— Article 45e(1), Regulation (EU) 2024/1183

This obligation applies at least to the attributes in Annex VI of the regulation:

Annex VI, minimum list of attributes

  1. address;
  2. age;
  3. gender;
  4. civil status;
  5. family composition;
  6. nationality or citizenship;
  7. educational qualifications, titles and licences;
  8. professional qualifications, titles and licences;
  9. public permits and licences;
  10. financial and company data.

Important: this is an obligation at the user’s request, not an obligation to hand out attestations proactively. And the obligation only bites when the attribute actually relies on an authentic source within the public sector.

The PubEAA: a route, not an opt-out

This is where the explanation is often cut too short. The PubEAA (public electronic attestation of attributes) is an attestation issued by, or on behalf of, a public body responsible for an authentic source (Article 45f and Annex VII). Its appeal is that a government can issue attestations about data it already manages anyway, without depending on a qualified trust service provider (QTSP).

The claim that “there is no obligation” is only true of the instrument. The underlying obligation is very real: Article 45e requires member states to ensure that attributes relying on authentic sources within the public sector (at least those in Annex VI) can be verified electronically at the request of the user. Through national implementation that duty lands on the source holders themselves, and for much of that data the municipality is the source holder.

Two things matter here:

  1. It is always at the user’s request. The citizen takes the initiative; nothing is handed out about residents proactively, nor imposed on them.
  2. The choice is in the mechanism, not in taking part. A municipality that holds an authentic source must make the attribute deliverable or verifiable on request. Whether that happens through verification against the source (by a QTSP) or by the municipality issuing PubEAAs itself is an implementation choice. What is not optional is that the attribute can be delivered on request.

So “do we have to issue PubEAAs?” is the wrong question. Issuing PubEAAs is one route and not mandatory in itself, but staying out of it as an authentic source and not making the attribute available at all is not an option.

For which data is the municipality then the source?

In the Dutch system, municipalities are the source holder of several base registers:

  • BRP, the Municipal Personal Records Database: address, age, civil status, nationality, family composition. With this, the municipality covers a large part of the personal data in Annex VI.
  • BAG, the Register of Addresses and Buildings.
  • BGT, the Register of Large-Scale Topography (shared source holding).
  • WOZ, the Valuation of Immovable Property.

For this data, particularly via the BRP, lies the real impact of eIDAS 2.0 for municipalities.

BRP versus the PID: fill in what the PID does not

For the BRP an important nuance applies, because here it overlaps with the PID (person identification data), the core identity that every EUDI wallet receives on issuance. The PID rulebook defines what it contains: name, date of birth, place of birth, and nationality are mandatory, and items such as resident address and gender are carried as optional fields. That data does originate from the BRP, but it is issued centrally as the PID, not by the municipality itself. So there is no point in a municipality trying to attest those same attributes again.

The municipality’s added value lies precisely in the Annex VI attributes the PID does not cover. The PID contains no civil status and no family composition, even though both are on the Annex VI list and the municipality is their authentic source. Dedicated age attributes (such as “over 18”) are not part of the standard PID either; they were deliberately removed. That is where the municipality’s concrete role sits: not duplicating the identity core, but making available the additional, verified facts a wallet cannot otherwise derive from the PID.

And permits?

Annex VI explicitly mentions “public permits and licences”. Many municipal permits (the environmental permit, and general by-law / special-law permits such as event, terrace, market-stall, or Alcohol Act permits) fall under this in principle. Yet for permits there is no separate base register and no legally designated national authentic source.

That does not mean no source exists. Municipalities do record permits in VTH case systems (Permit Granting, Supervision and Enforcement), environmental permits run through the Digital System for the Environment and Planning Act, and for specific domains national registers exist (for example the National Childcare Register). Because the municipality is by definition the primary source of the permits it grants itself, such an administration in principle already meets the legal definition of an authentic source, even without formal base-register status.

So the real hurdle for permits is not the absence of a register, but three other things:

  1. recognition/designation that this system is the authentic source;
  2. standardization, since right now these are hundreds of separate municipal systems;
  3. an electronic verification facility with which a wallet or trust service provider can check the attribute automatically.

The VNG warns in its implementation analysis that if every municipality has to set up verification infrastructure separately for each authentic source, a “complex and hard-to-govern landscape of hundreds of decentralized facilities” will arise, with “very substantial” impact. The aim is therefore to arrange this as centrally as possible (for example via a central provisioning facility on top of the BRP), so that individual municipalities are relieved of the burden.

The timeline in brief

  • 20 May 2024, regulation enters into force.
  • 2024 to 2026, European implementing acts and technical standards (the Architecture and Reference Framework of the EUDI wallet).
  • End of 2026, every member state makes at least one certified wallet available.
  • ~20 November 2026, expected start of the acceptance obligation for (semi-)public service providers (exact date dependent on implementing acts).

The VNG says: wait. But is that wise?

The VNG’s official line is essentially: prepare technically, but hold off on real implementation until the national EDI system and its preconditions are in place. Only once there is a working system, a Dutch wallet, clarity on the acceptance obligation, and sufficient national coverage does action by municipalities become opportune in the VNG’s view. From a governance perspective that is understandable: nobody wants to build on foundations that might still shift.

Yet waiting carries real downsides, and it is fair to ask whether it is the wisest stance.

First, the countries around us are not waiting. France Identité is already running in production, with millions of issued digital identities, and is building rapidly toward a full EUDI wallet, including tests with relying parties and features such as age verification. While the Netherlands waits on its preconditions, other member states are already gaining practical experience with citizens, service providers, and real transactions. Whoever only steps in once everything is settled starts with a deficit in knowledge and routine that does not close by itself.

Second, waiting is a poor plan in a society where social services are under pressure. That is exactly where wallets can make life considerably easier. Think of someone applying for a participation scheme (meedoenregeling) or another benefit: instead of collecting, scanning, and uploading documents, the resident shares precisely the certified data needed in a single action. That lowers the threshold for the people who need the scheme most, and at the same time eases the workload at the counter. Every year of waiting is a year in which that gain goes uncaptured.

Third, there is far more than identification. The debate is almost always about logging in, but wallets have broader uses. Permit issuance around events is a good example: an organizer demonstrably meeting the conditions, a volunteer showing a particular qualification, or a stallholder sharing their registration. These are relatively low-threshold, well-bounded use cases through which a municipality can gain practical experience now, without waiting for the complete system. Starting with use cases like these is a safe way to learn to walk before the acceptance obligation really starts to pinch.

So the message is not “ignore the VNG”, but rather: preparing and experimenting are not mutually exclusive. A municipality that starts small now with concrete, useful applications will be in a much stronger position than one that sat still until the last precondition box was ticked.

What should municipalities do now?

Concretely, and without waiting for the last detail:

  1. Map your digital services that currently require login at the substantial/high level, that is where the acceptance obligation will land.
  2. Follow the relying party register and prepare for registration and for the principle of data minimization.
  3. Determine your role as source holder, especially around the BRP, and connect to national/central facilities instead of building everything yourself.
  4. Keep permits on the radar: no hard obligation yet, but a likely next step once sources are designated.
  5. Think privacy by design from the start: the wallet is about the citizen being in control and minimal data sharing.

Privacy by design: the whole point of the wallet

That last point is no side issue. eIDAS 2.0 shifts control to the citizen: they decide which attributes are shared, with whom, and for how long. Techniques such as selective disclosure, sharing only “over 18” instead of your full date of birth, make it possible to provide services with a minimum of personal data.

That is exactly the philosophy on which Yivi is built: open source, privacy by design, and data sharing the user holds in their own hands. For municipalities now thinking about their role in the wallet era, that is a useful benchmark: the regulation prescribes not only that you accept and provide data, but invites you to do so in a way that maximally respects residents’ privacy.

Sources

This article is a high-level explanation and not legal advice. For application to a specific situation, the final regulation text and the Dutch implementing legislation are decisive.