Signature levels: SES, AES and QES

The short version

The SDK defaults to SES, Acrobat Sign's normal e-signature. You can raise the level for a whole project, for one agreement, or for one signer. AES and QES are the same API request; what makes a signature qualified is the trust service provider that issues the signer's certificate, which is configured on your Acrobat Sign account, not in code.

What eIDAS says

eIDAS is the European Union's regulation on electronic identification and trust services, Regulation (EU) No 910/2014. It has applied across the EU since 2016 and was amended by Regulation (EU) 2024/1183, often called "eIDAS 2". Because it is a regulation rather than a directive, the rules are the same in every member state, and the EEA countries follow it too. It defines three levels of electronic signature, each building on the one below.

Simple electronic signature (SES)

The regulation's baseline definition is broad: data in electronic form that is attached to, or logically associated with, other electronic data and that the signatory uses to sign. A typed name, a drawn squiggle, a scanned image or a click on "I agree" can all qualify.

The important legal point is the non-discrimination rule: a court may not refuse an electronic signature as evidence, or deny it legal effect, just because it is electronic or because it isn't qualified. An SES is valid. What it lacks is a built-in presumption: if the signer later says "that wasn't me", the party relying on the signature has to prove otherwise, using evidence such as Acrobat Sign's audit report (email address, IP address, timestamps, identity checks).

Advanced electronic signature (AES)

An advanced signature is an electronic signature that meets four requirements:

1. Uniquely linked to the signatory

   The signature belongs to one person and no one else.

2. Capable of identifying the signatory

   From the signature you can tell who signed, typically because the certificate names them.

3. Created under the signatory's sole control

   The signing key is something only the signer can use, with a high level of confidence; for cloud signatures that means the provider authenticates the signer before each use.

4. Linked to the signed data so that changes are detectable

   Alter a single byte of the document afterwards and the signature no longer validates.

In practice these requirements point towards public-key cryptography: a certificate issued to the signer, and a signature computed over a hash of the document. That is exactly what Acrobat Sign produces when you ask for a digital signature.

Qualified electronic signature (QES)

A qualified signature is an advanced signature with two extra ingredients: it is based on a qualified certificate for electronic signatures, and it is created by a qualified signature creation device (QSCD). Qualified certificates may only be issued by a qualified trust service provider (QTSP): a provider that has been audited against the regulation's requirements, granted qualified status by a national supervisory body and listed on that country's trusted list. Before issuing a qualified certificate, the QTSP must verify the person's identity to a high standard (in person, by video identification, with a national eID, and so on).

The QSCD used to be a smart card or USB token. Today it is usually a certified hardware security module run by the QTSP, which holds the signer's key and lets them use it remotely after strong authentication. This "remote QSCD" model is what makes QES possible from a browser, and it is how cloud providers integrated with Acrobat Sign work.

The legal effect is the strongest the regulation offers: a QES has the equivalent legal effect of a handwritten signature, and a QES based on a qualified certificate issued in one member state must be recognised as a QES in all the others.

Trusted lists

Each member state publishes a trusted list of its QTSPs and their qualified services, and the European Commission publishes the list of those lists. Validation software uses them to decide whether a certificate was qualified at the moment of signing. You can browse them through the Commission's trusted list browser. When this page says a provider is "qualified", it means the provider and the specific service used appear on a trusted list.

What changed with Regulation (EU) 2024/1183

The 2024 amendment keeps the three signature levels as they were. Its headline change is the European Digital Identity Wallet: member states must offer citizens a wallet that holds identity data and attestations, and the wallets are expected to let people create qualified electronic signatures. It also adds new trust services such as electronic attestations of attributes and electronic ledgers. For an integration built on Acrobat Sign, the practical effect so far is that more people may already hold a qualified signing means, and more providers may appear as options. The way you request levels through the API is unchanged.

Beyond the EU

SES, AES and QES are eIDAS terms. Almost every country now gives electronic signatures legal effect, but they organise them differently, and only some use three tiers. Broadly, national laws follow one of three models:

• Tiered, like eIDAS: simple, advanced and qualified (or similarly named) signatures, with stronger legal presumptions at each step.
• Certificate-based: any electronic signature can be valid, but signatures made with certificates from licensed or accredited providers get special standing.
• Technology-neutral: the law does not rank signing technologies. What matters is the intention to sign, consent to deal electronically, and evidence of who signed.

