Artifact GuideGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements

Use this crosswalk to decide which CA/Browser Forum requirements apply to an EN 319 411-1 V1.5.1 certificate policy.

Selected [WEB] controls generally refer to BR V1.8.6, but the domain and IP validation requirement cites the undated BR reference. DVCP, OVCP, and IVCP require the full latest TLS .

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

ETSI EN 319 411-1 V1.5.1 does not replace the CA/Browser Forum for publicly trusted TLS server certificates. Apply the ETSI CP/CPS and certificate-service controls first. Then use one of two BR paths: a policy that adopts [WEB]-tagged controls follows the selected BR references cited by ETSI, including the undated domain/IP validation reference, while a CA asserting the ETSI DVCP, OVCP, or IVCP policy OID must also follow the full latest BR for the corresponding DV, OV, or IV policy. Check the live official BR text and its effective dates before deciding which version applies.

Side-by-side comparison

ETSI EN 319 411-1 vs CA/B Forum BR: where the work splits

Separate the ETSI baseline, the selected BR references used by [WEB] controls, and the full latest BR required for DVCP, OVCP, or IVCP.

Review all sources
First framework
ETSI EN 319 411-1

Defines general policy and security requirements for TSPs issuing public key certificates, including CP/CPS expectations, service components, publication, registration, revocation, and ETSI certificate-policy profiles.

Second framework
CA/B Forum BRG dependency

Has two ETSI entry points: selected BR clauses for [WEB] controls, including undated domain/IP validation references, and the full latest BR for DVCP, OVCP, or IVCP policy profiles.

Scope and certificate types

ETSI EN 319 411-1

EN 319 411-1 covers TSPs issuing public key certificates, including trusted web site certificates, and supports reference policies such as LCP, NCP, NCP+, DVCP, OVCP, IVCP, and EVCP.

CA/B Forum BRG dependency

A policy adopting [WEB]-tagged controls follows selected BR references; domain and IP validation cites undated BRG [6], while other controls cite fixed V1.8.6 [5]. A CA asserting DVCP, OVCP, or IVCP follows the full latest BR for the corresponding publicly trusted TLS certificate policy.

Operational implication

Name the certificate policy and OID first. That determines whether the ETSI bridge is limited to selected [WEB] controls or extends to the full latest BR.

Covered actors

ETSI EN 319 411-1

EN 319 411-1 applies to TSPs issuing public key certificates and covers the CA, registration, dissemination, revocation management, revocation status, and optional subject-device functions within their certificate services.

CA/B Forum BRG dependency

The BRG dependency arises for TSPs asserting DVCP, OVCP, or IVCP policy OIDs for publicly trusted TLS/SSL certificates, where root programs, browser vendors, and relying parties depend on CA/Browser Forum requirements being satisfied.

Operational implication

Map actors by their certificate-service role under EN 319 411-1 and by their CA, delegated-party, application-software-supplier, or relying-party role under the BR.

Trigger

ETSI EN 319 411-1

An EN 319 411-1 review is triggered when a certification authority asserts an ETSI NCP, LCP, NCP+, DVCP, OVCP, IVCP, or EVCP certificate policy OID, or when a CP/CPS review or audit is required for any of those policy profiles.

CA/B Forum BRG dependency

A full current BR review is required by the ETSI policy definition when a CA asserts DVCP, OVCP, or IVCP. A policy using [WEB]-tagged controls follows each stated reference, including the undated domain/IP reference, without automatically adopting the full latest BR.

Operational implication

Record the exact policy profile and whether the dependency arises from a [WEB] tag, a DVCP/OVCP/IVCP OID, or a separate relying-party or contractual rule.

Core obligations

ETSI EN 319 411-1

EN 319 411-1 requires a CP stating what must be adhered to and a CPS explaining how the TSP implements those requirements. Selected obligations are tagged [WEB] to mark controls that apply specifically to web-authentication certificates; DVCP, OVCP, and IVCP profiles add BRG-linked CPS duties.

CA/B Forum BRG dependency

[WEB] controls incorporate selected BR requirements; verify whether each control cites fixed V1.8.6 [5] or undated BRG [6]. Domain and IP validation cites [6]. DVCP, OVCP, and IVCP add full-current-BR monitoring and the conflict rule that the latest BR prevails unless ETSI is more stringent.

Operational implication

Keep the mapping of individual [WEB] references separate from the full-current-BR mapping for DVCP, OVCP, and IVCP.

Evidence

ETSI EN 319 411-1

EN 319 411-1 requires the TSP to verify subscriber and subject identity, check requests for accuracy, authorization, and completeness, and collect or validate direct evidence or attestation from appropriate sources.

CA/B Forum BRG dependency

