AATL vs Qualified Electronic Signature: What Your Certificate Actually Buys

What are the two questions people mix up?

The first question is technical: will the recipient's software validate this signature without being configured? That is what trust-list membership answers. The second is legal: what does this signature count as under eIDAS? That is set by the class of certificate and where its private key lives. A certificate can score perfectly on the first and only mid-range on the second, and the one most organisations buy does exactly that.

The confusion is understandable, because both questions get answered by the same green tick in a PDF reader. Acrobat's validity indicator is reporting two facts: the signing certificate chains to a root Acrobat trusts, and the document has not been modified since it was signed. Neither fact says anything about eIDAS. A signature can be valid, trusted and intact while sitting at the advanced level, and it can be qualified while showing a warning in a reader that cannot resolve the trust.

Keeping the questions apart also fixes the pricing confusion. Moving right on the horizontal axis is a purchase: buy from a CA that is on the trust lists. Moving up the vertical axis is not a purchase upgrade so much as a different process, because qualified status requires a vetted issuer, a vetted device and an identity check on the person signing.

What does Adobe AATL actually get you?

AATL gets you automatic trust in Acrobat and Acrobat Reader. Adobe distributes the root certificates of member authorities to its readers, so a signature made with a certificate from an AATL member validates on open with no configuration by the recipient. That is the whole of what membership guarantees. It is a statement about distribution and about the member's audited practices, not a statement about European law.

Getting onto the list is not trivial, which is why AATL carries real weight. Adobe's technical requirements oblige members to keep subscriber private keys in a medium that prevents export and duplication, backed by certified hardware — FIPS 140-2 Level 2 or a Common Criteria evaluated device are the benchmarks cited, with higher levels used in practice for CA keys — and to run strong identity and authorisation procedures they can document to Adobe. Minimum key sizes are RSA 2048 or ECC P-256.

The key-protection rule is why cloud document signing exists without being a shortcut. The requirement is that the key sits in hardware that will not surrender it, not that the hardware sits on your desk. A CA-operated HSM satisfies it as well as a USB token does, which is the mechanism behind every "no physical device" document signing product, including the cloud-based document signing certificates we issue through Certum.

What AATL does not do is tell a lawyer anything. There is no eIDAS level implied by membership, and the list contains both qualified and non-qualified authorities. Reading a green check mark as legal equivalence is the single most common mistake in this area, and it is the one that only surfaces when somebody disputes a document.

What are the three eIDAS signature levels?

eIDAS defines three: simple, advanced and qualified. A simple electronic signature is any data in electronic form used to sign — a typed name will do. An advanced signature must pass the four tests in Article 26. A qualified signature is an advanced one plus a qualified certificate and a qualified signature creation device, and only it carries the handwritten-signature equivalence in Article 25(2). Each level contains the one below it.

The legal framework is Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183, which is the text people call eIDAS 2.0. Article 25(1) does the quiet heavy lifting: a signature cannot be denied legal effect or admissibility as evidence just for being electronic, or for failing to meet the qualified requirements. That is the sentence worth remembering when someone claims an advanced signature is "not legally valid". It is admissible. What it lacks is the automatic equivalence, and the reversal of the argument that comes with it.

Article 26's four tests are where certificates do their work. A certificate binds a verified identity to a key pair, which handles "uniquely linked" and "capable of identifying". Hardware key storage handles "sole control". The signature's own cryptography handles tamper detection. This is why a PKI-based signature reaches the advanced level almost by construction, while a drawn squiggle in a web form has to be argued for.

The jump to qualified adds no cryptography at all. It adds supervision: the issuer must hold qualified status granted by a Member State supervisory body, the certificate must meet Annex I, and the device holding the key must meet Annex II. Qualified status is a statement about process and oversight, and that is the reason it cannot be bought as an add-on to a certificate you already hold.

Is a document signing certificate a qualified signature?

Not unless it is sold as a qualified certificate. A commercial document signing certificate from an AATL member produces an advanced electronic signature: identity-validated, hardware-held, tamper-evident, trusted in Acrobat. It becomes qualified only when the issuer holds qualified trust service provider status for that service and the key is on a qualified signature creation device. Those are catalogue entries, not configuration options.

Certum, whose certificates we resell, is a useful illustration because it appears in both places. Its Document Signing Certificate is an AATL product aimed at PDFs and Office documents. Its qualified electronic signature services are listed separately, under qualified services, because they are a different class of certificate issued under its qualified trust service provider status. Most CAs that do both split their catalogue the same way, and the split is the fastest way to tell what you are looking at: if a product page talks about AATL and Acrobat trust, it is the advanced product; if it talks about trusted lists, supervisory bodies and identity verification sessions, it is the qualified one.

One row deserves emphasis, because it is where the two axes finally touch. Both certificates are trusted in Acrobat, and they get there by different routes: one through AATL, the other through the European Union Trusted Lists. The route is recorded, and that is what makes the level checkable from inside a PDF.

What is the EUTL, and how does Acrobat use it?

The European Union Trusted Lists are the public registry of trust service providers granted qualified status by a Member State supervisory body under eIDAS. Acrobat and Acrobat Reader ship with support for them, built as an extension of the same framework that maintains AATL roots. A signature made under a certificate published through the EUTL validates in Acrobat without special software, and the reader records that the trust came from the EU lists rather than from AATL.

That recorded distinction is more useful than it first appears. Open the signature properties of a signed PDF and the trust source is named. Wording that points at the European Union Trusted Lists means a qualified trust service provider stands behind the certificate, which is the single fastest practical indicator that you are looking at something more than an advanced signature. It is not a formal determination of qualified status — a provider can be on the EUTL for one service and not another, so a complete answer still needs the certificate itself — but as a first check it takes about five seconds.

