Artifact GuideGLOBALETSI EN 319 411-2

ETSI EN 319 411-2 qualified certificate operations

Run EU qualified certificate services with the operational evidence EN 319 411-2 expects across policy selection, identity validation, issuance, QSCD handling, and status services.

Align CP/CPS clauses, certificate policy identifiers, subscriber terms, lifecycle gates, status services, trusted-list evidence, and supervisory change records.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
7

Structured answer sets in this page tree.

Primary sources
15

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Run the as a controlled sequence: establish the qualified service and policy, verify identity and attributes, authorize the request, generate and release the certificate, control renewal or change, process suspension or revocation, and preserve status information. Apply the current eIDAS text and binding EU adaptations with EN 319 411-2 V2.6.1; the standard alone does not establish compliance or qualified status.

Section 1

Set the operational boundary before issuing certificates

Start each qualified certificate operation with the service boundary: issuing TSP, CA or RA roles, certificate population, subject type, policy identifier, CP, CPS, subscriber terms, repository location, and relying-party notice. EN 319 411-2 incorporates EN 319 411-1 general certificate requirements, so the operating file should show both the general control baseline and the qualified-certificate additions.

Separate standards implementation from qualified-service recognition. Record the national trusted-list service entry, service digital identifier, certificate population, and status. For qualified signature and seal certificates, maintain an adaptation register for Regulation (EU) 2025/1943 instead of operating from the unmodified standard.

  • Name the qualified certificate policy in use: QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, or QNCP-w-gen.
  • Record whether the certificate service is for natural persons, legal persons, qualified electronic signatures, qualified electronic seals, or website authentication.
  • Map the selected policy to the CP, CPS, subscriber agreement, certificate profile, and repository material that relying parties can use.
  • Keep EN 319 411-1 inherited controls and binding EU adaptations visible instead of treating EN 319 411-2 as a standalone operating manual.
Section 2

Operate identity validation and application processing by profile

Qualified certificate operations begin before key or certificate generation. Apply an identity route allowed by current eIDAS Article 24 and preserve separate evidence for every certified attribute. Regulation (EU) 2025/1943 adapts the QCP-n and QCP-l clauses to refer to Article 24(1c) implementing acts, so the standard's unadapted physical-presence or equivalent-assurance wording is not the complete current legal route list.

For website authentication, verify the natural or legal person and the subscriber's link with the domain. For signature and seal certificates issued to a natural person associated with an organization, the adapted issuance rule keeps the natural person as subject identifier while the organization attributes represent the legal person or its sub-entity.

  • For QCP-n and QCP-n-qscd, keep evidence for the natural person's identity and any specific attributes placed in the certificate.
  • For QCP-l and QCP-l-qscd, keep evidence for the legal person, the authorized representative route, and any specific attributes placed in the certificate.
  • For QEVCP-w, QNCP-w, and QNCP-w-gen, keep evidence linking the natural-person or legal-person subscriber to the certified domain name.
  • When remote or delegated validation is used, preserve the Article 24 route, proofing provider, conformity-assessment or national-law basis where required, and impersonation controls.
Section 3

Control issuance, acceptance, and certificate profile content

The issuance record should prove that the certificate policy identifier matches the policy applied. Clause 6.6.1 permits the profile's ETSI identifier, an allocated OID for the applied policy, or both, according to the profile-specific choice. The CP must incorporate or further constrain the applicable EN 319 411-2 requirements.

Put certificate acceptance and profile checks in the same release gate. If the subscriber agreement is electronic, EN 319 411-2 says it should be signed with an advanced electronic signature or seal. Certificates should include the appropriate qcStatements, and only QCP-n-qscd or QCP-l-qscd certificates should include the QSCD qcStatement.

  • Check that each issued certificate includes at least one policy identifier permitted for the selected profile and that every allocated OID resolves to the CP actually applied.
  • Verify that CP and CPS text explain the certificate purpose, subject class, policy identifier, and whether QSCD use is required.
  • Keep the subscriber agreement and acceptance evidence with the certificate issuance record.
  • Include QSCD qcStatement evidence only for QCP-n-qscd and QCP-l-qscd certificates, and confirm it is absent from non-QSCD qualified certificates.
Section 4

Run QSCD, key-use, and subject-control checks

For QCP-n-qscd and QCP-l-qscd, verify that the device is certified as a QSCD and the public key comes from a key pair generated by a QSCD. A controlled import between QSCD roles is conditional: the environmental assumptions and security objectives for both certified-device roles must remain met, and movement risks must be assessed and mitigated.

Where the TSP manages the QSCD, signing must occur within a QSCD. Natural-person signature keys remain under the subject's sole control; legal-person seal keys remain under the subject's control. Regulation (EU) 2025/1943 adds that a TSP managing the subject's remote QSCD must provide the corresponding qualified remote-QSCD management service.

  • Keep QSCD certification evidence for every QCP-n-qscd and QCP-l-qscd issuance path.
  • Record how certificate requests prove the certified public key came from a QSCD-generated key pair.
  • For a TSP-managed remote QSCD, document controls that restrict private-key use to the QSCD, preserve sole control or control as applicable, and prove the manager's qualified-service status.
  • Monitor QSCD certification status through the certificate validity period and document the CPS measures used if status changes.
