How Do You Know If a Website Is Really Who They Say They Are?

June 20, 2026 ·Gustav Poola ·

website-identitycompany-identitylegal-entity-identityqwaceidasarticle-45authenticationamlrtlsev-certificatecross-border-e-signaturecompany-sealqtsp

The padlock in your browser tells you the connection is encrypted. It does not tell you who runs the website. eIDAS Article 45 defines a separate primitive for that — the Qualified Website Authentication Certificate (QWAC). The Implementing Act was adopted on 17 December 2025; major browsers still do not display QWACs in a user-friendly UI.

How Do You Know If a Website Is Really Who They Say They Are?

The padlock in your browser tells you the connection is encrypted. It does not tell you who runs the website. eIDAS defines a separate primitive for that — the Qualified Website Authentication Certificate (QWAC). On 17 December 2025 the Implementing Act on QWACs was adopted; major browsers still do not display QWACs in a user-friendly UI in 2026.

In our work building the identity-proofing layer for SMEs that have to demonstrate cross-border verifiability to EU customers, the "is this website who it says it is?" question comes up earlier than most SMEs expect. A Vilnius-based SaaS vendor we worked with last quarter — selling supplier-onboarding software into the German Mittelstand — discovered the gap when a Munich manufacturing client's procurement team refused to consume an offer email from a non-QWAC-anchored domain on the second round of due diligence; the vendor's German pilot stalled for six weeks while their counsel and the QTSP they eventually engaged worked out which Trusted List entry they actually needed. The whole conversation that follows turns on a confusion that the web has been carrying for fifteen years: the difference between connection security and identity verification. The two are not the same thing, the EU has a specific tool for the second, and the major browser vendors have spent the last several years arguing that the EU's tool shouldn't be visible to users. The procurement-side analogue of the same confusion — buying identity vs buying a wallet — is the topic of our later post on Digital ID vs Digital Wallet.

What does the browser padlock actually verify?

That the connection between your device and the server is encrypted and that the server holds a private key matching the public key in a certificate signed by a Certificate Authority your browser trusts. That's it.

The certificate type the padlock represents in 2026 is, in almost all cases, a Domain-Validated (DV) certificate. DV certificates verify only that the entity requesting the certificate controls the domain — typically demonstrated by responding to an HTTP or DNS challenge from the CA. There is no verification of who is behind the domain, what legal entity operates it, or whether the domain owner is in the country implied by the URL. The padlock has been functionally the same icon since browsers stopped distinguishing EV (Extended Validation) certificates with a green company-name bar around 2019.

This is the part that has stayed steady through fifteen years of web-PKI evolution. The padlock answers a real and important question — is this connection intercept-resistant? — and it answers it well. It does not answer the question SMEs and their customers actually care about when they're about to sign a contract: is the legal entity I'm transacting with the one I think it is?

What is a QWAC, and what does it prove that DV doesn't?

A QWAC is a Qualified Website Authentication Certificate under eIDAS Article 45. It is issued by a Qualified Trust Service Provider (QTSP) listed on the EU Trusted List. A QTSP issuing a QWAC has to verify the legal identity of the entity behind the website — company registration, legal representative authorisation, address — to substantially higher assurance than a DV certificate.

The cryptographic content of the certificate carries: the legal name of the entity, its registration number in a national company register, the country of incorporation, and the addresses associated with it. A verifier presented with a QWAC can confirm, by checking the signature chain back to a QTSP on the EU Trusted List, that the website is operated by a specifically-named legal entity that has been verified to do exactly that.

That's an architecturally different question from "is the connection encrypted". And it is the question the cross-border SME's German customer is actually asking. Wikipedia's QWAC article walks through the certificate profile in detail; ETSI EN 319 411-2 defines the policy QTSPs follow when issuing QWACs.

The eIDAS Implementing Act on Qualified Certificates for Website Authentication was officially adopted on 17 December 2025, replacing the long-running drafting process that had been running since the eIDAS 2.0 negotiations in 2022-2024. The Implementing Act defines the technical and operational rules for QWACs in the post-eIDAS-2.0 framework, including the EU Trusted List integration and the conformity-assessment requirements for QTSPs issuing them.

Why don't browsers show QWACs in 2026?

