CA Trust Infrastructure & Audit Standards: Trusted Lists, WebTrust and FIPS 140

A certificate is only as trusted as the audit behind it

When you sign a contract or open an HTTPS website, your software verifies a certificate against a chain of trust that ends in a root certificate authority (CA). But who checks the CA? That is where trust infrastructure comes in: trusted lists, audit standards and hardware requirements that tell the world a CA can be relied on. Understanding these layers matters when choosing an eSignature or document-signing provider, because the strength of the underlying trust chain is what makes a signature verifiable years after it was made.

At a glance

Trusted lists are the public register of approved trust-service providers — signed, published and continuously updated by a regulator.

WebTrust and ETSI audits are the independent checks that let a CA's root certificate be pre-installed in browsers and operating systems.

The CA/B Forum is the industry body where CAs and browser vendors jointly set the technical rules a publicly trusted CA must follow.

FIPS 140 sets the hardware bar for private keys: above a certain level, the key must never leave its cryptographic module in plaintext.

Four pillars of CA trust infrastructure

Trusted lists (ETSI TS 119 612)

In the EU, a trusted list is a regulator-signed register of qualified trust-service providers (QTSPs) and the services they offer, each marked as granted, suspended or withdrawn. Because the list is digitally signed and publicly verifiable, relying parties can check whether a provider was qualified at the moment a signature was made. This mechanism is what lets a signature created in one EU member state be validated across the other 26.

ETSI EN 319 401 — the baseline for every TSP

Before a provider appears on a trusted list, it must satisfy a common policy framework. ETSI EN 319 401 sets the general requirements for trust-service providers: management and operational controls, continuous risk assessment, and documented policies and practices that auditors can verify. It is the minimum bar that keeps audits consistent across providers.

WebTrust — the audit that opens browser trust

WebTrust is a security audit framework created by the Canadian and American institutes of chartered accountants. It assesses a CA across organization, personnel, physical security and the full certificate lifecycle. Major browsers require a CA to pass WebTrust or an equivalent ETSI audit before its root certificate can be pre-installed — and the resulting audit report must be published for anyone to read.

The CA/B Forum — the rule-makers

The CA/B Forum brings together certificate authorities and browser vendors (Google, Mozilla and others) to set the technical baseline every publicly trusted certificate must meet: certificate lifetimes, key sizes, domain validation and code-signing key protection. A CA that breaks these rules risks having its certificates distrusted by browsers — a near-fatal outcome for a business built on trust.

FIPS 140 — the private-key red line

FIPS 140 (NIST) is the reference standard for cryptographic modules. At Security Level 3 and above, a private key must not be exported in plaintext from its module: it is generated, stored and used inside tamper-resistant hardware. The CA/B Forum applies the same logic to code-signing keys, and China mirrors the four-level approach in GM/T 0028 and GB/T 37092.

Audit standards compared

Each standard answers a different part of the trust question.

	ETSI EN 319 401	WebTrust	FIPS 140
What it covers	TSP management, risk and documentation	CA operations end-to-end	Cryptographic module security
Who relies on it	EU trust-service providers	Publicly trusted CAs (browser roots)	Hardware and software crypto vendors
Output	Conformity assessment and trusted-list entry	Published audit report	Security-level certification
Key focus	Process and policy	CA accountability	Private-key protection

Common questions

A trusted list is the official register of trust-service providers a regulator has approved. It is signed so anyone can verify it, and it records whether each provider is active, suspended or withdrawn — which matters when you need to prove a signature was valid at a specific point in time.

Team discussing the right eSignature approach for a business

Explore the right eSignature approach for your business

Talk to our team about eSignature requirements, compliance considerations, and document workflows across your target markets.

Keep reading

Industry Insights