eIDAS 2.0 in 2026: Regulation 910/2014, trust services and the EU Digital Identity Wallet

Origins: from a directive to a regulation

eIDAS was preceded by Directive 1999/93/EC on a Community framework for electronic signatures. After fifteen years four weaknesses were plain. Transposition differed between member states, so a signature recognised in one country was not always recognised in another. Electronic identification fell outside the scope of the rules altogether, so a citizen could not use a national identification means abroad. The catalogue of services covered only signatures - no seals, timestamps or website authentication certificates. And there was no mechanism for mutual recognition of national solutions.

The 2014 regulation answered all of that at once. It entered into force on 17 September 2014 and applies from 1 July 2016 for trust services and from 29 September 2018 for mandatory recognition of notified identification means. It established a single framework for trust services across the Union, a three-tier hierarchy of signatures, an extended catalogue of services and a public list of qualified providers. Choosing a regulation rather than a directive was not accidental: it removed the source of the earlier divergence, because there was no longer anything to transpose.

The amendment of 11 April 2024 ^[2] shifted the centre of gravity from the document to identity. It introduced the European Digital Identity Wallet, whose provision is the state's duty and whose use is the citizen's choice. It added a mechanism for disclosing selected attributes instead of whole documents, extended the catalogue of trust services with attestations of attributes, electronic archiving and electronic ledgers, tightened the requirements on providers, and obliged designated entities to accept the wallet.

The dates deserve care. The amendment entered into force on 20 May 2024, but the deadlines for the obligations are not counted from that date - they run from the entry into force of the Commission's implementing acts ^[10], adopted at the end of 2024. From that follow the two different dates discussed below: the obligation on member states to make the wallet available, and the obligation on designated entities to accept it, a year later.

Two pillars: identification and trust services

The regulation combines two fields that are easily confused, because both concern "electronic confirmation". The first pillar answers who the person on the other side is; the second, whether a document is authentic and unaltered.

Electronic identification rests on notification. A member state notifies the Commission of a national identification scheme, and after notification the other states must recognise it in their public services at the corresponding level. Poland has notified one scheme - the Public Electronic Identification System, announced on 19 April 2023 ^[12] - covering two means: the trusted profile at substantial level and the personal profile stored in the electronic layer of the national identity card at high level. The mObywatel application does not appear in that notification as a separate identification means, which is a frequent source of confusion.

Trust services are electronic services normally provided for remuneration, whose catalogue the 2024 amendment set out in article 3(16) as fourteen activities. They cover issuing and validating certificates for signatures, seals and website authentication, creating and validating signatures and seals themselves, their preservation, management of remote signature creation devices, issuing and validating attestations of attributes, timestamps, registered electronic delivery together with validation of the data it carries, electronic archiving, and recording data in an electronic ledger. The last four - attestations of attributes, remote signature devices, archiving and the electronic ledger - are new, and they set the direction of the market for the coming years.

Levels of assurance for identification

Article 8 divides electronic identification means into three levels of assurance, and the detailed technical and procedural requirements for each are in Implementing Regulation 2015/1502 ^[11]. The difference between levels concerns two things at once: how identity was verified when the means was issued, and how strong the authentication is on each use.

Low assumes limited certainty about identity. One authentication factor is enough, and identity verification may be remote, from document data. It suits services where the consequences of impersonation are slight - access to information forms or bulletins.

Substantial requires authentication based on at least two different factors among knowledge, possession and inherence, and identity verification on issue in a way equivalent to a face-to-face check - by video verification against a document, say, or confirmation through a bank. The Polish trusted profile is notified at this level.

High adds three requirements: identity confirmation against an authoritative source with the physical presence of the person or an equivalent procedure, protection of the means against copying and manipulation, and authentication resistant to impersonation. In practice this is delivered by a cryptographic element in a card or in a device's secure module. The personal profile from the electronic layer of the identity card is notified at this level. Two meanings of the word "qualified" are worth keeping apart: high is a level of electronic identification, whereas qualified status attaches to trust services - two independent categories, and holding one does not imply the other.

The recognition rule is simple and works in one direction. A service requiring substantial must accept means notified at substantial and high; a service requiring high accepts only means at that level; a service requiring low accepts all three.

Qualified and non-qualified services

The most important distinction in the second pillar runs between qualified services and the rest, and its essence is the burden of proof. A non-qualified service may be supplied by any provider; no legal presumption attaches to it, so in a dispute a court weighs its evidential value like any other evidence. Such services are cheaper and sufficient in many uses - a typical example being advanced signatures in internal document workflow systems.