Because the browser vendors — Mozilla, Google, Apple — pushed back hard against the original eIDAS 2.0 draft requiring them to display QWAC-issuer information in the UI, and the eIDAS 2.0 final text (Regulation (EU) 2024/1183) softened the obligation enough that the browsers, in practice, do not yet implement the EV-style UI for QWACs that the 2021 drafts had envisaged.

The technical argument the browser vendors made was that imposing trust on a government-controlled list of QTSPs would create a security risk if any of those QTSPs were compromised or pressured to issue certificates inappropriately. The Electronic Frontier Foundation's 2022 analysis is the most widely-cited expression of this concern; Mozilla's #SecurityRiskAhead campaign gathered signatures from web-security researchers in 2023.

The policy argument the European Commission made was that the EU was creating a parallel trust framework for legal-entity identity that the existing CA/Browser Forum framework was not designed to address — and that the browser vendors, by refusing to display QWAC information, were leaving EU users without access to identity-assurance information that the EU's own qualified trust framework had certified. The compromise text that landed in eIDAS 2.0 stops short of forcing browsers to elevate QWACs into the UI but does require them to at least accept QWACs from EU Trusted List QTSPs as valid root certificates.

What's actually visible to the user in 2026 is therefore: the padlock, exactly as it has been. The QWAC information sits inside the certificate, accessible to a developer who clicks through the browser's certificate viewer, but not surfaced as a "this site is operated by [Legal Entity Name] verified by [QTSP]" indicator. The cryptographic chain exists; the user-facing surface does not.

If you sit with the eIDAS Article 45 text and the December 2025 Implementing Act, the part that has been argued for two years is whether the browser is required to display the QWAC information or only permitted to. The final text leans toward permitted-but-not-required, which is why the EV-style UI hasn't landed. Honestly, the most under-stated implication of the December 2025 Implementing Act is that it sets the technical baseline against which browser-vendor compliance will be measured if the EU does eventually push for mandatory display.

Four certificate types for website authentication — Domain-Validated, Organisation-Validated, Extended Validation, and Qualified Web Authentication Certificate — showing what each verifies and what is displayed in the browser today.

So how can you actually check a website yourself, right now?

Five quick checks that work in 2026, in roughly increasing order of effort.

Look at the URL itself. Misspelled domains, near-homograph characters (Cyrillic letters mimicking Latin ones, hyphenated variants of well-known brands) are the cheapest fraud signal and the easiest to miss at a glance. A reader who has trained themselves to look at the URL bar deliberately catches most consumer-grade phishing before any certificate check is needed.

Click the padlock and open the certificate viewer. Every major browser exposes this in two clicks — usually under "Connection is secure" → "Certificate is valid" or the equivalent in your browser. The fields worth looking at are Issued To (the legal entity name if the certificate is OV or EV — DV certificates show only the domain), Issued By (the CA), Validity Period (a recently-issued certificate on an otherwise-old-looking site is a yellow flag), and Subject Alternative Names (the full list of domains the certificate covers). What I find most useful in compliance audits is this 30-second check — it reveals more than most users assume.

Cross-check the legal entity in a public register. If the certificate shows a company name, search for it in the national business register of the country it claims to be in (EU Business Register, UK Companies House, Estonian Äriregister, French Infogreffe, etc.). Confirm the company exists, is currently active, and the address roughly matches what the website displays.

For eIDAS claims, check the EU Trusted List. If the website claims a QWAC or another qualified trust service (typical for PSD2-regulated services, eHealth platforms, and qualified-signature portals), the issuing QTSP must be on the EU Trusted List. The Commission's LOTL browser lets you confirm any QTSP in any Member State in under a minute.

Look at the contact channels. A legitimate operating company will have a physical address that matches public registers, an email on the same domain as the website (not a free-mail address), and a phone number that survives a reverse lookup. The absence of any one of these is not itself proof of fraud; the absence of all of them is a strong signal.

None of these checks individually is decisive. Run several together and the signal-to-noise improves quickly — particularly for cross-border transactions where the receiving party doesn't have the home-jurisdiction context to read certificates intuitively.

What about verifying the company itself, beyond just the website?

The website is the visible surface. The legal entity behind it is the substance. The two get verified by different mechanisms, at different moments, against different audit requirements.

A QWAC verifies the legal-entity-website binding passively, at TLS handshake — once issued, the certificate sits in the server, the browser checks the signature chain, and that's the verification event. It happens before any actual transaction. The certificate's content (legal name, registration number, country of incorporation) is what the receiving party can read out of the chain.

