Why there are two models
During the eIDAS 2 negotiations, browsers, Mozilla and Google in particular, objected that being forced to accept as TLS certificates those issued by any qualified provider would take away their control over who can guarantee the security of connections. A provider with qualified status but weak practices could issue certificates for other people’s domains and enable traffic interception.
The final text answered with recital 65 of Regulation 2024/1183: the obligation to recognise QWACs does not affect browsers’ freedom to ensure web security, domain authentication and traffic encryption as they see fit. ETSI turned this into two models. In a 1-QWAC, everything is in one certificate and the provider has to pass the browsers’ rules. In a 2-QWAC, encryption still depends only on the TLS certificates browsers already accept, and the QWAC serves only to attest identity.
1-QWAC in detail
A 1-QWAC is an X.509 TLS server certificate issued under two standards at once: the CA/Browser Forum Baseline Requirements (usually with extended validation, EV) and ETSI EN 319 411-2. In practice, it is an EV or OV certificate with the qualified statements added. The browser:
- validates the chain up to a root in its programme, as for any website;
- checks certificate transparency (CT logs), as for any public TLS certificate;
- if it supports QWACs, confirms on the EU trusted lists that the issuing CA had an active qualified QWAC service at the time of issue;
- displays the organisation’s identity and the statement that it is qualified.
A browser without QWAC support stops after the first two steps: the site works, the connection is secure, and the qualified identity is not shown.
2-QWAC in detail
A 2-QWAC involves two separate objects:
- the 2-QWAC, a qualified certificate with the holder’s identity and domains, which is not used in the TLS handshake;
- the binding (TLS certificate binding), a small JSON document signed with the 2-QWAC key in JAdES format, which lists the TLS certificates the holder recognises as its own, identified by their cryptographic digest.
The server announces the binding in an HTTP Link header. The browser downloads it, validates the signature, validates the 2-QWAC against the trusted lists and confirms that the TLS certificate of the current connection is on the list. Only then does it display the identity. If the binding fails, the site keeps working as an ordinary site; a 2-QWAC never weakens encryption.
The practical advantage is renewal: because one binding can include several TLS certificates, including upcoming ones, the site can renew its TLS certificate every 47 days via ACME without going through qualified validation again. The downside is that it needs new work from everyone: browsers have to implement the process, and servers have to publish and update the binding.
As of November 2026 we know of no browser that implements the 2-QWAC model. The support announced by Opera for Android covers 1-QWACs only. The QWACs on sale, including the ones we provide, are 1-QWACs.
The technical profile of a QWAC
The elements that identify a QWAC in an X.509 certificate, under ETSI EN 319 412-4 and 412-5:
| Element | Identifier | Purpose |
|---|---|---|
| qcStatements extension | 1.3.6.1.5.5.7.1.3 | Holds the qualified statements below |
| QcCompliance | 0.4.0.1862.1.1 | States that the certificate is qualified under eIDAS |
| QcType: web | 0.4.0.1862.1.6.3 | States that it is a website authentication certificate |
| QcPDS | 0.4.0.1862.1.5 | Link to the provider’s PKI disclosure statement |
| QEVCP-w policy | 0.4.0.194112.1.4 | QWAC with extended validation, EV-compatible |
| QNCP-w policy | 0.4.0.194112.1.5 | QWAC under the normalised policy |
| QNCP-w-gen policy | 0.4.0.194112.1.6 | General-purpose QWAC, outside browser requirements |
| organizationIdentifier | 2.5.4.97 | Registration number, e.g. NTRPT-500000000, VATPT-500000000 or, for PSD2, PSDPT-BP-… |
| PSD2 statement | 0.4.0.19495.2 | PSD2 QWACs only: authorised roles and competent authority |
1-QWACs with extended validation also carry the EV subject fields: jurisdiction country, business category and registration number.
Validity, renewal and transparency
- Validity: a 1-QWAC is a public TLS certificate and follows the CA/Browser Forum limits: 200 days since 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029.
- Validation reuse: the organisation check can be reused for a limited period; after that, the provider asks for proof again. Domain control is revalidated more often.
- Certificate transparency: like any public TLS certificate, a 1-QWAC is published in CT logs that anyone can search (for example with the DigitalTrust certificate transparency lookup).
- Revocation: the provider runs OCSP services or revocation lists, whose location is in the certificate itself (Annex IV, point j).
What changes on the server
With a 1-QWAC, nothing special. It is installed like any TLS certificate, on nginx, Apache, IIS, a load balancer or a CDN: private key, certificate and intermediate chain. If you need to convert formats (PEM, PFX), the DigitalTrust converter does it in the browser, without the key leaving your computer.
With a 2-QWAC, besides the TLS certificate, the server has to publish the JAdES binding at a URL and add the matching Link header to its responses, updating the binding whenever the TLS certificate changes.