Concept · Trust & e-signatures
What is eIDAS?
Qualified electronic signatures for PDF
eIDAS is EU Regulation 910/2014, the law that gives electronic signatures legal standing across all EU member states. It defines three tiers of trust (SES, AES, QES) and recognises PAdES as the PDF profile that satisfies its technical requirements. This guide explains what each tier means, how PAdES connects PDF to the regulation, and where long-term validation keeps signatures verifiable for decades.
The clearest analogy: a sealed wax letter
A wax-sealed letter from a medieval notary told the recipient two things at once: who sealed it (the seal bears the notary's unique stamp) and whether it had been opened (a broken or mismatched seal is immediately visible). No one could copy the contents without leaving obvious evidence.
A scanned image of a handwritten signature on a PDF proves neither. Anyone can copy the image into any document. There is no mechanism that ties the image to a specific signer, and there is nothing that would change if the document's numbers were altered after signing.
An eIDAS-compliant electronic signature works like the wax seal: it is uniquely and cryptographically tied to the signer (via a private key and a certificate) and covers every byte of the document, so any change (even a single character) invalidates the signature. The verifier does not have to trust the appearance; they check the mathematics.
The three tiers of electronic signature
eIDAS defines a ladder. Each rung adds technical requirements that increase legal weight. Most enterprise and cross-border use cases require at least AES; contracts with the weight of a handwritten signature require QES.
Simple Electronic Signature
The lowest tier: any electronic mark.
- A typed name at the bottom of an email
- A scanned image of a handwritten signature
- A checkbox confirming agreement
- No tamper-evidence, no signer identification
Advanced Electronic Signature
Four requirements, all cryptographic.
- Uniquely linked to the signer
- Capable of identifying the signer
- Created with data under the signer's sole control
- Detects any subsequent change to the signed data
Qualified Electronic Signature
An AES backed by the highest-grade infrastructure.
- Based on a qualified certificate from a QTSP on an EU Trusted List
- Created on a Qualified Signature Creation Device (QSCD)
- Legally equivalent to a handwritten signature across the EU
- Non-repudiable in cross-border proceedings
rust-pdf produces the cryptographic PAdES container. Whether the result is AES or QES depends on the certificate you supply: if it is a qualified certificate from a QTSP, the signature is QES.
What eIDAS actually requires of a PDF signature
To qualify as an Advanced Electronic Signature, Article 26 of eIDAS specifies four technical properties. PAdES is the standard that tells you exactly how to achieve all four inside a PDF file.
Uniquely linked to the signer
The signature is created with the signer's private key. Only the holder of that key could have produced that exact signature over that exact document content.
Capable of identifying the signer
The certificate bound to the signature carries the signer's name, organisation and issuing authority, all verifiable by a relying party without contacting anyone.
Created under the signer's sole control
The private key is held exclusively by the signer: on a hardware token (QSCD) for QES, or in well-managed PKI infrastructure for AES. Others cannot co-sign unknowingly.
Detects any subsequent change
The signature covers a cryptographic hash of the document's byte ranges. If even a single character is altered after signing, the hash changes and the signature fails verification immediately.
PAdES: the PDF profile that satisfies eIDAS
PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 142) is the normative specification for how an electronic signature must be embedded in a PDF to meet eIDAS requirements. It defines three conformance levels that build on each other.
Baseline
The cryptographic signature is embedded in the PDF with a ETSI.CAdES.detached subfilter. The document is tamper-evident and the signer is identified. Satisfies AES today.
Long-Term
Adds a Document Security Store (DSS) embedding the certificate chain and revocation data (CRLs). The signature stays verifiable even after the issuing CA goes offline.
Long-Term with Archiving
Adds a trusted document timestamp over the whole document including the DSS. Provides a tamper-evident time-seal. Signatures remain verifiable for decades, regardless of certificate expiry.
rust-pdf produces all three levels. B-B via sign(…, pades=True),
B-LT via add_dss, and B-LTA via timestamp.
Validate with pdfsig or openssl cms -verify.
Staying valid for decades: Long-Term Validation
A signature is only as good as its verifiability. Certificates expire, typically after one to three years. If a court or auditor checks your signed contract in 2035 and the signing certificate has long since expired, how can they confirm the signature was valid at the time of signing?
PAdES-B-LT solves this by embedding the complete certificate chain and revocation evidence (CRL or OCSP responses) into the PDF at signing time, in the Document Security Store (DSS dictionary). A verifier in 2035 does not need to contact any online service; everything required is inside the file.
PAdES-B-LTA goes further: a trusted timestamp authority (TSA) signs a hash of the entire document (PDF bytes, signature, and DSS), creating a cryptographic proof of what existed at a specific moment in time. Even if the original signing certificate is later found compromised, the timestamp proves the document and signature existed before that compromise.
For a deep dive into how timestamps work and what a TSA does, see Timestamps & LTV for PDF signatures.
Scanned signature image vs eIDAS advanced signature
| Scanned signature image | eIDAS Advanced Signature (PAdES) | |
|---|---|---|
| Proves who signed | No:anyone can copy an image | Yes:certificate binds identity cryptographically |
| Detects document tampering | No:document can be altered after signing | Yes:any change invalidates the signature |
| Non-repudiation | No:easily forged or denied | Yes:private key proves sole control |
| Machine-verifiable | No:requires human visual inspection | Yes:any PDF viewer or validator can verify |
| Long-term verifiable | No:no time-binding mechanism | Yes:with B-LT/B-LTA stays valid for decades |
| Accepted in EU cross-border proceedings | No clear legal status | Yes:eIDAS Article 25 prohibits denial of effect |
How to sign a PDF with PAdES using rust-pdf
rust-pdf signs with PAdES (the eIDAS-aligned PDF profile) and keeps signatures verifiable long-term. You supply the key and certificate.
# pip install rustpdf
import rustpdf
pdf = open("contract.pdf", "rb").read()
key = open("signing-key.pkcs8.der", "rb").read()
cert = open("signing-cert.der", "rb").read()
signed = rustpdf.sign(pdf, key, cert, reason="Approved", pades=True) # PAdES-B-B
lt = rustpdf.add_dss(signed, certs=[cert], crls=[crl]) # -> B-LT
lta = rustpdf.timestamp(lt, tsa_key, tsa_cert) # -> B-LTA
open("contract.signed.pdf", "wb").write(lta)
# Verify in a shell: pdfsig contract.signed.pdf -> "Signature is Valid."// dotnet add package RustPdf
using RustPdf;
byte[] signed = Pdf.Sign(pdf, keyDer, certDer, reason: "Approved", pades: true); // B-B
byte[] lt = Pdf.AddDss(signed, certs: new[]{ certDer }, crls: new[]{ crl }); // B-LT
byte[] lta = Pdf.Timestamp(lt, tsaKeyDer, tsaCertDer); // B-LTA// go get github.com/rustpdf/rustpdf-go@latest
signed, _ := rustpdf.Sign(pdf, key, cert, rustpdf.SignOptions{Reason: "Approved", Pades: true})
lt, _ := rustpdf.AddDss(signed, [][]byte{cert}, [][]byte{crl}) // B-LT
lta, _ := rustpdf.Timestamp(lt, tsaKey, tsaCert) // B-LTA// npm install rustpdf
const { sign, addDss, timestamp } = require("rustpdf");
const signed = sign(pdf, key, cert, { reason: "Approved", pades: true }); // B-B
const lt = addDss(signed, { certs: [cert], crls: [crl] }); // B-LT
const lta = timestamp(lt, tsaKey, tsaCert); // B-LTAAvailable in all nine language bindings: Python, C#/.NET, Go, Node.js, Java, PHP, Ruby, Delphi and Swift. One Rust core, the same output everywhere. Full reference in the documentation.
eIDAS FAQ
What is eIDAS?
eIDAS stands for electronic IDentification, Authentication and trust Services. It is EU Regulation 910/2014, which creates a single legal framework for electronic signatures across all EU member states. Under eIDAS, an electronic signature is admissible as evidence in court and cannot be denied legal effect solely because it is electronic. It defines three tiers of signature: SES, AES and QES, each with increasing requirements and legal weight.
What is the difference between SES, AES and QES?
SES (Simple Electronic Signature) is any electronic mark: a scanned image, a checkbox, or a typed name. It has no tamper-evidence and proves little. AES (Advanced Electronic Signature) must be uniquely linked to the signer, capable of identifying them, created with data under the signer's sole control, and capable of detecting any subsequent change to the signed document. QES (Qualified Electronic Signature) is an AES that additionally uses a qualified certificate from a Qualified Trust Service Provider (QTSP) listed on an EU Trusted List and is created on a Qualified Signature Creation Device (QSCD). QES is legally equivalent to a handwritten signature across the EU.
Is rust-pdf's signature qualified (QES)?
rust-pdf produces the cryptographic PAdES container (B-B, B-LT, and B-LTA) that satisfies the technical requirements of an Advanced Electronic Signature. Reaching QES additionally requires a qualified certificate issued by a QTSP and a QSCD hardware token (both of which you supply). If you sign with a qualified certificate from an EU Trusted List provider, the resulting PAdES signature is QES. rust-pdf handles the cryptography and the PDF packaging; the key and certificate you provide determine the trust level.
What is PAdES and how does it relate to eIDAS?
PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 142) is the PDF profile of AdES, the family of Advanced Electronic Signature formats recognised under eIDAS. PAdES defines exactly how an electronic signature must be embedded in a PDF to satisfy the legal requirements of eIDAS, including tamper-evidence, signer identity, sole-control proofs, and long-term verifiability. Using PAdES is what elevates a PDF signature from a simple electronic mark (SES) to advanced (AES) or, with a qualified certificate, qualified (QES).
How do I keep a PDF signature valid long-term?
Certificates expire, and a verifier checking a signature years later may find that the signing certificate has since been revoked or expired. PAdES Long-Term Validation (LTV) solves this by embedding the evidence at signing time. PAdES-B-LT adds a Document Security Store (DSS) containing the certificate chain and revocation data (CRLs or OCSP responses) so the signature can be verified even if the original infrastructure is gone. PAdES-B-LTA adds a trusted document timestamp over everything, creating a tamper-evident time-seal. rust-pdf produces B-LT via add_dss and B-LTA via timestamp. See the timestamps page for detail.
eIDAS-aligned PDF signatures in your language
One Rust core, PAdES output across nine language bindings. Prototype for free, license the signing features when you ship.