A qualified service may be supplied only by a provider granted that status by the national supervisory body and appearing on the trusted list. The requirements are markedly higher: a mandatory audit at least every 24 months by an accredited conformity assessment body, conformity with ETSI standards - including the general standard EN 319 401 ^[4] and those specific to the service - liability insurance, certified cryptographic devices, documented policies and procedures together with a continuity plan, and entry on the trusted list.

In return the legislator grants a legal effect that removes the need to prove anything. A qualified electronic signature has, under article 25(2), legal effect equivalent to a handwritten signature throughout the Union. A qualified seal enjoys a presumption of the integrity and authenticity of origin of the data, and a qualified timestamp a presumption of the accuracy of the date indicated and of the integrity of the data at that moment. It is those presumptions, rather than the technology itself, that justify the difference in price.

Status can be verified through the trusted list ^[6]. Each member state publishes a list of its qualified providers in XML conforming to ETSI TS 119 612, and the Commission provides a consolidated browser. Checking a provider there before signing a contract takes a minute and is the only reliable way to confirm that the service offered really is qualified.

Three levels of electronic signature

The regulation builds a hierarchy in which each level contains the requirements of the one below. A simple electronic signature, defined in article 3(10), is data in electronic form attached to or logically associated with other data and used by the signatory to sign - so a scanned image of a signature, a word in a message or a ticked box all qualify. No presumption attaches to it, but article 25(1) guarantees that it cannot be denied legal effect or admissibility as evidence solely because it is in electronic form. That is a minimum guarantee, not equivalence with a handwritten signature.

An advanced electronic signature must meet the four conditions of article 26: be uniquely linked to the signatory, allow the signatory to be identified, be created using data under the signatory's sole control, and be linked to the signed data in such a way that any subsequent change is detectable. It is usually implemented as a cryptographic signature with a certificate, though the certificate need not be qualified. Its evidential weight is clearly greater than a simple signature, but it still falls to the court to assess.

A qualified electronic signature meets every condition of an advanced signature and is additionally created using a qualified signature creation device - a cryptographic card, a token or a compliant remote solution - based on a qualified certificate issued by a qualified provider. Only it has effect equivalent to a handwritten signature, and only it must be recognised in every member state.

In Polish practice a qualified signature is required, among other things, for concluding an employment contract remotely, for most filings with the National Court Register and for electronic court submissions; it is also used in invoice workflow and in notarial documents drawn up electronically. The range of those uses is widening gradually, so for a particular act it is worth checking the specific provision rather than relying on a general rule.

Formats are a separate matter, because they determine whether a signature will still be verifiable in a few years. The PAdES standard embeds a signature in a PDF and dominates commercial practice. XAdES signs XML documents and appears in administrative systems. CAdES is a general format tied to no particular document type, and JAdES is a newer format for interfaces exchanging JSON data. The format should be agreed with the recipient, because not every system verifies all four.

Electronic seals and timestamps

The electronic seal, governed by articles 35 to 40, is the counterpart of a signature for legal persons. The difference is not formal: a signature identifies a particular human being and expresses their will, while a seal identifies an organisation and confirms the origin and integrity of a document. A seal therefore suits documents issued in bulk and automatically - invoices, certificates, messages exchanged between systems - where naming a natural person would be artificial. Like a signature, a seal comes in simple, advanced and qualified forms, and the last enjoys a presumption of the integrity of the data and the authenticity of its origin.

A timestamp, described in articles 41 and 42, attests that particular data existed at a given moment. A qualified timestamp, issued by a qualified provider from an accurate time source linked to coordinated universal time, enjoys a presumption of the accuracy of the date and the integrity of the data. Its importance is greater than the simplicity of the mechanism suggests: it is the timestamp that allows you to show a signature was made while the certificate was valid, and so to preserve the evidential weight of a document even after that certificate expires or is revoked. Without one, a document signed with a qualified signature becomes hard to verify over time, which matters directly for long-term archiving.

Website authentication certificates

The qualified website authentication certificate, governed by article 45, is the counterpart of the certificate used in TLS, but issued under the supervision of a member state and attesting the identity of the entity running the site in line with the regulation's requirements. What sets it apart from commercial extended validation certificates is precisely the supervisory regime and the resulting legal presumption, not the technology.

This provision was the subject of one of the sharpest disputes during the amendment. Browser makers argued that requiring trust in certificates designated by member states would weaken their ability to react quickly to abuse in the certificate infrastructure. The version adopted places two obligations on browsers - to recognise such certificates and to present the entity's identity data in a user-friendly way - but includes a safety valve: in exceptional circumstances, faced with justified concerns about a breach of the security or integrity of the certificates, a browser may take precautionary measures while informing the Commission and the competent authorities.

