How Pacta signatures hold up: eIDAS, CAdES, LTV

Most “electronic signature” tools do something like this when you sign:

You draw your name on a canvas
They save an image of it
They paste that image onto a PDF
The PDF gets emailed around

That’s a legally valid signature in most jurisdictions — but it’s not a particularly strong one. If someone disputes the signature years later, your only proof is “well, we have a PDF with their name on it” and “they’re listed in our database.”

Pacta does this differently. Every signature you collect is a cryptographic envelope — a mathematically-verifiable proof that ties a specific person to a specific document at a specific moment in time. The PDF itself becomes the proof; you don’t need Pacta around later to defend it.

This article walks through what that means in practice and which standards apply.

The three layers of a Pacta signature

1. Identity binding

When Pacta sends a signing email, the link includes a unique signing token bound to:

The recipient’s email address
The specific envelope ID
The specific role (signer A, signer B, etc.)
An expiration timestamp

Only the person who received that email can produce a valid signature for that envelope. The token can’t be forwarded usefully — if you forward the email to someone else and they sign, the audit trail records their IP, their user agent, and the original token — not a forgery of the original recipient.

For higher-security workflows, Pacta also supports:

Email re-verification — recipient enters a code we email them before they can sign
Two-factor authentication — recipient links a phone number for OTP confirmation
Identity portal authentication (Enterprise) — full identity-provider integration

2. Document integrity (the CAdES envelope)

Once you submit a signature, Pacta:

Calculates a cryptographic hash of the entire PDF (SHA-256)
Combines that hash with metadata (your identity, timestamp, signing method, IP, user agent)
Signs the combined package with Pacta’s PKCS#7 certificate using AES-256-GCM for the symmetric encryption layer
Embeds the resulting CAdES envelope inside the PDF using the PAdES specification (PDF Advanced Electronic Signatures)

CAdES stands for “CMS Advanced Electronic Signatures” — it’s the European standard for digital signatures, but it’s interoperable worldwide. The signature lives inside the PDF, not in a separate file you might lose.

Any change to a single byte of the signed PDF invalidates the signature when verified. So:

Someone changes the date by editing the PDF? Signature broken.
Someone tampers with a clause and re-signs? Signature broken.
Someone re-saves the PDF in another app without resigning? Signature broken.

This is what makes Pacta signatures legally meaningful — they’re tamper-evident in a way you can prove mathematically.

3. Time anchoring (TSA + LTV)

A signature is only as good as the moment it was made. Pacta uses two mechanisms to anchor that moment:

Time Stamp Authority (TSA)

After producing the CAdES envelope, Pacta sends the signature hash to an independent Time Stamp Authority — a trusted third party that adds its own signature with the current time. The TSA’s signature is provably from a date and time you can verify against the TSA’s public records.

Why this matters: if someone tries to back-date or forward-date a signature, the TSA’s timestamp won’t match. The TSA is independent of Pacta, so we can’t fake it either.

The TSA Pacta uses is configurable per instance. For the Pacta-hosted service we use time.certum.pl — an EU- qualified TSA. Self-hosted Pacta instances can use their own TSA.

Long-Term Validation (LTV)

Certificates expire. The signing certificate Pacta uses today won’t be valid in 20 years. Long-Term Validation is the mechanism for keeping signatures verifiable even after the originating certificates expire.

LTV works by embedding all the validation material (certificates, revocation lists, OCSP responses, TSA tokens) inside the PDF at signing time. When someone verifies the PDF in 2046, the verifier doesn’t need to contact Pacta or Certum or anyone else — all the proof material is in the file itself.

This is the difference between “your contract is binding while we keep the lights on” (most e-sig tools) and “your contract is binding as long as you keep the PDF” (Pacta).

What standards Pacta meets

Standard / framework	Status	Where it matters
ESIGN Act + UETA	✓ Compliant	Almost all US contracts
eIDAS (EU)	✓ AES (Advanced Electronic Signature) classification	EU + UK contracts
CAdES-T / CAdES-LT / CAdES-LTA	✓ Supported (envelope levels)	Long-term verifiability
PAdES (ETSI EN 319 142)	✓ Compliant	PDF-embedded signature standard
CFR21 Part 11	✓ Optional flag (Business+)	FDA-regulated workflows
HIPAA	✓ Optional flag (Business+)	Healthcare contracts
GDPR	✓ Aligned	EU privacy + data minimization
SOC 2	In progress	Required by enterprise procurement

What we’re NOT (yet)

Pacta provides Advanced Electronic Signatures under eIDAS. We are not currently a Qualified Trust Service Provider for Qualified Electronic Signatures (QES), which requires recipients to use a qualified signing device + qualified ID. QES is rare in B2B contract workflows; AES is sufficient for almost every commercial contract, regulatory filing, and employment agreement we’ve seen.

If you specifically need QES for some EU member-state public-sector filing, contact us — there’s a path involving QTSP integration but it’s case-by-case.

What the signing certificate page looks like

The final PDF you get from Pacta includes a certificate page at the end. It’s a one-page summary of everything that happened:

The document title + hash
Each signer’s name, email, IP, user agent
Exact UTC timestamp for each action (viewed, started signing, applied signature, submitted)
The CAdES envelope details + the TSA token’s time
A QR code linking to a verification endpoint
A clear “verify with Adobe Reader” instruction

You can hand this PDF to any auditor, lawyer, or court and they have everything they need to verify the signature without involving us.

Verifying a Pacta signature

See the next article — Audit trails + verification.

Where to go next

Audit trails + verification — the step-by-step on actually verifying a signed PDF
Sign a document you received — what your signers see from their side