eIDAS & electronic signatures, explained

1. What is eIDAS?

eIDAS (Regulation EU No 910/2014) is the European Union regulation that governs electronic identification and trust services for electronic transactions across the single market. It came into force in 2016 and gives electronic signatures, seals, timestamps and certificates a single, harmonised legal framework that applies identically in every member state.

Before eIDAS, each country recognised electronic signatures differently. The regulation changed that: a qualified signature created in one member state must be recognised in all the others. For developers, eIDAS matters because it defines exactly what a “valid” signature is — and that definition is what a validation service like Sealium implements.

The technical detail lives in the ETSI standards (PAdES, CAdES, XAdES, JAdES and ASiC), which specify how signatures are embedded in PDFs, XML, JSON and container formats. eIDAS is the law; ETSI is the engineering.

2. Three levels of electronic signature

Not all electronic signatures carry the same legal weight. eIDAS defines three tiers, and the difference between them is the single most important thing a validation result tells you.

A QES is an AdES created with a qualified certificate on a qualified signature-creation device, issued by a qualified trust service provider (QTSP) that appears on a national trusted list. That chain of qualifications is what gives it handwritten-signature equivalence — and it is exactly what is impossible to assert without checking the EU trust lists.

3. How certificate validation works

A signature is only as trustworthy as the certificate behind it. Validating a certificate means answering four questions, in order:

• Integrity— does the signature's cryptographic hash still match the document? If a single byte changed after signing, this fails.
• Chain — can the signing certificate be traced through its issuing intermediates up to a trusted root (a trust anchor)?
• Revocation — was the certificate revoked before it was used? This is checked live via OCSP (Online Certificate Status Protocol) or against a CRL (Certificate Revocation List).
• Time — was the certificate valid at the moment of signing? A qualified timestamp proves when the signature was made, so an expired certificate can still yield a valid signature if it was valid at signing time.

Getting all four right — especially revocation and timestamp reasoning — is where most home-grown validation attempts fall short. A signature with an expired certificate is not automatically invalid; the timestamp decides.

4. The EU List of Trusted Lists (LOTL)

The trust anchors above don't come from your operating system's certificate store. They come from the EU List of Trusted Lists(LOTL) — a master list, maintained and signed by the European Commission, that points to each member state's national trusted list. Every national list enumerates that country's qualified trust service providers and the exact services they are qualified to offer.

This is the mechanism that makes “qualified” a verifiable, machine-checkable property rather than a marketing claim. A certificate earns the QES designation only if it chains to a QTSP that is listed — and listed for the right service type — on a current trusted list. Sealium refreshes the LOTL daily and validates against it on every request.

The LOTL aggregates national trusted lists across the EU and EEA — 31 lists in total, refreshed daily.

5. Hungarian market specifics

Hungary has its own e-administration ecosystem that sits on top of eIDAS, and documents from Hungarian banks, insurers and public bodies routinely use formats that generic validators don't understand.

• KRX — a government container format (a ZIP wrapper) that bundles several signed sub-documents. Validating it means unpacking the container and validating each enclosed PDF or ASiC-E document individually.
• AVDH— “authentication-backed document authentication”, the seal applied by Hungary's central e-government identification service.
• Microsec e-Szigno — one of the principal Hungarian QTSPs; its root CA must be present in the trust store to build certificate chains for Hungarian signatures.
• NMHH — the supervisory authority that publishes the Hungarian national trusted list.

Sealium is the only API platform with native multi-document KRX validation, which is why it is built specifically for the CEE market rather than retrofitted for it.

6. How to choose a validation solution

If you are evaluating a signature-validation service, these are the questions worth asking — the answers separate a real eIDAS validator from a PDF signature checker:

• Does it return the eIDAS signature level (QES / AdES), or just “signed / not signed”?
• Does it validate against the EU LOTL, and how often is the list refreshed?
• Does it perform live revocation checks (OCSP / CRL) and reason correctly about timestamps and expired certificates?
• Does it support the formats you actually receive — PDF, ASiC-E/S, XAdES, CAdES, JAdES and, for the CEE market, KRX?
• Where are documents processed, and are they stored? For regulated workflows, in-memory processing with no document retention is essential.

Sealium answers yes to all five — and returns a structured, audit-ready report you can store, query and defend.