The sketches below show where a range of jurisdictions sit. They are deliberately short, describe only the general position, and change over time. Use them to frame questions for local counsel, not as answers.

United Kingdom

Tiered. After leaving the EU, the UK kept the eIDAS framework in domestic law ("UK eIDAS"), alongside the Electronic Communications Act 2000, so the same three levels exist. English law has long accepted simple electronic signatures for most commercial documents. Qualified status depends on the UK's own trust-service regime, so check that a provider is recognised in the UK as well as in the EU.

Switzerland

Tiered. The Federal Act on Electronic Signatures (ZertES) defines advanced, regulated and qualified electronic signatures, and a Swiss qualified signature generally satisfies the legal requirement of written form. It must come from a provider recognised under Swiss rules, which is a different list from the EU's, so cross-border projects often need a provider that offers both.

Brazil

Tiered and certificate-based. The ICP-Brasil public-key infrastructure, created by Provisional Measure 2.200-2 of 2001, gives signatures made with ICP-Brasil certificates a presumption of authenticity. Law 14.063 of 2020 adds simple, advanced and qualified tiers for dealings with public bodies, where qualified means an ICP-Brasil certificate. Between private parties, other signing methods are valid when the parties accept them.

United Arab Emirates

Tiered. Federal Decree-Law No. 46 of 2021 recognises electronic signatures in tiers that broadly mirror eIDAS, up to qualified signatures from providers licensed under the supervision of the TDRA, and UAE PASS offers a national digital identity with signing. Financial free zones such as the DIFC and ADGM have their own rules.

India

Certificate-based. The Information Technology Act 2000 recognises electronic signatures and gives particular standing to digital signatures backed by certificates from Certifying Authorities licensed by the Controller of Certifying Authorities, including Aadhaar-based eSign. Some instruments, such as wills and certain property documents, are excluded from electronic execution.

Saudi Arabia

Certificate-based. The Electronic Transactions Law recognises electronic signatures and records, and signatures backed by certificates from licensed certification service providers carry stronger evidential weight. Government bodies and regulated sectors often prescribe their own signing platforms, so check what a counterparty expects.

United States

Technology-neutral. The federal ESIGN Act (2000) and the Uniform Electronic Transactions Act, adopted by almost every state, give an electronic signature legal effect when the signer intended to sign and the parties agreed to deal electronically; there are no levels to choose from. Strength comes from the evidence around the signature (audit trail, identity checks). Some documents, such as wills and certain family-law matters and notices, fall outside these laws.

Canada

Technology-neutral, with a federal secure tier. Provincial electronic-commerce laws, largely based on a uniform model act, are technology-neutral. Federally, PIPEDA and its regulations define a certificate-based "secure electronic signature" for particular federal purposes; most commercial agreements use ordinary electronic signatures.

Singapore

Technology-neutral, with a secure tier. The Electronic Transactions Act recognises electronic signatures generally and gives stronger presumptions to "secure" electronic signatures that meet its conditions. Some documents have been excluded from electronic execution; the list has been narrowed over time, so check the current position.

Australia

Technology-neutral. The Commonwealth Electronic Transactions Act 1999 and matching state laws accept any method that identifies the signer, shows their intention and is appropriately reliable. Deeds, witnessed documents and some land dealings follow separate rules that differ between states.

What this means for your integration

• Technology-neutral regimes: SES is normally enough. Strengthen the evidence with an identity check (identity verification) and keep the audit report.
• Tiered or certificate-based regimes, where a document needs the stronger presumption: request AES or QES, with a trust service provider that is licensed or qualified in that jurisdiction configured on your Acrobat Sign account, and check the issuer afterwards with the qualified-issuers list.
• Signers in several countries: set the level per signer (per signer, in either direction), so each person signs at the level their side needs.

Which level do I need?

Start from the highest requirement anyone places on the document, then step down. Most commercial agreements are fine with SES plus a sensible identity check. AES is a business choice for higher assurance. QES is usually driven by a specific legal or contractual requirement.

These are common patterns, not rules. Your counsel decides; the SDK makes any of the three a one-line change.

How Acrobat Sign implements each level

Acrobat Sign has a single switch for this, isDigitalSignatureRequired, set per participant set. The SDK translates levels into that switch:

The API cannot express "qualified": Adobe offers a digital signature and lets the account decide which providers are available. That is why the SDK keeps QES as a separate value at all: it records your intent, so you can check the result against it after signing.

Choosing a level in code

