Artifact GuideGLOBAL

ETSI EN 319 411-2 Requirements

A practical requirements map for issuing EU qualified certificates under eIDAS.

Focus: current V2.6.1 policy OIDs, identity verification rules, QSCD obligations, trusted-list validation, and audit-ready evidence for relying parties and supervisory scrutiny.

Back to main artifactReview sources
Author
Sorena AI
Published
Mar 4, 2026
Updated
Mar 4, 2026
Sections
9

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 4, 2026
Updated Mar 4, 2026
Overview

ETSI EN 319 411-2 V2.6.1 builds on ETSI EN 319 411-1 and adds requirements to support EU qualified certificates under eIDAS. The operational trick is to treat the qualified policy identifier you assert as a contract: it determines what identity checks you must perform, what key-control boundaries you must enforce, how qualified status is signaled, and what you must be able to prove years later. The current edition was adopted on 3 June 2025 and published by ETSI on 6 June 2025.

Section 1

1) What EN 319 411-2 is and what it is not

EN 319 411-2 specifies additional requirements for trust service providers issuing EU qualified certificates. It incorporates the general requirements of EN 319 411-1 and adds qualified-specific rules to align with eIDAS expectations.

Conformance to EN 319 411-2 alone does not automatically make your service or certificates qualified under eIDAS. Qualification is a regulatory status that also depends on conformity assessment, supervisory treatment, and the relevant trusted-list publication.

  • Use EN 319 411-2 as the operational baseline for qualified-certificate issuance controls
  • Keep a clear separation between standard-conformance evidence and regulatory qualification evidence
Section 2

2) Qualified certificate policy identifiers you can assert

EN 319 411-2 defines EU qualified certificate policy identifiers that can be included in certificates. Including one of these identifiers indicates the certificate is issued and managed according to EN 319 411-2 for that policy.

Treat this as relying-party semantics. The policy identifier is used to determine suitability and trustworthiness in an eIDAS context, so CP, CPS, certificate profiles, and subscriber obligations all have to match the asserted OID.

  • QCP-n: EU qualified certificates issued to natural persons
  • QCP-l: EU qualified certificates issued to legal persons
  • QCP-n-qscd and QCP-l-qscd: qualified certificates where the private key is related to the certified public key in a QSCD
  • QEVCP-w, QNCP-w, and QNCP-w-gen: qualified website authentication certificate policies
  • Document which OIDs you assert, where they appear, and how relying parties find interpretation guidance
Section 3

3) Requirement inheritance from EN 319 411-1

A large portion of EN 319 411-2 is composition. It says certain requirement sets in EN 319 411-1 apply, and then adds qualified-specific constraints. That means your compliance mapping has to include both documents, not one or the other.

In practice, build a two-layer mapping so assessors can follow policy choice, inherited baseline requirements, and the qualified deltas without guessing.

  • Build a two-layer mapping: EN 319 411-2 policy choice to applicable EN 319 411-1 requirement sets to qualified deltas
  • Store evidence links in one place so inheritance is reviewable and not trapped in tribal knowledge
Recommended next step

Turn ETSI EN 319 411-2 Requirements into an operational assessment

Assessment Autopilot can take ETSI EN 319 411-2 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on ETSI EN 319 411-2 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow
Open Assessment Autopilot for ETSI EN 319 411-2 Requirements

Start from ETSI EN 319 411-2 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step
Talk to Sorena
Talk through ETSI EN 319 411-2

Review your current process, evidence gaps, and next steps for ETSI EN 319 411-2 Requirements.

Explore next step
Section 5

5) QSCD obligations and key-control boundaries

Qualified certificates with QSCD requirements introduce a hard boundary: the private key cannot be used for signing except within a QSCD, and the private key has to stay under the required subject-control model for the asserted policy.

