eIDAS 2.0 in 2026: trust services and the EU Digital Identity Wallet

From the 2014 Regulation to eIDAS 2.0

The original eIDAS Regulation entered into force on 17 September 2014. Its trust-service provisions became applicable from 1 July 2016, and mandatory cross-border recognition of notified electronic identification means followed from 29 September 2018.

The 2024 amendment entered into force on 20 May 2024. It introduced the European Digital Identity Wallet, selective disclosure of attributes, qualified electronic attestations of attributes and additional trust-service categories. It also strengthened requirements for providers and created obligations for specified public and private relying parties to accept the Wallet where the statutory conditions are met.

The important deadlines do not run simply from 20 May 2024. Article 5a and related provisions link several deadlines to Commission implementing acts adopted at the end of 2024. The first package entered into force on 24 December 2024. As a result, Member States must provide at least one Wallet by 24 December 2026, while specified private relying parties have a later acceptance deadline, generally 24 December 2027.^[10]

Two pillars: identification and trust services

Electronic identification answers the question "who is the person accessing the service?" Trust services answer different questions: who signed or sealed a document, whether data existed at a given time, whether an electronic delivery took place, or whether a website certificate can be trusted.

The distinction matters. An electronic identification means is not an electronic signature. Logging in with a notified eID can establish identity, but it does not automatically create a signature on a document. Conversely, a qualified signature proves the act of the signatory in relation to signed data; it is not a general-purpose login mechanism.

Electronic identification assurance levels

The eIDAS system uses the assurance levels low, substantial and high. Implementing Regulation (EU) 2015/1502^[11] defines minimum technical specifications and procedures for those levels. A Member State that notifies a scheme under Article 9 enables cross-border recognition under the conditions of eIDAS.

Poland has notified its Public Electronic Identification System.^[12] The exact assurance level and recognition requirements of a particular means should be checked in the notification and current national documentation rather than inferred from the product name.

A service requiring substantial assurance must accept notified means that satisfy the applicable cross-border recognition rules at substantial or high level. A service requiring high assurance can require the high level. These rules should not be confused with the term "qualified", which belongs to trust services.

Electronic signatures: simple, advanced and qualified

An electronic signature is data in electronic form attached to or logically associated with other electronic data and used by the signatory to sign.

An advanced electronic signature must be uniquely linked to the signatory, capable of identifying the signatory, created using signature-creation data under the control of the signatory with a high level of confidence, and linked to the signed data so that subsequent changes are detectable.

A qualified electronic signature is an advanced signature created by a qualified electronic signature creation device and based on a qualified certificate. Article 25 gives it the legal effect equivalent to a handwritten signature and requires recognition of qualified signatures based on qualified certificates issued in other Member States.

The legal effect of a non-qualified electronic signature cannot be denied solely because it is electronic or because it does not meet qualified-signature requirements. However, equivalence with a handwritten signature is a specific statutory effect of the qualified signature.

Electronic seals, time stamps, delivery and website certificates

Electronic seals are designed primarily for legal persons and support integrity and origin of data. They are not simply "company signatures" in the sense of a declaration of intent by a natural person.

Electronic time stamps bind data to a particular time and provide evidence that the data existed at that time. Qualified time stamps receive the specific presumptions established in eIDAS.

Electronic registered delivery services provide evidence relating to sending and receiving electronic data and protect against risks of loss, theft, damage or unauthorized alteration. Qualified services receive additional legal effects under the Regulation.

Website authentication certificates help authenticate websites and entities. Their legal category is distinct from TLS security as a whole: a certificate does not by itself prove that the web application is secure.

Trust service providers and qualified status

A trust service provider (TSP) may provide trust services without all of them being qualified. A qualified trust service provider (QTSP) is a provider that has been granted qualified status for one or more qualified trust services and appears on the national trusted list.

Qualified status is service-specific. The fact that a company appears on a trusted list does not mean every service it offers is qualified. Users should check the exact service entry and status on the EU Trusted List Browser or the national trusted list.^[6][13]

