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.
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.
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.
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.
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, source support, 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, 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.
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.
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.
"overall responsibility"
"Registration Authority"