--- title: "ETSI EN 319 411-1 RA Delegation Review Workflow" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1" - "registration authority delegation" - "registration service provider" - "CPS" - "trust service audit" - "registration authority" - "registration service" - "audit evidence" --- **[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) --- # 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. *Artifact Guide* *GLOBAL* *ETSI EN 319 411-1* ## ETSI EN 319 411-1 RA Delegation Review Workflow A review workflow for certificate authorities that use internal or external registration authorities to collect, validate, and pass registration evidence into certificate issuance. Use it to check CPS coverage, recognized registration service providers, authenticated data exchange, retained TSP responsibility, and audit records before delegated RA activity feeds certificate issuance. Use this workflow when a trust service provider relies on a registration authority, registration officer, subcontractor, or external registration service provider to perform identity validation or certificate-application intake under ETSI EN 319 411-1. The goal is not to rubber-stamp the delegation; it is to prove that registration work remains controlled by the TSP's CP/CPS, uses authorized sources, protects registration data, and leaves enough evidence for certificate issuance, renewal, re-key, modification, revocation, and audit review. ## Set the RA delegation boundary before reviewing evidence Start by naming the registration work that is delegated. ETSI EN 319 411-1 describes the registration service as the component that verifies the identity and, where applicable, specific attributes of a certificate subject, then passes the results to certificate generation. That makes the boundary narrower than a general vendor review: it should cover who collects identity evidence, who validates attributes, who authenticates the certificate request source, who transmits registration data, and who can approve reuse of prior validation. Keep the CA/TSP accountability explicit. EN 319 411-1 notes that the TSP remains responsible for conformance even when functionality is performed by outsourcers, and EN 319 401 requires overall responsibility and documented agreements when parts of the trust service are provided through subcontracting, outsourcing, or other third-party arrangements. - List each RA actor: internal registration officer, affiliate office, reseller intake team, outsourced registration service provider, or other delegated party. - Map each actor to the exact certificate policies, certificate profiles, subscriber types, subject types, and issuance paths they can support. - Record what the delegated party may do and what remains with the CA: identity evidence collection, attribute checks, request authentication, approval, certificate generation, revocation intake, or records archival. - Block delegation where the party is not recognized by the TSP, its identity is not authenticated for data exchange, or the CP/CPS does not describe the practice. 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 the registration service, explains its relationship to certificate generation, and states that TSP responsibility continues when outsourced functions are used. - [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 retained-responsibility and documented third-party agreement checks for outsourced or subcontracted trust-service components. *Recommended next step* *Placement: after practical guidance* ## Operationalize RA delegation review Use this ETSI EN 319 411-1 workflow to connect delegated registration work to CPS clauses, authorized RA roles, secure data exchange, certificate issuance controls, and audit-ready records. - [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert delegated registration controls into accountable tasks, evidence requests, and review gates. - [Research ETSI EN 319 411-1 source questions](/solutions/research-copilot.md): Use cited ETSI source material to resolve RA scope, CPS coverage, and evidence questions before implementation. - [Talk through ETSI EN 319 411-1 RA delegation](/contact.md): Review delegated RA scope, control gaps, source support, and next compliance actions with Sorena. ## RA delegation intake questions Use these questions before allowing a delegated RA path to feed certificate issuance. They turn EN 319 411-1 registration, application-processing, audit-logging, and CPS requirements into a review that an audit owner can repeat. Treat any unclear answer as a hold on delegated issuance until the CP/CPS, agreement, operating procedure, or evidence record is corrected. A delegated RA path should not depend on undocumented custom handling by a local office or partner. - Is the delegated party inside the TSP, an external registration authority, a subcontracted identity checker, or another trust-service component provider? - Does the CPS identify how the TSP operates the service, and does it cover the delegated registration practice or reference controlled internal procedures that auditors can review? - For natural persons, legal persons, organization-associated subjects, devices, or systems, which clause 6.2.2 evidence is collected and who checks it? - How does the RA prove the certificate request is accurate, authorized, complete, and tied to the collected identity evidence or attestation? - If registration data crosses organizational or system boundaries, how is it exchanged securely and only with recognized, authenticated registration service providers? - What logs prove the application was received, accepted, validated, transmitted, and acted on by authorized personnel? 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) - Grounds the intake checks in CPS requirements, identity-validation records, certificate application processing, external registration authority controls, and registration event logging. - [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) - Provides the general policy basis for communicating policies to external parties and identifying obligations of external organizations supporting the TSP service. ## Workflow: approve or reject an RA delegation path Run the review at onboarding, before adding a certificate policy or profile to an existing RA, after material process changes, and before relying on registration evidence from a new system integration. The output should be a signed review record, not just an email approval. Use the following operating table in planning documents: Step | Owner | Evidence | Decision. - 1 | CPS owner | CP/CPS section, delegated RA procedure, policy OIDs and certificate profiles in scope | Does the public and internal documentation describe the delegated registration practice? - 2 | RA operations owner | RA roster, role authorization, training records, authentication method, and agreement or internal appointment | Is this party recognized and authorized to submit registration data? - 3 | Identity-validation owner | Clause 6.2.2 evidence map by subject type, attestation rules, data-protection note, and capture-minimization rationale | Is the identity evidence sufficient for the certificate's intended use without collecting unsupported excess data? - 4 | Issuance control owner | Application-processing procedure, request authentication evidence, secure data-exchange control, and exception path | Can certificate issuance be securely and unambiguously linked to the associated registration? - 5 | Audit owner | Registration event logs, application records, identity of accepting entity, submitting RA name where applicable, and archival access procedure | Can an assessor reconstruct what the RA checked, who accepted it, and which certificate action used it? 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 workflow rows for CPS content, identity evidence, application processing, secure links to registration, and registration audit records. - [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 review of subcontracting, outsourcing, third-party arrangements, obligations, and required controls for parties used by the TSP. ## Evidence pack for delegated RA review The evidence pack should show both control design and operating evidence. Design evidence proves the delegated RA path is allowed and controlled; operating evidence proves a specific certificate action used the path correctly. Avoid vague artifacts such as a vendor security summary with no certificate-policy boundary. The useful records are the ones that connect a delegated RA, a subject type, an identity-validation method, a certificate request, and the CA action that followed. - CPS or controlled procedure describing the RA's registration duties, certificate policies supported, accepted evidence, authentication method, and escalation rules. - Documented agreement, appointment, or internal authorization binding the RA or outsourced party to the TSP's applicable policies, practices, and controls. - Registration evidence record showing identity or attribute evidence, attestation source where used, reference numbers or limitations, and why the evidence was sufficient for the intended certificate use. - Secure exchange evidence showing registration data moved only with recognized registration service providers whose identity was authenticated. - Application-processing record showing the request was accurate, authorized, complete, and securely linked to the registration before certificate issuance, renewal, re-key, or modification. - Audit log and archive access record showing registration events, request handling, identity of the accepting entity, and submitting RA name where applicable. 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) - Provides the concrete evidence expectations for identity validation, application processing, registration data exchange, registration logging, and records archival. - [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 evidence of third-party obligations, subcontractor controls, personnel competence, and return or termination procedures for external parties. ## Escalation and rejection criteria Escalate the delegation review when the RA path changes the assurance of identity validation, introduces a new data exchange channel, expands to a new certificate profile, or relies on a party not covered by the existing CPS and agreements. Reject or pause delegated RA use when the missing control affects the CA's ability to prove that registration data is trustworthy. A compensating note is not enough if the RA cannot be authenticated, the request cannot be linked to registration evidence, or the log trail cannot identify who accepted the application. - Reject: the RA is not a recognized registration service provider, or its identity is not authenticated before registration data is exchanged. - Reject: the CP/CPS does not cover the delegated practice, the certificate profile, or the allowed reuse window for identity validation. - Reject: the RA cannot show evidence that certificate requests are accurate, authorized, and complete according to collected identity evidence or attestation. - Escalate: the RA changes identity-proofing methods, evidence sources, system interfaces, subject types, subscriber authorization checks, or data-retention practices. - Escalate: termination of an RA path could affect registration information, revocation status information, event log archives, or unexpired certificates. 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 rejection criteria tied to recognized registration service providers, request accuracy, CPS consistency, registration information, and CA or RA termination. - [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 escalation for third-party changes, termination, and obligations of external organizations supporting the TSP service. ## Common RA delegation review mistakes Most RA delegation failures are traceability failures. The audit problem is usually not that a partner helped with registration; it is that the CA cannot show the partner was recognized, authorized, bound to the right practices, and connected to the specific certificate action. - Treating an RA as a generic supplier while ignoring whether EN 319 411-1 registration, application-processing, logging, privacy, and termination clauses apply to the delegated work. - Approving a reseller or local office without mapping exactly which subject types, certificate profiles, and validation methods it may use. - Letting registration data move through email, portals, or batch files without authenticated provider identity and secure exchange controls. - Keeping identity proofing evidence but omitting the certificate request, subscriber authorization, accepting entity, or submitting RA name needed to reconstruct the issuance path. - Assuming outsourcing transfers accountability away from the TSP, despite the EN 319 411-1 and EN 319 401 retained-responsibility requirements. 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) - Grounds the mistake list in the standard's RA definition, external registration authority controls, registration logging, and TSP responsibility for outsourced functionality. - [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) - Grounds the mistake list in EN 319 401 requirements for external organizations, subcontractor competence, documented agreements, and overall TSP responsibility. ## 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 source for registration service responsibilities, initial identity validation, certificate application processing, external registration service providers, registration records, CA/RA termination, and retained TSP responsibility. - Quote: "Policy and security requirements for Trust Service Providers issuing certificates" - [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 source for general TSP policy, external-organization obligations, subcontractor competence, documented third-party agreements, and responsibility for outsourced trust-service components. - Quote: "General Policy Requirements for Trust Service Providers" ## Related 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 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. - [RA delegation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md): 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](/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. --- [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/ra-delegation-review-workflow