Qualified providers are subject to stricter legal, organizational and technical requirements. They use relevant ETSI standards, maintain security and continuity arrangements, protect cryptographic material, cooperate with supervision and undergo conformity assessment by an accredited conformity assessment body. Article 20 requires a conformity assessment at least every 24 months, with the report submitted to the supervisory body.^[1][4]

ETSI EN 319 401 is an important general policy standard for trust service providers. The applicable version should always be verified; in 2026 ETSI published EN 319 401 V3.2.1.^[4]

The most important distinction in the trust-service layer is not between one brand and another, but between qualified and non-qualified status. A non-qualified trust service can still be technically strong and legally useful, but it does not receive the specific legal presumptions that eIDAS grants to qualified services. In a dispute, its evidential value is assessed on the ordinary rules of evidence.

Trusted lists

Each Member State publishes a trusted list identifying qualified providers and qualified services. EU tools aggregate those lists. A relying party should not treat a logo, marketing claim or certificate file as sufficient evidence of qualified status; the trusted-list entry is the authoritative operational reference.

The Polish trusted list is published in the European trusted-list format.^[13] The set of providers and services can change, so an article or audit report should identify the date on which the list was checked.

Signature formats and long-term validation

The legal level of a signature and the technical format are separate questions. PAdES is commonly used for PDF documents, XAdES for XML, CAdES as a more general cryptographic container, and JAdES for JSON-oriented environments. The receiving system must be able to validate the format it accepts; a legally qualified signature that cannot be technically validated by the recipient is an operational failure even if its legal status is clear.

Long-term evidence also requires more than checking a certificate on the day of signing. For records that must remain verifiable for years, the organization should consider qualified time stamps and long-term validation data. A qualified time stamp can help prove that signed data existed at a particular time and that the signature was created while relevant trust material was valid. The retention design should therefore cover signature validation, revocation information and preservation of evidence, not only storage of the PDF itself.

Qualified providers in Poland

The Polish trusted list^[13] identifies providers that have been granted qualified status by the competent supervisory authority. In the edition of 27 August 2026, the list contained nine providers, but their qualified service portfolios differed significantly. This is why procurement should start from the required service and only then from the provider name.

Because the list is dynamic, the current service entry should always be verified immediately before procurement or legal reliance. Brand names can also obscure the legal counterparty. CenCert is a brand used by Enigma Systemy Ochrony Informacji, while other brands may belong to separate companies or corporate groups. The contract, trusted-list entry and certificate policy should therefore identify the legal entity, the exact qualified service and the applicable policy identifier.

Supervision and the national trust infrastructure in Poland

A frequent terminology mistake is to confuse eIDAS supervision with the national cybersecurity certification authority created under the EU Cybersecurity Act. They are different systems. In Poland, supervision of trust services is exercised by the minister competent for digital affairs under the Act of 5 September 2016 on trust services and electronic identification.^[3]

The same national framework provides for a public register of trust service providers, the national trusted list and the national certification centre used within the domestic trust infrastructure. The minister may also use statutory mechanisms involving the National Bank of Poland for specified national certification functions.

Supervisory powers include granting and withdrawing qualified status, updating the trusted list, carrying out or ordering controls, requiring remediation and applying the national enforcement mechanisms. The most consequential outcome for a QTSP is not necessarily a fine: loss of qualified status can remove the legal basis on which the qualified service is offered.

The recurring conformity assessment under Article 20 is therefore central. It reviews not only cryptographic algorithms but the organization, personnel, continuity, incident handling, operational controls and service-specific technical requirements of the provider. A provider that passes one audit does not receive permanent qualification; continued status depends on ongoing conformity.

European Digital Identity Wallet

The Wallet is the most visible feature of eIDAS 2.0. Its design is asymmetric: Member States must provide at least one Wallet solution, while use by individuals is voluntary. A person should be able to obtain and present identification data and electronic attestations of attributes and, where applicable, use signature functionality without being forced to reveal more data than necessary.

The Architecture and Reference Framework published by the Commission^[5] distinguishes wallet solutions, wallet instances or units, wallet providers, issuers of person identification data and attestations, and relying parties. The separation of roles is important for privacy and accountability.

