PAdES signature levels: what B-B, B-T, B-LT, and B-LTA each survive

PAdES signature levels define how much trust material a signed PDF carries. A PDF signed at the lowest level stops validating when the signing certificate expires — typically 1 to 3 years after signing. At the highest level, the same document can be verified decades later without touching any network. The difference is permanent: once a signing certificate lapses, you can no longer embed the revocation data that makes offline validation possible.

PAdES (PDF Advanced Electronic Signatures, defined in ETSI EN 319 102 and EN 319 142) specifies four baseline levels: B-B, B-T, B-LT, and B-LTA. Each is a strict superset of the previous. What follows covers what each level embeds, what breaks without it, and when the choice becomes irreversible.

What PAdES adds that plain PDF signing doesn't

A raw PDF signature is a hash of the document signed with the signer's private key, plus the signer's certificate. It proves the document hasn't changed since signing and that whoever held that private key signed it. What it doesn't prove is whether the certificate was revoked before signing, or whether the certificate was valid at the moment the signature was applied.

Validation fails if the CA's OCSP responder is unreachable, the verifier has no network access, or the signing certificate has simply expired. There is no meaningful fallback.

PAdES solves this by defining exactly what material should be embedded in the PDF's Document Security Store (DSS) dictionary at signing time, so future validators don't need to reach any external service. Each baseline level adds a different class of material. Picking the right level means understanding what you're embedding and what you're not.

B-B: a valid signature that stops validating

B-B is a cryptographic signature with the signer's certificate attached. No timestamp. No revocation data. No cert chain beyond the end-entity certificate.

A PDF validator can verify a B-B signature today because the signing certificate is still within its validity window and the CA's OCSP responder is reachable. Three years from now, that certificate will have expired. The validator reports failure, not because the document was altered, but because it can no longer confirm the cert was valid at any point in time.

Some validators support a 'best signature time' mode that accepts the signature as valid at the time of verification, on the assumption that the certificate was valid when the document was signed. This is a policy decision on the verifier's side, not a protocol feature. You can't count on it being available in an arbitrary viewer, court IT system, or third-party audit tool.

B-T: proof of time, with conditions

B-T adds a timestamp token from a trusted Timestamp Authority (TSA). The TSA computes a hash of the signature value and the document, signs that hash with its own private key, and returns a signed timestamp token that is embedded in the PDF.

What this proves: the document existed in its current form at the moment the TSA issued the token. This is the core protection against backdating: the claim that a signature was applied to a document after the fact, once the other party's position was known.

What B-T doesn't solve: it still doesn't embed the signing certificate's revocation data. Verifying a B-T signature offline requires reaching the CA's OCSP responder to confirm the cert wasn't revoked at signing time. If the CA's endpoint is unavailable or the CA has been decommissioned, verification fails.

There is also a TSA lifetime problem. The TSA signs the timestamp with its own certificate, and that certificate has a validity window, typically 10 to 15 years. Once the TSA certificate expires, the timestamp cannot be verified without additional trust material. B-T pushes the expiry problem further into the future; it doesn't remove it.

B-LT: the first level that validates offline

B-LT adds a Document Security Store (DSS) dictionary containing all certificates in the signing cert's chain, from the end-entity certificate to the root CA, plus OCSP responses or CRL snapshots confirming the cert was valid at signing time.

With this material embedded, a verifier doesn't need to reach any CA endpoint. The full chain is in the PDF. The revocation evidence is in the PDF. A validator with the correct root CA certificates can confirm the signature entirely offline, years after signing, even if the CA has shut down its infrastructure.

This matters in three concrete situations. First, CAs retire OCSP endpoints with little notice. Adobe's CDS OCSP endpoint went dark in 2019; any B-T signatures that depended on it lost online-verifiability with no warning. B-LT signatures from the same CA remain valid because the OCSP response was captured at signing time. Second, regulated document archives (HR records, financial agreements, property documents) are frequently verified in environments without internet access. B-LT makes that possible; B-T does not. Third, ETSI recommends B-LT as the minimum for Advanced Electronic Signatures under eIDAS. For Aadhaar eSign documents, B-LT is the safest baseline for anything that might face legal scrutiny.

