How Do Multiple Parties Sign the Same Document Digitally?

September 3, 2026 ·Gustav Poola ·

multi-party-signingdigital-signatureelectronic-signaturesequential-signingparallel-signingcounter-signatureadeseidaspadesxadeslong-term-validity

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.

How Do Multiple Parties Sign the Same Document Digitally?

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 Advanced Electronic Signature formats (PAdES, XAdES, CAdES), but the cryptographic semantics, the timestamp coordination, and the Long-Term Validity 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.

The engineering lead of a Munich-based freight-forwarding platform sent a question into a shared engineering channel last week: their platform's multi-party workflow was producing signed bills of lading that verified cleanly for the first two signatures (shipper, carrier) but failed the third signature verification (consignee) whenever the three parties signed within a short time window. The failure was intermittent, appeared to depend on network latency between the signing platform and the timestamp authority, and had started producing enough support tickets from the consignee side that operations had escalated. This post is the answer at the layer the engineering team actually had to reason about — where multi-party signing differs from the more familiar single-signer or batch-signing (one signer, many documents) patterns, and where the cryptographic layer stops being invisible in a way that matters at the workflow architecture level.

What does "multi-party document signing" actually mean, and how does it differ from batch signing?

Different axis. Batch signing is one signer, many documents — a single cryptographic operation binds the signer to a set of documents through a hash-tree root or a container object. Multi-party signing is many signers, one document (or one document set) — each of N signers applies their own signature to the same underlying data, and the verifier eventually checks that every required signature is present and valid.

The two patterns are architecturally independent — a workflow can be batch-and-multi-party at once (five signers each applying signatures to a fifty-document quarterly filing), or single-signer and single-document, or any combination. But the design questions each pattern raises are different. Batch signing raises questions about legal separability (can each document be disputed independently?) and evidence trees (how does the Merkle root prove membership without exposing the other documents?). Multi-party signing raises questions about order dependency (does the signature at position N depend on the signature at position N-1?), evidence coordination (does each signer bind their own timestamp, or does the workflow provide a single coordinated timestamp?), and revocation cascade (if signer A's certificate is later revoked with retroactive effect, does that invalidate signers B, C, and D's signatures on the same document?).

The workflow choice — sequential or parallel — is the load-bearing architectural decision. Almost every downstream question about cryptographic format, timestamp coordination, LTV envelope, and revocation handling flows from this choice.

What is the difference between sequential and parallel multi-party signing?

Sequential means order matters cryptographically. Parallel means order does not matter cryptographically, even if it may matter procedurally.

Sequential (counter-signature) pattern. Party A signs the document. Party B receives a document that already contains A's signature and signs the combined payload (original document + A's signature). Party C receives the payload with both A's and B's signatures and signs that. Each signature after the first is technically a counter-signature — it binds not just the document but also the preceding signatures. Under ETSI EN 319 142-2 for PAdES, the counter-signature construct is a specific signature attribute that references the earlier signature's hash. Under XAdES per ETSI EN 319 132, counter-signatures are handled via the SignatureTimeStamp and CounterSignature elements. The important cryptographic property: verifying signature C requires signatures A and B to be present and valid; if you strip A's signature, C's signature verification fails. This is the pattern for workflows where the order genuinely matters — a contract signed by the vendor first, then the buyer, then witnessed by a notary; a board resolution where the chair signs last after all directors have signed; a real-estate transaction where the buyer, seller, and notary sign in a specific legally-required sequence.

Parallel (independent signature) pattern. Each party receives the same original document (or a hash of it) and signs it independently. Party A's signature does not depend on B's or C's. When all N signatures have been collected, an aggregator combines them — typically by attaching each signature as a separate signature entity within the same signed container (PAdES supports multiple parallel signatures within one PDF; XAdES via multiple <Signature> elements; CAdES via multiple SignerInfo structures in the CMS SignedData). The cryptographic property: any subset of signatures can be verified independently. If signature A is invalid or gets stripped, signatures B and C still verify correctly against the underlying document. This is the pattern for workflows where the parties sign in whatever order suits them procedurally — a multi-founder shareholder consent where all three founders need to sign but the order among them is irrelevant; a supplier-quality attestation where an operations lead, a quality lead, and a compliance lead each independently sign the same weekly report; a joint venture agreement where six parties across three jurisdictions sign asynchronously.