Company identity verification at the transaction layer is the active version of the same question, asked at the moment the transaction is signed or the relationship is established. Under Regulation (EU) 2024/1624 — AMLR, applying from 10 July 2027, obliged entities (banks, payment service providers, regulated marketplaces, increasingly broader sectoral lists) must verify the legal-entity counterparty including its beneficial owners — not once at TLS handshake, but at customer onboarding and at periodic review. AMLR explicitly extends to non-EU entities with EU links: a Turkish supplier transacting with an EU customer has to be verifiable to the EU customer's AMLR obligations, regardless of whether the supplier's website carries a QWAC.

An Estonian SME exporter we work with asked us last year whether their planned QWAC purchase would satisfy the German importer's KYC requirement. The answer was no, and the gap is structurally important to name. QWAC verifies the website operator at TLS handshake; AMLR/KYC verifies the company at the moment of the transaction; the two are checked by different teams (German importer's compliance officer vs the importer's IT/security team) against different evidence requirements (EU Trusted List signature chain vs registration-extract + UBO declaration + AdES-bound legal-entity record). The two are complementary, not substitutable.

The product layer we ship for this active verification is what we call Company Identity — verifying a legal entity's registration, beneficial owners, and authorised representative against authoritative national registries, producing an audit-defensible record. The downstream artefact — an Advanced e-Seal under eIDAS Article 36 / Article 39 sealing documents on behalf of the verified legal entity — sits in the Company Seal product. Both are AdES-grade (no QES claim since IdentiGate is not a QTSP), retained by the customer for later regulator inspection. Where QWAC answers "is this website operated by [Legal Entity]", Company Identity answers "is this legal entity the one I should be signing a contract with right now".

What this means at the procurement table: if the question is "regulators ask whether our website has eIDAS-grade identity attestation", the answer is QWAC. If the question is "the receiving counterparty's compliance team needs proof of who we legally are at the moment of contract sign", the answer is a separate active-verification step. SMEs hitting cross-border procurement processes need both, ordered correctly, and not bundled by a vendor that only ships one of them.

What this means for verifiable websites today

If you are an SME, a fintech, or any legal entity that needs to demonstrate website identity to a regulated counterparty in 2026, the operational read is layered.

A QWAC is the EU's normative answer. If your counterparty asks for eIDAS-compliant website identity — particularly under PSD2/PSD3 (where QWAC has been required for payment service providers since 2019 (GlobalSign — PSD2 QWAC onboarding guide)), or under sectoral regulations expected to extend the requirement — buying a QWAC from a QTSP on the EU Trusted List is the documented path. The QTSP onboarding flow verifies your legal entity at substantially higher assurance than your DV CA did, and the certificate's audit trail survives regulatory scrutiny.

The browser UI is unlikely to surface the QWAC information in 2026. The QWAC is real, the chain is verifiable, your regulated counterparty can confirm the issuer against the EU Trusted List. Your retail website visitors will not see a different padlock. This is a regulatory-compliance buy, not a marketing buy.

The adjacent question — verifying the legal entity at the moment of transaction, not at the moment of TLS handshake — sits in a different layer. That's the identity-proofing layer we ship at IdentiGate as the Company Identity product, with the resulting Advanced e-Seal under eIDAS Article 36 bound to the verified entity for downstream signing flows. We are not a QTSP and we do not issue QWACs. We sit one layer above — verifying the legal entity at substantial assurance and producing AdES-bound records the counterparty's compliance team can retain independently of any QWAC.

The honest engineering reading is that website identity in 2026 has three layers — connection security (the padlock, working well), legal-entity website attestation (QWAC, working but invisible), and transaction-time legal-entity verification (the IdentiGate layer, or equivalent). Most SMEs procuring "website identity" buy at the first layer because it is the only one their CA sells them. Most regulated counterparties asking for "website identity" mean the second or third. Picking the right layer for the question is what makes the procurement actually defensible.

Sources

Primary — eIDAS and QWAC framework

Primary — Legal-entity identity and AMLR

Regulation (EU) 2024/1624 — AMLR — EUR-Lex

Primary — Technical standards

Browser-vendor positions and analysis (secondary, used for the policy controversy)

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.