The implementing acts adopted in late 2024 cover core functionality and integrity, protocols and interfaces, person identification data and electronic attestations of attributes, and notifications to the Commission. Regulation (EU) 2024/2977^[10], for example, defines rules for issuance of identification data and attestations to Wallets and was amended in 2026; the current consolidated version should be used for implementation.

Security requirements include secure cryptographic components, integrity protection, authentication of the user, controlled interfaces, privacy safeguards and certification requirements. The legal framework does not justify reducing EUDIW security to the phrase "keys must always be stored in one specific hardware element". Implementations may use different secure hardware and software architectures as long as the applicable legal and certification requirements are met.

Wallet deadlines and Poland

Member States must provide at least one European Digital Identity Wallet within 24 months of the relevant implementing acts, giving the 24 December 2026 deadline used in current implementation planning.^[10]

Acceptance obligations apply later. Article 5f covers public-sector bodies requiring electronic identification for online services and specified private-sector relying parties where the statutory conditions are met, including sector and strong-authentication criteria and exceptions for micro and small enterprises. Very large online platforms designated under the Digital Services Act form a separate category. These duties should not be generalized to every website or every business.

For the relevant private relying parties, the main planning date is 24 December 2027. Wallet use remains at the request of the user; acceptance adds a path rather than automatically abolishing existing identification methods.

Poland has been developing its Wallet approach around the mObywatel ecosystem. The Polish Act on trust services and electronic identification^[3] supplies the domestic legal framework for supervision and national trust infrastructure and must be aligned with revised eIDAS requirements. Because national implementation work can change quickly, organizations should verify the current legal act and technical integration documentation before procurement or deployment rather than rely on older project descriptions.

Relationship with the GDPR, the AI Act, NIS2 and e-Delivery

GDPR

Processing of personal data under eIDAS remains subject to the GDPR.^[7] Wallet design emphasizes data minimization and user control, but neither the Wallet nor qualified status exempts an organization from lawful-basis, transparency, retention, security or data-subject-rights requirements.

Biometric data requires particular care. GDPR Article 9 applies where biometric data are processed for the purpose of uniquely identifying a natural person. eIDAS can provide the identity framework, but it does not automatically create a GDPR legal basis for every biometric processing operation.

AI Act

The AI Act treats biometric systems according to their concrete use. Some practices are prohibited and certain biometric systems may fall within high-risk categories. It is therefore inaccurate to say that every biometric function used in a Wallet is automatically a high-risk AI system. AI Act analysis is required only where the specific component meets its definitions and classification rules.

NIS2

Qualified trust service providers and certain digital-identity actors can also be subject to NIS2/KSC cybersecurity requirements.^[8] eIDAS governs trust-service and identity requirements; NIS2 governs cybersecurity risk management and incident obligations within its scope. An audit should identify which requirement comes from which legal regime. An ISO/IEC 27001-based information security management system can help organize common evidence and controls, but it does not replace the legal requirements of eIDAS, the GDPR or NIS2.^[9]

Polish e-Delivery

The Polish e-Delivery system is a national electronic-delivery regime that uses legal concepts related to electronic registered delivery but also depends on Polish statutes and implementation rules. An Address for Electronic Delivery is not automatically created for every individual; for many businesses and public entities specific statutory deadlines apply.

For organizations, the important practical lesson is to separate three questions: whether a communication must be delivered through the national e-Delivery system, whether the underlying service is a qualified electronic registered delivery service, and what evidence of sending and receipt the process must preserve.

Audit and security checklist

1. Identify all electronic identification means and trust services used by the organization.
2. Determine which services are qualified and verify them on trusted lists.
3. Check certificate, seal, signature and time-stamp validation procedures, including long-term validation where needed.
4. Review protection of private keys and signing or sealing devices.
5. Assess continuity, incident management, logging and change management of trust-service integrations.
6. For EUDIW, determine whether the organization will issue attributes, provide a Wallet, or act as a relying party.
7. Check whether the December 2026 or December 2027 deadlines actually apply to the organization.
8. Map personal-data processing and GDPR obligations separately.
9. Assess third-party dependencies and the security of APIs and integration components.
10. Retain evidence of the legal and technical versions used in the assessment.