FAQGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 RA delegation for certificate authorities

A focused answer for certificate authorities and trust service providers using internal or external functions.

Based on ETSI EN 319 411-1 and ETSI EN 319 401 source text. Use it as implementation guidance, not for legal interpretation.

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

Under ETSI EN 319 411-1 V1.5.1 (April 2025), a certificate authority can use support, including external registration service providers, but the TSP still needs traceable identity-validation evidence, secure exchange of registration data, trusted-role controls, and records that identify the receiving TSP or submitting RA where applicable. Delegation does not transfer the TSP's overall responsibility for conformity. EN 319 411-1 supplies a technical baseline; the applicable certificate policy, assessment scheme, contract, browser program, and law can impose additional controls.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

Can a certificate authority delegate RA work under ETSI EN 319 411-1?

Yes, but delegation does not turn registration into an unmanaged hand-off. ETSI EN 319 411-1 defines a as the entity responsible mainly for identifying and authenticating certificate subjects, and notes that an RA can assist with certificate applications, revocation, or both.

For initial identity validation, the TSP must ensure that the subscriber and subject are verified, that direct evidence or an attestation from an appropriate and authorized source is collected and validated, and that certificate requests are accurate, authorized, and complete. A subcontracted person may supply identity evidence only when the identity check follows clause 6.2.2. The who verifies identity cannot be the natural person receiving the certificate.

  • Define which RA tasks are delegated: identity proofing, certificate application intake, revocation request handling, or registration-data submission.
  • Keep the TSP accountable for the certificate policy and CPS controls even when the registration work is performed by another party.
  • Do not accept delegated registration evidence unless it supports the subject, subscriber, authorization, and certificate profile requirements that apply to the certificate being issued.
  • Keep certificate issuance separate from registration approval: the application must come from a trusted and authorized source, and the issuing procedure must remain securely and unambiguously linked to the associated registration.
Question 2

What controls should cover an external RA?

External registration authorities are controlled trust-service participants. ETSI EN 319 411-1 requires registration data from external registration service providers to be exchanged securely and only with recognized providers whose identity is authenticated.

The same clause points external RAs back to general TSP security requirements, including human resources, operational security, networks, and privacy. ETSI EN 319 401 adds that third-party arrangements need documented agreements and clear obligations for the relevant information security requirements.

  • Maintain a current list of recognized external registration service providers and the authentication method used for each provider.
  • Document the contract or agreement terms that bind the RA to identity proofing, registration-data protection, incident reporting, personnel, and termination obligations.
  • Require each , each revocation officer, and other trusted roles involved in RA work to be appointed, trained, screened where applicable, and separated from prohibited self-validation scenarios.
  • Authenticate each recognized external registration service provider and protect registration data during exchange; a contract alone does not satisfy those operational controls.
Question 3

What evidence should auditors expect for RA delegation?

The audit file should make the delegated registration chain reconstructable. ETSI EN 319 411-1 requires registration information to be logged and recorded, including document types, unique identification data or references where applicable, storage locations, subscriber-agreement choices, the identity of the entity accepting the application, validation method, and the receiving TSP or submitting RA when applicable.

RA delegation evidence should also cover retention and exit handling. Clause 6.4.6 sets a minimum of seven years after any certificate based on the records ceases to be valid for CA-managed key-lifecycle logs and the documentation identified in clause 6.3.4. Other RA records need their own applicable and disclosed retention period. The CA/RA termination requirements cover registration information, revocation status information, and event log archives.

  • Keep the RA delegation register, provider agreement, provider authentication evidence, CP/CPS mapping, and list of delegated registration tasks together.
  • Retain sample registration records that show the identity evidence or attestation source, the validation method, the application-acceptance entity, and any submitting RA.
  • Document how registration records, revocation-related records, and event log archives remain accessible if an RA relationship ends or the CA/RA service terminates.
Question 4

Questions and answers

Can a TSP delegate RA work under ETSI EN 319 411-1?

