QES, digital signature and advanced e-signature: the difference and which one is legally binding

Short answer. Digital signature (the old "electronic digital signature") is a legacy term from previous legislation that still lives on in everyday speech. Today the Law of Ukraine "On Electronic Identification and Electronic Trust Services" uses three concepts: ES (electronic signature — the broadest one), AdES (advanced electronic signature — cryptographic, but without qualified status) and QES (qualified electronic signature). Only a QES carries the legal force of a handwritten signature out of the box; an AdES works by agreement between the parties. Technically, what separates a QES from an AdES is a qualified certificate issued by an accredited provider — and that is exactly what the accredited field in the DSTUcrypt verification result shows.

Glossary: digital signature, ES, AdES, QES

Let's start with the terms, because that is where most of the confusion is born.

• Digital signature ("electronic digital signature") — the term from the previous law. Officially it is no longer in use, but in everyday speech people still say "digital signature" — and almost always mean what the current law calls a QES. If a counterparty writes "sign it with a digital signature", in 99% of cases they mean a QES.
• ES (electronic signature) — the broadest concept: any electronic data attached to a document that makes it possible to identify the signer. Formally, even a typed name under an email or a checkbox in a form fits this definition — there may be no cryptography at all.
• AdES (advanced electronic signature) — now a "real" cryptographic signature: it is created with a private key, uniquely linked to the signer, and reveals any change to the document after signing. But the signer's certificate is not necessarily qualified.
• QES (qualified electronic signature) — the same cryptographic signature, but with two extra conditions: the certificate is qualified, issued by a qualified (accredited) trust service provider, and the key is stored in a secure device. The QES is the gold standard for documents with full legal force.

So the hierarchy is simple: ES ⊃ AdES ⊃ QES. Every QES is an AdES, and every AdES is an ES — but not the other way around.

The legal difference: what is equal to a handwritten signature

The main practical difference lies in the legal consequences.

A QES is equated to a handwritten signature by law. A document signed with a QES has the same legal force as a paper one with a "wet" signature — no additional agreements required. That is why state registries, tax reporting, court and banking systems accept precisely the QES.

An AdES works by agreement between the parties. The law allows using an advanced signature in relationships where the parties have agreed to it: for example, a company and its clients stipulate in a contract or public offer that documents signed with an AdES are recognized by both sides. Within such an agreement the AdES is a perfectly workable tool — but outside of it (say, in dealings with a government body that requires a QES) its force is not guaranteed.

A simple ES is the weakest level: its evidentiary value depends on the circumstances and also rests on agreements, but without cryptography it is far harder to prove the integrity of the document and the identity of the signer.

The technical difference: certificate, provider, secure device

Cryptographically, an AdES and a QES can be built identically: in Ukrainian practice it is an elliptic-curve signature under DSTU 4145-2002 paired with a hash function — DSTU GOST 34.311-95 or the modern Kupyna (DSTU 7564:2014). The signature file itself (CAdES, PAdES, XAdES or ASiC) looks the same. The difference is in the trust attributes around the key:

• Who issued the certificate. For a QES the certificate must be qualified — issued by an accredited trust service provider whose chain traces back to the official root of the central CA (CZO). A certificate from a home-grown or non-accredited authority gives you an AdES at best.
• Where the key lives. For a QES the private key must be stored in a device that meets the requirements for qualified signature creation devices.
• What the certificate states. A qualified certificate contains mandatory markers and the signer's details — full name, RNOKPP or EDRPOU — which is precisely what makes it possible to identify the person unambiguously in legal terms.

The takeaway for a developer: "valid signature" and "QES" are not synonyms. A signature can be cryptographically flawless (the math checks out, the document has not changed), but if the certificate is not from an accredited provider, it is an AdES — and it must not be accepted as a QES.

How to tell a QES from an AdES programmatically: the accredited field

This is exactly why the DSTUcrypt verification results include a dedicated accredited field. The verify widget performs full validation — cryptography, certificate chain, OCSP/CRL, timestamps — and for each signer returns, among other things, the valid verdict and the provider's accreditation status:

signature verification: is it valid? and is it actually a QES?

import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';

const verifier = await embed('verify', { mount: 'modal' });
const report = await verifier.verify(signatureBytes, null); // null — the signature is attached