Levels come from Conceptlz\AdobeSign\Enum\SignatureLevel, a backed enum with the cases SES, AES and QES. Two helper methods make comparisons easy: requiresDigitalSignature() is true for AES and QES, and satisfies(SignatureLevel $required) is true when a level is at least as strong as the one required (QES satisfies AES, AES satisfies SES).

A project-wide default

Set ClientOptions::$defaultSignatureLevel once and every agreement built with AgreementInfo uses it unless it says otherwise:

use Conceptlz\AdobeSign\AdobeSign;
use Conceptlz\AdobeSign\ClientOptions;
use Conceptlz\AdobeSign\Enum\SignatureLevel;

$sign = AdobeSign::withIntegrationKey(
    getenv('ADOBE_SIGN_INTEGRATION_KEY'),
    options: new ClientOptions(defaultSignatureLevel: SignatureLevel::AES),
);

The default is SignatureLevel::SES, which sends nothing extra and keeps Acrobat Sign's normal behaviour. The default applies only to agreements built with the AgreementInfo builder: raw arrays and generated AgreementCreationInfo models are sent exactly as you wrote them.

Per agreement

AgreementInfo::signatureLevel() sets the level for every signer in the agreement, overriding the client default:

use Conceptlz\AdobeSign\Builder\AgreementInfo;
use Conceptlz\AdobeSign\Enum\SignatureLevel;

$agreementId = $sign->agreements()->create(
    AgreementInfo::create('Employment contract')
        ->file($documentId)
        ->signers('employee@example.com', 'hr-director@example.com')
        ->signatureLevel(SignatureLevel::QES),
);

Per signer, in either direction

ParticipantSetInfo::signatureLevel() overrides the agreement's level for one participant set. It works both ways: raise one signer above the rest, or let one signer sign more simply than the rest. Here is one agreement where the borrower signs with AES and the witness with SES:

use Conceptlz\AdobeSign\Builder\{AgreementInfo, ParticipantInfo, ParticipantSetInfo};
use Conceptlz\AdobeSign\Enum\SignatureLevel;

$agreementId = $sign->agreements()->create(
    AgreementInfo::create('Loan agreement')
        ->file($documentId)
        // Step 1: the borrower signs with a certificate (AES)
        ->participantSet(
            ParticipantSetInfo::signer(ParticipantInfo::email('borrower@example.com', 'Borrower'))
                ->signatureLevel(SignatureLevel::AES),
        )
        // Step 2: the witness signs normally (SES, the client default)
        ->participantSet(ParticipantSetInfo::signer('witness@example.com')),
);

The builder turns that into a payload where only the first set asks for a digital signature:

"participantSetsInfo": [
  {
    "role": "SIGNER",
    "order": 1,
    "memberInfos": [{ "email": "borrower@example.com", "name": "Borrower" }],
    "isDigitalSignatureRequired": true
  },
  {
    "role": "SIGNER",
    "order": 2,
    "memberInfos": [{ "email": "witness@example.com" }]
  }
]

The opposite direction works the same way: a QES agreement with one internal signer who only needs SES.

AgreementInfo::create('Share purchase agreement')
    ->file($documentId)
    ->signatureLevel(SignatureLevel::QES)                                  // everyone…
    ->participantSet(ParticipantSetInfo::signer('buyer@example.com'))
    ->participantSet(ParticipantSetInfo::signer('seller@example.com'))
    ->participantSet(
        ParticipantSetInfo::signer('company-secretary@example.com')
            ->signatureLevel(SignatureLevel::SES),                          // …except this signer
    );

Which level wins

Only sets with the SIGNER role ever receive a level. Approvers, acceptors, form fillers, certified recipients and delegates don't sign, so the agreement-level and project-level settings skip them. You can read back what you set with AgreementInfo::getSignatureLevel() and ParticipantSetInfo::getSignatureLevel().

Validation before anything is sent

The builders refuse combinations that can't work and throw Conceptlz\AdobeSign\Exception\InvalidArgumentException before any request is made, so a requested level is never dropped without you knowing:

Two details are easy to miss:

• The "no signer" rule applies only to a level set explicitly on the agreement. A project default of AES does not break approval-only agreements; it simply has no one to apply to.
• The WRITTEN rule does include the project default. If your client defaults to AES and you need a written (wet-ink) agreement, set ->signatureLevel(SignatureLevel::SES) on it explicitly.

