ETSI EN 319 411-2 requirements map

EN 319 411-2 does not define one generic certificate service. It defines EU qualified certificate policies and uses those policy indicators to decide which additional requirements apply. The first mapping step is therefore to identify the service as QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, or QNCP-w-gen.

The profile choice changes the requirement baseline. QCP-n and QCP-l build on EN 319 411-1 NCP or NCP+ depending on whether the TSP's terms require a secure cryptographic device. QCP-n-qscd and QCP-l-qscd add QSCD-specific provisions. QEVCP-w, QNCP-w, and QNCP-w-gen add website-authentication policy dependencies, including BRG, EVCG, or EN 319 411-1 requirements tagged for web authentication.

The public requirement map should separate three layers: the certificate policy states what quality and applicability the service claims, the Certification Practice Statement explains how the TSP operates the service, and the certificate itself carries policy identifiers that relying parties can evaluate.

For EN 319 411-2, the certificate policy identifiers in clause 5.3 are not decorative metadata. Including one of those identifiers indicates that the EU qualified certificate is issued and managed according to the standard for that policy. If a TSP uses only its own allocated OID, the referred certificate policy still needs to identify clearly which EN 319 411-2 policy it adopts as its basis.

EN 319 411-2 labels requirements by service component, so a useful map should preserve that structure instead of flattening everything into a generic checklist. The standard uses OVR for general requirements, GEN for certificate generation, REG for registration, REV for revocation, DIS for dissemination, SDP for subject device provisioning, and CSS for certificate status service.

Many clauses say that the corresponding EN 319 411-1 requirement applies, then add qualified-certificate-specific requirements. Treat those imports as live obligations in the map: the qualified service is not covered just because the EN 319 411-2 add-on text was reviewed.

QSCD handling should not be buried in a general key-management row. If the selected profile is QCP-n-qscd or QCP-l-qscd, EN 319 411-2 adds requirements for verifying QSCD certification, ensuring the public key comes from a QSCD-generated key pair, handling third-party TSP device management, and documenting measures when QSCD status changes before the certificate expires.

Certificate content must also reflect the QSCD branch correctly. EN 319 411-2 requires the QSCD qcStatement for QCP-n-qscd and QCP-l-qscd certificates, and it says that the QSCD qcStatement must not be included in certificates that are not issued under those QSCD policies.

Annex A is useful because it maps eIDAS requirements for TSPs issuing qualified certificates to EN 319 411-2, EN 319 411-1, and EN 319 401 references. It covers areas such as Article 19 security measures and incident notification, Article 24 identity verification, records, termination planning, certificate database, revocation publication, and certificate status information.

Annex A also warns that it is not a definitive statement of eIDAS conformance, that some Regulation requirements are not technical, and that the standard has not been subject to legal review. Public content should therefore present Annex A as traceability support, not as a legal conclusion that a service is compliant with eIDAS.