ETSI EN 319 411-2 Identity Proofing

Identity proofing depends on the certificate policy and the legal identity route. Identify whether the certificate uses QCP-n, QCP-l, QCP-n-qscd, QCP-l-qscd, QEVCP-w, QNCP-w, or QNCP-w-gen before reviewing the registration file.

The policy identifies what must be bound into the certificate: a natural person, a legal person, a natural person associated with an organization, or a website-authentication subscriber and domain. QSCD status is a separate key and device branch; it does not replace identity or attribute verification.

Current eIDAS Article 24(1a) allows identity verification, directly or through a third party, through an EU Digital Identity Wallet or notified eID means at assurance level high; a qualified signature or seal certificate issued through a permitted underlying route; another method that identifies the person with a high level of confidence and is confirmed by a conformity assessment body; or physical presence with appropriate evidence and procedures under national law. Methods may be combined when needed.

Article 24(1b) has a separate list for attributes, including a qualified electronic attestation of attributes. Record the identity route and attribute route independently when they differ. Regulation (EU) 2025/1566 makes ETSI TS 119 461 V2.1.1 Annex C.3, with adaptations, the reference standard from 19 August 2027; do not present that future application date as a current deadline that has already passed.

The proofing result must control issuance. EN 319 411-1 requires the TSP to check that the request is accurate, authorized, and complete against the identity evidence or attestation.

Compare the registration result, request, CP, and certificate profile before signing the certificate. Reject unsupported names, organization identifiers, roles, domains, representative authority, or other attributes. Route QSCD claims to a separate device and key check.

The registration record should let an auditor reconstruct the proofing decision. EN 319 411-1 calls for logging registration events and recording the documents or attestations used, unique identification data where applicable, storage location of copies, subscriber agreement choices, the entity accepting the application, validation method, and the receiving TSP or submitting Registration Authority where applicable.

Protect the record as personal data. Store only what the applicable route, policy, law, and evidence purpose require; restrict access; protect confidentiality and integrity; and state the retention period in the practice documentation. A public certificate or artifact should not expose the underlying identity documents.

The main failures are mismatches: the certificate contains an unsupported attribute, the registration record cannot show the route used, or the service applies old standard wording without the current legal adaptation.

Close each gap in the registration procedure, CPS, subscriber agreement, issuance gate, or evidence-retention process before issuing production certificates.