PAdES Signature Levels Explained: Why B-B Verification Breaks When the Certificate Expires

A PDF carrying a digital signature looks permanent. The padlock icon appears, the signer's name shows up, and it's easy to assume that proof will hold for as long as the file exists. It won't, not on its own. PAdES signature levels exist precisely because a cryptographic signature is a claim tied to a certificate, and certificates expire. ETSI's baseline specification for PDF Advanced Electronic Signatures defines four levels, B-B, B-T, B-LT and B-LTA, and each one closes a specific gap in how long that claim stays checkable. Most signing tools apply only the weakest level by default. Here's what separates the four, and how to tell which one a given document actually got.

Why a Perfectly Valid Signature Can Stop Verifying

A digital signature over a PDF is built from a private key, a certificate that binds that key to an identity, and a chain of certificates back to a trusted root. When someone validates the signature later, software checks three separate things: that the document bytes still match what was signed, that the signing certificate was valid at signing time, and that the certificate hadn't been revoked. That third check is the fragile one. A certificate authority typically issues signing certificates valid for one to three years, and once a certificate expires, the authority is no longer obliged to answer revocation queries about it through OCSP or publish it on a current certificate revocation list.

That creates a timing problem that has nothing to do with document integrity. A contract signed today might need to stay legally usable for seven or eight years under standard commercial retention practice, or considerably longer for financial or regulatory records. The signing certificate will have expired long before that window closes. If a validator can't reach revocation data that no longer exists anywhere, it has to report the signature as unable to be verified, not because anything was tampered with, but because the supporting infrastructure aged out first. The four PAdES levels are a direct response to that gap, each one moving more of the verification evidence from "ask a server" to "already inside the file."

B-B: The Baseline, and Its Built-In Expiry

B-B, Basic Signature, is the minimum PAdES conforms to: a signed hash of the document, the signer's certificate, and enough structure for a validator to confirm the signature was mathematically correct at the moment it was checked. It doesn't embed a trusted timestamp and it doesn't embed revocation evidence. A validator checking a B-B signature the day it's created has everything it needs, because it can query a live OCSP responder or CRL for the certificate's current status.

The problem shows up later. Six months after signing, the certificate authority's OCSP responder for that specific certificate may no longer answer, particularly for shorter-lived certificates from smaller or intermediate CAs. Two years later, after the certificate itself expires, most CAs stop maintaining revocation records for it entirely, since there's nothing left to revoke. At that point a B-B signature can't be freshly re-validated against live infrastructure, and depending on the validator's fallback behaviour, it may render as unknown status rather than simply invalid. Nothing about the document changed. The evidence needed to trust the signer's certificate just aged out.

B-T: Proving a Signature Existed, Not That It's Still Trustworthy

B-T, Signature with Time, adds one thing on top of B-B: a trusted timestamp token, typically obtained from an RFC 3161 timestamp authority, applied over the signature value itself as an unsigned property. This proves the signature existed at a specific point in time, which matters for a narrow but real question: was this document signed before or after some other event, such as a certificate's revocation date or a contractual deadline.

What B-T does not solve is the same long-term validation gap as B-B. It proves the signature existed at time T. It says nothing about whether the certificate was actually valid and unrevoked at that moment, because it still doesn't embed the certificate chain or the revocation data. A B-T signature checked years later still depends on a validator being able to reconstruct that historical revocation state from somewhere, which is exactly what the next level fixes.

B-LT: Freezing the Certificate Chain Before It Rots

B-LT, Signature with Long-Term Validation Material, is where the practical fix arrives. It embeds the full certificate chain, from the signer's certificate up to the trusted root, along with the OCSP responses or CRLs that were current at validation time, directly inside the PDF's Document Security Store, a dedicated structure PAdES defines for exactly this purpose. A B-LT signature no longer depends on any external server to be checked. Everything needed to confirm the certificate chain was valid and unrevoked at signing time travels with the file.

This is the level most people mean when they talk about a PDF signature that "stays valid." It solves the OCSP-goes-dark problem directly: even if the certificate authority disappears entirely five years from now, the revocation evidence collected at signing time is already sitting inside the document. The trade-off is size, since embedding full certificate chains and revocation responses adds several kilobytes to tens of kilobytes per signature, and DSS entries can accumulate across multiple signers on the same document.

B-LTA: Re-Timestamping Against Cryptographic Decay