Adobe can also refuse a digital-signature request for account reasons: the spec lists DIGITAL_SIGNATURE_ENFORCEMENT_PER_PARTICIPANT_NOT_ALLOWED and ..._DISABLED as possible 403 answers to POST /agreements. These arrive as an ApiException with that $errorCode, and are fixed in Acrobat Sign admin, not in code. See Errors & exceptions.

What the signer experiences

For an SES, nothing changes: the signer opens the email, clicks through to the document and types or draws a signature. For AES and QES, the signing step looks different:

1. The usual email

   The invitation looks the same as for any agreement. If you added an identity check, that happens first.

2. A provider dropdown

   When the signer clicks the signature field, Acrobat Sign asks them to sign with a digital ID and shows a dropdown of the cloud signature providers (trust service providers) that your account has enabled for their region.

3. Authenticate with the provider

   The signer is sent to the chosen provider and logs in with whatever that provider requires, for example a username, a PIN and a one-time code. Someone without an identity at that provider has to enrol first, which can include the provider's own identity proofing.

4. Sign with a cloud certificate

   The provider uses the certificate it holds for the signer to sign the document hash, and hands the signature back to Acrobat Sign. The signer never installs anything.

5. Back in Acrobat Sign

   Adobe embeds the signature in the PDF, logs a DIGSIGNED event and moves the agreement to the next step in the signing order.

What a real AES looked like

When the SDK was tested against a real account, the signer picked Intesi Group Cloud Signature from the dropdown and signed with a test certificate issued by Intesi Group Advanced Cloud Signature CA Test. That is an advanced certificate, not a qualified one, so the result was an AES and not a QES. Adobe recorded the signature like this (trimmed):

{
  "type": "DIGSIGNED",
  "participantRole": "SIGNER",
  "signatureInputType": "TYPED",
  "digitalSignatureInfo": {
    "certificateIssuer": "Intesi Group Advanced Cloud Signature CA Test",
    "providerName": "Intesi Group Cloud Signature",
    "providerUrl": "https://services.time4mind.com/csc/v1/",
    "providerIp": "194.15.44.117"
  }
}

Two things in that payload are worth knowing:

• Adobe's spec names the provider fields cloudProviderName, cloudProviderUrl and cloudProviderIp; the live API sent providerName, providerUrl and providerIp. signatureEvidence() reads both spellings. The generated DigitalSignatureInfo model only has the spec's names, so if you read events yourself, look in the raw array too.
• signatureInputType was TYPED even though the signature was digital: it describes how the visible signature appearance was made, not the cryptography. Use the event type and digitalSignatureInfo to tell digital signatures apart.

Why QES depends on the provider

Everything that makes a signature qualified lives at the provider: the qualified certificate, the identity proofing done before issuing it, and the certified device (the QSCD) that holds the key. Acrobat Sign orchestrates the signing, but the provider performs it. So the same API request yields an AES with one provider and a QES with another. Even one provider can offer both an advanced and a qualified service, as the test above shows.

Setting an account up for QES

1. Check the plan

   Digital signatures with cloud providers need an Acrobat Sign plan that includes them. Ask your Adobe representative; QTSPs also charge for their certificates and signatures.

2. Enable digital signatures and add a qualified provider

   In Acrobat Sign admin, enable digital signatures and add a qualified trust service provider as a cloud signature provider. Restrict the list for the regions or groups that need QES, so signers can't pick a non-qualified option by mistake.

3. Make sure signers can get a qualified certificate

   Each signer needs an identity with that provider. Tell them in the agreement message, because enrolment can take a few minutes the first time.

4. Request QES in code and record the accepted issuers

   Use SignatureLevel::QES, and keep the certificate issuers your compliance team accepts as qualified in configuration, for the check after signing.

The EU trusted lists show which providers and services are qualified. Several QTSPs advertise integrations with Acrobat Sign; confirm with the provider which of its services is qualified, and under which jurisdiction.

The qualified-issuers list

The SDK can see the certificate issuer of each digital signature, but it cannot know by itself whether that issuer is qualified. You tell it, with a list of issuer names you accept. Matching is case-insensitive and by substring, so 'TrustPro QTSP' matches an issuer called "TrustPro QTSP Qualified CA 1".

// Keep this in configuration so compliance can change it without a deploy.
$qualifiedIssuers = array_values(array_filter(array_map(
    'trim',
    explode(',', getenv('QUALIFIED_ISSUERS') ?: ''),
)));

