--- title: "ETSI EN 319 411-1 certificate lifecycle workflow" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/certificate-lifecycle-workflow" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/certificate-lifecycle-workflow" author: "Sorena AI" description: "Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1" - "certificate lifecycle" - "certificate issuance" - "certificate revocation" - "certificate status" - "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 certificate lifecycle workflow Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records. *Artifact Guide* *GLOBAL* *ETSI EN 319 411-1* ## ETSI EN 319 411-1 certificate lifecycle workflow A certificate-service workflow for registration, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and records. Use it to align CP/CPS commitments with operational evidence. It does not supersede the ETSI standard or a conformity assessment. ETSI EN 319 411-1 organizes public-key certificate services around registration, certificate generation, dissemination, revocation management, revocation status, and optional subject-device provisioning. This workflow turns those service components into operating gates a certification authority can use before issuing, changing, renewing, re-keying, suspending, or revoking certificates. ## Define the certificate service boundary before accepting applications Start the workflow by naming the certificate policy profile, CPS version, certificate profile, registration channel, CA or RA boundary, repository location, revocation-status method, and assessment period. EN 319 411-1 treats registration, generation, dissemination, revocation management, and status services as distinct service components, so the evidence file should not blur those responsibilities. The intake record should also state whether the subscriber and subject are the same entity, whether the subject is a natural person, legal person, device, or system, and whether the subscriber is authorized to act for the subject. Those choices affect identity validation, agreement records, certificate publication consent, and later revocation or modification handling. - Record the applicable CP profile or custom CP, the policy OID, certificate profile, CPS version, and any web-certificate dependency that sits outside the ETSI PDF. - Identify the service components in scope: registration, certificate generation, dissemination, revocation management, revocation status, repository, and subject-device provisioning if used. - Name the operational owner for each component, including any external RA or subcontracted service whose records feed certificate issuance. - Keep confidential procedure names out of public copy when needed, but preserve enough evidence for an assessor to trace each lifecycle event to the CP and CPS. 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) - Grounds the certification-service components, CP/CPS model, subscriber-subject relationship, and lifecycle clauses used in this workflow. - [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) - Grounds the general TSP policy baseline and practice-statement context that EN 319 411-1 builds on. ## Gate 1: certificate application and registration evidence No certificate should enter issuance until the registration file supports the request. EN 319 411-1 expects subscriber and subject identity validation, current assessment of the attributes that will appear in the certificate, an applicable identity-proofing process under the CPS, and proof that the subscriber authorized issuance where the subscriber and subject differ. If the subject key pair is not generated by the CA, the application process should provide reasonable assurance that the subject has possession or control of the private key associated with the public key presented for certification. When an external registration service provider is used, the registration data exchange should be secure and limited to recognized, authenticated registration service providers. - Application record: subscriber, subject, subject category, certificate profile, requested names and attributes, requested validity, and issuance authorization. - Validation record: identity evidence or attestation, method used, who accepted the application, applicable CPS identity-proofing process, and any expiry on reusable validation. - Key record: proof-of-possession or control when the key is not generated by the CA, or CA-generated subject-key handling evidence when the CA creates the key. - RA handoff record: authenticated RA identity, secure transmission evidence, registration data received, and any exception or rejection reason. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1, clauses 6.2.2, 6.3.1, and 6.3.2](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the registration, certificate application, application-processing, authorization, proof-of-possession, and external RA handoff steps. *Recommended next step* *Placement: after practical guidance* ## Operationalize certificate lifecycle controls Use this EN 319 411-1 workflow to assign application, issuance, renewal, re-key, modification, revocation, status-service, and archival evidence. - [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert certificate lifecycle controls into owned evidence requests and review milestones. - [Research ETSI EN 319 411-1 source questions](/solutions/research-copilot.md): Use cited ETSI source material to resolve lifecycle, revocation, status-service, and archival questions before implementation. - [Talk through certificate lifecycle evidence](/contact.md): Review certificate lifecycle scope, CP/CPS evidence, status-service records, and next actions with Sorena. ## Gate 2: issuance, dissemination, and certificate acceptance The issuance gate links the approved registration file to the generated certificate. EN 319 411-1 requires secure certificate issuance to maintain certificate authenticity, measures against forgery, secure handling where the CA generates subject keys, and checks against certificates whose lifetime exceeds the CA signing certificate unless status verification remains possible. After issuance, the workflow should prove that the complete and accurate certificate is available to the subscriber or subject, that relying-party terms and conditions are available and identifiable for the certificate, and that acceptance is supported by durable, human-readable terms and recorded agreement evidence. - Issuance approval: link certificate serial number, subject distinguished name, public key, CP identifier, certificate profile, issuing CA, and registration evidence. - Generation evidence: CA signing event, anti-forgery controls, serial-number handling where applicable, CA-generated subject-key confidentiality, and certificate-profile checks. - Dissemination evidence: delivery to subscriber or subject, repository publication when consent and policy allow it, and availability of terms and conditions to relying parties. - Acceptance evidence: durable terms, explicit acceptance by a traceable action, subscriber agreement, subject agreement where required, and publication-consent choice. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1, clauses 6.1, 6.3.3, and 6.3.4](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the issuance, certificate availability, relying-party terms, acceptance, durable communication, and agreement-record requirements. ## Gate 3: renewal, re-key, and modification changes Renewal, re-key, and modification are separate lifecycle actions. Renewal keeps the subject public key and certificate information unchanged except for the serial number and possible expiry update. Re-key issues a certificate with a new subject public key and may update subject attributes. Modification issues a new certificate because certificate information changes while the key remains the same. For each change path, the workflow should reopen the relevant application and processing checks instead of copying the previous certificate blindly. The file should show whether prior validation information may still be reused under the CPS, whether certified names or attributes changed, whether terms and conditions changed, and whether the previous certificate was used to authenticate the request. - Renewal check: confirm the key did not change, the previous certificate exists and is valid when used for authentication, and the public key remains cryptographically sufficient for the new validity period. - Re-key check: collect the new public key, repeat the applicable application and processing requirements, and verify any changed names or attributes against registration evidence. - Modification check: identify the changed certificate information, verify related registration evidence, and confirm the subject key remains the same. - Terms check: communicate changed terms and conditions to the subscriber and record the new agreement before completing the lifecycle action. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1, clauses 6.3.6 to 6.3.8](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the distinct renewal, re-key, and modification pathways and their reuse, validation, previous-certificate, and changed-terms checks. ## Gate 4: revocation, suspension, and certificate status services The revocation branch starts when a revocation or suspension request, problem report, key compromise, certificate-content change, policy non-compliance, or cryptographic weakness affects a non-expired certificate. EN 319 411-1 requires authorized and validated revocation handling, timely status changes, and a maximum 24-hour delay between receiving a revocation or suspension request and making the changed status information available to relying parties. Status-service evidence should cover both the decision and the public signal. Revocation status information must be available continuously, protected for integrity and authenticity, include status at least until certificate expiry, support OCSP or CRL, and be publicly and internationally available. If both CRL and OCSP are supported, updates should be available for both methods and differences caused by update delays should be explained in the CPS. - Request intake: authenticated requester or authorized source, certificate identifier, reason, receipt time, future-date instruction if applicable, and confirmation status. - Decision record: validation result, revocation or suspension outcome, responsible revocation officer or process owner, subject/subscriber notification attempt, and exception procedure if confirmation cannot happen within 24 hours. - Status publication: CRL or OCSP update evidence, 24/7 availability monitoring, integrity and authenticity controls, public international reachability, and consistency checks across supported methods. - Irreversibility check: once a certificate is definitively revoked rather than suspended, keep the workflow from reinstating it. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1, clauses 6.2.4, 6.3.9, and 6.3.10](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the revocation and suspension request timing, revocation reasons, definitive-revocation rule, CRL/OCSP handling, and status-service availability controls. ## Workflow evidence file for each certificate lifecycle event Close each lifecycle event with an evidence file that can be reconstructed later. EN 319 411-1 calls for logging registration events, certificate generation and dissemination events, certificate lifecycle events, CA-managed key lifecycle events, revocation requests and reports, and subject-device preparation events where NCP+ applies. For archival, the standard requires retaining named records for at least seven years after any certificate based on those records ceases to be valid. The workflow should therefore capture not only the event result, but also the archive location, retention basis, access control, privacy protection for subject information, and handover treatment under the termination plan. - Lifecycle event header: certificate identifier, event type, CP/CPS version, service component, responsible role, timestamps, and source requirement reference. - Input evidence: registration file, subscriber or subject agreement, certificate request, prior certificate, key evidence, revocation request, problem report, or status-service record. - Decision evidence: approval, rejection, issuance, renewal, re-key, modification, suspension, revocation, publication, exception, or termination-path decision. - Archive evidence: log location, record owner, retention period, privacy protection, access method, and termination-plan handover classification. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1, clauses 6.4.5 and 6.4.6](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the lifecycle logging, registration-record, revocation-record, certificate-generation, dissemination, CA-key, subject-device, and seven-year archival evidence requirements. - [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 TSP evidence-retention and practice-statement context used for lifecycle audit records. ## 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 the page's certificate lifecycle workflow: registration, application, issuance, dissemination, acceptance, renewal, re-key, modification, revocation, suspension, status services, logging, and archival records. - Quote: "Certificate Life-Cycle operational requirements" - [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 TSP policy, practice-statement, and evidence-retention context referenced by EN 319 411-1. - 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 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 Identity Validation Evidence Workflow](/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow.md): A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls. - [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/certificate-lifecycle-workflow