The lists are also how cross-border recognition works in practice. Article 25(3) makes a qualified signature based on a qualified certificate issued in one Member State qualified in all of them, and the trusted lists are the machine-readable plumbing that lets a verifier in Lisbon resolve a provider supervised in Warsaw. Certum, as a Polish qualified trust service provider, is on the list for exactly that reason.

How do I check whether a certificate is qualified?

Look inside the certificate for the qualified certificate statements extension, OID 1.3.6.1.5.5.7.1.3, and specifically for the ETSI QcCompliance statement, 0.4.0.1862.1.1. That statement is the issuer declaring the certificate qualified under Regulation (EU) No 910/2014. If it is absent, the certificate is not qualified, and no amount of trust-list membership changes that.

The extension comes from the qualified certificates profile in RFC 3739; the statements inside it are defined by ETSI EN 319 412-5. Three are worth knowing. QcCompliance (0.4.0.1862.1.1) is the qualified declaration itself. QcSSCD (0.4.0.1862.1.4) says the private key lives on a qualified signature creation device, which is the other half of the qualified-signature requirement. QcType (0.4.0.1862.1.6) says what the certificate is for, with 0.4.0.1862.1.6.1 meaning electronic signatures, as opposed to electronic seals or website authentication.

OpenSSL will show you the extension is present, but not what it says. There is no built-in profile for it, so the contents print as a hex dump rather than as names:

# Does the certificate carry qualified statements at all?
openssl x509 -in signing-cert.pem -noout -text | grep -A6 "1.3.6.1.5.5.7.1.3"

# The ETSI OIDs are inside that dump; OpenSSL does not decode them.
# For a readable answer, use one of the checks below instead.

So in practice, run three checks in this order. Open the signed PDF in Acrobat and read the trust source in signature properties — thirty seconds, and it usually settles the question. Then look the provider up in the European Commission's Trusted List Browser and confirm it holds qualified status for the service you care about, since a provider qualified for timestamping is not automatically qualified for signature certificates. Only then go to the certificate bytes, which is where you confirm QcCompliance and QcSSCD rather than taking a product page's word for it.

Worth keeping in mind: the statements are the issuer's own assertion. They are checkable against the trusted list, and an issuer that misstates them is risking its qualified status, which is a strong deterrent. But the authoritative source for "is this provider qualified" is the list, not the certificate. The certificate tells you what the issuer intended this particular certificate to be.

Which level do you actually need?

Work backwards from whoever can refuse the document. If you and the counterparty decide between yourselves, an advanced signature is normally sufficient and that covers most commercial contracts, invoices, reports and internal approvals. If a statute, court, registry or regulator requires written form or names a qualified signature, nothing below qualified will do. The expensive mistake is choosing on how much assurance sounds comforting.

The middle branch is where real money gets wasted. Enterprise procurement portals and tender systems often specify a signature level in a document nobody reads until the submission is rejected, and a signature level cannot be upgraded after the fact — you re-sign with a different certificate, which means re-collecting approvals from everyone who already signed. Ask for the required level in writing before the first signature, not after.

There is also a reason not to default to qualified when nothing demands it. Qualified certificates require identity verification of each individual signer, which for a team means a verification session per person, repeated at renewal. For a finance department sending out three hundred signed invoices a month, an organisation-level document signing certificate signs in the company's name and avoids that entirely. The choice is partly legal and partly about who is actually doing the signing.

A practical rule that has held up well: pick the lowest level that survives a dispute you can actually picture. If you cannot describe the scenario in which the signature gets challenged and an advanced signature loses, you are buying insurance against nothing.

Do timestamps change any of this?

Timestamps do not change the eIDAS level, but they decide whether the signature still verifies in five years. A signature with no timestamp becomes unverifiable once the signing certificate expires, because a verifier cannot tell whether the signature was made while the certificate was valid. Long-term validation, the LTV mechanism in PAdES, embeds a trusted timestamp plus the revocation data needed to check the chain as it stood at signing time.

This matters more for document signing than for anything else a CA sells, because documents outlive certificates by design. A supply contract signed today may be litigated in 2034, long after the certificate that signed it expired and possibly after the issuing CA has retired the intermediate. Without a timestamp, the reader has a signature it cannot date. With one, the signature carries its own evidence.

The practical advice is short: timestamp every signature, and if you are pursuing a qualified signature, use a qualified timestamp, since eIDAS defines qualified electronic timestamps as their own trust service with their own presumption of accuracy. Mixing a qualified signature with an unqualified timestamp is a common and avoidable gap. The same reasoning drives timestamping in code signing, where a signed binary has to keep validating after the certificate behind it expires.

What changed under eIDAS 2.0?

Regulation (EU) 2024/1183 entered into force on 20 May 2024 and added three new qualified trust services, one of which matters directly here: the management of remote electronic signature and seal creation devices. Remote qualified signing — the key held in a provider-operated HSM instead of on a card in your hand — is now a supervised qualified service in its own right, not an arrangement left to each provider.

The alignment date has passed. Implementing regulations setting the reference standards for managing remote qualified devices were published on 30 July 2025, and 21 May 2026 was the date by which providers had to bring their remote device management into line with them. As of 1 October 2026, that means a concrete check you can run: if you sign with a cloud-based qualified signature, the provider's qualified status for remote device management should be visible on the trusted list, alongside its status for issuing the certificates.

The other change worth tracking is the European Digital Identity Wallet, which is designed to let citizens create a qualified electronic signature from a phone. If that lands as intended, the practical barrier to the qualified level stops being the card reader and becomes the identity-verification step, and the calculation in the section above shifts. It has not shifted yet, and buying decisions made now should be based on what providers are supervised for today rather than on wallet timelines.