A focused guide for certificate authorities and trust service providers that use internal or external registration authority support.
Grounded in ETSI EN 319 411-1 and ETSI EN 319 401 source text. Use it as implementation guidance, not for legal interpretation.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this page to define what a Registration Authority may do for a certificate authority, what the trust service provider must still control, and what evidence should exist before delegated registration work is relied on for certificate issuance or revocation.
ETSI EN 319 411-1 defines a Registration Authority as the entity mainly responsible for identifying and authenticating certificate subjects, and notes that an RA can assist in the certificate application process, the revocation process, or both. The first control decision is therefore not whether delegation is allowed in the abstract; it is which registration tasks are in scope and which certificate policies they support.
Document the boundary in the CP/CPS or supporting operating procedures. Separate identity proofing, certificate application intake, authorization checks, registration-data submission, revocation request handling, and evidence retention so a reviewer can see which activities are performed by the CA, by an internal RA, or by an external registration service provider.
When an external registration service provider is used, EN 319 411-1 requires registration data to be exchanged securely and only with recognized providers whose identity is authenticated. The standard also points external RAs back to general TSP security requirements for human resources, operational security, networks, and privacy.
ETSI EN 319 401 gives the governance layer for that arrangement: where parts of the trust service are supplied through subcontracting, outsourcing, or other third-party arrangements, the TSP maintains overall responsibility, defines outsourcer liability, and keeps a documented contractual relationship that makes both parties' security obligations clear.
Use this ETSI EN 319 411-1 guide to align CP/CPS wording, RA agreements, registration records, and audit evidence before relying on delegated registration work.
Convert RA delegation into control owners, evidence requests, and audit-ready checkpoints.
Check ambiguous RA scope, CP/CPS wording, or registration evidence against cited ETSI requirements.
Review delegated RA scope, provider agreements, registration records, and termination evidence with Sorena.
Delegated RA work must still support the identity validation requirements behind the certificate. EN 319 411-1 requires the TSP to verify the identity of the subscriber and subject and to collect and validate direct evidence or an attestation from an appropriate and authorized source for the identity and relevant attributes.
For registration records, the audit trail should show what evidence was presented, how documents or attestations were validated, who accepted the application, where application and subscriber-agreement records are stored, and the receiving TSP or submitting RA when applicable. That makes the delegated chain reconstructable without relying on undocumented RA judgment.
RA delegation should be reviewed whenever the delegated role, provider, certificate profile, validation source, secure exchange method, or CP/CPS wording changes. EN 319 411-1 also highlights trusted roles for registration and revocation officers, so the delegation model should show who is authorized to perform registration and revocation work and how incompatible duties are controlled.
Termination is a separate trigger. If a CA or RA relationship ends, the evidence plan should preserve registration information, revocation status information, and event log archives for the periods communicated to subscribers and relying parties. EN 319 401 also requires authorization of subcontractors to be terminated before the TSP terminates services.
"terminate authorization of all subcontractors"
"registration and revocation officers"