The confusion I see repeatedly in workflow designs is teams using the sequential pattern for what is genuinely a parallel workflow (introducing artificial serialisation that slows the process and creates coordination bugs) or using the parallel pattern for what is genuinely a sequential workflow (accepting all signatures as independent when the legal or business context requires one to depend on another). Getting this right at design time is much cheaper than retrofitting.

How does the cryptographic layer actually handle multiple signatures?

Each AdES format has a specific construction for multi-signature scenarios, and the format choice constrains the workflow options.

PAdES (ETSI EN 319 142) is the AdES profile for PDF documents. PAdES supports parallel signatures natively — a PDF can carry multiple signature fields, each signed independently. The signatures are stored in the PDF's incremental-update structure, so each signer effectively appends a new revision of the PDF with their signature added. PAdES also supports sequential counter-signatures via the /DocMDP (Document Modification Detection and Prevention) mechanism, which lets the first signer specify what changes subsequent signers are allowed to make. Multi-party PAdES with a mix of parallel and sequential is possible but requires careful /DocMDP configuration to avoid one signer's constraints breaking another's ability to add their own signature.

XAdES (ETSI EN 319 132) is the AdES profile for XML data. XAdES supports both patterns via distinct elements — multiple <Signature> elements at the same level for parallel signing, and <CounterSignature> elements nested inside an existing signature for sequential counter-signing. XAdES is dominant in workflows where the underlying data is structured (invoicing, freight documents, healthcare records) rather than presentation-oriented.

CAdES (ETSI EN 319 122) is the AdES profile built on RFC 5652 Cryptographic Message Syntax. CAdES supports parallel signatures via multiple SignerInfo structures inside a single SignedData object, and counter-signatures via the id-countersignature unsigned attribute. CAdES is common in machine-to-machine signing workflows and long-term archival scenarios.

ASiC (Associated Signature Containers) (ETSI EN 319 162) is a container format that wraps a document plus one or more signatures (in any of PAdES, XAdES, or CAdES) in a single ZIP archive. ASiC is often the practical answer for multi-party workflows because it decouples the document format from the signature format — a Word document, an image, a JSON payload can all be multi-party-signed via ASiC without embedding signatures inside the document itself.

The pattern I see work best in practice is: choose the document format first (PDF, XML, JSON, ZIP-of-mixed), then choose the AdES profile that natively supports the document format, then use the workflow pattern (sequential or parallel) that the format supports cleanly. Fighting the format's default multi-signature semantics is possible but generates operational bugs — the Munich freight-forwarder case that opens this post was exactly this: a parallel signing workflow implemented via sequential counter-signature semantics because the platform's default was PAdES-with-/DocMDP, which serialises signature application. When the three parties tried to sign within a short window, race conditions in PDF revision generation produced the intermittent verification failures.

When does timestamp coordination become the load-bearing question?

At the moment when the workflow requires the multi-party signing to establish a specific chronology and each signer's local system clock is not sufficient.

Every AdES signature can carry a timestamp — either an unsigned signature timestamp added by the signer (embedded in the signature attributes) or a signature timestamp obtained from an external timestamp authority (TSA) at the moment the signature is applied. For single-signer signatures, the timestamp establishes when the signature was created. For multi-party signatures, the timestamp establishes not just when each signature was created but also the order if the workflow needs to prove that signer B signed after signer A.

Sequential workflows have an easier time here because the cryptographic dependency itself proves the order (signer B's signature includes signer A's signature by reference; therefore signer B signed after signer A). Parallel workflows have a harder time because the cryptographic layer is order-neutral by design, so if the workflow needs to prove that signer A signed at 14:03 and signer B signed at 14:07 (rather than the other way around), the ordering has to be established by external timestamps that each signer's system independently obtains from a trusted TSA at the moment of signing.

The engineering pattern that survives compliance review for parallel workflows is: each signer's system fetches a fresh signature timestamp from a well-known TSA at the moment of signing, embeds the timestamp in the signature attributes, and the aggregator that combines the signatures preserves each signer's timestamp intact. The timestamp authority becomes an implicit fourth party in the workflow — one that all signers must be able to reach at the moment of signing. Platforms that skip this and rely on their own server-side clock end up with signatures whose ordering cannot be proven independently, which surfaces as an audit finding the first time a dispute questions which party signed first.

What is the LTV envelope answer for multi-party signatures?

Each signature needs its own LTV wrapper, and the wrapping needs to preserve the multi-signature semantics.

