In this blog post, we will see what changed in Firefox 153 around certificate verification, why a small padlock detail now matters a lot more than before, and what a Qualified Website Authentication Certificate (QWAC) actually tells you about a site.
I spend a good chunk of my day at Salesforce/MuleSoft dealing with PKI and authentication, so when I saw this show up in a browser panel, I had to dig in. This is not a flashy feature. It is a quiet one. But if you work anywhere near certificates, TLS, or backend authentication, it is worth understanding.
Table of Contents
What is a QWAC
QWAC stands for Qualified Website Authentication Certificate. It is a certificate type defined under the EU’s eIDAS Regulation (originally Regulation 910/2014, now updated by eIDAS2, Regulation (EU) 2024/1183).
Unlike a regular TLS certificate issued by any certificate authority in your OS or browser trust store, a QWAC can only be issued by a Qualified Trust Service Provider (QTSP). A QTSP goes through a formal audit process and has to verify the legal identity of whoever is requesting the certificate with a much higher bar than a standard Domain Validated (DV) certificate.
Think of it as the legal identity layer sitting on top of the usual cryptographic identity layer that TLS already gives you.
What changed in Firefox 153
Firefox has supported the idea of QWACs behind a pref for a while, but Firefox 153 is the release where Mozilla flipped it on by default on desktop. The relevant bug (2043399, filed by Dana Keeler on the PSM team) is titled plainly: “enable QWACs by default on desktop.”
Here is what that actually means under the hood:
- Firefox now discovers QWACs presented alongside the regular TLS certificate during the handshake.
- It verifies the QWAC against the EU Trusted List infrastructure.
- It performs revocation checking on that QWAC, same as it would for a normal cert chain.
- If everything checks out, it surfaces the qualified identity in the connection info panel, the little padlock dropdown you get when you click the site info icon.
The official release note wording from Mozilla is straightforward: “Firefox now verifies and displays Qualified Website Authentication Certificates (QWACs) in accordance with eIDAS regulations.”
Walking through a real example
The screenshot that got me writing this is a QWAC in the wild, on eidas.ec.europa.eu, the EU’s own eIDAS dashboard site. Head to eidas.ec.europa.eu/efda/home in Firefox 153 and click the padlock icon, then “Connection protections,” and you will see something like this:
- Certificate issued to: The European Commission, Brussels, BE
- Verified by: Greek Universities Network (GUnet)
- Qualified as specified in: Regulation (EU) 2024/1183
As shown in the below screenshot, this is exactly the layout Firefox now renders. GUnet here is acting as the QTSP. It did the identity vetting for “The European Commission” as a legal entity and issued the QWAC. Firefox verified that chain against the EU Trust List and is now telling you, in plain language, who legally stands behind this site.
Compare that to a typical DV certificate from Let’s Encrypt on some random domain. That certificate proves you are talking to whoever controls the private key for that domain name. It says nothing about who that legal entity actually is. The QWAC panel is the difference between “this is definitely example.com” and “this is definitely example.com, and example.com is legally the European Commission, verified by an accredited body.”
Before it was built in: the eIDAS QWAC Validator extension
Here is the part I found genuinely interesting while digging into this. QWAC detection in Firefox is not a new idea. It has existed as a third-party extension for years, called eIDAS QWAC Validator, built by AgID, the Agenzia per l’Italia Digitale (Italy’s digital agency).
The add-on shows a greyed-out EU flag icon at the right of the address bar. Visit a site with a valid QWAC and the flag lights up in EU colours. Visit a site without one, or with a broken one, and it stays grey or shows a red exclamation mark. Under the hood it queries the European Commission’s TL-Browser API to check the certificate against the EU Trusted Lists, and it looks for qcStatement metadata conforming to ETSI EN 319 412-5 to decide whether a certificate qualifies at all.
That is a genuinely clever piece of engineering for 2019, when it was first published. But looking at it now, next to what shipped natively in Firefox 153, it is a good case study in why “built in” beats “bolted on”:
- Adoption never happened. The listing shows 9 users and a 3 out of 5 rating from 2 reviews. Years of availability, barely any pickup. A feature buried behind an optional extension install is a feature almost nobody finds.
- The permission ask was heavy for what it did. To show a flag icon, it needed “access your data for all websites,” which is the same broad grant you would expect from a much more invasive extension. That is a rough trade for a passive indicator.
- It phoned home on every page load. Validating via the TL-Browser API meant sending the URL and TLS certificate details of every site you visited to an external EU endpoint. The extension’s own privacy policy is upfront about this, but it is exactly the kind of per-request external lookup that a native, in-browser verification path avoids entirely.
- It could produce false negatives. The developers themselves note that certificates using non-standard but legal OIDs to self-qualify would fail validation, since the extension checks for a specific
qcStatementformat rather than doing broader semantic verification. - It stopped being maintained. Last updated in February 2020, version 5.4. Meanwhile the actual eIDAS2 legal and technical groundwork needed to make this a first-class browser feature kept moving for another five plus years before Firefox 153 landed it properly.
Firefox 153’s native support fixes all of that in one move. No extra permissions beyond what Firefox already needs to run TLS verification. No external API call added per page, since discovery and revocation checking are folded into the existing certificate verification pipeline Firefox already runs. And it is maintained by the same team that maintains the rest of PSM (Personal Security Manager), not a side project that can go quiet after one release.
It is a nice reminder that a lot of “new” browser features had a scrappy extension-based prototype running in the wild for years before the platform caught up.
Why this exists: the eIDAS2 backstory
This feature has a long and genuinely contentious history, and it is worth knowing if you are going to talk about it with anyone in security circles.
The original eIDAS proposal (the Article 45 draft) wanted to force every browser to automatically trust any QTSP approved by any EU member state, no exceptions, no ability for a browser vendor to reject a QTSP even if it had security concerns. Mozilla, the EFF, and a long list of security researchers pushed back hard on that version, arguing it would have forced browsers to weaken their own root store vetting standards and created a huge new attack surface, since compromising one QTSP could compromise trust for a lot of sites at once.
That pushback worked, at least partially. The European Parliament approved changes to eIDAS in February 2024 that walked back the strictest version of the mandate, and eIDAS2 (Regulation (EU) 2024/1183) was published in the Official Journal in April 2024, entering into force in May 2024. Browsers kept more control over which QTSPs they trust and how they handle security incidents. The Implementing Act specifically covering QWACs was adopted in December 2025, which is what cleared the runway for browsers to actually ship support without it being a legal minefield.
Firefox 153 enabling QWACs by default is effectively the payoff of that multi-year negotiation between EU regulators and browser vendors.
How QWACs differ from regular TLS certificates
A few points that matter if you are coming from a pure TLS background:
- They are additive, not a replacement. A site still needs a normal TLS certificate for the handshake to work. The QWAC rides alongside it as extra, legally backed identity proof. Nothing breaks if a site does not have one.
- Issuance is stricter. QTSPs have to comply with ETSI standards like EN 319 411-2 and go through government-supervised audits, well beyond a domain-control check.
- They carry legal weight. A QWAC has recognized legal effect across the EU under eIDAS2, which matters for regulated sectors like banking (PSD2 already leans on this) and government portals.
- Revocation checking is mandatory. Firefox checks QWAC revocation status the same way it does for the base TLS chain, so a compromised QTSP certificate does not stay trusted silently.
If you remember the old Extended Validation (EV) certificate green bar from years ago, this will feel familiar. EV quietly died out because browsers found it did not meaningfully reduce phishing and the UI real estate was not worth it. QWAC is a different animal because it has actual regulatory teeth behind it, not just a marketing tier from a CA.
What this means if you build or secure web services
A few practical angles for anyone in backend or platform engineering:
- If your product serves EU government, banking, or regulated sectors, expect QWAC-related questions from compliance teams sooner rather than later.
- If you are building anything that inspects or terminates TLS (proxies, API gateways, service meshes), be aware QWAC data rides in the handshake and your tooling may not currently parse or surface it.
- For anyone doing cert-pinning or TLS-related observability work, this is one more certificate type to account for in your monitoring and alerting logic.
- It is not going to touch performance testing directly since it is a display and trust layer, not a new crypto operation Firefox negotiates differently, but it is worth knowing if a client ever asks why their site “shows extra certificate info in Firefox but not Chrome.”
My take
This is one of those features that will be invisible to almost everyone and genuinely useful to a small, important slice of the internet: government portals, banks, regulated EU services. I like that it survived years of pushback and came out the other side less heavy-handed than the original proposal. Browser vendors keeping veto power over which QTSPs they trust is the right outcome.
If you are into PKI, authentication, or just like understanding what that padlock icon is actually telling you, go find a .eu government or bank site in Firefox 153 and take a look at its connection panel. It is a small, satisfying rabbit hole.
Happy Testing!
Have you spotted a QWAC on any site you use regularly? Drop it in the comments, I would like to build a small list.
