Questions and answers

ETSI EN 319 411-2 makes the EN 319 411-1 revocation request controls applicable to qualified certificate services. In practice, the QTSP's CPS should define who can submit revocation requests or event reports, how they are submitted, when confirmation is required, what reasons can lead to suspension or revocation, and which mechanism distributes revocation status information. The procedure should separate a request from an event report: both need intake and authorization controls, but the party reporting a key compromise or policy breach may not be the subscriber asking for revocation.

The timing control is concrete: EN 319 411-1 requires the actual certificate status change to be available to relying parties no later than 24 hours after receipt of the revocation or suspension request. If confirmation cannot be completed within that window, the CPS needs an exception procedure and the QTSP must record the actions taken and justification. Under eIDAS Article 24(3), revocation takes effect immediately when the published status changes.

Evidence should show that the QTSP can receive, authenticate, decide, publish, and preserve revocation status consistently for the qualified certificate profiles it issues. Follow the sequence from the request or event report through the certificate database update and CRL or OCSP publication.

For revoked or suspended certificates, keep enough records to prove the received request time, authorization check, confirmation or exception path, decision time, certificate-database update, status publication time, and notification to the subject or subscriber where possible. Article 24(4) requires per-certificate information to be automated, reliable, free of charge, efficient, available at any time, and available beyond validity. Reconcile the source ticket, database, CRL, OCSP response, and subscriber notice so their certificate identifier, reason, and timestamps agree.

Use a checklist that follows the certificate lifecycle clauses. The review should prove that requests and event reports are controlled, suspension is separated from permanent revocation, revoked certificates are not reinstated, and relying parties can obtain status information through the published mechanisms. Repeat the review after a policy or status-service change, key compromise, QSCD status change, CA termination, failed publication, or missed 24-hour deadline.

Start with the certificate policy. ETSI EN 319 411-2 names QCP-n for EU qualified certificates issued to natural persons and QCP-l for EU qualified certificates issued to legal persons. If the private key corresponding to the certified public key resides in a QSCD, use the matching QSCD policy route: QCP-n-qscd for a natural person and QCP-l-qscd for a legal person.

That distinction also changes the intended certificate use. QCP-n supports advanced electronic signatures based on a qualified certificate, while QCP-l supports advanced electronic seals based on a qualified certificate. The QSCD variants support qualified electronic signatures for natural persons and qualified electronic seals for legal persons. For example, a certificate identifying an employee and the employee's organization remains a natural-person route; a certificate whose subject is the company itself uses the legal-person route.

The unadapted EN 319 411-2 text describes physical-presence or equivalent-assurance routes for natural persons and for authorized representatives of legal persons. For qualified signature and seal certificates using the Regulation (EU) 2025/1943 presumption-of-compliance route, that Regulation replaces those Part 2 clauses with identity verification under the implementing acts adopted pursuant to eIDAS Article 24(1c). EN 319 411-1 adds the registration evidence needed to distinguish the person, verify attributes, and prove subscriber authority.

Current eIDAS Article 24 supplies the legal method list. Identity may be verified through a European Digital Identity Wallet or notified electronic identification means at assurance level high, a qualified signature or seal certificate issued through an allowed route, another method that identifies the person with a high level of confidence and is confirmed by a conformity assessment body, or physical presence under national law. The file should identify the exact route used; a generic label such as remote verification is not enough. Commission Implementing Regulation (EU) 2025/1566 sets reference standards for the checks but does not apply until 19 August 2027.

For a legal person, preserve the organization's official identity and registration data where applicable, the representative's identity, and proof that the representative may act for the organization. For a natural person, preserve the identity and distinguishing attributes required by the applicable policy and certificate profile. If the natural person is identified in association with a legal person, also preserve the organization identity, registration data, affiliation, authorization, and approval of the organization attributes. Website authentication adds evidence that the subscriber controls or is otherwise linked to each certified domain name.

Use the checklist to avoid issuing or describing a qualified certificate before the subject route, policy identifier, identity evidence, and subscriber authority match the actual natural-person, legal-person, or website-authentication scenario.

Use five inputs: intended use, subject type, QSCD condition, website assurance route, and issuing service scope. EN 319 411-2 defines separate policy identifiers for qualified certificates issued to natural persons, qualified certificates issued to legal persons, qualified certificates tied to a QSCD, and a QWAC. If the intended use is outside signature, seal, or website authentication, these seven profiles do not answer the certificate-policy question.

For signatures, the natural-person route is QCP-n, and QCP-n-qscd is used where the private key related to the certified public key resides in a QSCD. For seals, the legal-person route is QCP-l, and QCP-l-qscd is used where the private key resides in a QSCD. For website authentication, EN 319 411-2 separates QEVCP-w, QNCP-w, and QNCP-w-gen depending on the certificate route and the assurance model behind it. QEVCP-w follows EVCG-based requirements, QNCP-w follows BRG-based requirements for natural or legal persons, and QNCP-w-gen is the general-purpose website-authentication route.

