Can You Sign Multiple Documents with One Digital Signature?

August 20, 2026 ·Gustav Poola ·

digital-signaturebatch-signingcontainer-signatureasic-epades-portfoliomerkle-treeadeseidasmulti-document-signingnon-repudiation

Yes — and there are two distinct patterns, each with different legal effects. A container signature (ASiC-E, PDF portfolio, or equivalent) produces one cryptographic signature over a manifest that hashes multiple documents together; the documents are bound to the signature and to each other. A batch signing operation lets the signer consent once to sign N documents in one session, producing N independent signatures. Which pattern is correct for your deployment depends on whether the documents belong together legally (container) or independently (batch).

Can You Sign Multiple Documents with One Digital Signature?

An Amsterdam-based freight platform's product lead sent us an architecture question at a recent conversation. Their operations team was signing weekly manifest batches — 500 to 1,500 individual shipment records per week per operator — and the signing workflow was becoming the friction point in the whole logistics chain. The team had proposed a "one-click sign-all" button that would produce a single AdES signature over the entire weekly batch. Legal counsel had flagged the proposal: what happens legally when 800 of those shipments are disputed six months later and the customer wants to challenge only 12 of them specifically? Can you challenge a subset of a batch signature? The answer, once we drew the architecture, depended on which of two very distinct multi-document signature patterns the platform actually implemented. This post is that decomposition, walked through in the shape a product lead, compliance officer, or signing-platform architect needs.

What does "one signature over multiple documents" actually mean technically?

Two fundamentally different cryptographic constructions can produce what feels to the signer like "signing multiple things at once." They are not interchangeable.

Container signature. A single cryptographic signature is computed over a manifest — a data structure that lists the documents and includes their hashes. The most common containers are ASiC-E (Associated Signature Container — Extended) defined under ETSI EN 319 162-1, and PDF Portfolio + PAdES-B defined under ETSI EN 319 142. In both cases the signature applies to the manifest structure; the documents inside the container are cryptographically bound to that manifest through their hashes. Modify any document in the container and the manifest hash breaks, invalidating the signature.

Batch signing operation. The signer authenticates once (biometric, PIN, or Dual Key challenge) and consents to sign N documents in a single session. The platform then produces N independent AdES signatures — one per document — each cryptographically valid and legally separable from the others. Each signature has its own timestamp, its own certificate binding, and its own LTV embedding under ETSI EN 319 142 if the AdES envelope requires it. From the cryptographic layer the signatures are entirely independent; from the user-experience layer they feel like one action.

Merkle hash tree. Both container signatures and batch signing operations often use Merkle tree constructions under the hood — the document hashes are combined pairwise into intermediate hashes, which are combined again into higher-level hashes, until a single root hash remains. That root hash is what the actual cryptographic signing operation runs against. The Merkle structure means the signer commits to all N documents through a single root — but crucially, any individual document's inclusion in the batch can be proven or challenged independently by walking the tree from that document's leaf up to the root. The relationship between hashing and signing is walked in What's the Difference Between Hash and Digital Signature?.

Where I most often see the two patterns confused is in vendor pitches for "batch signing." Some vendors implement Pattern 1 (container) and describe it as batch signing; others implement Pattern 2 (independent signatures per document) and use the same term. The distinction matters because the legal effect at dispute time is different — and the wrong architectural choice for a given document class becomes very expensive later.

How do batch signing and container signing differ legally?

Under eIDAS Article 26, an Advanced Electronic Signature must be "linked to the data signed in such a way that any subsequent change is detectable." Both container signatures and batch signatures satisfy this requirement — but the "data signed" is different in the two cases.

Container signature — legal scope. The data signed is the manifest structure, which by definition includes all documents inside the container. Legally, the signer has committed to the entire package as a whole. If a dispute arises over one document inside the container, the challenger's position is that they are challenging the composite entity the signature was applied to. A subset challenge is architecturally awkward — the signature is over the whole, so partial invalidation raises interpretation questions the AdES envelope alone does not answer. Container signatures are the right pattern when the documents belong together as a unit — an insurance policy plus its schedules plus its terms and conditions; a construction contract plus its plans plus its bill of materials; a due-diligence deliverable plus its supporting workbooks.

Batch signing — legal scope. Each of the N signatures produced applies to its own document independently. Legally, the signer has committed to each document as a separate act, all executed in one session. A dispute over one document is a challenge to that one signature — the other 499 signatures are entirely independent and unaffected. The evidentiary walk-back mechanics that apply to any individual signature challenge — walked in What Happens if Someone Denies They Signed Digitally? — apply per signature, not per session. Batch signing is the right pattern when the documents are legally independent even though the operational workflow signs them together: 500 weekly shipment records; a portfolio of insurance policies for 200 individual customers; monthly payroll approvals across a distributed team.

The legal-scope test to distinguish which pattern you need: if a challenger might reasonably want to invalidate one document without touching the others, batch signing is the right pattern. If the documents are legally a single deal that would either stand or fall as a whole, container signing is correct. Deploying the wrong one produces friction at dispute time that no amount of downstream cleanup can eliminate.

Where I disagree with the loud vendor pitch on "batch signing" more broadly is that the term is used to mean "user consent once, platform signs many" — which is a UX pattern, not a legal-scope pattern. Both container and batch achieve that UX. The architectural question the vendor should be answering first is: do the resulting signatures need to be legally separable or legally bound together? The vendor whose answer is "our platform supports both patterns and we can advise which one applies per document class" is having the right conversation. The vendor whose answer is "we support batch signing" is not.

