August 18, 2026
CAdES (CMS Advanced Electronic Signatures) is the ETSI standard — EN 319 122 — for creating advanced electronic signatures on top of the Cryptographic Message Syntax (CMS), the format defined in RFC 5652 and originally known as PKCS#7. In plain terms: CAdES takes a conventional CMS/PKCS#7 digital signature and adds the signed attributes needed to prove who signed, when they signed, and that the signed data has not changed since. It is most often used to sign arbitrary data or files (software packages, e-invoices, registry records, transaction payloads) rather than visually presented PDF documents — that role belongs to PAdES — or XML-native data, which is XAdES territory.
If your team operates in or sells into the European Union, CAdES matters because it is one of the three signature formats ETSI standardized to satisfy eIDAS requirements for advanced and qualified electronic signatures. This article walks through what CAdES is, how it satisfies eIDAS advanced signature requirements, what each baseline profile adds, and how to decide between CAdES, PAdES, and XAdES in real systems.
What is CAdES?
CAdES stands for CMS Advanced Electronic Signatures. The current specification is ETSI EN 319 122, which defines how to build electronic signatures using CMS SignedData structures — the same binary envelope format (RFC 5652, historically PKCS#7) used in S/MIME email, code signing, and many PKI applications.
A plain CMS signature already contains the signer's certificate and a signature value computed over the content (or over signed attributes). What CAdES adds is a controlled set of signed and unsigned attributes that turn a raw cryptographic signature into an evidentiary object:
- Signing-certificate attribute: binds the signature to the exact signer certificate, preventing certificate substitution attacks.
- Signature time-stamp: a trusted timestamp proving the signature existed at a given moment.
- Complete validation data (later profiles): the certificate chain, revocation responses (CRL/OCSP), and further archive time-stamps embedded so the signature can be validated long after keys expire or CAs disappear.
Because CAdES is content-agnostic, the signed payload can be anything: a binary file, a JSON transaction, a batch of records. That makes it the natural choice for system-to-system signing, e-invoicing pipelines in some jurisdictions, long-term archival of signed data sets, and any workflow where the signed object is not a human-readable PDF.
How CAdES maps to eIDAS advanced electronic signatures
Under eIDAS, an advanced electronic signature (AdES) must meet four requirements: it is uniquely linked to the signatory, it is capable of identifying the signatory, it is created using signature creation data under the signatory's sole control, and it is linked to the signed data so any later change is detectable.
CAdES is designed precisely so that a conforming signature can demonstrate all four:
- Unique link and identification: the signature embeds a reference to the signer's certificate, issued by a CA after identity proofing.
- Sole control: the private key that produced the signature is held only by the signer (on a token, HSM, or remote signing service under their control). The format itself cannot enforce this, but CAdES is the container in which such sole-control signatures are expressed and evidenced.
- Tamper detection: the signature is computed over the content (via signed attributes, including the message digest), so any modification invalidates the signature mathematically.
When the signing key sits in a qualified signature creation device (QSCD) and the certificate is qualified, the same CAdES structure becomes a qualified electronic signature (QES) — the highest eIDAS tier, legally equivalent to a handwritten signature across the EU. For a deeper look at the legal tiers, see our guides to advanced electronic signatures as a business standard, qualified electronic signatures, and what makes an eIDAS-compliant electronic signature in practice.
CAdES baseline profiles: B-B, B-T, B-LT, B-LTA
ETSI defines four baseline profiles. Each profile builds on the previous one, adding attributes that extend how long the signature can be validated and with how much confidence.
A practical reading: B-B is the floor for an advanced signature; B-T is the sensible default for most business transactions; B-LT is what you want for contracts and records kept for their retention period; B-LTA is for archival-grade evidence where legal retention runs for many years. Note that CAdES-B-LT and B-LTA signatures are typically produced by augmenting an existing signature with validation data — a job often done by the receiving system or an archival service rather than the signer.
Detached vs enveloping CAdES signatures
CMS SignedData supports two packaging styles, and CAdES inherits both:
- Enveloping (attached): the signed content is embedded inside the signature structure. One file carries everything, which is convenient for storage and transport, but recipients need a CMS-aware tool to extract the content.
- Detached: the signature structure contains only the signature; the content lives in a separate file. The original file stays byte-identical and readable by any tool, but you must keep and transport both parts together — losing the detached signature means losing the evidence.
Choose detached signatures when the signed artifact must remain usable by non-cryptographic systems (for example, a data file that downstream pipelines parse). Choose enveloping signatures when a single self-contained evidence package is more important than direct readability of the payload.
CAdES vs PAdES vs XAdES: which format when
The three ETSI AdES formats share the same baseline profile logic (B-B, B-T, B-LT, B-LTA) and the same eIDAS goals; they differ in the container they sign.
Rules of thumb:
- Sign a document people will read and print → PAdES. Our PAdES guide for advanced electronic signatures on PDF and the explainer on what PAdES is for PDF cover that path in detail.
- Sign XML at the document or element level (e-invoices under EN 16931 profiles, SOAP/XML services) → XAdES.
- Sign arbitrary files, data blobs, or batches where CMS/PKCS#7 tooling already exists → CAdES.
None is "stronger" than the others at the same profile level; the choice is about the data format your ecosystem speaks.
Validation and long-term archival
Creating a CAdES signature is only half the story; validating it — today and in ten years — is the other half. Validation of a B-LT or B-LTA signature can proceed offline because everything needed (chain, revocation data, time-stamps) travels with the signature. Validation of a bare B-B signature depends on live access to the CA's revocation services, which may not exist years later.
A sound validation workflow checks: the signature's cryptographic integrity, the certificate path to a trusted root, revocation status at the claimed signing time, the time-stamp token's own validity, and (for B-LTA) the chain of archive time-stamps. For the operational side of checking signatures day to day, see our digital signature verification guide.
For long-term archival, treat B-LTA plus periodic re-timestamping as the pattern: as hash or signature algorithms age, an archive adds a fresh archive time-stamp with current algorithms, preserving evidentiary value without needing the original signer again.
Practical adoption notes for businesses
A few grounded recommendations before you standardize on CAdES:
- Check your ecosystem's expectations first. If partners, regulators, or schemes (e-invoicing networks, customs, registries) mandate a format, follow the mandate; where they say "AdES," match the container to your data.
- Default to B-T at minimum for anything transactional; the marginal cost of a TSA timestamp is trivial against its evidentiary value.
- Plan who adds validation data. Moving from B-T to B-LT requires capturing revocation evidence at validation time — assign that step explicitly to your receiving/archival system.
- Prefer qualified certificates and, where required, QSCDs or qualified remote signing when you need QES-level effect.
- Don't hand-roll CMS. Use maintained libraries or a signing platform that already handles profile conformance, TSA integration, and validation-data capture; subtle attribute errors silently break conformance.
Build compliant advanced signatures with Nota Sign
Nota Sign is FaDaDa's global e-signature platform, built on infrastructure ranked #1 in China's e-signature software market by IDC for consecutive years. The platform supports SES, AES, and QES signature levels across 100+ countries and regions, with deep APAC compliance coverage — including iAM Smart in Hong Kong and Singpass in Singapore — and regional data centers for data residency requirements.
Whether your workflow calls for PDF-based PAdES signatures on contracts or CMS-based signatures on data payloads, Nota Sign's platform and APIs handle certificate management, trusted timestamping, and long-term validation evidence so your team doesn't have to assemble the plumbing itself. Pricing is designed to be friendly to growing teams: no per-seat fees for small businesses, with tailored plans available for mid-market and enterprise requirements.
Ready to discuss your compliance architecture? Talk to the Nota Sign team about your signature-format and validation requirements.
