Artifact GuideGLOBALETSI EN 319 411-2

ETSI EN 319 411-2 Qualified Certificate Scope

A scope guide for deciding which EU qualified certificate policy profile applies before drafting CP/CPS text or issuing certificates.

Use the standard with its current EU adaptations and the trusted-list entry for the specific service; the standard alone does not establish qualified status.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 2026

Overview

Define each service by certificate purpose, subject type, policy profile, route, and qualified-status evidence before drafting the CP or CPS. EN 319 411-2 V2.6.1 supplies seven policy profiles, but current implementation also requires the applicable eIDAS text and EU implementing regulations. A provider and service are qualified only when that service appears as qualified in the relevant .

Section 1

What EN 319 411-2 adds to the scope

ETSI EN 319 411-2 is not a general PKI checklist. It addresses issuance, maintenance, and lifecycle management of EU qualified certificates. It imports general policy and security requirements from ETSI EN 319 411-1 and adds requirements for qualified signature, seal, and website authentication certificate policies.

The scope record should name the issuing trust service provider (TSP), the certification service components, the certificate population, the claimed policy identifier, and the relying-party use. Keep three layers separate: conformance to the standard, compliance with the binding eIDAS framework and applicable implementing regulations, and the qualified status of the particular service shown in the .

Name the issuing TSP and the certificate service components covered by the .
State whether the certificate is intended to support an electronic signature, electronic seal, or website-authentication use case, and whether the selected route is intended to support a qualified signature or seal.
Link the EN 319 411-2 scope to the corresponding EN 319 411-1 baseline requirements instead of treating Part 2 as a standalone control set.
Record the qualified status evidence separately from the standards-conformance evidence.

Sources for this answer

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Supports the scope boundary for issuance, maintenance, and lifecycle management of EU qualified certificates and the warning that standards conformance alone is not qualified status.

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements

Supports the Part 1 baseline used by EN 319 411-2 for general certificate policy and security requirements.

Regulation (EU) No 910/2014 (eIDAS)

Current consolidated legal context for qualified trust services, qualified certificates, supervisory status, and national trusted lists.

European Commission EU trusted lists

Explains the constitutive effect of national trusted lists: the provider and specific service are qualified only when listed as qualified.

Recommended next step

Operationalize Qualified Certificate Scope

This ETSI EN 319 411-2 scope guide helps align policy profile choice, CP/CPS evidence, QSCD assumptions, and trusted-list reliance before issuance or assessment.

Assessment workflow

Open Assessment Autopilot for ETSI EN 319 411-2

Convert the selected qualified policy profile into owners, evidence requests, and assessment-ready review items.

Explore next step

Research workflow

Research ETSI EN 319 411-2 source questions

Resolve profile, QSCD, trusted-list, and CP/CPS questions against cited standards before implementation.

Explore next step

Talk to Sorena

Talk through ETSI EN 319 411-2 implementation

Review the certificate scope, evidence boundary, and next actions with Sorena.

Explore next step

Section 2

Choose the qualified policy profile

Select one EN 319 411-2 policy before mapping requirements. The choice determines the subject, intended certificate use, inherited EN 319 411-1 policy family, conditions, and any CA/Browser Forum dependency.

For signature and seal certificates, Regulation (EU) 2025/1943 references EN 319 411-2 V2.6.1 with binding adaptations, including changes to identity validation, remote management, cryptographic controls, and certificate issuance. For qualified website authentication certificates issued for transport layer security authentication outside a web-browser, Regulation (EU) 2025/2527 lists QEVCP-w, QNCP-w, and QNCP-w-gen as reference routes and applies from 6 January 2027; until then, teams must keep that future application date distinct from the standard's publication.

Use QCP-n for EU qualified certificates issued to natural persons.
Use QCP-l for EU qualified certificates issued to legal persons.
Use QCP-n- or QCP-l-qscd only when the private key related to the certified public key resides in a QSCD.
Use QEVCP-w for qualified website authentication certificates based on the EVCP profile.
Use QNCP-w for qualified website authentication certificates based on NCP plus OVCP or IVCP; use QNCP-w-gen for the NCP plus web-tagged requirement route.

Sources for this answer

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Defines the QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, and QNCP-w-gen policy identifiers used to scope the service.

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements

Supplies the NCP, NCP+, EVCP, OVCP, IVCP, and web-tagged requirement families inherited by EN 319 411-2 profiles.