The practical uses today are narrower than expected. The clearest is in payments, where qualified certificates serve for mutual identification of institutions in open banking interfaces. Beyond that they appear in public administration services where the identity of the site's issuer carries evidential weight, and as an element of demonstrating control over communications in the financial sector (see the DORA article).

Qualified providers in Poland

The Polish trusted list ^[13] names the providers granted qualified status by the supervisory body, which is the minister responsible for digitisation. According to issue 160 of 3 June 2026, nine entities hold that status, but the range of their services varies widely and appearing on the list settles nothing by itself.

Six of them issue qualified certificates. The widest range belongs to Asseco Data Systems, trading as Certum - certificates, timestamps, validation, preservation of signatures and seals, and registered delivery. The Polish Security Printing Works, trading as Sigillum, issues certificates and timestamps, runs remote signature and seal creation devices and provides registered delivery. The National Clearing House, trading as Szafir, offers certificates and timestamps. Enigma Systemy Ochrony Informacji, trading as CenCert, issues certificates and timestamps and provides validation and remote signature devices. EuroCert issues certificates and timestamps, and Unizeto Technologies issues qualified certificates. The remaining three - Poczta Polska, Autenti and a further company - provide only qualified registered electronic delivery, one of them also validation.

Two practical notes are a frequent source of costly mistakes. First, a brand is not the same as an entity: CenCert belongs to Enigma, while EuroCert is a separate company, so a contract signed "with CenCert" in fact binds a different firm than the buyer supposes. Second, before purchasing, check not only that the provider is on the list but that it holds qualified status for the specific service - a provider qualified for delivery need not be qualified for signature certificates.

Obtaining the status is a multi-stage process. The entity must be a legal person with adequate organisational and financial resources and liability insurance, prepare policies, procedures and a continuity plan conforming to ETSI EN 319 401 ^[4] and to the service-specific standards, pass an audit by an accredited conformity assessment body, notify the supervisory body with that assessment report, obtain the status and entry on the trusted list, and then submit to audits at least every 24 months. Entry to this market is expensive precisely because the cryptographic infrastructure, the first audit and the insurance all have to exist before the status is granted. Price lists for end customers are published by the providers themselves and change independently, so the only sensible source of prices is the current list of a particular provider.

The European Digital Identity Wallet

The digital identity wallet is the most visible change introduced by eIDAS 2.0 ^[2]. The structure of the obligation is asymmetric: making the wallet available is the member state's duty, while using it remains the citizen's choice and nobody can be compelled.

The wallet is to hold the national identification means and attestations of attributes - professional qualifications, diplomas, a driving licence, vehicle data, prescriptions or banking data - and to allow a qualified signature to be created and authentication in public and private services. Its most interesting property, though, is how data is disclosed. Instead of showing a whole document, the user is to disclose only the attribute needed in the situation - confirmation of being over eighteen, say, rather than a full date of birth. The Commission has announced mechanisms allowing a condition to be confirmed without revealing the attribute value itself. For data protection this is a qualitative change: it delivers the minimisation principle at the level of architecture rather than declaration (see the GDPR article).

The architecture is described in the Commission's reference framework ^[5], which separates the roles: the wallet instance is the application on the user's device, the wallet solution covers it together with its back end and management, the wallet provider is the state or an entity it authorises, the issuer issues attestations of attributes, and the relying party receives and verifies them. Separating those roles is meant to prevent any one entity from seeing the whole of a user's activity.

Poland is building its wallet on the mObywatel application, with the legal layer to come from an amendment to the act on trust services and electronic identification ^[3], which will set out among other things the national sets of data identifying a wallet user, separately for natural and legal persons. The deadline in the regulation for member states to make the wallet available falls on 24 December 2026. It is reasonable to assume that the first release will cover a limited catalogue of attributes and that expanding it will take longer.

The obligation to accept the wallet is governed by article 5f and separates three situations. Public bodies that require electronic identification for access to their online services must accept the wallet too. Designated private sectors - transport, energy, banking and financial services, social security, health, drinking water, postal services, digital infrastructure, telecommunications and education - are covered where the law requires strong customer authentication of them, excluding micro and small enterprises. The third group is very large online platforms designated under the Digital Services Act; a frequent error is extending the obligation to all websites. These obligations apply from a later date than the wallet's availability - 24 December 2027 - giving the entities concerned a year to prepare. In every case the wallet is used at the user's request, so for a bank or an operator it means adding a new path alongside the existing ones, not replacing them.

