WorkflowGLOBALETSI EN 319 411-2

ETSI EN 319 411-2 Qualified certificate lifecycle workflow

A lifecycle workflow for EU qualified certificate services covering policy profile selection, identity validation, issuance, certificate changes, revocation, status services, and records.

Grounded in ETSI EN 319 411-2, ETSI EN 319 411-1, and eIDAS source material. Use it for implementation planning, not for legal interpretation.

Author
Sorena AI
Published
May 9, 2026
Updated
May 27, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
15

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 27, 2026
Overview

Use this workflow when a trust service provider needs to turn an ETSI EN 319 411-2 qualified certificate policy into day-to-day lifecycle controls. The page follows the certificate from intake through issuance, change, revocation, status publication, disclosure, and archival evidence, while keeping EN 319 411-2's own caveat visible: conformance to the standard alone does not make the TSP or its certificates qualified under eIDAS.

Section 1

Start the lifecycle with the exact qualified certificate policy

The first workflow gate is not a generic compliance intake. It is a certificate-policy decision: identify whether the service is issuing qualified certificates to natural persons, legal persons, or website-authentication subscribers, and whether the claim depends on a QSCD.

Record the selected policy profile before registration work begins. EN 319 411-2 names QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, and QNCP-w-gen, and links each route to inherited Part 1 requirements such as NCP, NCP+, EVCP, OVCP, IVCP, DVCP, and WEB-tagged controls. This selection determines the identity checks, certificate profile, QSCD evidence, browser-forum dependencies, relying-party notice, and lifecycle records that follow.

  • Choose QCP-n for an EU qualified certificate issued to a natural person and QCP-l for one issued to a legal person.
  • Use QCP-n-qscd or QCP-l-qscd only when the private key and related certificate reside on a QSCD and the lifecycle includes QSCD verification and status monitoring.
  • Use QEVCP-w, QNCP-w, or QNCP-w-gen for qualified website authentication certificates, then capture the applicable EVCP, BRG, OVCP, IVCP, NCP, or WEB-tagged dependencies.
  • Keep the policy identifier, CP/CPS version, subscriber type, subject type, certificate usage, and eIDAS qualification basis in the same intake record.
Section 2

Registration and certificate application workflow

Registration evidence should be collected before the CA signs anything. EN 319 411-2 points qualified-certificate identity validation to the person type: natural-person identity for QCP-n routes, legal-person identity and authorized representative evidence for QCP-l routes, and subscriber identity plus domain-link evidence for qualified website authentication routes.

For every initial issuance, renewal, re-key, or modification, the application workflow should prove that the subscriber and subject were registered, the attributes to be certified are still correct, the identity-proofing method is still allowed by the CPS, and the certificate request is accurate, authorized, complete, and linked to the registration evidence.

  • Input: selected policy profile, subscriber and subject identity evidence, attribute evidence, domain-link evidence for website certificates, and proof of possession or control when the subject key pair is not generated by the CA.
  • Owner: registration service owner, with CA operations accepting only trusted and authorized certificate applications.
  • Decision: issue only when registration evidence, certified attributes, authorization, and application completeness match the selected EN 319 411-2 profile.
  • Output: registration record, application approval, CP/CPS reuse limits for prior validation, and an auditable link between the application, subject identity, public key, and certificate profile.
Section 3

Issuance, certificate profile, and relying-party notice

The issuance gate should verify that the certificate profile matches the policy selected at intake. EN 319 411-2 requires appropriate qcStatements, requires the QSCD qcStatement for QCP-n-qscd and QCP-l-qscd, and says the QSCD qcStatement must not be included outside those QSCD policy routes.

The relying-party notice is part of the lifecycle because it explains how the certificate can be relied on as an EU qualified certificate. EN 319 411-2 requires the notice to point relying parties to the appropriate EU trusted-list entry for the QTSP trust anchor, and the terms-and-conditions section requires a clear statement that the policy is for EU qualified certificates and whether QSCD use is required.

  • Confirm that the certificate includes the correct EN 319 411-2 policy identifier or a TSP-allocated OID that clearly identifies the EN 319 411-2 policy basis.
  • Check qcStatements before release, especially the QSCD statement for QCP-n-qscd and QCP-l-qscd and the prohibition on using it for non-QSCD routes.
  • Publish terms, conditions, and PKI disclosure material that identifies the EU qualified certificate policy and the QSCD requirement status.
  • Include relying-party instructions for trusted-list validation instead of treating an internal CA name or certificate chain alone as proof of EU qualified status.
Section 4

Renewal, re-key, modification, and QSCD status changes

