- Supports using ENISA material as supervision context for QTSP oversight rather than as a source of new statutory calendar dates.
"supervision of qualified trust service providers"
Track grounded eIDAS and eIDAS 2 milestones for EUDI Wallet delivery, implementing acts, pilots, Architecture and Reference Framework updates, annual supervision reports, and QTSP transitions.
Use the calendar to separate hard legal dates from programme milestones, assign owners, and keep evidence for wallet providers, relying parties, issuers, qualified trust service providers, legal, product, security, and compliance teams.
Structured answer sets in this page tree.
Cited legal and guidance references.
This page is a practical eIDAS calendar, not a generic workflow. It lists only milestones grounded in official EU, Commission, EUR-Lex, ENISA, or ETSI material in the source set, and flags dependent dates where the legal trigger is an implementing act rather than a standalone calendar day. Timings in this page are source-linked; verify current legal source language before implementation decisions.
Use one calendar row per legal or programme milestone, with the source, affected owner, evidence to keep, and dependency status. The most important distinction is whether the date is a fixed date in the Regulation, an annual reporting date, a transitional date for trust services, or a programme milestone from the EUDI Wallet implementation track.
Do not treat every EUDI Wallet news update as a compliance deadline. Treat Commission wallet implementing regulations, Article 5a wallet availability dependencies, Article 45 attribute deadlines, annual supervisory reports, and transitional QTSP measures as calendar items. Treat pilots, ARF publications, and reference implementation updates as evidence and readiness signals.
The calendar is useful only if each row tells an owner what changed and what proof to keep. For eIDAS 2, the same date can affect different teams in different ways: a wallet provider tracks certification and core functions, an issuer tracks person identification data and attestations, a relying party tracks registration and data-request controls, and a QTSP tracks Article 24, remote QSCD, certificate, preservation, timestamp, and website-authentication standards.
For dependent dates, record both the legal formula and the operational date used internally. For example, wallet availability should preserve the Article 5a dependency on implementing acts, while programme planning may also reference the Commission's public summary that Member States are to provide wallets by the end of 2026.
Keep two columns in the calendar: one for fixed dates and one for dependent triggers. Fixed dates include dates such as 31 March annual reports, 21 May 2025 implementing-act or guidance deadlines, 21 May 2026 review and transition dates, and 21 May 2027 device-transition expiry. Dependent triggers include wallet availability and authentic-source verification measures that run from the entry into force of specified implementing acts.
This separation prevents a calendar from converting a legal dependency into an unsupported date. Where a source gives a programme shorthand such as end of 2026, keep that shorthand as a planning milestone and preserve the legal dependency beside it.
Before adding a new eIDAS calendar row, classify the source. EUR-Lex legal text supports binding dates and obligations. Commission wallet pages support programme milestones, ARF releases, pilots, technical specification navigation, and policy summaries. ENISA and ETSI material can support security, supervision, and standards context, but should not be used to invent statutory deadlines.
Do not add penalties, thresholds, fines, or national supervision dates unless the grounding source directly states them. For this page, the grounded calendar focuses on EU-level eIDAS and eIDAS 2 dates; Member State wallet launch dates, national supervisory enforcement deadlines, and sector-specific acceptance dates need separate source support before publication.
Use the cited sources listed here to verify obligations and the supporting evidence requirements.
Verify the following areas from the cited sources: eIDAS 2 dates, wallet implementation dependencies, QTSP transitions, and the cited Commission or EUR-Lex sources.
Check whether your wallet, issuer, relying-party, or trust-service calendar separates legal deadlines from programme milestones and has evidence for each row.
"supervision of qualified trust service providers"
"by the end of 2026"
"Publication 10 February 2023"
"non-mandatory"
"same common specifications"
"Publication 04 December 2024"
"four large-scale pilot projects"
"By 21 May 2025"
"European Digital Identity Wallets"