PAdES Conformance Levels Explained: B-B, B-T, B-LT, B-LTA

PAdES (PDF Advanced Electronic Signatures) is a European standard defined by ETSI EN 319 142 for electronic signatures in PDF documents. It establishes four conformance levels that progressively increase the longevity and trustworthiness of a digital signature. Understanding these levels is essential for eIDAS compliance, long-term archival, and legally binding electronic signature workflows.

Why PAdES Matters

A basic digital signature proves that a document was signed by a specific person and hasn't been tampered with. But what happens when the signer's certificate expires? What if the signing CA is later compromised? What if the cryptographic algorithm becomes weak in 10 years?

PAdES conformance levels address these questions by defining what additional data must be embedded in the PDF to support verification over increasingly longer time horizons.

The Four Conformance Levels

B-B (Basic)

Requirements:

• Valid CMS/PKCS#7 signature
• Signer certificate embedded
• Signed attributes present (signing time, message digest, content type)

What it means: The signature is cryptographically valid at the time of verification. This is the minimum baseline for a legally valid electronic signature under eIDAS. However, if the signer's certificate expires or is revoked, and no timestamp proves when the signature was created, verifying the signature becomes impossible.

Typical use: Short-lived documents, internal approvals, non-regulated contexts.

B-T (Timestamp)

Requirements:

• Everything from B-B
• Embedded RFC 3161 timestamp from a trusted Time Stamping Authority (TSA)

What it means: A trusted third party has cryptographically attested to when the signature was created. Even if the signer's certificate expires later, the timestamp proves the signature existed while the certificate was still valid. This provides non-repudiation of time.

Typical use: Contracts, agreements, and any document where proving the signing date is important.

B-LT (Long-Term)

Requirements:

• Everything from B-T
• Embedded validation data: full certificate chain and revocation information (CRL or OCSP responses)

What it means: The PDF contains everything needed to verify the signature without network access. Even if the CA's servers go offline, the OCSP responder shuts down, or the CRL distribution point becomes unavailable, the signature can still be fully validated using the embedded data.

Typical use: Regulated industries, financial documents, healthcare records, legal archives.

B-LTA (Long-Term Archival)

Requirements:

• Everything from B-LT
• Document timestamp that covers the entire validation data (not just the signature)

What it means: The document timestamp protects the embedded validation data against future algorithm compromise. If SHA-256 becomes weak in 20 years, the document timestamp (using a then-current algorithm) proves the validation data was intact at the time of timestamping. Multiple document timestamps can be stacked over time for indefinite archival.

Typical use: Government archives, notarized documents, 10+ year retention requirements, eIDAS qualified signatures.

Detecting PAdES Levels with VerifyKit

VerifyKit automatically detects the PAdES conformance level of each signature:

import { createVerifier } from '@trexolab/verifykit-core'
 
const verifier = await createVerifier()
const result = await verifier.verify(pdfBuffer)
 
for (const sig of result.signatures) {
  console.log(`${sig.signerName}: PAdES ${sig.padesLevel ?? 'N/A'}`)
}

The padesLevel field returns one of: 'B-B', 'B-T', 'B-LT', 'B-LTA', or null (for non-PAdES PKCS#7 signatures).

PAdES detection only applies to ETSI signature types (ETSI.CAdES.detached, ETSI.RFC3161). Standard PKCS#7 signatures (adbe.pkcs7.detached, adbe.pkcs7.sha1) return null for padesLevel.

eIDAS and Legal Context

The European eIDAS Regulation (EU 910/2014) establishes three types of electronic signatures:

VerifyKit's 8-point verification model covers the technical checks needed for all three types. Combined with PAdES conformance detection, it gives your application the data to make informed decisions about signature validity and compliance.

Document Timestamps vs. Signature Timestamps

A common source of confusion:

• Signature timestamp — An RFC 3161 token embedded within a single signature's CMS structure. It proves when that specific signature was created. Required for B-T and above.
• Document timestamp — A special signature with sub-filter ETSI.RFC3161 that covers the entire document. It protects validation data for archival purposes. Required for B-LTA.

VerifyKit identifies document timestamps by checking subFilter === 'ETSI.RFC3161' and displays them with a distinct visual indicator in the React viewer.

Practical Guidance

Next Steps

• Core Concepts — The full 8-point verification model
• Security — VerifyKit's security model and compliance references
• Live Demo — Verify a PAdES-signed document in your browser
• Contact Us — Questions about eIDAS compliance?