eIDAS Advanced Electronic Signatures

If your auditor, legal team, or EU counter-party asks “what eIDAS class of signature does Pacta produce?” — the answer is Advanced Electronic Signature (AES). This article explains what that means, why it’s sufficient for almost every B2B contract, and where AES ends and Qualified Electronic Signature (QES) begins.

The three eIDAS classes

EU Regulation 910/2014 (eIDAS) defines three classes of electronic signature, ordered by strength:

Class	Description	Pacta?
Simple Electronic Signature (SES)	Any electronic indication of consent (typed name, image upload, “I accept” checkbox). No identity binding or integrity guarantee.	✓ Trivially supports
Advanced Electronic Signature (AES)	Uniquely linked to the signer, capable of identifying them, created via means under their sole control, and detects subsequent changes.	✓ Default class
Qualified Electronic Signature (QES)	AES plus: created with a Qualified Signature Creation Device (QSCD) + based on a qualified certificate issued by a Qualified Trust Service Provider (QTSP).	✗ Not on the standard plan

Most B2B commercial contracts only need AES. QES is required for specific legal acts (some EU member-state public-sector filings, specific notarial acts, EU-wide cross-border equivalence of handwritten signature in court). For 99% of contract use cases — MSAs, NDAs, employment agreements, vendor contracts, partner agreements — AES is sufficient and legally binding throughout the EU.

What makes Pacta signatures Advanced

eIDAS Article 26 lists four AES requirements. Pacta meets each:

1. Uniquely linked to the signer

Each signing link Pacta emails is bound to:

A unique cryptographic token (~32 chars)
The recipient’s email address
The envelope ID
An expiration timestamp

Only the email recipient can produce a signature on the document. The token is not reusable, transferable, or guessable.

2. Capable of identifying the signer

Pacta records, in the audit trail embedded in the signed PDF:

The signer’s email (verified via possession of the inbox)
IP address at the moment of signing
User agent (browser + OS fingerprint)
Timestamp from an independent Time Stamp Authority

For higher-assurance flows, Pacta also supports:

Email re-verification — signer enters a code we email them at sign time, on top of the original signing link
Two-factor authentication — recipient links a phone number for OTP confirmation before signing
Authentication Portal (Enterprise) — full identity-provider integration (your IdP authenticates the signer; Pacta records the IdP token in the audit trail)

3. Created using data under the signer’s sole control

The signing key material is bound to the signing link, which is bound to the recipient’s email. No one else — not Pacta, not the sender, not other signers — can use that key material to produce the same signature.

4. Detects any subsequent change

This is the CAdES envelope. After the signer submits, Pacta:

Hashes the entire PDF (SHA-256)
Combines that hash with metadata (signer identity, timestamp, IP)
Signs the combined package with the platform certificate using PKCS#7 / CMS structure under the CAdES profile
Embeds the envelope inside the PDF using the PAdES specification (PDF Advanced Electronic Signatures, ETSI EN 319 142)

Any byte changed in the PDF invalidates the signature when verified. The verifier (Adobe Reader, EU DSS Tool, command-line pdfsig) shows a clear “invalid” indicator if the document has been tampered with.

Long-Term Validation (LTV)

Pacta’s CAdES envelopes are extended to CAdES-LT (Long-Term) by embedding all the verification material (certificate chain, revocation lists, OCSP responses, TSA tokens) inside the signed PDF itself.

This means: the PDF stays verifiable for decades, even after the issuing certificate authority changes hands, goes out of business, or has its certificate expire. Long after Pacta itself ceases to exist, the PDF you have in 2046 still validates with any standards-compliant PDF reader.

See Audit trails + verification for the operational side of this.

What about QES?

QES requires two things Pacta doesn’t ship by default:

Qualified Signature Creation Device (QSCD) — hardware or highly-restricted software that holds the signing key material under signer’s sole control. Typically a hardware token, smart card, or government-issued ID with embedded chip
Qualified Certificate issued by a Qualified Trust Service Provider (QTSP) — a TSP listed on the EU Trust List

For most B2B contracts, this is overkill. The legal effect of QES under eIDAS is “equivalent to handwritten signature throughout the EU” — which sounds important, but in practice:

AES is already legally binding in commercial contexts
Most disputes are about whether there was an agreement, not whether the signature was qualified
AES signatures are admissible as evidence and have been consistently upheld in EU court

If you specifically need QES for some EU member-state public-sector filing or notarial workflow, contact hello@pacta.ink — there’s a path involving QTSP integration but it’s case-by-case work, not a standard plan feature.

How to prove Pacta signatures are AES to a counter-party

If a counter-party’s legal team asks for evidence of eIDAS classification:

Send them a signed PDF from Pacta
Point them to https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation — the official EU DSS validation tool
They upload the PDF; the tool returns a structured report showing:
- Signature is CAdES-LT (Long-Term)
- PAdES container is conformant
- Certificate chain validates
- TSA token is from a recognized provider
- LTV material is complete

That report is your AES classification proof. You don’t need a letter from Pacta — the EU’s own tool confirms it from the PDF alone.

Standards we conform to

For the standards-bingo card on procurement questionnaires:

ETSI EN 319 102 (CAdES creation procedures)
ETSI EN 319 122 (CAdES signature profile)
ETSI EN 319 142 (PAdES profile)
ETSI EN 319 422 (Time-Stamp Authority profile)
RFC 5652 (Cryptographic Message Syntax — the basis for CAdES)
RFC 3161 / RFC 5816 (Time-Stamp Protocol)

Where to go next

Audit trails + verification — step-by-step on actually verifying a signed PDF
How Pacta signatures hold up — same content with less regulatory framing
CFR21 Part 11 and HIPAA — the US regulatory equivalents