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. Qualified status is not just a marketing label; eIDAS ties it to a supervisory body and to qualified services granted that status.

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 file 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.

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 grounded 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.