Section 5

Distinguish renewal, re-key, and modification

Use the lifecycle action that matches what changes. Renewal issues a new certificate without changing the subject public key or other certificate information, apart from the new serial number and any permitted validity update. Re-key issues a new certificate with a new subject public key and may update certified attributes. Modification issues a new certificate because certificate information changes while the subject public key stays the same.

Do not carry old validation evidence forward automatically. Apply the reuse and revalidation conditions in EN 319 411-1 and the selected profile. QEVCP-w has specific EVCG-based substitutions for renewal, re-key, and modification. Record the old and new certificate identifiers, changed fields, evidence reused, checks repeated, approval, overlap period, and whether the former certificate must be revoked.

  • Renewal: confirm that the public key and certificate information remain unchanged except for the serial number and any permitted validity update.
  • Re-key: verify the new public key, proof of possession or control, permitted attribute changes, and any required revocation of the former certificate.
  • Modification: verify every changed attribute while confirming that the subject public key remains the same.
  • For each action, apply the profile-specific evidence-reuse conditions and rerun the certificate request, policy identifier, qcStatement, and authorization gates.
  • Keep the former certificate's status and the new certificate's release record linked so relying-party status remains unambiguous.
Section 6

Maintain revocation, status, and relying-party evidence

Authenticate and validate revocation or suspension requests, then publish the resulting status without exceeding the applicable deadline. Current eIDAS Article 24(3) requires a revocation to be registered in the certificate database and published in a timely manner, in any event within 24 hours after receipt of the request; revocation takes effect immediately on publication. EN 319 411-1 also requires the CPS to define the relevant processing delays and exception procedure.

EN 319 411-2 requires revocation status information beyond certificate validity through at least one method used during validity, unless the validity-assured short-certificate exception applies and the certificate carries the required extension. For CRLs, whether expired revoked certificates remain listed determines the ExpiredCertsOnCRL treatment. For OCSP, the standard describes ArchiveCutOff and a conditional final-response approach.

The CPS and terms must state the availability period and how status survives CA key compromise or TSP termination. The relying-party notice must connect qualified-certificate validation to the service digital identifier in the appropriate trusted-list entry.

  • For CRL operations, document whether expired revoked certificates remain on the CRL and whether the ExpiredCertsOnCRL extension is used when required.
  • For OCSP operations, document the archive-cutoff or final-response approach used for status information beyond certificate validity.
  • Keep the request receipt time, authorization and validation result, decision time, publication time, effective status, reason, and affected certificate population.
  • Keep relying-party notice text, trusted-list service digital identifier evidence, and the date and scope of the trusted-list check.
Section 7

Control service changes and termination

Certificate operations also include changes to the qualified service itself. Article 24(2)(a) requires notice to the supervisory body at least one month before a qualified-service change and at least three months before intended cessation. Regulation (EU) 2025/2530 identifies significant changes to policies, practices, terms, architecture, hosting, cryptography, registration, governance, termination, trusted-list data, and third-party arrangements as notification subjects.

Maintain a termination plan for each qualified service. Review it at least every two years and when service changes occur. The plan must address certificate revocation where relevant, trusted-list updates, status and validation continuity, evidence preservation, subscriber and affected-party notices, third-party arrangements, and resources needed to execute the plan.

  • Route significant service changes through supervisory notification before implementation.
  • Include the change description, planned date and time, reasons, supporting evidence where applicable, and updated documents where applicable.
  • Link certificate, CRL, OCSP, trusted-list, repository, subscriber, and third-party actions to the service termination plan.
  • Preserve records needed to show prior compliance and to verify previously created trust-service outputs after termination.
Primary sources

References and citations

etsi.org
Referenced sections
  • Supports the distinction between Certificate Policy, Certification Practice Statement, subscriber terms, and disclosure material used in certificate operations.
"Certification Practice Statement"
etsi.org
Referenced sections
  • Supports the operational requirements for revocation status beyond certificate validity, CRL and OCSP evidence, CPS status-service disclosure, and relying-party trusted-list notices.
"Revocation status information shall be made available"
etsi.org
Referenced sections
  • Supports the operating scope for EU qualified certificate issuance, maintenance, life-cycle management, policy identifiers, and the warning that standard conformance alone is not qualified status.
"issuance, maintenance and life-cycle management"
digital-strategy.ec.europa.eu
Referenced sections
  • Explains that qualified status attaches to the provider's specific listed service, not every service the provider operates.
eur-lex.europa.eu
Referenced sections
  • Current Article 24 identity and attribute routes and qualified trust service provider duties.
"qualified trust service"
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.
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 profile selector
Select the right ETSI EN 319 411-2 qualified certificate policy profile for signatures, seals, QSCD use, and website authentication.
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 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 vs EN 319 411-1
Compare ETSI EN 319 411-2 EU qualified certificate requirements with EN 319 411-1 general certificate-service requirements, including policy inheritance, QSCD controls, and CP/CPS evidence reuse.
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: end-to-end qualified certificate lifecycle management workflow
Lifecycle workflow for ETSI EN 319 411-2 qualified certificate services, from policy selection and identity validation through issuance, renewal, re-key, modification, revocation, status services, and records.
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.
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.