For domain and IP information, REG-6.2.2-03A [WEB] cites clauses 3.2.2.4 through 3.2.2.9 of undated BRG [6]. Check the latest edition, its effective dates, and the referenced methods. DVCP, OVCP, and IVCP additionally require the full latest BR.

Operational implication

Record the validation method, ETSI requirement, exact BR reference and clause, edition, effective date, and evidence. Domain and IP validation uses the undated reference even outside the full-BR policy route.

Publication duties and BR deadlines

ETSI EN 319 411-1

EN 319 411-1 requires public CPS disclosure, availability of terms and conditions to relying parties, public international availability of those terms for publicly trusted certificates, support for OCSP or CRL, and public international availability of revocation status information.

CA/B Forum BRG dependency

The current BR has its own effective dates and lifecycle deadlines. Those requirements must be read from the live BR for DVCP, OVCP, and IVCP rather than inferred from ETSI notes or older clause references.

Operational implication

Track ETSI availability duties and current BR deadlines as separate cited controls; apply the stricter rule where the ETSI conflict clause requires it.

Conflict and change control

ETSI EN 319 411-1

EN 319 411-1 V1.5.1 sets the ETSI baseline and permits confidential CPS sections. ETSI TC ESI is the relevant body for EN 319 411-1 revisions; conflicts with CA/B Forum SSL/TLS certificate policies should be reported to both ETSI TC ESI and the CA/Browser Forum.

CA/B Forum BRG dependency

For OVCP, DVCP, and IVCP, BRG takes precedence when EN 319 411-1 conflicts with the latest BRG version, unless EN 319 411-1 is more stringent. The TSP must monitor BRG revisions and ensure compliance as requirements become effective, making BRG monitoring a live, repeating obligation.

Operational implication

When BRG conflicts with EN 319 411-1 for DVCP, OVCP, or IVCP, BRG takes precedence unless the ETSI requirement is more stringent; retain the conflict and stringency analysis.

Overlap

ETSI EN 319 411-1

EN 319 411-1 supplies the TSP baseline for registration, publication, certificate generation, revocation management, and certificate status services.

CA/B Forum BRG dependency

The BR can address the same operations for publicly trusted TLS certificates, but the actors, conditions, deadlines, and evidence details must be compared requirement by requirement.

Operational implication

A shared artifact may support both sources, but do not label a control jointly satisfied until the applicable ETSI and current BR requirements have been compared and the service boundary matches.

Decision rule

ETSI EN 319 411-1

ETSI evidence should be organized by policy profile and service component: CP/CPS, subscriber and subject registration, certificate generation, dissemination, revocation management, revocation status, and supporting procedures.

CA/B Forum BRG dependency

Map each [WEB] control to its stated BR reference, preserving the undated domain/IP dependency. Keep the full-current-BR mapping for DVCP, OVCP, or IVCP and separate root-program or application-software supplier rules.

Operational implication

Do not infer public trust from an ETSI assessment. Public trust depends on the root being distributed by application software and on the applicable relying-party program requirements.

Practical decision rule

How to use this comparison without overclaiming

  • Use EN 319 411-1 as the controlling source for ETSI CP/CPS structure, TSP service components, and ETSI policy-profile evidence.
  • Review the current official CA/Browser Forum text, effective dates, and applicable policy before deciding whether the BR requirements are met.
  • For DVCP, OVCP, and IVCP, preserve the bridge between ETSI policy OIDs, BRG references, revision checks, and conflict/stringency decisions.
Section 1

What the comparison can and cannot prove

EN 319 411-1 covers TSPs issuing public key certificates, including trusted website certificates. It contains provisions aligned with the CA/Browser Forum documents that ETSI abbreviates as EVCG and BRG, and it cites both a fixed BR V1.8.6 and an undated BR reference.

The two references do different work. Clause 3.4 describes selected BR V1.8.6 requirements for [WEB] controls, which do not by themselves require the full latest BR. However, REG-6.2.2-03A specifically cites undated BRG [6] for domain and IP validation, so each reference must be checked. By contrast, the DVCP, OVCP, and IVCP policy definitions and OVR-5.2 require the corresponding CA to follow the full latest BR, monitor revisions, and meet requirements as they become effective.

  • Use EN 319 411-1 as the source for CP/CPS structure, service components, ETSI policy identifiers, [WEB] tags, and ETSI conformity evidence.
  • For a [WEB]-only policy, record the BR reference cited by each requirement. Clause 3.4 describes selected BR V1.8.6 requirements, but REG-6.2.2-03A cites the undated BRG [6] for domain and IP validation.
  • For DVCP, OVCP, or IVCP, review the current TLS independently, including effective dates. The BR itself says its requirements are necessary but not sufficient for publicly trusted TLS issuance and become mandatory for a CA when adopted and enforced by relying-party application software suppliers.
Section 2

Policy profiles: where EN 319 411-1 points to BRG

