How you sign today, and why that stops being enough

Almost nobody who signs electronically thinks about algorithms: they think about a national eID card and a PIN, or a cloud-based signing app prompt on their phone. It's worth understanding what sits behind each one, because they're different mechanisms with a different cryptographic result. In Spain, for instance, the DNIe (the national electronic ID card) has carried a chip with a personal certificate since 2006: the PIN unlocks the chip, and the chip signs inside itself, so the private key never leaves the physical card. It's probably the most widely deployed qualified signing device in Europe.

A parallel system, Cl@ve, is different: it isn't a certificate, it's an identification scheme for accessing public administration. Its PIN mode grants one-off access via an SMS code; its signing mode does enable electronic signatures, but with the private key held in the cloud by the government, not on a chip the citizen carries.

The FNMT (Spain's national mint and stamp office) issues the most widely used software certificate in the country: it's downloaded and installed in the browser or operating system, and the private key lives as a password-protected file on the user's own computer.

In all three cases, the actual act of signing a document (taking the PDF or XML, computing its digest, and applying the private key of the relevant certificate) is carried out by desktop signing software provided by the government, which is the point where the certificate turns into a real XAdES, PAdES or CAdES signature embedded inside the file itself.

ETSI (the European Telecommunications Standards Institute) defines three formats depending on the document type: XAdES for XML, PAdES for PDF, and CAdES for generic binary formats (CMS). Desktop signing software produces one or the other depending on the file, but internally all three share the same logic.

Within each format there are levels, and they're the key to everything this tool audits:

• B (Basic). Just the signature. If the signer's certificate later expires or is revoked, there's no way to prove the signature was made while it was still valid.
• T (Timestamp). Adds a timestamp from a trusted third party, proving the signature already existed on a specific date.
• LT (Long-Term). Embeds the full certificate chain and the revocation status (CRL/OCSP) at the time, so it can still be validated years after those services have disappeared.
• LTA (Long-Term with Archive timestamps). Adds renewable archive timestamps: before the previous timestamp's algorithm weakens, it can be re-sealed with a new one without breaking the chain of custody. It's the only level actually built to last decades, and the one almost nobody uses in production.

All of the above exists within a single legal framework shared by all 27 member states: eIDAS (Regulation (EU) 910/2014, revised as eIDAS 2 in 2024). eIDAS distinguishes three levels of electronic signature, which are not legally equivalent:

• Simple. Any data in electronic form attached to a document with the intent to sign: a click on "I accept", a scanned signature. Weak evidentiary value.
• Advanced (AdES). Uniquely linked to the signer, capable of identifying them, created using means under their sole control, and bound to the data so that any later change is detectable. This is the technical level this tool audits.
• Qualified. An advanced signature made with a qualified signature-creation device and a qualified certificate issued by a qualified trust service provider (QTSP). It's the only one with direct legal equivalence to a handwritten signature across the whole EU, by law, with no need to prove it case by case. A national eID card and a properly issued FNMT-style certificate are, in this sense, qualified.

Every member state maintains its own Trusted List (TSL): the official registry of which providers are authorized to issue qualified certificates, and since when. The European Commission aggregates the 27 national lists into one, the LOTL (List Of Trusted Lists). That's exactly what this tool's verification layer archives every day: to know whether a 2022 signature was trustworthy, you need to know what that country's TSL said in 2022, not what it says today.

eIDAS 2 adds the European Digital Identity Wallet (EUDI Wallet), which every member state must offer before the end of 2026: an attempt to unify national eID schemes and their equivalents across France, Germany or Italy under one digital wallet recognized throughout the Union.

With encryption, the quantum threat is that someone stores encrypted traffic today and decrypts it a decade from now (harvest now, decrypt later). With an electronic signature the problem is different, and worse.

Once a sufficiently powerful quantum computer exists, Shor's algorithm breaks RSA and ECDSA regardless of key size, the very algorithms behind national eID cards and nearly every FNMT-style certificate in use today. Anyone with the public key of a current certificate will be able to forge signatures indistinguishable from legitimate ones, with a backdated timestamp. The signature doesn't "expire" in the usual sense: from that moment on, there's simply no way to tell an authentic signature from a forged one.

That "once" isn't indefinite. The 2019 reference estimate (Gidney and Ekerå) put factoring an RSA-2048 key at twenty million physical qubits with error correction; in May 2025, a new result from Google cut that to under a million, twenty times fewer in six years. Today's processors (Google Willow, IBM Heron) still work with hundreds of qubits, far below that figure, and no manufacturer promises a system capable of breaking RSA-2048 within this decade. But it's the rate of reduction, not the absolute figure, that makes 2030 and 2035 (the dates when NIST stops recommending, then bans, RSA and ECDSA, per its NIST IR 8547 draft) prudent rather than alarmist deadlines for a document that, like a notarial deed, has to remain defensible fifty years from now.