Treat renewal, re-key, and modification as separate lifecycle events. EN 319 411-1 distinguishes renewal as a new certificate using the previously certified public key, re-key as a new certificate with a new subject public key, and modification as a new certificate caused by changes to certified information other than the subscriber public key.

For EN 319 411-2 website-authentication routes, QEVCP-w has specific reuse and validity-period dependencies tied to EVCG, while non-QEVCP-w routes inherit the applicable Part 1 renewal, re-key, and modification requirements. For QSCD routes, the workflow must also monitor QSCD certification status and define CPS measures for status changes before certificate expiry.

  • Renewal gate: confirm that the old key is still cryptographically sufficient, the private key is not known to be compromised, and changed terms have been communicated and agreed where required.
  • Re-key gate: verify changed names or attributes, record subscriber agreement, and check the previous certificate if it is used to authenticate the request.
  • Modification gate: verify and record changed certified attributes, because the key remains the same but the certificate content changes.
  • QSCD gate: for QCP-n-qscd and QCP-l-qscd, verify QSCD certification, prove that the public key came from a QSCD-generated key pair, and document what happens if QSCD status changes during certificate validity.
Section 5

Revocation, suspension, and certificate status services

The revocation workflow should be documented in the CPS before incidents occur. EN 319 411-1 requires the CPS to identify who can submit revocation requests or reports, how requests are submitted, confirmation procedures, reasons for revocation or suspension, the distribution mechanism for status information, and the maximum delays for status changes.

For qualified certificate services, status information is not just an operational convenience. EN 319 411-2 carries forward Part 1 status-service requirements and adds that revocation status information must be available beyond the certificate validity period through at least one method used during validity, such as CRL or OCSP, except for the validity-assured short-term certificate route described by the standard.

  • Authenticate revocation requests and reports, process them on receipt, and keep UTC synchronization for revocation-service time.
  • Make certificate status changes available to relying parties within the Part 1 24-hour maximum, including both CRL and online status services where both are supported and delays are possible.
  • Never reinstate a definitively revoked certificate, and revoke non-expired certificates when the TSP is aware of changes that affect validity or when cryptography no longer binds the subject to the public key.
  • Document how CRL or OCSP status remains available beyond expiry, including CA key compromise and TSP termination scenarios.
Section 6

Records, disclosure, and conformance boundaries

Close each lifecycle event with records that can be read after the certificate, CA key, supplier process, or TSP operation changes. EN 319 411-2 adds qualified-certificate record expectations to the inherited audit logging and records archival controls, including the need to maintain information as necessary to meet legal requirements beyond TSP termination.

Keep the conformance boundary explicit. EN 319 411-2 states that conformance to the standard alone does not imply that the TSP or its certificates are qualified under eIDAS, and Annex A says its policy mapping should not be treated as a definitive legal conformance statement.

  • Keep one lifecycle record per certificate or certificate batch: policy profile, identity evidence, application approval, issuance result, qcStatements, trusted-list relying-party notice, renewal or re-key decisions, modification history, revocation events, and status-service availability evidence.
  • Keep CP, CPS, terms-and-conditions, and PKI disclosure statement versions tied to the lifecycle events they governed.
  • Record exceptions separately from source requirements, especially where national law, supervisory body expectations, browser-forum rules, or a customer contract adds obligations outside EN 319 411-2.
  • Use EN 319 411-2 evidence to support implementation and assessment preparation, not as a standalone claim of eIDAS qualified status.
Primary sources

References and citations

etsi.org
Referenced sections
  • Supports the distinction between renewal, re-key, and modification and the application-processing controls inherited by EN 319 411-2.
"Certificate modification"
etsi.org
Referenced sections
  • Primary source for EN 319 411-2 policy profiles, qualified certificate lifecycle scope, identity validation additions, QSCD controls, certificate profiles, status beyond expiry, records, disclosure, and conformance caveats.
"life-cycle management"
eur-lex.europa.eu
Referenced sections
  • Supports the qualified trust-service context for identity verification, records, revocation, certificate databases, and status information mapped in EN 319 411-2 Annex A.
"qualified certificates"
Related guides

Explore more topics