The one gap B-LT leaves open: algorithm deprecation. If SHA-256 is considered broken at some future point, B-LT signatures relying on it cannot be re-verified because the hash itself is compromised. That is what B-LTA addresses.

B-LTA: the level that renews itself

B-LTA adds a document archive timestamp (ATS) covering the entire PDF, including the DSS dictionary populated at the B-LT step. This timestamp creates a cryptographic commitment over all the trust material already in the PDF.

The ATS exists to handle algorithm deprecation. If the original signing algorithm is deprecated (RSA-2048 with SHA-256, for instance), you can apply a new archive timestamp before the old one's algorithm is considered broken. Each new ATS covers the hash of the previous one, forming a chain. A document signed in 2024 can be verified in 2045 not because RSA-2048 is still trusted, but because a chain of successively-applied timestamps ties the original signature to algorithms still considered good.

In practice, this means your signing service must periodically apply new archive timestamps to documents in active storage. The renewal window depends on the cryptographic algorithm's estimated deprecation date; SHA-384 with RSA-4096 or ECDSA P-384 gives the longest runway under current guidance. B-LTA is not permanently valid: it's valid until the current archive timestamp's algorithm is deprecated, at which point you apply a new one.

Use B-LTA for any document with a legal or regulatory shelf life beyond the signing certificate's validity window: loan agreements, employment contracts, property transfers, regulatory submissions, anything that might be evidence in a dispute five or more years after signing.

PAdES signature levels: the survival matrix

The table below shows what each level embeds and what breaks without it. 'Offline validation' means a verifier with correct root certificates can confirm the signature with no network access. 'Survives cert expiry' means the signature remains verifiable after the signing certificate's validity window closes.

The timing constraint you can't work around

You must produce the B-LT or B-LTA signature before the signing certificate expires. OCSP data cannot be embedded retroactively.

The reason: an OCSP response is a signed assertion from the CA that 'on date X, certificate Y was valid.' The CA's OCSP responder can only issue that assertion while the certificate is within its validity window. Once the cert expires, the OCSP responder returns 'expired' or 'unknown', not 'was valid at this past date.' The revocation evidence no longer exists in a form the CA will sign.

Most CAs issue OCSP responses valid for 4 to 24 hours. After the cert expires, the responder stops issuing them. If you signed at B-B in January and the signing cert expires in December, you have until December to fetch and embed the current OCSP response to upgrade to B-LT. After December, the upgrade is impossible.

For production systems, the correct pattern is simple: sign at B-LT or higher from the start. Never sign at B-B or B-T with the intention of upgrading later. If your signing library produces B-B, configure it for B-LT before going live. If your provider says they produce a 'timestamped signature', ask specifically whether they populate the DSS with OCSP responses and the full cert chain; a timestamp and long-term validation are not the same thing.

What FlowVerify produces, and how to check your own PDFs

FlowVerify signs documents at B-LT by default across all production signatures. Aadhaar eSign-backed signatures include UIDAI's timestamp assertion embedded alongside the full certificate chain and OCSP response from the relevant certifying authority. BYO-DSC (.pfx) signing produces at minimum B-T; where the CA supplies a reachable OCSP endpoint at signing time (which most Indian certifying authorities do), the DSS is populated and the result is B-LT.

B-LTA archive timestamps are applied to documents where the signing certificate is within 60 days of expiry and the document is still in active storage. If you export documents to your own storage, archive timestamp renewal becomes your responsibility. Schedule it before the current timestamp's algorithm window closes.

To inspect a signed PDF's level, use the pyHanko command-line tool:

pip install pyhanko
python -m pyhanko sign validate signed.pdf

The output reports whether LT and LTA validation information is present. Alternatively, open the PDF in Adobe Acrobat Reader, click the signature in the panel, and look for 'Long Term Validation Information present' in the details view. If that line is absent, the signature is B-B or B-T at most.

The FlowVerify audit trail records the PAdES level produced, the OCSP response timestamp, and the TSA endpoint used for each signature. Retrieve it via the document audit API if you need chain-of-custody evidence in a dispute.