Search every question across sub-FAQs

No. ETSI EN 319 411-2 expressly warns that conformance to the standard alone does not mean that the TSP or its certificates are qualified. A supervision answer should therefore avoid treating an EN 319 411-2 audit result as a substitute for qualified status.

For a QTSP issuing EU qualified certificates, the standard is still central evidence. It incorporates EN 319 411-1 general policy and security requirements, then adds requirements for EU qualified certificates for signatures, seals, and website authentication.

Current eIDAS Article 20 requires an audit by a conformity assessment body at the QTSP's expense at least every 24 months. The QTSP must notify the supervisory body at least one month before a planned audit and submit the resulting report within three working days after receiving it. The supervisory body may also audit the QTSP or request another assessment at any time. Article 21 governs the supervisory decision for a new qualified service; the service may begin only after qualified status appears in the trusted list. Commission Implementing Regulation (EU) 2025/2162 supplies the current accreditation, assessment-scheme, and report rules.

A useful supervision file should start with the certificate service and policy identifier, then link the CPS, certificate profile, repository, identity proofing, revocation, status service, incident, and termination evidence to the relevant EN 319 411-2 and incorporated EN 319 411-1 requirements.

The record should also prove the relying-party path. EN 319 411-2 says relying-party notices for EU qualified certificates need to explain that the trust anchor is identified in the service digital identifier of an appropriate EU trusted-list entry for the QTSP. Record the provider, the specific qualified service, its status and status history, and the certificates or other service identifiers carried by that entry. Keep subcontracted operations in the same map: the QTSP identified in the trusted list retains overall responsibility for issuing the certificates even when another party performs a component activity.

The most common mistakes are to blur qualified-status evidence with standards conformance, omit the trusted-list reliance path, or leave the supervision file without a traceable link from the selected certificate policy to the operational records.

Another common problem is treating incident, revocation, and records-retention evidence as optional. EN 319 411-2 and EN 319 411-1 map those topics into the qualified-certificate supervision file, while eIDAS Article 46b gives the supervisory body powers to request conformity assessments, grant or withdraw qualified status, require remediation, and verify termination plans.

Start by separating ETSI policy conformance from EU qualification status. EN 319 411-2 incorporates the general certificate policy and security requirements from EN 319 411-1 and adds requirements for EU qualified certificate services, but conformance to the standard alone does not imply that the TSP or its certificates are qualified.

Under current eIDAS, qualified status follows conformity assessment, supervisory verification, and entry of the provider and service in the national trusted list. The certificate must also contain the data required by Annex I for signatures, Annex III for seals, or Annex IV for website authentication. Those Annexes require a machine-readable qualified-certificate indication, issuer and subject identity data, validity dates, a unique certificate code, issuer signature or seal, and status-service information, with type-specific data such as domain names for website certificates and a QSCD indication where applicable. Check all three layers before describing a certificate as qualified.

For each certificate service, identify which EN 319 411-2 policy family is being used: QCP-n for qualified certificates issued to natural persons, QCP-l for legal persons, QCP-n-qscd or QCP-l-qscd when the related private key resides in a QSCD, and QEVCP-w, QNCP-w, or QNCP-w-gen for qualified website authentication certificates. The selected policy drives the certificate-policy statement, CPS controls, certificate profile, subscriber obligations, and evidence set.

Prove that the certificate was issued and managed under the claimed EN 319 411-2 policy. Keep the certificate policy, Certification Practice Statement (CPS), terms and conditions, certificate profile, identity-verification record, status-service evidence, and revocation records aligned to the selected QCP route.

For QSCD-backed QCP-n-qscd and QCP-l-qscd certificates, the evidence needs to show the QSCD basis, including the certificate profile treatment of the ETSI EN 319 412-5 QSCD qcStatement and the standard's rule that the QSCD statement is not included in certificates outside those QSCD policies.

Use the checklist to prevent the common error of treating all certificates, all certificate policies, or all QTSP services as interchangeable. The useful review is certificate-policy specific and should be repeated when the certificate profile, CPS, QSCD route, website certificate route, trusted-list status, or relevant ETSI/eIDAS source changes.

ETSI EN 319 411-2 defines seven EU qualified certificate policies. QCP-n covers EU qualified certificates issued to natural persons, and QCP-l covers EU qualified certificates issued to legal persons. QCP-n-qscd and QCP-l-qscd are the corresponding policies when the private key related to the certified public key must reside in a qualified signature or seal creation device.

For qualified website authentication certificates, QEVCP-w is based on EVCP, QNCP-w is based on NCP plus OVCP or IVCP, and QNCP-w-gen is based on NCP plus requirements tagged as WEB in ETSI EN 319 411-1. The selected policy should be visible in the CP/CPS, terms and conditions, certificate profile, and policy identifier evidence.

