eIDAS Compliance

Create one service record for each eIDAS function the product or supplier performs. The regulation covers notified electronic identification schemes, European Digital Identity Wallets, trust service providers established in the Union, and trust services such as electronic signatures, electronic seals, electronic time stamps, electronic registered delivery, website authentication certificates, electronic attestations of attributes, electronic archiving, validation, preservation, and electronic ledgers.

The record should avoid vague labels such as digital signing or identity verification. Name the exact service, the actor providing it, the country of establishment or wallet ecosystem role, whether qualified status is claimed, and whether the organization is a provider, subscriber, relying party, wallet provider, attestation provider, or customer of a QTSP.

If the organization provides a qualified trust service, the compliance file should be built around supervisory status, conformity assessment, security controls, identity verification, service terms, incident handling, certificate databases where relevant, and termination planning. eIDAS ties qualified status to a supervisory body and to each qualified service granted that status.

A QTSP must be audited at its own expense at least every 24 months by a conformity assessment body and submit the resulting report to its supervisory body within three working days after receipt. The supervisory body may also audit or require an assessment at any time. Treat the two-year interval as a maximum cycle, not a reason to defer reviews after a material service, control, ownership, or threat change.

If the organization relies on a QTSP, procurement evidence should identify the exact qualified service being bought, not only the vendor name. Keep the trusted-list entry, certificate policy or practice statement, qualified service status, conformity or audit evidence supplied by the provider, service terms, limitations, revocation/status service information, and termination or continuity commitments needed to validate historic evidence.

For a relying application, the main compliance question is whether the validation result can be reproduced. Store the signed object, certificate chain, revocation and status responses, validation policy, time of validation, trusted-list version or source, qualified status determination, and final validation report. Do not treat a successful cryptographic check as proof that the result is qualified.

For qualified signatures and seals, the record should show the qualified certificate, whether the qualified signature or seal creation device condition is met, and whether the signer or legal person identity is tied to the certificate required by eIDAS. For qualified electronic time stamps, keep the time-stamp token, issuing authority evidence, clock/UTC basis where available, and validation output.

Commission Implementing Regulation (EU) 2025/1945 has applied since 20 October 2025. It establishes reference standards for qualified-signature and qualified-seal validation and for advanced signatures and seals based on qualified certificates. A conforming process benefits from a presumption of compliance, so the evidence pack should identify the validation policy and report profile used rather than citing the implementing regulation alone.

Use trusted lists as machine-readable evidence for which trust service provider, service type, status, and supervisory context existed when a signature, seal, certificate, or time stamp was validated. The compliance record should keep enough detail to explain why a service was accepted as qualified at the time of validation.

A web badge, certificate screenshot, or supplier statement should not replace trusted-list validation. For qualified services, trusted-list data should be checked regularly for status changes, new entries, withdrawn status, service cessation, or service-type mismatches that would change relying-party decisions.

For EUDI Wallet use, compliance evidence should focus on role, user control, data minimisation, registration, and authentication purpose. A relying party is a person or organization that relies on electronic identification, a European Digital Identity Wallet, another electronic identification means, or a trust service. The product record should show what data is requested, why it is necessary, how the user initiates or approves the presentation, and how relying-party registration or access certificates are managed where applicable.

When a private service provider is legally or contractually required to use strong user authentication, or when a very large online platform requires authentication for access, eIDAS 2 introduces wallet acceptance obligations in the official source scenarios. The evidence should avoid broad claims that every private site must accept the wallet; record the exact legal, contractual, platform, or product trigger.

A usable eIDAS compliance page should end in an evidence pack that another reviewer can test. Keep the legal source, service classification, role map, validation artifacts, trusted-list record, provider due diligence, and change history together. The pack should be specific enough to answer whether the organization provided a qualified trust service, relied on one, or merely used a technical signature or identity feature.

Do not add penalty amounts, legal deadlines, or certification claims unless the source record directly supports them. For unresolved facts, mark the item as needing legal review or supervisory confirmation rather than filling the gap with assumptions.