ETSI EN 319 411-2 Compliance

The qualified policy identifier you include in a certificate communicates assurance properties to relying parties. It also determines which requirement sets apply and what evidence you need to retain.

Treat policy selection as a governance decision with documented rationale, clear service scope, and an owner who keeps CP, CPS, profile settings, and issuance operations synchronized.

EN 319 411-2 requires policy documentation to say clearly that it is for EU qualified certificates and whether QSCD use is required. It also expects PKI disclosure support and builds on the publication and repository responsibilities inherited from EN 319 411-1.

This is a common failure mode: documents exist, but they do not clearly communicate qualified status, QSCD expectations, or which version was in force when a certificate was issued.

EN 319 411-2 adds qualified identity-verification rules for natural persons and legal persons, and it defines a choice rule for qualified website-authentication policies depending on whether the subscriber is a natural or legal person.

The compliance requirement is not just to verify identity. It is to be able to demonstrate that identity verification was performed correctly, with traceable evidence and approval records.

QSCD-related policies require strong key-control boundaries. EN 319 411-2 includes conditional requirements for cases where the TSP manages the QSCD for the subject, and it pushes obligations into subscriber obligations when the subscriber or subject maintains the private key.

Your assessment story must be consistent: who has control, what operations occur, what device or module is in scope, and what evidence proves that signing stays inside the permitted QSCD boundary.

Qualified status has to be externally verifiable. EN 319 411-2 points to the trusted-list ecosystem, including ETSI TS 119 612, ETSI TS 119 615, and ETSI TS 119 172-4, because relying parties validate qualified status against those materials.

A mature qualified program knows exactly how each service maps to trusted-list entries, how relying parties validate that mapping, and how support teams explain it during customer due-diligence reviews.

EN 319 411-2 inherits the EN 319 411-1 lifecycle and status-service expectations and also references status and certificate-profile mechanisms relevant to long-lived validation such as OCSP ArchiveCutOff and expired revoked certificates on CRLs.

In practice, auditors and relying parties care about status freshness, availability, interpretation rules, and whether the infrastructure behaved consistently with the qualified policy in force.

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

Operationally, this forces a maintenance program. You must track changes, assess impact, implement updates, and refresh CPS and evidence accordingly.

The strongest evidence is operational: logs, case records, configuration history, monitored controls, and trusted-list proof generated by your systems. Build an evidence index that links every requirement family to its proof and latest verification results.

A qualified program should be able to answer quickly which policy was asserted, why it was appropriate, how identity was verified, how QSCD boundaries were enforced, how qualified status was validated, and how revocation and status services performed.