EN 319 411-1 defines NCP, NCP+, and LCP as reference certificate policies, then defines EVCP, DVCP, OVCP, and IVCP for TLS/SSL certificates. DVCP, OVCP, and IVCP start with LCP and add the requirements needed for the corresponding CA/Browser Forum DV, OV, or IV certificate policy.

A CA that asserts an ETSI DVCP, OVCP, or IVCP OID in a TLS/SSL certificate is also expected by clause 4.2.2 to adhere to the corresponding CA/Browser Forum policy in the full latest BR. This is broader than adopting only the [WEB]-tagged requirements. The CP/CPS and evidence map should identify the asserted OID, the applicable BR policy, the BR version and effective date reviewed, and any additional BR requirement.

In this comparison, the web policy names distinguish Domain Validation Certificate Policy (DVCP), Organizational Validation Certificate Policy (OVCP), Individual Validation Certificate Policy (IVCP), and Extended Validation Certificate Policy (EVCP). The general reference policies are Lightweight Certificate Policy (LCP), Normalized Certificate Policy (NCP), and Extended Normalized Certificate Policy (NCP+).

  • List each certificate policy in scope: LCP, NCP, DVCP, OVCP, IVCP, or EVCP.
  • For DVCP, OVCP, and IVCP, record the ETSI policy OID, the corresponding BR policy, and the current BR version reviewed.
  • Do not infer that NCP, NCP+, or LCP alone satisfies the full current BR. For [WEB] controls, check each cited BR reference, including the undated reference for domain and IP validation. A browser root program or contract can impose separate requirements.
Section 3

CPS and publication duties to compare first

EN 319 411-1 distinguishes the CP from the CPS: the CP says what quality, profile, applicability, and rules apply, while the CPS explains how the TSP implements those rules in its own organization, systems, facilities, and procedures. The standard also requires the TSP to publicly disclose its CPS online on a 24x7 basis, while allowing sensitive aspects to remain undisclosed.

For OVCP, IVCP, and DVCP, EN 319 411-1 adds BRG-linked CPS requirements and requires the TSP to check for newer BRG revisions and ensure compliance as they become effective as specified by the CA/Browser Forum. The TSP therefore needs a continuing BR change-control process.

  • Confirm that the CPS names the certificate profiles, signature algorithms, parameters, and implementation practices needed for each asserted policy.
  • Keep a public CPS URL, publication owner, and review evidence for EN 319 411-1 OVR-5.2 requirements.
  • For DVCP, OVCP, and IVCP, add a BRG revision-monitoring record and a decision trail for any changed requirement.
Section 4

Validation, repository, and status checks that frequently overlap

EN 319 411-1 states that certificates issued under OVCP, DVCP, IVCP, or EVCP are publicly trusted certificates used to identify web servers accessed through TLS/SSL. REG-6.2.2-03A [WEB] points domain and IP verification methods to clauses 3.2.2.4 through 3.2.2.9 of BRG [6], the undated reference. Apply the latest edition under clause 2.1 and check the live BR text and effective dates; do not substitute the fixed V1.8.6 reference [5].

The same ETSI source gives concrete dissemination and status-service duties that should stay visible in a crosswalk: terms and conditions must be available to relying parties and, for publicly trusted certificates, publicly and internationally available; OCSP or CRL has to be supported; and revocation status information has to be publicly and internationally available.

  • Tie domain and IP address validation evidence to the EN 319 411-1 [WEB] requirement that refers to BRG methods.
  • Keep repository evidence for certificates, terms and conditions, CPS disclosure, cross-certified subordinate CA disclosure where applicable, and public availability claims.
  • Keep revocation evidence for OCSP or CRL support, consistency between methods when both are used, CPS documentation of delay interpretation, and public status availability.
Section 5

Conflict handling and change monitoring

For OVCP, DVCP, and IVCP, OVR-5.2-07A requires the TSP to check for newer BR revisions and comply as they become effective. Under the conditional conflict rule in OVR-5.2-07B, the latest BR takes precedence unless EN 319 411-1 is more stringent, in which case the ETSI requirement remains applicable.

Keep a change log with the ETSI version, BR version and effective date, policy profile, exact requirements compared, stringency decision, owner, and implementation evidence. Clause 4.2.2 also asks parties to bring conflicts between the latest CA/Browser Forum TLS policy and EN 319 411-1 to ETSI TC ESI and the CA/Browser Forum.

  • Track EN 319 411-1 version, BRG version, effective date reviewed, impacted CP/CPS section, and implementation owner.
  • When conflict is suspected, preserve the exact ETSI requirement, BRG requirement, stringency assessment, and escalation decision.
  • Review the bridge after BRG revisions, EN 319 411-1 revisions, new certificate profiles, root-program changes, or changes to validation and revocation operations.
Section 6

Evidence package for an audit-ready crosswalk