Use the subject and assurance model together. A natural-person signature route points to QCP-n or QCP-n-qscd, and a legal-person seal route points to QCP-l or QCP-l-qscd. For website authentication, QEVCP-w applies only to the EVCP and EVCG route for a legal person; QNCP-w applies to a natural or legal person under NCP plus IVCP or OVCP and the Baseline Requirements; QNCP-w-gen is the general-purpose NCP and WEB-tagged route. Do not choose QEVCP-w merely because the subscriber is a legal person.

The record should show why the certificate policy and certificate contents match the qualified service being offered. EN 319 411-2 says that including one of its policy identifiers indicates the certificate is issued and managed according to that policy. The identifier does not replace the separate eIDAS checks for certificate contents and trusted-list status. Retain the decision inputs, approver, effective date, sample certificate, automated profile test result, and link to the CP, CPS, terms, identity workflow, and issuance configuration.

For a QSCD profile, record why the service uses the -qscd route, how the certificate policy or CPS expresses the QSCD condition, and how the certificate includes the required QSCD statement.

Review the selected profile before first issuance and whenever the certificate purpose, subject population, QSCD handling, website-authentication route, policy OID, CPS wording, certificate content, inherited standard, CA/Browser Forum requirement, or trusted-list service scope changes. A profile that was correct for a non-QSCD natural-person certificate may be wrong after a QSCD service launch, and a signature or seal profile does not substitute for a website-authentication profile.

The review should compare the certificate policy, CPS, terms and conditions, certificate profile, and issuance process against the selected EN 319 411-2 policy family before new certificates are issued under the changed route.

ETSI EN 319 411-2 requires the relying-party notice to state that, as one condition for relying on the certificate as an EU Qualified Certificate, the validation trust anchor is identified in the service digital identifier of the appropriate EU trusted-list entry for the QTSP. This is a condition of the qualified-certificate reliance path, not a general statement that every certificate chaining to the provider is qualified.

That means the public reliance message should name the trusted-list dependency clearly. Under eIDAS Articles 21 and 22, a provider may begin a qualified service only after its qualified status appears in the trusted list, and each national list identifies both the QTSP and its qualified services. A certificate policy OID, CA certificate, repository page, or provider claim is not enough by itself.

The practical evidence set should show that relying parties were told how qualified-certificate reliance depends on the relevant EU trusted-list entry. Keep the public notice text, the CP/CPS or terms section it points to, and a mapping from the certificate service to the trusted-list service digital identifier.

For operational review, retain a dated validation record showing the trusted-list source checked, list signature or seal authentication result, QTSP name, service type and identifier, service status and status history considered, certificate profile or policy OID, path-validation result, revocation result, validation time, and procedure version. For a signature or certificate created in the past, validate status at the relevant time rather than relying only on the entry's current status. The record documents the reliance process; it does not replace the signed or sealed trusted list.

Use EN 319 411-2 to identify the relying-party notice obligation, then use the current trusted-list standards for the validation method. ETSI TS 119 612 V2.4.1 defines the trusted-list format and service digital identifier. ETSI TS 119 615 V1.3.1 specifies procedures for obtaining, authenticating, using, and interpreting EU Member State national trusted lists, including status at a specified date and time. Pin the procedure and trusted-list version used so a later reviewer can reproduce the result.

If the validation question is about whether a signature or seal qualifies, keep that separate from merely checking a certificate. EN 319 411-2 points to ETSI TS 119 172-4 for a signature validation policy that describes validation against EU trusted lists for European qualified electronic signatures or seals.

A TSP should handle QSCD by first selecting the right ETSI EN 319 411-2 qualified certificate policy. QCP-n-qscd applies to qualified certificates for natural persons where the private key corresponding to the certified public key resides in a QSCD. QCP-l-qscd applies to qualified certificates for legal persons under the same private-key-in-QSCD condition. Whether the provider and service have qualified status remains a separate eIDAS and trusted-list question.

The QSCD route brings in the ordinary QCP-n or QCP-l requirements and the NCP+ baseline, then adds QSCD-specific provisions. The standard ties those provisions to subject device provisioning, key pair and certificate usage, key generation and installation, certificate profile statements, and terms and conditions.

When the TSP manages the QSCD for the subject, ETSI EN 319 411-2 restricts use of the private key for signing to the QSCD and distinguishes natural-person sole control from legal-person control. The same area of the standard ties natural-person QSCD keys to electronic signatures and legal-person QSCD keys to electronic seals.

For key generation and installation, the TSP has to verify that the device is certified as a QSCD and ensure that the public key to be certified comes from a key pair generated by a QSCD. If a TSP generates the key pair and imports it into the signing or sealing QSCD, it must meet the certified devices' environmental assumptions and security objectives. If a private key moves between devices, it must identify compromise risks and implement adequate mitigations. The CPS must also state the measures taken when QSCD status changes during certificate validity.

Remote management has a separate legal service boundary. Under the amended eIDAS Articles 29, 29a, and 39a, generating or managing signature or seal creation data for a remote QSCD is a qualified trust service carried out by a QTSP that meets the remote-device management requirements. The transition that allowed other QTSPs to manage remote devices ended on 21 May 2026. The certificate issuer should therefore verify both the device certification and the current qualified status of any separate remote-QSCD management service.