What is the difference between XAdES and a standard XML signature?

A standard XMLDSig signature proves the document was signed with a key but carries no long-term evidence. XAdES adds qualifying properties — signer certificate, signing time, time stamps, revocation data, and archival evidence — so the signature remains verifiable long after creation, even if the CA or original key is no longer available.

What is the difference between XAdES-B-B and XAdES-T?

XAdES-B-B (and the closely related BES) includes the signer's certificate and signing time but relies on the signer's claimed time. XAdES-T adds a trusted time stamp from a TSA over the signature value, providing independent proof of when the signature existed — which matters for legal timelines.

Do I need a certificate to create an XAdES signature?

Yes. XAdES builds on XMLDSig, which requires a signing key and certificate. For legal validity, use a certificate from a recognized CA; for EU QES, a qualified certificate is required. Self-signed certificates work for testing but not for production legal signing.

How do I verify a XAdES signature?

Verification involves checking the XMLDSig core signature, validating the certificate chain at signing time, confirming the TSA time stamp, checking revocation status (CRL or OCSP), and ensuring no unsigned properties were tampered with. Most XML security libraries provide XAdES verification, but the verifier needs the CA's trust anchor or embedded LTA evidence.

Is XAdES recognized under eIDAS?

Yes. XAdES can implement Advanced Electronic Signatures (AES) and, with a qualified certificate and qualified signature creation device, Qualified Electronic Signatures (QES) under eIDAS. The format itself does not grant legal level — the certificate type, identity verification, and trust service provider qualification determine the eIDAS tier.

Which tools support XAdES?

