What is PAdES? The PDF signature standard, explained

PAdES is the standard that puts a real cryptographic signature inside a PDF rather than a picture of one on top of it. The name turns up on signed documents and in procurement questionnaires, almost always followed by a letter code nobody explains.

Pixacomms Ltd, Cardiff · Updated September 2026

If you have opened a signed PDF and seen PAdES B-T in its properties, or a client’s compliance team has asked which PAdES level your documents carry, this is the answer: what the standard is, what the four levels each add, what the timestamp contributes, and how to check any of it yourself.

PAdES, in one sentence

PAdES stands for PDF Advanced Electronic Signatures: the rules for how an advanced electronic signature is built into a PDF file, published by ETSI as EN 319 142-1 — PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures, version 1.1.1, April 2016 — with further profiles in EN 319 142-2.

It belongs to a family. CAdES (EN 319 122-1) covers signatures over arbitrary data in CMS format, XAdES (EN 319 132) covers XML, ASiC (EN 319 162) covers signed containers. PAdES is the PDF one, and it sits on machinery already in the PDF specification: ISO 32000-1 defines the signature dictionary a PDF can carry, and PAdES specifies what must go in it.

So PAdES is not a file format, a product or a vendor. It is a profile — which cryptographic attributes must be present, where, and in what form — so a signature applied by one piece of software can be verified by different software years later, by somebody who has never heard of the company that made it.

A signature in the file, not a picture on the page

Most “signed” PDFs in circulation are not signed in any technical sense. Somebody has pasted an image of a squiggle onto a page and saved the file. That image is ordinary page content: no key, no hash, no link to the rest of the document. It can be cut out and dropped onto a different contract in a minute, the page around it can be edited freely, and no PDF reader will object, because nothing unusual has happened to the file.

A PAdES signature is a different object. At signing, the software takes a SHA-256 digest over the bytes of the file, signs it with a private key, and writes the result into the PDF as a DER-encoded CMS SignedData object — the structure in IETF RFC 5652. Three entries in the signature dictionary carry it:

• Contents — the signature itself, the CMS object.
• ByteRange — exactly which bytes of the file it covers.
• SubFilter — the value ETSI.CAdES.detached, which is what marks the signature as PAdES rather than an older PDF signature encoding.

Change one byte inside the covered range and the digest no longer matches, so the signature fails. The squiggle you see on a properly signed PDF is a signature appearance: decoration for human readers. The evidence is the CMS object, and it would work just as well with nothing drawn on the page at all.

The four baseline levels: B-B, B-T, B-LT and B-LTA

Clause 6.1 of EN 319 142-1 defines four levels, each building on the one before, because a signature has a life cycle: what proves a document today is not what proves it once the certificates have expired and the algorithms have aged.

The “material” B-LT adds means the full certificate chain plus revocation data — a revocation list or an OCSP response for every certificate in it — stored in a Document Security Store dictionary inside the PDF. B-LTA then timestamps that structure, repeatedly if necessary, so protection can be extended indefinitely.

Every document Pixasign seals is PAdES B-T, RSA-3072 with SHA-256. It is not B-LT, and we would rather write that here than have you find it out. B-LT needs revocation data to embed, and that has to come from a certificate authority publishing a revocation list or running an OCSP responder. We run our own signing authority and publish neither, so there is nothing honest to embed. B-T is by design the level not meant to outlast its certificates, and the gap cannot be closed later: validation material goes in at signing time or not at all.

What an RFC 3161 timestamp adds

The trusted token that turns B-B into B-T is a timestamp, specified by IETF RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol, August 2001, updated by RFC 5816.

The mechanism is deliberately narrow. The signing software sends a hash of the signature to a Time Stamping Authority. The authority never sees the document — it only ever receives a digest. It takes its own reading from a trustworthy clock, signs the hash and the time together with its own key, and returns a TimeStampToken that is embedded in the PDF. What comes back is proof of existence: this exact signature existed no later than that moment.

The value of it turns entirely on who issued it. A timestamp from the same organisation that made the signature proves nothing about time to anybody else, because one party controlled both the signature and the clock — a company that timestamps its own documents is marking its own homework, and a competent opponent will say exactly that. Independent attestation by a trusted third party is the reason RFC 3161 exists. Pixasign’s timestamps are issued by DigiCert, independent and publicly trusted, whose root is already in the trust stores your PDF reader ships with. If signing cannot reach DigiCert the seal fails, rather than quietly falling back to something weaker.

“Covers the whole file”, and the trick that defeats it

Requirement k of clause 6.3 is short and load-bearing: “The ByteRange shall cover the entire file, including the Signature Dictionary but excluding the PDF Signature itself.” At the moment of signing, everything is inside the covered range.

The problem arrives afterwards. A PDF can be updated incrementally: new objects appended to the end of the file, earlier bytes never touched. That is a specified feature — it is how a second person counter-signs a contract. It also means a revision can be appended that overlays new text on an already-sealed page while the signed bytes stay intact. The maths still checks out, the certificate still chains, and the document now says something it did not say when it was signed. We did this to one of our own sealed quotations, stamping “PAID IN FULL” across it: the validator reported intact, valid and trusted — every answer correct in isolation, and the verdict assembled from them completely wrong.

Our verifier requires whole-file coverage, names the signature field it examined, and reports anything appended afterwards separately, so a stranger’s later signature can never be mistaken for ours.

How to check a PAdES signature yourself

None of this requires our software, which is the point of using a published standard.

• Adobe Acrobat Reader. The signature panel names the signer, shows the timestamp, states whether the document has been modified since the signature was applied, and tells you if revisions were added afterwards. It will also display the signed revision — the document as it stood at signing.
• pdfsig, part of the open-source poppler-utils package: signer, signing time, hash algorithm, signature type, the signed byte ranges, and whether they cover the whole document.
• pyHanko, an open-source Python library for signing and validating PDFs, with a command-line validator that reports coverage explicitly. It is what we use internally, and it is not ours.
• Our free public checker — no account, no login. The most convenient of the four and the least independent, which is why it is last.

Expect the Adobe warning on anything we have sealed, and read it precisely: the validity of the signature is unknown to Adobe, not bad. Membership of the Adobe Approved Trust List is a commercial arrangement costing several thousand pounds a year, and we have not bought it. The cryptography is unaffected, and so is the timestamp.

Questions