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.
Structured answer sets in this page tree.
Cited legal and guidance references.
Approve an RA path only when the TSP can show who may perform each registration task, which policies and subject types they may handle, how their identity is authenticated, how data reaches issuance securely, and how the TSP monitors the arrangement. Under ETSI EN 319 411-1 V1.5.1 (2025-04), using a , registration officer, subcontractor, or external registration service provider does not transfer the TSP's overall responsibility.
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 says the TSP maintains overall responsibility when other parties provide certification-service components. Current EN 319 401 requires documented agreements for subcontracting, outsourcing, and other third-party arrangements, and requires planned monitoring of supplier cybersecurity practices at least annually and after a related incident.
This ETSI EN 319 411-1 workflow helps connect delegated registration work to CPS clauses, authorized RA roles, secure data exchange, certificate issuance controls, and audit-ready records.
Convert delegated registration controls into accountable tasks, evidence requests, and review gates.
Use cited ETSI source material to resolve RA scope, CPS coverage, and evidence questions before implementation.
Review delegated RA scope, control gaps, cited requirements, and next compliance actions with Sorena.
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.
Run the review at onboarding, before adding a certificate policy or profile to an existing RA, after material process changes, before relying on registration evidence from a new system integration, and on the supplier-review schedule. EN 319 401 V3.2.1 requires supplier cybersecurity-practice review at planned intervals, at least annually, and after a related incident. Keep an approved review record that names the responsible role and the evidence used for the decision.
Use the following operating table in planning documents: Step | Owner | Evidence | Decision.
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.
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.
A delegated path fails the traceability test when the CA cannot show that the partner was recognized, authorized, bound to the applicable practices, and connected to the specific certificate action.
"overall responsibility"
"Registration Authority"