The ETSI policy OIDs are 0.4.0.194112.1.0 for QCP-n, 0.4.0.194112.1.1 for QCP-l, 0.4.0.194112.1.2 for QCP-n-qscd, 0.4.0.194112.1.3 for QCP-l-qscd, 0.4.0.194112.1.4 for QEVCP-w, 0.4.0.194112.1.5 for QNCP-w, and 0.4.0.194112.1.6 for QNCP-w-gen. EN 319 411-2 also permits an OID allocated by the TSP or another stakeholder, but the policy it identifies must state which EN 319 411-2 policy it uses as its basis.

Apply the choice in four steps. First identify the intended use: signature, seal, or website authentication. Second identify the subject as a natural person or legal person. Third decide whether the signature or seal key must reside in a QSCD. Fourth, for website authentication, select the EV, organization or individual validation, or general-purpose assurance route. A certificate intended for another use is outside these seven policy profiles.

Then check the device and baseline inheritance. EN 319 411-2 states that QCP-n and QCP-l use NCP unless the TSP terms and conditions require a secure cryptographic device, in which case NCP+ applies. The QSCD-specific policies include the corresponding QCP policy plus QSCD provisions. Website routes inherit EVCP, NCP, OVCP or IVCP, and WEB-tagged requirements as applicable.

The evidence should prove that the selected policy identifier matches the certificate type and the service actually operated. Keep the CP/CPS section that names the policy, the certificate profile showing the policy OID, the terms and conditions that determine secure-device use, and issuance or audit evidence showing whether the service follows the inherited EN 319 411-1 requirements. Sample issued certificates and trace each one back through identity validation, approval, profile generation, publication, status service, and revocation handling.

Do not treat Annex A as a legal conformance certificate. EN 319 411-2 says the annex maps policy references to eIDAS requirements, but also warns that the annex is not a definitive statement of conformance to eIDAS and that non-technical legal requirements are outside the standard's scope.

ETSI EN 319 411-2 defines three EU qualified website authentication certificate policy profiles: QEVCP-w, QNCP-w, and QNCP-w-gen. The selected policy determines which EN 319 411-1 baseline, CA/Browser Forum dependency, and qualified-certificate additions must appear in the CP, CPS, certificate profile, and evidence pack.

Apply three tests in order. First, confirm the certificate is for website authentication rather than signature or seal use. Second, identify the subscriber as a natural or legal person. Third, identify the assurance package. Choose QEVCP-w only for a legal person under the Extended Validation Certificate Policy and EVCG route. Choose QNCP-w for a natural or legal person under NCP plus OVCP or IVCP and the Baseline Requirements. Choose QNCP-w-gen for the general-purpose route based on NCP plus selected WEB-tagged requirements in EN 319 411-1.

Profile selection is only one layer. Current eIDAS Article 45 requires a qualified website authentication certificate to meet Annex IV, and qualified status still depends on the issuing service's trusted-list entry. Annex IV requires, among other data, the subject's identity, address elements, operated domain names, validity period, unique certificate code, issuer signature or seal, and validity-status service information. From 6 January 2027, Commission Implementing Regulation (EU) 2025/2527 lists EN 319 411-2 V2.6.1 with QEVCP-w, QNCP-w, or QNCP-w-gen as a reference-standards route for QWACs used in transport layer security authentication outside a web-browser. It lists ETSI TS 119 411-5 V2.1.1 for other QWACs, including browser use.

For QEVCP-w, QNCP-w, and QNCP-w-gen, EN 319 411-2 ties initial validation to the subscriber type and the domain name. If the subscriber is a natural person, verify the subscriber identity and link with the domain name using the QCP-n route. If the subscriber is a legal person, verify the legal-person identity, authorized-representative route, and link with the domain name using the QCP-l route.

That means the evidence pack should not stop at a domain-control check. It should show the selected QWAC policy identifier, subscriber type, identity route, authority to request the certificate, link to each certified domain, applicable CA/Browser Forum or WEB-tagged dependency, Annex IV certificate contents, and the issuing service's trusted-list status. Retain the source used for the identity and domain-link check, validation time, reviewer or automated control, result, approval, issued certificate, and later revocation or renewal record.

Review the QWAC profile whenever the QTSP changes its CP/CPS, certificate profile, subscriber validation workflow, CA/RA responsibility split, repository publication process, or CA/Browser Forum dependency. The review should confirm that the public certificate policy OID and the evidence trail still describe the same qualified website authentication route.

The most useful audit file is a profile matrix: one row for each QWAC profile offered, with the policy identifier, subscriber type, EN 319 411-1 dependency, CA/Browser Forum or web-authentication dependency, identity-validation route, domain-link evidence, certificate-profile checks, and repository/status-service evidence.