Where do container and batch signing fit different deployment patterns?

Five deployment shapes I have watched play out, each with a distinct multi-document signing profile.

Freight and logistics manifest signing. An operator produces 500 to 5,000 shipment records per week per country of operation. Each shipment is a legally independent contract of carriage under UNECE CMR Convention or the corresponding domestic freight law. Batch signing is the correct pattern — signatures must be legally separable because carriers, shippers, and consignees may dispute any one shipment without touching the others. The connection between per-shipment evidence and cross-border enforcement is walked in What Is eCMR? A Guide for Freight Companies.

Insurance policy issuance. An underwriter issues policies at monthly volume — dozens to hundreds — each policy legally independent. Batch signing. A Barcelona insurance carrier's operations team I worked with used a batch pattern for monthly policy issuance, and it held up cleanly through several individual-policy disputes without collateral damage to the other signatures in the batch.

Complex commercial contracts with schedules. A construction contract has the main body, several schedules, technical specifications, drawings, and a bill of materials — often 10-30 documents that legally form one binding agreement. Container signature. The parties intend to be bound to the whole thing; a challenger can attack the overall contract but should not be able to invalidate one schedule while leaving the rest standing.

Employee onboarding packages. A new hire receives 5-15 documents at start: employment contract, GDPR consent, IT policies, safety instructions, benefit enrolments. A Copenhagen HR-tech platform I reviewed uses batch signing here — each document is legally independent (the employee could theoretically revoke GDPR consent without walking away from the employment contract) and platform architecture reflects that. The general education/HR identity pattern is walked in How Do You Verify Student Identity for Attendance, Access, and Exams Under GDPR and the AI Act? — same primitive-reuse logic applies to workforce onboarding.

M&A due-diligence deliverables. A due-diligence report plus its supporting workbooks, data-room references, and appendices form a single deliverable the recipient is meant to rely on as a whole. Container signature. The signer is committing to the deliverable as a unit; partial invalidation would misrepresent the analytical conclusions.

My take on which one to default to: for high-volume operational workflows (freight manifests, policy issuance, payroll approvals), batch signing is almost always correct — the documents are legally independent even when the workflow signs them together. For lower-volume compound-legal-instrument work (complex contracts, M&A deliverables, insurance product packages), container signing is almost always correct. The mistake I see most often is defaulting to container signing everywhere because it is cheaper to compute — one signature versus N — without realising that the legal-separability property is lost when you do that.

What should you check in a batch-signing procurement architecture?

Six questions to put to any batch- or container-signing platform quote before signing off.

Does the platform support both patterns, and can you choose per document class? A platform that only supports one is forcing every workflow into that pattern regardless of legal fit.
Is the container format a recognised ETSI standard (ASiC-E, PDF Portfolio + PAdES) or a vendor-proprietary wrapper? Proprietary wrappers may verify correctly today but produce evidence that cannot be independently verified years later without vendor cooperation.
For batch signing: is each signature produced independently under its own certificate + timestamp + LTV, or is the platform amortising some evidence artefacts across the batch? If timestamps are batch-shared, the signatures are legally coupled in ways the pitch does not describe.
For container signing: how is a subset challenge handled? Not "we don't support subset challenges" — the specific procedural path for what happens when a challenger disputes one document inside a container and the court has to reason about the whole.
Is the Merkle-tree structure used, and can you produce an inclusion proof for any individual document? Under batch signing with a Merkle root, a challenger or a verifier can prove any specific document was in the batch by walking the tree from that leaf to the root. Platforms that flatten the batch structure lose that capability.
Does the platform's evidence retention treat each signature (batch) or each container (container) as an independent record? Under AMLR Article 77's 5-10 year retention, batch signatures each need to survive independently; container signatures survive as one unit. Retention architecture has to match.

My take on this: batch-signing procurement is one of the areas where the vendor-pitch conversation drifts furthest from the actual legal-architecture conversation. The right platform-choice depends on the specific document classes the workflow signs, and the answer is often that the same platform handles multiple document classes with different patterns per class. Vendors who cannot tell you which pattern applies to which of your workflow types are not equipped to make the architectural choice for you.

Where IdentiGate fits

IdentiGate's signature platform supports both batch signing (N independent AdES signatures per user session) and container signing (ASiC-E + PDF Portfolio + PAdES) — the choice is per document class, not a platform-level constraint. Our batch signing product uses Merkle-tree structures under the hood so that individual-document inclusion proofs are preserved even when the signing UX is single-consent per batch; every signature carries its own qualified timestamp and Long-Term Validity embedding regardless of batch size. Our evidence layer keeps the whole audit trail — whether it is 500 independent per-shipment signatures or one container over a 30-document contract package — independently verifiable across the retention periods AMLR + national commercial law require.

If your workflow is producing multi-document signing volume that is straining your current platform, or if you have a batch-signing procurement quote and the six-question audit above surfaces gaps, get in touch.

Sources

Legal + regulatory frameworks

Container + batch signature standards

Cryptographic primitives

Identity + assurance standards

About the author

Gustav Poola is a co-founder of IdentiGate, a European identity-verification and digital-signature company building on top of chip-anchored identity-proofing (ICAO 9303 passport NFC), Advanced Electronic Signatures (eIDAS Article 26) with Dual Key architecture, Advanced Electronic Seals, and multi-document signing (batch + container). He works on the architecture side — deployment patterns for cross-border teams in logistics, healthcare, fintech, HR-tech, defence, and cybersecurity — and writes about the intersection of cryptographic primitives, standards, and the practical decisions engineering and product teams have to make together.

The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.