The bundled examples/live-lifecycle.php reads the same QUALIFIED_ISSUERS variable, and the Laravel bridge reads it from its qualified_issuers config key. Keep the names specific: a bare company name can match that company's advanced (non-qualified) CA too.

Checking what was achieved

Requesting a level is half the job. After signing, ask the SDK what each signer actually did:

agreements()->signatureEvidence(string $agreementId): SignatureEvidenceGET /agreements/{agreementId} + /members + /events

use Conceptlz\AdobeSign\Enum\SignatureLevel;

$evidence = $sign->agreements()->signatureEvidence($agreementId);

if (!$evidence->allSigned()) {
    return; // try again after AGREEMENT_WORKFLOW_COMPLETED
}

if ($evidence->meets(SignatureLevel::QES, $qualifiedIssuers)) {
    $contract->markQualified();
} else {
    foreach ($evidence->shortfalls(SignatureLevel::QES, $qualifiedIssuers) as $problem) {
        $log->warning($problem);
        // "cfo@example.com signed digitally, but the certificate issuer "Intesi Group Advanced
        //  Cloud Signature CA Test" is not in your list of qualified issuers: AES, QES required."
    }
}

SignatureEvidence

meets() and shortfalls() throw InvalidArgumentException when you check for QES with an empty issuer list, because without it no signature could ever be counted as qualified.

SignerEvidence

Checking a mixed agreement

meets() holds every signer to one level. In the loan example above the witness signed with SES on purpose, so $evidence->meets(SignatureLevel::AES) is false even though everything went to plan. For agreements that mix levels, check each signer against what you asked of them:

use Conceptlz\AdobeSign\Enum\SignatureLevel;

// What you requested, stored when you created the agreement.
$required = [
    'borrower@example.com' => SignatureLevel::AES,
    'witness@example.com'  => SignatureLevel::SES,
];

$evidence = $sign->agreements()->signatureEvidence($agreementId);
$problems = [];

foreach ($evidence->signers as $signer) {
    $needed = $required[strtolower($signer->email)]
        // Fallback: Adobe remembers whether a digital signature was required,
        // but not whether you meant AES or QES.
        ?? ($signer->digitalSignatureRequired ? SignatureLevel::AES : SignatureLevel::SES);

    $achieved = $signer->achievedLevel($qualifiedIssuers);

    if ($achieved === null) {
        $problems[] = "{$signer->email} has not signed yet.";
    } elseif (!$achieved->satisfies($needed)) {
        $problems[] = sprintf('%s reached %s, %s required.', $signer->email, $achieved->value, $needed->value);
    }
}

How the SDK infers the level, and its limits

• SES: a signing event without digital signature data.
• AES: a DIGSIGNED event, or a signing event with digitalSignatureInfo.
• QES: an AES whose certificateIssuer matches your list.

Signers are matched by email. If a signer delegated to someone else, the delegate's signature is matched only when Adobe reports it under the original signer's email. Identity checks are reported in $verification but never change the inferred level.

Formal validation of the PDF

signatureEvidence() reads Adobe's records, which is the right tool for workflow decisions ("can we release the goods?"). For an authoritative statement, for example in a dispute, validate the signatures inside the signed PDF itself against the trusted lists, using validation software such as the EU's DSS demonstration service or Acrobat's signature panel. What is inside the signed PDF explains which signatures you will find there.

Identity checks are a separate dimension

Email OTP, SMS codes, knowledge-based questions, government ID scans and national eIDs control who can open the agreement. They make an SES much more convincing as evidence, and they are worth adding at any level, but they don't turn an SES into an AES. Only a certificate-based digital signature does that. Combine the two dimensions freely:

use Conceptlz\AdobeSign\Builder\{ParticipantInfo, ParticipantSetInfo, Verification};
use Conceptlz\AdobeSign\Enum\SignatureLevel;

ParticipantSetInfo::signer(
    ParticipantInfo::email('buyer@example.com')->verifyWith(Verification::emailOtp()),  // who may open it
)->signatureLevel(SignatureLevel::AES);                                                 // how they sign

The methods and their trade-offs are covered in Identity verification.

Common questions

Where next

• Identity verificationEmail OTP, SMS, government ID and national eIDs, and what each costs.
• Downloading signed filesGet the signed PDF and see the certificates inside it.
• WebhooksRun the evidence check as soon as the last person signs.
• Creating agreementsEverything else the AgreementInfo builder can do.