--- title: "ETSI EN 319 411-1 Identity Validation Evidence Workflow" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow" author: "Sorena AI" description: "A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1 identity validation" - "registration evidence" - "subscriber validation" - "certificate request evidence" - "RA evidence" - "ETSI EN 319 411-1" - "identity validation" - "subscriber evidence" - "certificate policy" - "CPS" --- **[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 Identity Validation Evidence Workflow A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls. *Evidence Workflow* *GLOBAL* *ETSI EN 319 411-1* ## ETSI EN 319 411-1 Identity Validation Evidence Workflow Build a registration evidence pack that shows how the TSP verified the subscriber, subject, attributes, authorizations, certificate request, and retention trail. Focused on ETSI EN 319 411-1 clauses for initial identity validation, certificate application, registration logging, archival, and RA handoff evidence. Use this workflow when a trust service provider needs a reviewable evidence trail for ETSI EN 319 411-1 identity validation. The page turns the standard's registration requirements into checkpoints for evidence intake, subject-type routing, certificate request approval, RA data exchange, and audit retention. ## Start with the subscriber, subject, and certificate policy The first evidence decision is not which document to upload. It is whether the certificate request is for a natural person, a natural person linked to a legal person, a legal person or organizational entity, or a device or system operated by one of those parties. ETSI EN 319 411-1 changes the evidence questions depending on that subject type and the applicable certificate policy. 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. - For every request, verify the identity of both the subscriber and the subject before the certificate is issued. - Collect either direct evidence or an attestation from an appropriate and authorized source for the subject identity and any certificate attributes. - When the subscriber and subject differ, keep evidence that the subscriber is authorized to act for the subject. - Do not let the registration officer who verifies identity be the natural person to whom the certificate is issued. 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 subscriber and subject identity validation requirements in clause 6.2.2, including evidence collection, authorization where subscriber and subject differ, and registration officer separation. ## Route evidence by subject type before approval 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. - Natural person: keep name evidence plus date/place of birth, a recognized identity document reference, or other distinguishing attributes. - Natural person associated with a legal person: add legal-person identity, registration information, affiliation evidence, and approval that the attributes identify the organization. - Legal person or organizational entity: keep full organizational name and, where applicable, evidence of the relationship to any related organization named in the certificate. - Device or system: keep the device identifier, relevant organization evidence, distinguishing organizational attributes, and any applicable domain or IP validation trail. 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 subject-type evidence routing in clause 6.2.2 for natural persons, legal persons, persons associated with legal persons, devices, and web domain/IP verification. ## Match the certificate request to the collected evidence Identity validation evidence is incomplete until it is linked to the certificate request. ETSI EN 319 411-1 requires the TSP to check that certificate requests are 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. - Confirm the subscriber was registered and the subscriber and subject identity were validated under clause 6.2.2 before initial issuance, renewal, re-key, or modification. - Assess whether the subject attributes are still correct at issuance time, especially when validation occurred earlier. - For externally generated key pairs, keep proof that the requester has possession or control of the private key associated with the public key. - If an external registration service provider is used, keep authenticated RA identity and secure registration-data exchange evidence. 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 certificate application and processing checkpoints in clauses 6.3.1 and 6.3.2, including reuse of prior validation, request completeness, proof of possession or control, and external registration service handling. ## Record the minimum audit trail for registration evidence 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. - Record the type of documents presented, unique identification data or document numbers where applicable, and the storage location of applications and identification documents. - Record subscriber-agreement choices, including consent choices relevant to publication or records. - Record the identity of the entity accepting the application and the name of the receiving TSP or submitting RA where applicable. - Document how recorded registration information is accessible, while maintaining the privacy of subject information. 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 registration logging and record contents in clause 6.4.5, and the identity-record requirement in REG-6.2.2-18. *Recommended next step* *Placement: after identity validation workflow* ## Operationalize ETSI EN 319 411-1 identity validation Use the workflow to assign registration evidence owners, close subscriber-subject gaps, and prepare a traceable evidence pack for audit or customer review. - [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert identity validation clauses into accountable tasks, evidence requests, and audit checkpoints. - [Research ETSI EN 319 411-1 evidence questions](/solutions/research-copilot.md): Use cited ETSI source material to resolve registration, subscriber, RA, and retention questions before implementation. - [Talk through identity validation evidence](/contact.md): Review the registration evidence route, CP/CPS assumptions, and audit handoff with Sorena. ## Retention, termination, and handoff checks Identity validation evidence must remain usable after certificate issuance. ETSI EN 319 411-1 requires archival of defined records for at least seven years after any certificate based on those records ceases to be valid, and termination planning must cover registration information, revocation status information, and event log archives. Before closing the workflow, verify the retention clock, the practice statement wording, the subscriber-facing disclosure, and the termination-plan handoff for registration records. This prevents a clean validation event from becoming unusable evidence later. - Set retention from the certificate validity end, not from the date of registration intake. - Document the retention period in practice statements and indicate which information is handed over through the termination plan. - Preserve registration information, subscriber agreement documentation, and event log archives according to the clauses cited in the CP/CPS. - Confirm that registration data confidentiality and integrity are protected when exchanged with subscribers, subjects, RAs, or distributed TSP components. 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 archival, retention, termination handoff, and registration-data confidentiality checks in clauses 6.4.5, 6.4.6, 6.4.9, and 6.8.4. - [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 general trust service provider control context that ETSI EN 319 411-1 incorporates for security management, termination, and confidentiality controls. ## Workflow table for identity validation evidence Use this table as 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? - Keep each workflow row tied to a clause reference or CP/CPS section so reviewers know why the evidence exists. - Store exceptions as explicit nonconformance or risk records; do not bury them in notes attached to the applicant file. - Re-open the workflow when certificate attributes change, the validation method is no longer allowed by the CPS, or a renewal, re-key, or modification relies on earlier identity validation. 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 end-to-end workflow across initial identity validation, certificate application, certificate application processing, registration logging, and records archival. ## 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 identity validation, certificate application, registration logging, archival, RA handoff, and subscriber-subject evidence requirements in ETSI EN 319 411-1. - 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) - General ETSI trust service provider policy source incorporated by ETSI EN 319 411-1 for security management, confidentiality, and termination context. - 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 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 RA Delegation Review Workflow](/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow.md): 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. - [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/identity-validation-evidence-workflow