The security requirements for the wallet are correspondingly high. Cryptographic material is to be held in a hardware element of the device, user authentication based on biometrics or a strong code, communication with the relying party encrypted and mutually authenticated, and the whole solution certified before launch. A separate and technically harder requirement is that third parties must not be able to link different transactions of the same user.

Supervision and the national trust infrastructure

It is worth starting by correcting a widespread confusion. In the eIDAS context the abbreviation NCCB, meaning national cybersecurity certification authority, is sometimes invoked. It comes from the Cybersecurity Act, Regulation 2019/881, and concerns an entirely different system - European certification schemes for products and services. Supervision of trust services in Poland rests with the minister responsible for digitisation, under article 27(1) of the act of 5 September 2016 on trust services and electronic identification ^[3].

The same act charges the minister with ensuring three elements of the national trust infrastructure operate: a public electronic register of trust service providers, the trusted list published as an XML file in ETSI TS 119 612 format, and the national certification centre, which issues qualified providers the certificates used to verify their signatures and seals and publishes revocation lists. At the request of the President of the National Bank of Poland the minister may authorise the central bank to carry out the national certification centre's tasks and to maintain the register and the trusted list.

The supervisory body's powers cover granting and withdrawing qualified status together with entry on and removal from the trusted list, inspections of providers by its own auditors, demands to remedy irregularities, financial penalties, and cooperation with supervisory bodies of other member states. The act further governs the procedure for entry, sanctions for providing services as qualified without authorisation, and the national electronic identification scheme and its supervision.

The heart of supervision, though, is the periodic audit. Article 20(1) of the regulation requires qualified providers to be audited at their own expense at least every 24 months by an accredited conformity assessment body. The examination covers conformity with ETSI standards including EN 319 401 ^[4], the cryptographic measures and infrastructure in use, organisational procedures, personnel security, business continuity and incident management. The report goes to the supervisory body, and a negative outcome can lead to withdrawal of the status - a real sanction, because it means losing the basis of the business rather than merely paying a fine.

Relationships with other legislation

Qualified trust service providers operate at the intersection of several regimes at once, and it is they who carry the greatest compliance burden. Under the GDPR ^[7] they are controllers of personal data: they process identification data when issuing a certificate, data relating to the act of signing itself and, in the case of the identity wallet, potentially the full spectrum of attributes. The data protection requirements apply to them in full, alongside the sector-specific ones (see the GDPR article).

Under the NIS2 directive ^[8] trust service providers belong to the digital infrastructure sector of annex I and - importantly - are covered regardless of size, so including where they are small enterprises. The result is a double track of obligations: the full catalogue of risk management measures from article 21 of the directive, and incident reporting both to the relevant response team and to the trust services supervisory body. The Polish national cybersecurity system act sets trust service providers a shorter deadline for reporting a significant incident - 24 hours from detection (see the NIS2 article). The documentation for both regimes can be maintained jointly if it is built on an information security management system conforming to ISO/IEC 27001 ^[9].

Two further links are narrower. Some wallet implementations use facial image comparison when confirming identity, which falls within the scope of the artificial intelligence rules and requires both regimes to be satisfied in parallel (see the AI Act article). Financial institutions using qualified signatures, seals and certificates are in turn subject to digital resilience requirements, and providers serving that sector may fall under oversight of critical third-party ICT service providers (see the DORA article).

What to check before deploying

The first decision is what the organisation actually needs. Establish which level of assurance matches the risk of the service, and whether a qualified signature, a seal or a website authentication certificate is required - those three solve different problems and are often ordered interchangeably. Only then does the choice of provider follow, whose status has to be confirmed on the trusted list, and for the specific service.

The second group of decisions is technical. Systems must be able not only to create but to verify signatures in the formats that will actually arrive from counterparties, and to check a provider's status against the European list rather than a local copy from last year. A cryptography policy covering certificate management and renewal before expiry is needed too, and for documents with a long retention period, qualified timestamps, without which the evidential weight expires with the certificate.

The third group concerns what is coming. The organisation should check whether it falls among the entities obliged to accept the identity wallet from 24 December 2027 and, if so, plan the integration as an additional path alongside the existing ones, including support for selective attribute disclosure. It is worth keeping the whole compliance documentation as part of an information security management system ^[9], because otherwise the same work gets done three times - once for eIDAS, once for NIS2 and once for the GDPR.