for (const s of report.signers) {
  console.log(s.signerName, s.signerCode); // full name and RNOKPP/EDRPOU from the certificate
  if (!s.valid) continue;                  // signature invalid — nothing more to discuss
  if (s.accredited === true)  { /* QES: the provider is accredited */ }
  if (s.accredited === false) { /* valid signature, but NOT a QES (AdES) */ }
  if (s.accredited === null)  { /* accreditation not checked */ }
}

Let's break down the key fields of each element in signers:

• valid — whether the signature is cryptographically valid: the signature math checks out and the document has not been modified since signing.
• accredited — whether the signer's certificate was issued by an accredited provider: true — it is a QES; false — the signature is valid but not a QES; null — trust data is unavailable, accreditation was not checked.
• signerName and signerCode — the full name (or organization name) and RNOKPP/EDRPOU from the certificate: exactly what you need to match the signer to your user or counterparty.

The same accredited field is also returned by the sign() method — right after the signature is applied — and by the server-side POST /api/verify endpoint, which returns accredited and qualified for each signer. Important: if your backend makes decisions based on the check (accept a document, credit a payment), trust only the server-side verification — the browser verdict is under the user's control.

Why this is convenient specifically in DSTUcrypt. All cryptography runs in the user's browser: the key and password never leave it under any circumstances. The core is a proven C/C++ library compiled to WebAssembly, supporting 16 signature formats (CAdES, PAdES, XAdES, ASiC-S/E at all levels) and the full stack of national standards: Kupyna, Kalyna, DSTU 4145. And the provider's accreditation status is just a field in the result — no separate registry lookups needed.

Comparison table: ES, AdES, QES

What a business should choose for which documents

The practical rule: the higher the legal risks of a document, the higher the signature level.

• QES — for everything that must unquestionably hold up: contracts with counterparties, HR documents, acts and invoices, reporting, any interaction with government systems. It is the safest default choice: you never have to prove there was an agreement on electronic form.
• AdES — for closed ecosystems where you control both sides and have fixed the rules in a contract or offer: internal document workflow, approvals in corporate systems, some B2C scenarios. Cheaper and more flexible, but outside your ecosystem the signature's force is not guaranteed.
• Simple ES — only for low-risk confirmations (consents, acknowledgements) where weak evidentiary value is enough for you.

If your website accepts signed documents from external users, the simplest workable policy is this: verify every signature and accept only those where valid === true and accredited === true. How to build such verification end to end — from cryptography to OCSP and timestamps — is covered in detail in our article on verifying electronic signatures on a website.

Frequently asked questions

Is it still OK to say "digital signature", or is that a mistake?

"Digital signature" ("electronic digital signature") is a term from the previous legislation that is officially no longer in use. The current Law of Ukraine "On Electronic Identification and Electronic Trust Services" operates with the concepts of "electronic signature", "advanced electronic signature" (AdES) and "qualified electronic signature" (QES). In everyday speech people still say "digital signature" and most often mean a QES, but in contracts and regulations it is better to use the modern terms.

Does an AdES have legal force?

Yes, but not automatically. An AdES applies by agreement between the parties: if you have agreed in writing to electronic interaction with an advanced signature, such documents have force in your relationship. In contrast, a QES is equated to a handwritten signature by the law itself and works without any separate agreements — including in dealings with the state.

How do I programmatically check that a signature is a QES?

By the accredited field in the DSTUcrypt verification result: true — the signer's certificate was issued by an accredited provider, so it is a QES; false — the signature is cryptographically valid but not a QES; null — accreditation was not checked. The field is present both in the sign() result and for each signer in verify(). When the decision is made by the backend, use the authoritative server-side POST /api/verify, which returns the same accredited and qualified.

Can a QES be applied with a file-based key right in the browser?

Yes. Qualified providers also issue file-based keys, and DSTUcrypt opens PKCS#12/PFX, JKS, PKCS#8 and Key-6.dat containers directly in the browser (WebAssembly): the key and password never reach the host website or the service's servers. Hardware tokens are not supported.

Read next

• Verifying an electronic signature on a website: cryptography, certificate chain, OCSP and timestamps
• Signing in to a website with a QES: user authentication via electronic signature
• Electronic signature formats: CAdES, PAdES, XAdES, ASiC — which one to choose

QES on your website — in 10 minutes

Ready-made DSTU signing, verification and encryption widgets. The key and password never leave the user's browser. Every new domain gets 7 days free.

Live demoHow to integrate