eIDAS QTSP supervision workflow for ETSI EN 319 411-2
Operational workflow for qualified trust service providers using ETSI EN 319 411-2 to manage supervisory-body changes, incidents, termination evidence, trusted-list checks, and assessment records.
EN 319 411-2 vs EN 319 411-1 Qualified Certs
Compare ETSI EN 319 411-2 qualified certificate requirements with EN 319 411-1 general certificate-service requirements, including QCP profiles, QSCD evidence, CP/CPS reuse, and audit boundaries.
ETSI EN 319 411-2 compliance checklist
Compliance checklist for ETSI EN 319 411-2 qualified certificate services, covering policy selection, CP/CPS evidence, identity validation, QSCD status, trusted-list reliance, and certificate status services.
ETSI EN 319 411-2 FAQ for EU Qualified Certificates
Answers to common ETSI EN 319 411-2 questions about EU qualified certificate policies, QSCD use, identity validation, trusted lists, and revocation status services.
ETSI EN 319 411-2 Identity Proofing
How EN 319 411-2 applies identity validation for EU qualified certificates, including QCP natural-person, legal-person, website, and evidence-record checks.
ETSI EN 319 411-2 QSCD Route
When QCP-n-qscd or QCP-l-qscd is the right EN 319 411-2 route, what QSCD evidence is needed, and which certificate-profile claims must stay aligned.
ETSI EN 319 411-2 QTSP supervision evidence workflow
Build an assessment-ready QTSP supervision evidence pack for ETSI EN 319 411-2 qualified certificate services, covering policy identifiers, trusted-list checks, incident records, QSCD evidence, and termination controls.
ETSI EN 319 411-2 qualified certificate operations: issuance, suspension, and revocation
Operational guide for ETSI EN 319 411-2 qualified certificate services: policy identifiers, identity validation, issuance, QSCD handling, revocation status, and relying-party notices.
ETSI EN 319 411-2 Qualified Certificate Scope
Use ETSI EN 319 411-2 to scope EU qualified certificate services by certificate policy, subject type, QSCD use, website authentication profile, and eIDAS context.
ETSI EN 319 411-2 requirements map
Map ETSI EN 319 411-2 requirements for EU qualified certificate services across QCP profiles, CP/CPS documentation, QSCD use, certificate profiles, revocation, and eIDAS Annex A references.
ETSI EN 319 411-2 trusted-list evidence
Build EN 319 411-2 trusted-list evidence for EU qualified certificate reliance: relying-party notice text, QTSP service identifiers, validation records, and change triggers.
ETSI EN 319 411-2 trusted-list validation workflow
Validate an EN 319 411-2 EU qualified-certificate claim by mapping the certificate service to the QTSP trusted-list entry, policy profile, relying-party notice, and status evidence.
ETSI EN 319 411-2 vs eIDAS Qualified Trust Services
Compare ETSI EN 319 411-2 certificate policy requirements with the eIDAS qualified-status, supervision, audit, and trusted-list framework.
ETSI EN 319 411-2: Certificate Revocation FAQ
Answer the ETSI EN 319 411-2 revocation question for qualified certificate services: CPS procedures, 24-hour publication, CRL or OCSP status, and evidence to retain.
ETSI EN 319 411-2: Legal vs Natural Person Certs
ETSI EN 319 411-2 separates qualified certificate policies for natural persons, legal persons, QSCD use, and website authentication subscribers.
ETSI EN 319 411-2: QCP, QNCP, and QEVCP Profile Selection
Choose the right ETSI EN 319 411-2 qualified certificate policy profile: QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, or QNCP-w-gen.
ETSI EN 319 411-2: workflow for selecting QCP-n, QCP-l, or QCP-w certificate profile
Select the right ETSI EN 319 411-2 qualified certificate policy profile for signatures, seals, QSCD use, and website authentication.
How should QTSPs select an ETSI EN 319 411-2 qualified certificate profile?
A focused FAQ on choosing QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, or QNCP-w-gen under ETSI EN 319 411-2.
How should relying parties use trusted lists under ETSI EN 319 411-2?
FAQ on EN 319 411-2 trusted-list reliance for EU qualified certificates: relying-party notices, QTSP service identifiers, validation evidence, and source references.
QSCD Requirements in ETSI EN 319 411-2
How ETSI EN 319 411-2 treats QSCD-backed qualified certificates, including QCP-n-qscd and QCP-l-qscd policies, key-use controls, QSCD verification, and certificate profile evidence.
QTSP Supervision and ETSI EN 319 411-2
How ETSI EN 319 411-2 supports QTSP supervision evidence for qualified certificate services, trusted-list reliance, liability responsibility, incident records, and audit preparation.
Qualified certificates under ETSI EN 319 411-2
FAQ answer for QTSPs on how ETSI EN 319 411-2 treats EU qualified certificates, policy identifiers, QSCD variants, website certificates, and lifecycle evidence.
What are the qualified certificate policies in ETSI EN 319 411-2?
FAQ on ETSI EN 319 411-2 qualified certificate policies, including QCP-n, QCP-l, QSCD variants, QEVCP-w, QNCP-w, and policy identifiers.
Which QWAC Profile Fits ETSI EN 319 411-2?
Choose between QEVCP-w, QNCP-w, and QNCP-w-gen for qualified website authentication certificates under ETSI EN 319 411-2.