Dokmatiq DOKMATIQ

PAdES

ETSI standard for electronic signatures in PDF documents — embeds the signature directly in the PDF, supports long-term validation and is eIDAS-compliant.

Also known as: PDF Advanced Electronic Signatures, ETSI EN 319 142, PAdES-BES, PAdES-LTV

Short definition

PAdES (PDF Advanced Electronic Signatures) is the standard for electronic signatures in PDF documents, published by ETSI as EN 319 142. Unlike an external signature file (CAdES or XAdES), a PAdES signature is embedded directly into the PDF — it becomes part of the document and travels with it.

PAdES is one of the signature formats recognised under the eIDAS regulation (EU 910/2014), giving it legal standing across the entire EU.

Profiles

PAdES defines four validation profiles that build on each other in increasing long-term robustness:

ProfileShort nameContainsTypical use
BasicPAdES-B-Bsignature + certificateshort-lived signatures
With TimestampPAdES-B-T+ timestampdocumented signing time
Long-Term ValidationPAdES-B-LT+ validation data (OCSP/CRL)decades-long verifiability
Long-Term with Archive TSPAdES-B-LTA+ archive timestampaudit-safe archiving

For invoices, contracts and official documents, PAdES-B-LT or PAdES-B-LTA is usually the right choice — they remain verifiable even after the signing certificate has expired.

PAdES, CAdES and XAdES

All three are ETSI Advanced Electronic Signature formats, but for different containers:

  • PAdES — signature inside PDF
  • CAdES — signature in binary files (ETSI counterpart to CMS/PKCS#7)
  • XAdES — signature in XML (e.g. for signing XRechnung)

Relevant for digital invoices: ZUGFeRD PDFs are typically signed with PAdES, pure XRechnung XML with XAdES when signing is required.

What it contains technically

A PAdES signature consists of a ByteRange (which part of the PDF was signed), a PKCS#7 structure carrying the actual signature and — depending on the profile — embedded timestamps and OCSP/CRL responses. These validation artefacts live in a DSS (Document Security Store), a dedicated PDF object defined by PAdES.

The signature block does not modify the PDF retroactively: it is appended as an incremental update, leaving the original bytes intact and verifiable.

Signing with the Dokmatiq API

curl -X POST https://api.dokmatiq.com/v1/pdf/sign \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@invoice.pdf" \
  -F "certificate=@signing.p12" \
  -F "passphrase=..." \
  -F "profile=PAdES-B-LT" \
  -F "reason=Invoice 2026-0042" \
  -F "location=Munich" \
  -o signed.pdf

When needed, the API fetches OCSP and CRL responses automatically and embeds them — the result is a PDF that is long-term validatable out of the box. Timestamps are pulled from a configured qualified TSA (Time Stamping Authority).

Verifying a signature

curl -X POST https://api.dokmatiq.com/v1/pdf/sign/verify \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  --data-binary "@signed.pdf"

Response: profile, certificate chain, trust anchor (EU Trusted List for eIDAS), timestamp status and any modifications made after signing.

Common pitfalls

  1. Wrong profile — PAdES-B-B is not enough for GoBD-compliant archiving; use at least PAdES-B-LT
  2. Expired certificate — without long-term validation the signature is no longer checkable once the certificate expires (even if the signing time was valid)
  3. Changes after signing — any modification invalidates the ByteRange; later annotations require a new signature layer
  4. Certificate not in the EU-TL — for qualified signatures the issuer must be listed in the EU Trusted List

Ready to use it via API?

Get started for free. No credit card. 100 documents per month included.