B-LTA, Signature with Long-Term Availability and Integrity, solves a problem B-LT can't touch: the timestamp itself, and the algorithms underneath it, eventually age too. A timestamp token relies on a hash algorithm and a signature scheme that were considered secure when it was issued. Decades later, that algorithm might be weakened or broken. If that happens, an attacker with enough resources could, in theory, forge a plausible-looking timestamp for a document that was never actually signed at the claimed time.

B-LTA defends against that by periodically applying a fresh archive timestamp over everything already in the DSS, the original signature, the earlier timestamps, and the embedded revocation data, before the older cryptography protecting them becomes suspect. Done correctly, this is repeated on a schedule, every several years, for as long as the document needs to remain provably unaltered. It's the level intended for archival horizons measured in decades, not the level needed for a document that just has to survive a routine multi-year retention period.

Matching PAdES Signature Levels to an Actual Retention Requirement

None of this is a case for always reaching for the strongest level. B-LTA's re-timestamping schedule is operational overhead: something has to run on a cadence, indefinitely, or the protection lapses anyway. For an internal approval that gets reviewed and superseded within weeks, B-B is enough, since nobody will be validating it five years out. For a commercial contract with an eight-year retention expectation, B-LT is close to the minimum sensible floor, because it removes the dependency on infrastructure that may not exist by the time anyone checks it again. For records under long statutory retention, such as certain financial or regulatory filings, B-LTA earns its overhead.

Legal recognition is a separate axis from all of this. India's IT Act, 2000 recognises electronic signatures on a technology-neutral basis under Section 3A and doesn't mandate PAdES or any specific ETSI level; the European Union's eIDAS regulation takes a similar technology-neutral stance while explicitly referencing the ETSI baseline formats as a recognised way to meet its advanced and qualified signature requirements. A signature can be legally recognised and still become practically unverifiable years later if it was only ever created at B-B. The legal question and the long-term verifiability question have to be answered separately.

Checking What Level a PDF Signature Actually Has

The fastest check for a single document is Adobe Acrobat's signature panel: opening a signed PDF and inspecting the signature properties shows whether long-term validation information is present. For anything closer to an engineering task, such as auditing a batch of signed PDFs from a vendor, an open-source library gives a direct answer rather than an inference from the UI.

pyHanko, an open-source PAdES library, can inspect a signed PDF's embedded signature dictionary and DSS contents from the command line:

pip install pyHanko

pyhanko sign validate --pretty-print contract-signed.pdf

# Example output fields to check:
#   Signature level: PAdES-B-LT
#   Trust anchor: valid, chain built to root
#   Revocation info: embedded (2 certs, 1 CRL, 1 OCSP response)
#   Timestamp: present, RFC 3161, TSA: <issuer name>

The output reports whether embedded revocation data and timestamps are present, which is what actually distinguishes B-LT and B-LTA from a bare B-B signature; the padlock icon in a PDF viewer won't tell that story on its own. For an organisation receiving signed documents from an external platform, that command is a five-minute way to confirm the vendor is producing something that will still validate after the signing certificate's window closes, rather than taking a marketing page's word for it.

Frequently Asked Questions

What happens to a PAdES B-B signature after the signing certificate expires? The signature bytes don't change, but a validator checking it after expiry has no fresh way to confirm the certificate wasn't revoked at signing time, unless it separately keeps the certificate authority's historical revocation records. In practice, most standard PDF viewers will flag the signature as unable to be validated, even though nothing in the document was altered.

Is B-LTA always the right level to use? No. B-LTA adds overhead, periodic re-timestamping over the archived validation data, that only pays off for documents that must stay verifiable for years or decades, such as contracts under long retention rules. A signature with a short shelf life, like an internal approval reviewed within weeks, rarely needs it.

Does India's IT Act require a specific PAdES level? No. The IT Act, 2000 recognises electronic signatures on a technology-neutral basis and doesn't mandate PAdES or any particular ETSI level. Which PAdES level a document carries is a technical choice about how long the signature stays independently verifiable; it's separate from the legal question of whether the signature is recognised at all.

How do I check which PAdES level a PDF actually has? Open the signature panel in Adobe Acrobat and look at the signature's properties, or inspect the signature dictionary directly with an open-source library such as pyHanko, which reports the embedded revocation data, timestamps and Document Security Store contents.

The ETSI baseline levels aren't a hierarchy of "better" signatures so much as a set of answers to a question most signing workflows never ask until it's too late: will this still verify after the certificate is gone. As document retention requirements stretch further, driven by regulatory record-keeping rather than convenience, the gap between what a signature proves on day one and what it can still prove a decade later is likely to matter to more teams that never had to think about it before.