Long-Term Validity for a single signature means capturing (at signing time or shortly after) the signer's certificate chain, the revocation status of every certificate in the chain, and a trusted timestamp — so that decades later, when the certificate itself may have expired and the certification authority may have gone out of business, the signature can still be verified using the captured evidence. For multi-party signatures, each signer's signature needs its own LTV package (certificate chain + revocation status + timestamp), and the aggregator container needs to carry all N LTV packages plus a single overarching document timestamp that ties them together.

Under PAdES-LTA (Long-Term Archival) per ETSI EN 319 142-1 Annex A, the LTV envelope is added as an incremental PDF update that follows the last signature. For a multi-party PAdES document, the LTA wrapper is applied once (after all signatures are collected), and it carries validation data for every signer. Under XAdES-A (ETSI EN 319 132) and CAdES-LTA (ETSI EN 319 122-1), the equivalent constructs apply.

Where I have seen this go wrong most often is workflow designs that add the LTV envelope after each signature individually rather than once after all signatures are collected. The individually-wrapped-per-signature pattern works but creates an LTV proliferation problem: N signers produce N nested LTV wrappers, the document balloons in size, and some verifiers get confused by the layered structure. The recommended pattern is: apply signatures first, then wrap the completed multi-party document with one LTV envelope containing all validation data. The LTV timestamp then acts as the "closing timestamp" for the workflow, and the document is archival-ready.

Where does IdentiGate fit in the multi-party signing picture?

The signatures product supports both sequential and parallel multi-party signing patterns via PAdES, XAdES, CAdES, and ASiC — with each participating signer's identity anchored via our chip-anchored identity-verification product and each signature retained through the evidence layer with a coordinated LTV envelope at workflow close. Where we typically integrate is at the signature-application step within the customer's existing signing workflow: the customer's platform orchestrates the multi-party workflow (who signs, in what order, with what deadline), and we produce the individual AdES signatures with the identity binding that comes from chip-anchored proofing rather than a document scan.

Where we do not (today) ship the orchestration layer itself — the workflow engine that manages sequential signing chains, parallel signing collection, deadline reminders, and party-substitution rules — that is typically a customer-owned or third-party workflow tool the platform integrates on top of our signature primitive. Native workflow-orchestration is on the roadmap for late 2026, and until it lands the pattern we recommend is: customer-owned orchestration, IdentiGate for identity + signature + evidence.

For batch-and-multi-party workflows — five directors signing forty policy documents in one quarterly action, for example — our batch-signing capability composes with the multi-party pattern: each director independently applies a batch signature to the document set, and the workflow aggregator collects all five directors' batch signatures. This is the shape that scales cleanly at high signer count times high document count.

The engineering push-back I would make

Where I would push back on the "we support multi-party signing" claim on most e-signature vendor pages is that the claim usually covers only the parallel pattern with a simple aggregator, not the sequential counter-signature pattern with proper /DocMDP handling, and not the LTV coordination across multiple signers. Ask any vendor to demonstrate a live three-party sequential workflow with a coordinated LTV envelope at close — most cannot without significant custom engineering. The vendors that can are the ones whose multi-party support was designed at the signature-format level rather than bolted on above it.

The other push-back is on the framing that multi-party signing is a "workflow feature" rather than a cryptographic architecture question. It is both — but the cryptographic side determines what workflows are actually possible. Deciding the workflow first and then discovering the cryptographic format cannot support it cleanly is one of the most common causes of e-signature project overruns I have seen. Getting the format-first, workflow-second sequence right saves the project.

Sources

Primary — eIDAS and AdES formats

Primary — IETF cryptographic standards

Primary — identity assurance and document standards

About the author

Gustav Poola is a co-founder of IdentiGate OÜ, a European identity-verification and digital-signature company building on top of chip-anchored identity proofing (ICAO 9303 passport NFC), Advanced Electronic Signatures under eIDAS Article 26, and Advanced Electronic Seals. He focuses on the cryptographic architecture of signature production, multi-party and multi-document workflows, and the LTV envelopes that make signature evidence survive decades of certificate lifecycle changes.

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.

You do not — you verify once, chip-anchored, and reuse the record across every subsequent task engagement with a lightweight activation step (biometric touch, PIN, or device unlock) that binds each task to the same verified person. The engineering pattern is reusable identity anchored at first-verify and retained under an AdES evidence envelope that survives well beyond any single task lifetime. This post walks the pattern, the three architectural properties that make it survive a compliance review, and where the picture is genuinely harder than the marketing suggests.