XAdES is supported by XML security libraries (such as Apache Santuario, .NET System.Security.Cryptography.Xml, and Java PKCS#7 toolkits), enterprise signing platforms, and government filing portals. The exact form supported (BES, T, LTA) varies by tool, so confirm before choosing.

When should I choose XAdES over PAdES or CAdES?

Choose XAdES when the document is natively XML — an e-invoice, SOAP message, or government XML filing. Choose PAdES for PDFs and CAdES for detached binary signatures. The concepts are similar across all three; the difference is the container format.

XAdES Standard: XML Advanced Electronic Signatures Explained

XAdES (XML Advanced Electronic Signatures) is an ETSI specification — primarily ETSI TS 101 903 — that extends the W3C XML Signature standard (XMLDSig) with long-term validation evidence, so XML-embedded signatures remain verifiable years after creation. It solves a real problem: digital signatures weaken over time as algorithms age, keys retire, and certificates expire. XAdES layers time stamps, certificate chains, and revocation data into the XML signature block, preserving proof of integrity and signing time for the life of the document. Anyone in e-government, e-invoicing, B2B XML messaging, or any workflow facing legal scrutiny benefits from understanding it.

What Is XAdES and Why Does It Exist?

XAdES is a family of signature profiles defined by ETSI TS 101 903 for signatures expressed as XML. It was created because the base W3C XML Signature standard answers only one question: was this content signed with this key? It does not answer the questions courts and auditors ask later: which certificate was used, was it valid at signing time, and can we still prove this after the certificate has expired?

Every signature decays. Certificates expire, certificate authorities retire, algorithms get deprecated, and revocation lists stop being published. XAdES freezes the evidence — time stamps, certificate chains, revocation responses — inside the signature itself, so verification does not depend on infrastructure that may no longer exist.

How XAdES Extends XMLDSig

An XMLDSig signature is an XML element with a few core parts: lists what was signed and which canonicalization and digest algorithms were used, holds the actual signature bytes, and identifies the signer's key or certificate. If you want the broader cryptography story behind these pieces, our guide to how digital signatures work covers keys, hashing, and certificates end to end.

XAdES keeps that structure untouched and adds one element: . Inside it sit signed properties — the signing certificate reference and the claimed signing time — and unsigned properties added later, such as time stamps, revocation data, and archival evidence. Because XAdES is a strict superset of XMLDSig, any XMLDSig verifier can still check the core signature.

XAdES-B-B and BES: The Baseline Forms

XAdES-BES (Basic Electronic Signature) is the simplest profile. It adds the signer's certificate reference and the signing time to the XMLDSig block — enough to qualify as an advanced electronic signature in the technical sense, but no more. XAdES-B-B is the eIDAS-era renaming of the same baseline level, defined in the ETSI EN 319 132 series that replaced the older TS 101 903 naming.

The limitation of the baseline forms is trust in the signer. The signing time is whatever the signer's computer claimed, and the certificate's validity at that moment is not proven — it must be checked live, against infrastructure that still exists. For anything that might be disputed years later, B-B is only the first rung of the ladder.

XAdES-EPES and Signature Policies

XAdES-EPES (Explicit Policy Electronic Signature) extends BES with one addition: a reference to a signature policy. A signature policy is a document that spells out the rules under which the signature was created — which certificate types are acceptable, what identity proofing was done, what the signature legally means, and how it must be verified.

The policy is identified by a hash and an object identifier inside the qualifying properties, so a verifier can confirm exactly which rulebook the signer committed to. EPES matters where many parties sign under one shared framework — a national e-invoicing network, an industry messaging scheme — because the policy reference removes ambiguity about what the signature means.

XAdES-T, XAdES-C, and XAdES-X: Trusted Time and Validation Data

XAdES-T adds a trusted time stamp token from a Time Stamping Authority (TSA) over the signature value. Unlike the claimed signing time in BES, this is independent, third-party proof that the signature existed at a specific moment — the foundation of every higher level.

XAdES-C adds references to the certificate chain and revocation data (CRL or OCSP responses) used to validate the signature. XAdES-X adds time stamps over that validation data, protecting against later claims that the signer's key was compromised. The progression is cumulative:

XAdES form	What it contains	When you need it
BES / B-B	Signer certificate + claimed signing time	Basic internal signing, low dispute risk
EPES	BES + signature policy reference	Signing under a shared industry or national policy
T	BES + trusted TSA time stamp	Any signature whose signing time may be contested
C	T + certificate and revocation references	Offline validation of the certificate path
X	C + time stamps over validation data	Protection against later key compromise claims
XL / LTA	X + embedded certificates, CRLs, OCSP + archival time stamps	Long-term archiving and regulated retention

XAdES-XL and XAdES-LTA: Built for Long-Term Archiving

XAdES-XL (Long Term) embeds the actual validation material — the full certificate chain, CRLs, and OCSP responses — directly into the signature. A verifier no longer needs to fetch anything from the outside world; everything required to re-run validation is inside the XML.

XAdES-LTA (Long Term with Archive time stamps) adds periodic archival time stamps over the entire signature and its evidence. Because algorithms weaken over time, LTA signatures are meant to be re-stamped with stronger algorithms before the old ones become vulnerable. A well-run archive renews the archive time stamp every few years, keeping the signature provable for decades — the pattern regulators expect for records with ten-year-plus retention duties.

XAdES vs CAdES vs PAdES: Same Family, Different Containers

XAdES, CAdES, and PAdES are sibling ETSI standards built on the same idea: baseline signatures plus progressively richer validation evidence, up to long-term archival forms. They differ only in the container. CAdES profiles CMS/PKCS#7 binary signatures, typically detached from the signed file. PAdES profiles signatures embedded in PDF documents, which is why it dominates document-signing workflows. XAdES profiles XML signatures.

The practical rule is to match the standard to the document's native format: a UBL XML e-invoice calls for XAdES, a contract PDF for PAdES, a detached binary signature for CAdES. The evidence model is essentially the same across all three, so skills transfer directly.

Where XAdES Fits Under eIDAS

eIDAS defines three legal tiers: Simple (SES), Advanced (AES), and Qualified (QES) Electronic Signatures. XAdES is a technical format, not a legal tier — but it is the standard XML vehicle for reaching the upper two. A XAdES signature created with a proper certificate and unique signer control can meet AES requirements; one created with a qualified certificate on a qualified signature creation device (QSCD) can meet QES.

The format alone never grants the tier — the certificate, the identity proofing behind it, and the trust service provider's status decide that. Buyers comparing platforms can use our eIDAS e-signature buyer's checklist to see what to ask vendors about signature levels and evidence.

Where XAdES Is Used: Invoices, SOAP, and Government Filings

XAdES shows up wherever structured XML carries legal weight. E-invoicing is the largest use case: many regimes express invoices as XML and require embedded signatures, and XAdES is the natural fit. SOAP-based web services use XML signatures to secure message-level exchanges in B2B and government integrations. Tax, customs, and regulatory portals frequently require XAdES-signed XML filings. Long-term archiving is the fourth scenario: regulated records must remain provable for decades, exactly what XAdES-XL and LTA were designed for.

In all of these workflows, the certificate behind the signature matters as much as the profile. A recognized certificate authority list helps confirm which issuers are trusted, and teams still procuring credentials can follow how to make a digital signature certificate. One caution: a self-signed certificate is rarely secure enough for business contracts, because no trusted third party vouches for the signer's identity.

Nota Sign: Advanced Signatures That Stay Verifiable

Choosing XAdES usually means your documents face legal scrutiny years after signing, so the signature level and the evidence behind it matter more than the file format alone. Nota Sign, FaDaDa's global e-signature platform, lets teams issue signatures across SES, AES, and QES levels with identity checks matched to each tier — so an XAdES-LTA workflow can map to the qualified tier eIDAS expects, backed by certificate handling designed for long-term validation. The platform holds IDC's No. 1 ranking in China's e-signature software market across consecutive annual reports, with signatures legally effective in 100-plus countries and regions. If your XML signing must remain provable for the life of the document, talk to Nota Sign about the signature levels and evidence retention your files need.