Artifact GuideGLOBALETSI EN 319 411-2

ETSI EN 319 411-2 Identity Proofing

Choose a current eIDAS identity-verification route, then map the policy profile, subject, attributes, domain link, and registration evidence required before issuance.

Use EN 319 411-2 V2.6.1 with the binding adaptations in Regulation (EU) 2025/1943; the identity reference standard in Regulation (EU) 2025/1566 applies from 19 August 2027.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 2026

Overview

For a qualified certificate, must establish the person and each certified attribute through a route allowed by current eIDAS Article 24, then retain evidence that the certificate request matches the verified result. Do not treat the unadapted EN 319 411-2 wording about physical presence or equivalent assurance as the complete current-law route list: Regulation (EU) 2025/1943 replaces the relevant signature and seal certificate clauses with references to Article 24(1c) implementing acts.

Section 1

Start with the certificate policy and subject type

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.

For QCP-n and QCP-n-qscd, prove the natural person's identity and any certificate attributes before issuance.
For QCP-l and QCP-l-qscd, prove the legal person's identity and the authority of the representative used for the registration.
For QEVCP-w, QNCP-w, and QNCP-w-gen, prove the subscriber identity and the subscriber's link with the domain name to be certified.
For a natural person associated with a legal person, keep the natural person as the subject identifier and ensure organization attributes represent the legal person or its sub-entity, as required by the Regulation (EU) 2025/1943 adaptation.
For QSCD policy profiles, keep the identity decision aligned with the separate QSCD and certificate-request checks.

Sources for this answer

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Defines the qualified certificate policy identifiers and the additional identity-validation requirements for natural-person, legal-person, and qualified website certificate profiles.

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements

Provides the general subscriber, subject, registration service, and certificate lifecycle requirements that EN 319 411-2 imports.

Commission Implementing Regulation (EU) 2025/1943

Adapts initial identity validation and certificate issuance for qualified signature and seal certificates, including natural persons associated with legal persons.

Section 2

Choose and document the verification route

Current eIDAS Article 24(1a) allows , 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.

Record the exact Article 24 route or combination used, the proofing provider, the authoritative or attesting source, the verification result, and any conformity assessment or national-law dependency.
For a natural person, retain evidence for the name and each specific attribute that the certificate will contain; do not collect extra identity data merely because the system can.
For a legal person, retain the legal-person evidence and, where the route uses a representative, the person's identity and current authority to act.
For a website certificate, retain the subscriber-to-domain link in addition to the identity and attribute evidence.
For remote or delegated proofing, record impersonation controls, handoffs, failed checks, and the basis for accepting the result.

Sources for this answer

Consolidated Regulation (EU) No 910/2014, Article 24

Binding current routes for identity and attribute verification when a QTSP issues a qualified certificate.

Commission Implementing Regulation (EU) 2025/1943

Replaces the adapted QCP-n and QCP-l identity clauses with verification under Article 24(1c) implementing acts.

Commission Implementing Regulation (EU) 2025/1566

Sets ETSI TS 119 461 V2.1.1 Annex C.3, with adaptations, as the identity and attribute verification reference standard from 19 August 2027.

Section 3

Check the certificate request against the evidence

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.

Block issuance when the certificate request includes an identity attribute not supported by the registration evidence.
Block issuance when a legal-person representative is not supported by mandate, corporate registry, or other authorized-source evidence.
Block issuance when a website certificate lacks evidence linking the subscriber to the domain name being certified.
Block issuance when the requested identity or attribute route does not meet current Article 24, applicable national law, or the binding adaptation used by the service.
Block issuance when a QSCD policy identifier or statement lacks the separate QSCD route evidence.

Sources for this answer

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Connects qualified certificate profile selection, identity validation, website authentication profiles, and QSCD-specific certificate handling.

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements

Requires certificate requests to be accurate, authorized, and complete against the collected identity evidence or attestation.

Recommended next step

Operationalize identity proofing

This ETSI EN 319 411-2 guidance helps align certificate profiles, registration procedures, certificate-request gates, and evidence records.

Assessment workflow

Open Assessment Autopilot for ETSI EN 319 411-2

Convert identity-proofing checks into accountable tasks, registration evidence requests, and audit review milestones.

Explore next step

Research workflow

Research ETSI EN 319 411-2 source questions

Use cited source material to resolve profile, registration, evidence, and certificate-request questions before implementation.

Explore next step

Talk to Sorena

Talk through implementation

Review identity-proofing scope, evidence gaps, owners, and the next certificate-service actions with Sorena.

Explore next step

Section 4

Keep registration records an auditor can replay

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.

Log each registration event, including certificate re-key or renewal requests when identity evidence is reused or refreshed.
Record the type of identity document or authorized attestation presented and the validation method used.
Record where application copies, identity documents, and subscriber agreements are stored rather than embedding sensitive material in public-facing artifacts.
State the retention period for registration information in the practice statements and identify what would be handed over through a termination plan.

Sources for this answer

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements

Lists the registration information to record, including document type, identification data, storage location, agreement choices, accepting entity, validation method, and RA/TSP information.

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Maps qualified certificate policy requirements to eIDAS article 24 identity verification and recordkeeping expectations without presenting the annex as a legal-conformance statement.

Section 5

Common identity-proofing gaps

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.

Using a QCP-n or QCP-l profile without recording whether the subject is a natural person, legal person, or natural person associated with a legal person.
Treating physical presence and equivalent assurance as the only current legal routes, or accepting a remote route without the Article 24, conformity-assessment, implementing-act, or national-law basis it requires.
Approving a website authentication certificate without evidence linking the subscriber identity to the domain name.
Keeping copies of identity evidence without a clear storage location, access model, retention period, and privacy control.
Publishing broad qualified-certificate claims while the CPS, certificate policy identifier, subscriber agreement, and registration record are not aligned.

Sources for this answer

ETSI EN 319 411-2 V2.6.1 EU qualified certificate requirements

Supports the policy-specific identity and website-link structure; its unadapted identity wording must be read with the current legal adaptations.

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements

Supports the registration-record, CPS, subscriber/subject, privacy, and certificate-request controls summarized in the gap list.

Consolidated Regulation (EU) No 910/2014, Article 24

Current legal routes and conditions for identity and attribute verification.

Primary sources