EN 319 411-2 also pushes obligations into subscriber obligations or TSP obligations when the TSP manages QSCD on behalf of the subject. Your documentation has to make those control flows explicit.

  • If the TSP manages the QSCD, private-key use stays restricted to QSCD operation and the control model still has to be provable
  • Subscriber obligations should require QSCD use where the asserted policy demands it
  • Define who controls the key, what operations are allowed, and what evidence proves QSCD-only signing
Section 6

6) Qualified disclosures, certificate profiles, and QCStatements

EN 319 411-2 requires the certificate policy to include a clear statement that the policy is for EU qualified certificates and whether it requires use of a QSCD. It also requires a PKI disclosure statement and relies on the ETSI certificate-profile stack, including QCStatements, to express qualified semantics in certificates.

Do not let CP, CPS, PKI disclosure text, certificate-profile configuration, and actual certificates diverge. Relying parties and assessors will compare them.

  • Add explicit EU-qualified language and explicit QSCD statements to policy documentation
  • Keep CP, CPS, subscriber terms, PKI disclosure content, and certificate-profile settings synchronized
  • Verify that QCStatements and profile elements support the qualified assertions you make
Section 7

7) Trusted-list validation and qualified-status proof

Relying parties do not infer qualified status from marketing text. They validate against EU trusted lists and related profile material. The EN 319 411-2 reference set explicitly points to trusted-list and validation specifications such as ETSI TS 119 612, ETSI TS 119 615, and ETSI TS 119 172-4.

Operationally, this means your evidence pack needs to show how your service is represented, how certificate validation against trusted lists works, and how you explain that validation path to relying parties and customers.

  • Map each qualified service to the correct trusted-list entry and service digital identifier
  • Test relying-party validation paths using the relevant trusted-list and validation specifications
  • Keep customer and auditor guidance for how qualified status is validated, not just how it is claimed
Section 8

8) Revocation and status services for qualified certificates

Qualified programs still inherit the EN 319 411-1 lifecycle and status-service expectations, but EN 319 411-2 also points directly to RFC 6960 and X.509 mechanisms relevant to long-lived relying-party validation.

If you keep expired revoked certificates on CRLs or use OCSP ArchiveCutOff handling, document the behavior clearly and make sure the profile, CPS, and status infrastructure all tell the same story.

  • Run revocation and online-status services as critical infrastructure with monitored freshness and availability
  • Document any use of OCSP ArchiveCutOff or expired-revoked-certificate handling so relying parties can interpret status correctly
  • Retain evidence that shows status information remained consistent with the certificate lifecycle and qualified policy in force
Section 9

9) CAB Forum conflict rule for web policies

For qualified website-authentication policies, EN 319 411-2 includes a conditional conflict rule: if there is conflict between EN 319 411-2 requirements and the latest relevant CA Browser Forum requirements, the CA Browser Forum requirements take precedence.

Operationally, you need a change-tracking process. You cannot freeze controls to a single version and assume continuing compliance for QNCP-w or QEVCP-w operations.

  • Track CA Browser Forum requirement updates relevant to the web-policy OIDs you assert
  • Maintain a remediation process with evidence from gap analysis through change validation and CPS updates
Primary sources

References and citations

ETSI EN 319 411-1 V1.5.1
etsi.org
Referenced sections
  • Baseline lifecycle and CP and CPS framework incorporated by EN 319 411-2.
Related guides

Explore more topics

ETSI EN 319 411-2 V2.6.1 Compliance Playbook (EU Qualified Certificates and QSCD Operations)
How to operationalize ETSI EN 319 411-2 V2.6.1 for EU qualified certificates: policy OID governance, CP and CPS disclosures, identity verification workflows.
ETSI EN 319 411-2 V2.6.1 FAQ (EU Qualified Certificates, QCP, QNCP, QEVCP, QSCD)
Frequently asked questions about ETSI EN 319 411-2 V2.6.1 for qualified trust service providers: policy OIDs, QSCD requirements, trusted-list validation.