Commission Implementing Regulation (EU) 2025/1943

References and adapts EN 319 411-2 V2.6.1 for qualified certificates for electronic signatures and electronic seals.

Commission Implementing Regulation (EU) 2025/2527

Lists the EN 319 411-2 QWAC policy routes as reference standards for TLS authentication outside a web-browser and applies from 6 January 2027.

Section 3

Scope questions to answer before issuance

Answer each question that changes the requirement set before issuance. The CP, CPS, terms and conditions, subscriber obligations, certificate profile, and relying-party notice should give consistent answers.

Keep a profile matrix with the subject type, policy identifier, inherited Part 1 family, applicable EU adaptation, dependency, certificate purpose, website-authentication route, trusted-list service identifier, and owner for each evidence record.

Is the subject a natural person, a legal person, or a website-authentication subscriber whose identity and domain link must be verified?
Do the terms and conditions require a secure cryptographic device, causing the NCP+ route to apply for QCP-n or QCP-l?
For a profile, who manages the device and how is the device certification, key generation route, and QSCD status monitored?
If the TSP manages a remote for the subject, does it hold the qualified status required for that remote QSCD management service under the adapted requirements in Regulation (EU) 2025/1943?
For QEVCP-w or QNCP-w, which BRG or EVCG dependency applies, and how will conflicts with the ETSI profile be handled?
What notice tells relying parties that the trust anchor must be identified through an appropriate EU trusted-list entry for a ?

Sources for this answer

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Supports the profile-dependent scoping questions for secure cryptographic devices, QSCD routes, website-authentication profiles, and relying-party trusted-list notices.

Regulation (EU) No 910/2014 (eIDAS)

Provides the eIDAS context for qualified certificates for signatures, seals, website authentication, and qualified trust service providers.

Commission Implementing Regulation (EU) 2025/1943

Adds the condition that a TSP managing a remote QSCD for the subject must provide the corresponding qualified remote-QSCD management service.

Section 4

Evidence that makes the scope reviewable

The scope decision should be reviewable without asking the reader to infer why a profile was chosen. Keep evidence at the level of the actual service: the clause, the certificate policy identifier, the terms and conditions, the subscriber or subject identity record, the evidence where applicable, the certificate profile, and the relying-party notice.

For profiles, the evidence must show more than an internal design preference. EN 319 411-2 includes requirements for verifying QSCD certification, ensuring the public key to be certified is from a QSCD-generated key pair, handling QSCD status changes, and including or excluding the QSCD qcStatement according to the selected policy.

Profile matrix: policy identifier, subject type, inherited EN 319 411-1 policy family, applicable EN 319 411-2 additions, and binding EU adaptations.
extract: the clauses that identify the certificate policy, certificate usage, PKI participants, and service responsibilities.
Identity and domain evidence: records showing the verified subject and, for website authentication, the subject's link to the domain name.
evidence: device certification, management responsibility, key-pair generation route, status monitoring, and qcStatement handling.
Qualified-status record: the national trusted-list service entry, service digital identifier, current service status, certificate population covered, and date checked.
Relying-party notice: the statement connecting qualified-certificate reliance to the appropriate EU trusted-list service entry.

Sources for this answer

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Supports the concrete evidence list for policy identifiers, CP/CPS alignment, identity verification, QSCD handling, certificate profile requirements, and trusted-list reliance notices.

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements

Supports the underlying CP/CPS, repository, registration, revocation, and certificate lifecycle controls inherited by qualified profiles.

Section 5

Scope mistakes that create audit rework

Profile mixing and generic qualified-status claims create avoidable review failures. Resolve profile-specific assumptions before the CP, CPS, certificate profile, and service evidence diverge.

A scope file should establish why the selected policy route fits the service and identify the next evidence set. It cannot by itself prove eIDAS compliance or qualified status.

Do not label a service as qualified only because it maps to EN 319 411-2; keep supervisory and trusted-list evidence explicit.
Do not use a policy identifier unless the private key and certificate route meet the QSCD-specific requirements.
Do not mix QEVCP-w, QNCP-w, and QNCP-w-gen evidence because their inherited baseline requirements differ.
Do not omit the EN 319 411-1 baseline; EN 319 411-2 builds on it instead of replacing it.
Do not apply the unadapted standard where a binding implementing regulation changes or supplements the cited requirement.
Do not let the relying-party notice skip the EU trusted-list dependency for qualified-certificate reliance.