Build the evidence package around the EN 319 411-1 service components: registration, certificate generation, dissemination, revocation management, revocation status, and optional subject device provision. Then add BRG-specific references only for the profiles and [WEB] controls where EN 319 411-1 points to BRG.

The result should show what EN 319 411-1 itself requires, which BRG dependency was identified, which current BRG requirements still need independent review, and which operational record proves the control in the current assessment period.

  • CP/CPS map: policy OID, certificate profile, service component, public CPS location, and confidential procedure reference where sensitive details are withheld.
  • BRG bridge: DVCP/OVCP/IVCP requirement, BRG clause referenced by EN 319 411-1, current BRG source checked separately, and conflict/stringency result.
  • Operational records: subscriber and subject validation evidence, domain/IP validation evidence, issuance logs, repository publication checks, OCSP/CRL status records, revocation processing evidence, and change approvals.
  • Gap register: BR-only claims not established by EN 319 411-1, review owner, current CA/B Forum source still needed, and review deadline.
Primary sources

References and citations

cabforum.org3 citations
Referenced sections
  • Live official source for the current TLS Baseline Requirements version, scope, adoption boundary, and requirements that must be reviewed separately from the ETSI text.
  • Provides the live CA/Browser Forum TLS Baseline Requirements, including the current published version and the document's scope and adoption boundary.
  • Current official BR text and version for the independent review required by the DVCP, OVCP, and IVCP bridge.
etsi.org2 citations
Referenced sections
  • Grounds the EN 319 411-1 scope, CP/CPS model, DVCP/OVCP/IVCP relationship to BRG, [WEB] requirement tagging, CPS disclosure, domain/IP validation references, revocation-status expectations, and conflict rule for BRG-referenced certificate policies.
  • Grounds the EN 319 411-1 scope, CP/CPS model, DVCP/OVCP/IVCP relationship to BRG, certificate policy and CPS obligations.
"The present document includes provisions consistent with the requirements from the CA/Browser Forum in EVCG [4] and BRG [6]."
Show all related guides (22)

ETSI EN 319 411-1 FAQ for Certificate Services

Answers to common ETSI EN 319 411-1 questions on certificate policies, CPS content, CA and RA boundaries, subscriber evidence, revocation, status services, and record retention.

ETSI EN 319 411-1 Identity Validation

Identity validation requirements in ETSI EN 319 411-1 for subscribers, subjects, RAs, certificate requests, registration evidence, and issuance records.

ETSI EN 319 411-1 Identity Validation Evidence Workflow

A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls.

ETSI EN 319 411-1 RA Delegation Guide

How to scope registration authority delegation under ETSI EN 319 411-1, including delegated RA tasks, external provider controls, registration records, and audit evidence.

ETSI EN 319 411-1 RA Delegation Review Workflow

Review delegated registration authority work under ETSI EN 319 411-1: retained CA responsibility, recognized registration service providers, secure data exchange, CPS coverage, and audit evidence.

ETSI EN 319 411-1 requirements map for certificate services

Map ETSI EN 319 411-1 requirements for certificate policies, CP/CPS content, registration, revocation, certificate status, and CA key-management evidence.

ETSI EN 319 411-1 Revocation Evidence Workflow

Build a revocation evidence workflow for ETSI EN 319 411-1 covering CPS procedures, request authentication, 24-hour status updates, CRL/OCSP publication, logs, and retention.

ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations

Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, applicable 24-hour timing, CRL and OCSP controls, exceptions, and audit evidence.

CP vs CPS under ETSI EN 319 411-1

Understand how ETSI EN 319 411-1 separates Certificate Policy from Certification Practice Statement work for certification authorities and trust service providers.

ETSI EN 319 411-1 certificate re-key FAQ

What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key.

ETSI EN 319 411-1 Certificate Suspension FAQ

How CAs should handle certificate suspension under ETSI EN 319 411-1: CPS disclosure, validated requests, status publication, subscriber notice, and audit evidence.

ETSI EN 319 411-1 Certification Audit Evidence FAQ

How CAs should prepare ETSI EN 319 411-1 audit evidence for CP/CPS scope, registration records, revocation records, CA key logs, and retained assessment files.

How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?

What ETSI EN 319 411-1 expects CAs to evidence for certificate revocation requests, status publication, CRL or OCSP updates, and archived revocation records.

RA delegation under ETSI EN 319 411-1

How certificate authorities can delegate registration authority work under ETSI EN 319 411-1 while keeping identity validation, secure data exchange, role controls, and audit evidence traceable.

Subscriber agreements under ETSI EN 319 411-1

How ETSI EN 319 411-1 expects CAs and TSPs to inform subscribers, record acceptance, handle subject consent, and retain subscriber-agreement evidence.

Subscriber identity validation under ETSI EN 319 411-1

How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records.