---
title: "RA delegation under ETSI EN 319 411-1"
canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq/ra-delegation"
source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq/ra-delegation"
author: "Sorena AI"
description: "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."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "ETSI EN 319 411-1"
  - "registration authority"
  - "RA delegation"
  - "identity validation"
  - "trust service provider"
  - "trust services"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# 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.

*FAQ* *GLOBAL* *ETSI 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 registration authority functions.

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

Under ETSI EN 319 411-1, a certificate authority can use registration authority 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.

## 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 Registration Authority 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 verify the subscriber and subject, collect and validate direct evidence or an attestation from an appropriate and authorized source, and check that certificate requests are accurate, authorized, and complete. The standard also allows evidence of identity to be provided by a subcontracted person, provided that the identity check was performed in line with the clause 6.2.2 requirements.

- 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.

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Defines Registration Authority responsibilities and supports the answer that delegated identity evidence must still satisfy clause 6.2.2 validation requirements.
- [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the point that subcontracting or outsourcing does not remove the TSP's overall responsibility for policy conformance.

## What controls should cover an external RA?

External registration authorities should be treated as controlled trust-service participants, not just intake vendors. 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 registration and revocation officers, and other trusted roles involved in RA work, to be appointed, trained, screened where applicable, and separated from prohibited self-validation scenarios.

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the secure-registration-data exchange requirement for external registration service providers and the trusted-role expectations for registration work.
- [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports documented third-party agreements, supplier obligations, subcontractor competence, and TSP responsibility for outsourced service components.

## 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. EN 319 411-1 requires specified records to be retained for at least seven years after any certificate based on those records ceases to be valid, and its RA termination clause calls out 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.

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the specific RA-delegation audit evidence: registration logging, submitting RA identification, records archival, and CA/RA termination handling.
- [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports retaining supplier-relationship evidence because the TSP remains responsible for conformance when third parties provide parts of the service.

## Primary sources

- [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Primary ETSI source for RA definitions, identity validation, external registration service provider controls, registration logging, records archival, and CA/RA termination requirements.
  - Quote: "Registration Authority (RA): entity that is responsible for identification and authentication"
- [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary ETSI source for TSP responsibility, third-party agreements, subcontractor competence, and trusted-role controls that apply when RA work is outsourced.
  - Quote: "provide parts of its service through subcontracting"

## Topic Guides

- [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md): Understand how ETSI EN 319 411-1 separates Certificate Policy from Certification Practice Statement work for certification authorities and trust service providers.
- [EN 319 411-1 vs EN 319 411-2 Certificate Policy](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-en-319-411-2.md): Compare ETSI EN 319 411-1 general certificate-service requirements with EN 319 411-2 EU qualified certificate requirements, including policy scope, CP/CPS evidence, and audit boundaries.
- [ETSI EN 319 411-1 Audit File Evidence](/artifacts/global/etsi-en-319-411-1/audit-file-evidence.md): 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](/artifacts/global/etsi-en-319-411-1/ca-key-management.md): 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](/artifacts/global/etsi-en-319-411-1/certificate-lifecycle-workflow.md): 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 certificate re-key FAQ](/artifacts/global/etsi-en-319-411-1/faq/re-key.md): 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](/artifacts/global/etsi-en-319-411-1/faq/suspension.md): 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](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md): 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.
- [ETSI EN 319 411-1 Compliance Guide](/artifacts/global/etsi-en-319-411-1/compliance.md): 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](/artifacts/global/etsi-en-319-411-1/cp-and-cps-template.md): 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](/artifacts/global/etsi-en-319-411-1/faq.md): 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](/artifacts/global/etsi-en-319-411-1/identity-validation.md): 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](/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/ra-delegation.md): 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](/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/requirements.md): 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](/artifacts/global/etsi-en-319-411-1/revocation-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations.md): Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, 24-hour CRL or OCSP publication controls, and audit evidence.
- [ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-ca-browser-forum-baseline-requirements.md): Compare how EN 319 411-1 incorporates CA/B Forum BRG concepts for DVCP, OVCP, IVCP, [WEB] requirements, CPS disclosure, domain validation, and conflict handling.
- [How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md): What ETSI EN 319 411-1 expects CAs to evidence for certificate revocation requests, status publication, CRL or OCSP updates, and archived revocation records.
- [Subscriber agreements under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md): 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](/artifacts/global/etsi-en-319-411-1/faq/subscriber-identity-validation.md): How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records.

*Recommended next step*

*Placement: after RA delegation evidence*

## Map RA delegation to ETSI EN 319 411-1 evidence

Use this FAQ to align CP/CPS wording, RA agreements, registration records, and audit evidence before relying on delegated registration work.

- [Review RA controls](/solutions/assessment.md): Convert delegated registration work into control owners, evidence requests, and audit-ready checkpoints.
- [Resolve source questions](/solutions/research-copilot.md): Check ambiguous RA scope, CP/CPS wording, or registration evidence against cited ETSI requirements.
- [Talk through implementation](/contact.md): Review delegated RA scope, provider agreements, registration records, and termination evidence with Sorena.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq/ra-delegation