Yes. ETSI EN 319 411-1 says an RA can assist in the certificate application process, the revocation process, or both. The TSP remains responsible for the supported policy and for controlling outsourced components. It must ensure that the subscriber and subject are verified, that identity evidence or an authorized-source attestation is validated, and that certificate requests are accurate, authorized, and complete.

What controls should cover an external RA?

External registration service providers must exchange registration data securely and only with recognized providers whose identity is authenticated. The TSP must also apply the general security requirements for human resources, operational security, networks, and privacy, and keep documented agreements that define the external party's obligations.

What evidence should auditors expect for RA delegation?

Auditors should expect a reconstructable chain: the registration record, identity evidence or attestation source, validation method, entity accepting the application, any receiving TSP or submitting RA, and retention and termination handling. Registration events must be logged. Clause 6.4.6 applies its seven-year minimum to CA-managed key-lifecycle logs and clause 6.3.4 documentation, while other RA records follow their applicable ETSI, disclosed, legal, contractual, and scheme rules.

Primary sources

References and citations

etsi.org4 citations
Referenced sections
  • Primary ETSI source for TSP responsibility, third-party agreements, subcontractor competence, and trusted-role controls that apply when RA work is outsourced.
  • Supports the point that subcontracting or outsourcing does not remove the TSP's overall responsibility for policy conformance.
  • Supports documented third-party agreements, supplier obligations, subcontractor competence, and TSP responsibility for outsourced service components.
Show 1 more
  • Supports retaining supplier-relationship evidence because the TSP remains responsible for conformance when third parties provide parts of the service.
"provide parts of its service through subcontracting"
More quoted passages
"it shall maintain overall responsibility"
"documented agreement and contractual relationship"
"subcontracting, outsourcing or other third party arrangements"
etsi.org4 citations
Referenced sections
  • Primary ETSI source for RA definitions, identity validation, external registration service provider controls, registration logging, records archival, and CA/RA termination requirements.
  • Defines Registration Authority responsibilities and supports the answer that delegated identity evidence must still satisfy clause 6.2.2 validation requirements.
  • Supports the secure-registration-data exchange requirement for external registration service providers and the trusted-role expectations for registration work.
Show 1 more
  • Supports the specific RA-delegation audit evidence: registration logging, submitting RA identification, records archival, and CA/RA termination handling.
"Registration Authority (RA): entity that is responsible for identification and authentication"
More quoted passages
"Evidence of identity may be provided by a person subcontracted"
"registration data shall be exchanged securely"
"name of receiving TSP and/or submitting Registration Authority"
Show all related guides (22)

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.

EN 319 411-1 vs EN 319 411-2 Certificate Policy

Compare ETSI EN 319 411-1 V1.5.1 with EN 319 411-2 V2.6.1, including policy profiles, inherited controls, QSCD routes, trusted-list status, and evidence boundaries.

ETSI EN 319 411-1 Audit File Evidence

Build an ETSI EN 319 411-1 audit evidence file for CA logging, registration records, revocation records, CA key lifecycle evidence, and records archival.

ETSI EN 319 411-1 CA Key Management

CA key management guidance for ETSI EN 319 411-1: CPS commitments, key ceremonies, secure cryptographic devices, backup, recovery, and lifecycle evidence.

ETSI EN 319 411-1 certificate lifecycle workflow

Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records.

ETSI EN 319 411-1 Compliance Guide

Build an ETSI EN 319 411-1 compliance file for certificate policies, CPS commitments, certificate lifecycle controls, revocation services, CA keys, and audit evidence.

ETSI EN 319 411-1 CP and CPS template

Build a certificate policy and Certification Practice Statement template for ETSI EN 319 411-1 certificate services, with fields for policy identifiers, subscribers, relying parties, revocation, publication, and evidence.

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.

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

Compare ETSI EN 319 411-1 V1.5.1 with the CA/Browser Forum TLS Baseline Requirements, including [WEB] controls, DVCP, OVCP, IVCP, CPS duties, and change monitoring.