How to choose a QES solution for your website: a business checklist

Short answer. You choose a QES solution not by brand or by the length of the price list, but by architecture. The key criteria: the user's private key must be processed only in their browser (in an isolated iframe — not on a server and not in your page's code); the cryptography must cover the full stack of national DSTU standards and all the signature formats you need, including long-term ones; verification must be complete (chain, OCSP, TSP) and able to tell a qualified electronic signature (QES) from a merely valid one; and the delivery model must be transparent: a production-grade core, a subscription with a known price, integration in minutes, and an exit that does not require "uprooting" someone else's files from your infrastructure. Below is a seven-question checklist that covers all of it.

Why choosing a QES solution is a critical decision

A qualified electronic signature is not "just another button" in your product. A QES key legally represents a person: a document signed with it carries the force of a handwritten signature. That means an architectural mistake in key handling is not technical debt to fix in the next sprint, but a direct legal and reputational risk. If your clients' keys pass through your server and that server is compromised, an attacker will be able to sign documents on behalf of your users — and you will be the one explaining it.

The second reason: QES is adopted for the long haul. The signature formats you start creating today will be verified years from now; national hashing standards get updated; a vendor who does not maintain the cryptography eventually becomes a source of problems. So the questions should be asked before rollout — here is the checklist itself.

The checklist: seven questions for a vendor

1. Where is the private key processed?

The most important question. There are three options. On a server — the worst: all keys pass through a single point whose compromise means compromising every user at once. In your page's code — better, but any XSS on the site (including through third-party analytics or chat scripts) can reach the key. In an isolated iframe on a separate origin — the architecturally strongest option: the key and password are entered inside the iframe, and the browser's Same-Origin Policy guarantees that neither your code nor XSS on your site can physically access them. We covered this in detail in "Why the private key must never leave the browser".

2. Which standards are supported?

The Ukrainian QES is a DSTU 4145 signature on elliptic curves. But it never works alone: it is paired with a hash function and, when needed, encryption. Check that the solution supports both the current hash DSTU GOST 34.311-95 (it is what government validators accept today) and the modern Kupyna (DSTU 7564:2014) — otherwise, when government systems move to the new standard, you will have to change vendors. For data encryption the standard is Kalyna (DSTU 7624:2014). A solution covering the whole stack is ready for today's requirements and tomorrow's.

3. Which signature formats and levels are available?

Different documents call for different containers: CAdES for arbitrary files, PAdES for signatures inside a PDF, XAdES for XML, ASiC for multi-file containers. The levels matter just as much: a basic signature (BES) eventually becomes unverifiable — the certificate expires, status services get switched off. Contracts and archives need the long-term levels CAdES-XL and PAdES-LTA, where timestamps and certificate-status data are embedded in the container itself. Why this is critical — in the article on long-term signatures.

4. Is verification complete — and does it show it's genuinely a QES?

"The signature is mathematically correct" is only a third of the verification. Full validation includes the certificate chain up to a trusted root, the certificate's current status via OCSP/CRL, and TSP timestamp checks. And separately: a valid signature is not yet a QES. What makes it qualified is a certificate from an accredited CA, so the solution must return this flag explicitly (in DSTUcrypt — the accredited field in the signing and verification result, plus authoritative server-side verification for the decisions your backend makes).

5. Who maintains the cryptography?

Cryptographic code is no place for experiments: pure-JS implementations of DSTU have known vulnerabilities such as timing attacks and key recovery from signatures. Ask which core the solution runs on and who keeps it updated. DSTUcrypt runs on a battle-tested native C/C++ library that has served Ukrainian PKI for years, compiled to WebAssembly. It is a production solution with predictable updates, not a community experiment that may end up unmaintained.

6. What is the cost of ownership?

Compare the total cost, not the license price: building in-house means staff cryptographers, keeping up with standard updates, certification questions, and liability for incidents. A service model shifts all of that to the vendor for a fixed fee. As a reference — DSTUcrypt's transparent model: UAH 4,500/month or UAH 38,880/year per domain, optionally "Custom design" (+UAH 1,200/month), "Multiple signers" (+UAH 700/month), and "Encryption" (+UAH 900/month), with 7 days of free testing on every new domain. That is less than one hour of a crypto consultant's work per month.

7. How fast is the rollout — and how fast is the exit?

A good solution is easy both to connect and to switch off. If rollout requires installing packages, hosting crypto files yourself, and building WASM, you get not only weeks of integration but also vendor lock-in: someone else's artifacts take root in your infrastructure. In the iframe model, integration is a single SDK import, and the exit is deleting a few lines of code; the signed documents remain standard containers, verifiable by any compatible tool.

Summary table: question → what to look at

How complex the integration really is

The "fast rollout" criterion is easy to test in practice: ask the vendor for a minimal working example. Here is the complete signing integration with DSTUcrypt — no package installation and not a single file on your server:

complete signing integration — one import

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

const signer = await embed('sign', { mount: 'modal' });
const { signature, accredited } = await signer.sign(fileBytes, {
  format: 'CAdES-T', // format and level — a single option
});
signature.download('document.p7s');

A step-by-step walkthrough of this example is in "How to add QES to your website in 10 minutes".

Why DSTUcrypt passes this checklist in full. The key and password are processed only in the user's browser, in an isolated iframe; the cryptography is performed by a production crypto core on WebAssembly with the full stack of national standards — DSTU 4145, both hashes (GOST 34.311 and Kupyna), Kalyna; 16 signature formats up to CAdES-XL and PAdES-B-LTA; full verification with the accredited flag; a transparent subscription with no hidden costs and not a single file in your infrastructure.

Conclusion

Adopting an electronic signature for business is above all a choice of architecture, and the seven questions above let you assess it in a single meeting with a vendor. In short: the key — only in the user's browser; the standards — the full DSTU stack; the formats — including long-term levels; the verification — complete and with a QES flag; the core — production-grade; the price — transparent; the exit — painless. A solution that answers all seven will not need replacing after a security audit or after a national standards update.

Frequently asked questions

Do we need our own cryptographers to add an electronic signature to the website?

No. In the service model the vendor maintains the cryptography: DSTUcrypt runs on a production-grade core, and algorithm and format updates happen automatically on the service side. Your team only needs a frontend developer to do one SDK import and call a few methods.

How much does a QES solution from DSTUcrypt cost?

The base subscription is UAH 4,500/month or UAH 38,880/year per domain. Optional add-ons: "Custom design" (+UAH 1,200/month or +UAH 10,368/year), "Multiple signers" (+UAH 700/month or +UAH 6,048/year), "Encryption and decryption" (+UAH 900/month or +UAH 7,776/year). Every new domain automatically gets 7 days free.

Why is processing the private key on a server a risk?

A QES key legally represents the signer, so any copy of it outside the owner's control is an opportunity to sign documents on their behalf. If user keys pass through a server, compromising that server means compromising all keys at once. The safer architecture is one where the key is processed only in the user's browser, in an isolated iframe on a separate origin.

How quickly can QES go live — and how easy is it to leave the service later?

Integration is one SDK import and a few lines of code: a typical setup takes minutes, with no package installation and no files hosted on your side. Leaving is just as simple: there are no service files in your infrastructure, and the signed documents are standard CAdES/PAdES/XAdES/ASiC containers verifiable by any compatible tool.

Read also

• Why the private key must never leave the browser
• How to add QES to your website in 10 minutes
• Long-term electronic signatures: CAdES-XL and PAdES-LTA

A QES solution that passes the whole checklist — in 10 minutes

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

Live demoHow to connect