ETSI EN 319 411-1 Identity Validation Evidence Workflow

First classify the subject as a natural person, a natural person linked to a legal person, a legal person or associated organizational entity, or a device or system operated by a natural or legal person. ETSI EN 319 411-1 changes the evidence questions by subject type, certificate policy, and marked condition. Physical-presence or equivalent-assurance checks are NCP conditions for specified subject routes, while website domain and IP information follows the referenced CA/Browser Forum methods.

Create one intake record per certificate request. The record should name the subscriber, the subject, the certificate policy profile, the registration route, the registration officer or RA accepting the application, and whether the subscriber is acting for the subject.

Use a routing table before the RA or CA approves the request. A natural person evidence pack should not be treated like an organization or device evidence pack, and domain or IP verification for web certificates has its own referenced verification methods.

The workflow should capture why each evidence route was selected. That matters when a reviewer asks whether physical presence, equivalent-assurance remote proofing, organizational registration data, legal-person representation, device identifiers, or domain/IP checks were the right evidence class for the certificate.

Identity evidence is incomplete until it is securely and unambiguously linked to the certificate request and resulting issuance. ETSI EN 319 411-1 requires the TSP to check that the request is accurate, authorized, and complete against the collected evidence or identity attestation.

The workflow should therefore make the approval reviewer compare the requested subject name, attributes, public key, policy profile, and subscriber authorization with the registration evidence before issuance. If the certificate is issued after an earlier validation, the CP/CPS needs to state how long and under what conditions that validation may still be reused.

The evidence pack should separate the data used for identity proofing from the long-term audit record. ETSI EN 319 411-1 says the TSP does not need to archive every item collected during registration over the long term when a reference to the documentation used is enough for the record and applicable law.

For each registration, keep a structured record that lets an auditor reconstruct what evidence was used, who accepted the application, where supporting files are stored, and how the validation method was applied.

Identity validation evidence must remain usable after issuance, but clause 6.4.6 does not impose a blanket seven-year minimum on every registration item. It applies that minimum to CA-managed key lifecycle records and the agreement documentation identified in clause 6.3.4. Registration events and information still need documented retention, accessibility, privacy, and handover treatment under clauses 6.4.5 and 6.4.9 and the general EN 319 401 evidence rules.

Before closing the workflow, state the retention period and its legal, policy, scheme, or contractual basis; identify the event that starts the period; and verify the practice statement, terms, archive location, access method, privacy controls, and termination-plan handoff. Do not default every record to certificate expiry plus seven years unless that rule or another controlling source applies.

This table is the operating sequence for a registration evidence pack.

1 | Intake | Registration officer or RA | Subscriber, subject, certificate policy profile, subject type, and subscriber authorization question | Can this request enter the selected validation route?

2 | Evidence collection | Registration officer or trusted registration service | Direct evidence or authorized attestation, subject attributes, organization or device evidence, domain/IP evidence where applicable | Does the evidence class match the subject type?

3 | Request check | CA or authorized approval role | Certificate request, public key proof where needed, registration record, and CP/CPS reuse limits | Is the request accurate, authorized, complete, and current?

4 | Record creation | Evidence owner | Document references, validation method, accepting entity, subscriber-agreement choices, storage location, and RA/TSP handoff records | Can an auditor reconstruct the validation without hidden context?

5 | Retention and handoff | Compliance or audit owner | Retention clock, practice statement wording, confidentiality controls, and termination-plan coverage | Will the evidence remain available for the required archival period?