TL;DR

ETSI TS 119 461 V2.1.1 changes the identity-proofing conversation for Qualified Trust Service Providers. Remote onboarding is no longer simply a matter of checking an identity document, running face matching and storing the result. The standard frames identity proofing as a trust-service component with two levels of confidence, Baseline and Extended Level of Identity Proofing, and it makes the security of biometric capture part of the compliance architecture.

The important change is not only that presentation attack detection matters. It is that injection attacks now have to be treated as a first-class threat: the attacker may not show a mask, a photo or a replayed video to the camera at all. They may bypass the camera and inject synthetic content directly into the capture flow. For QTSPs operating under the eIDAS transition, this creates a practical deadline problem. PAD, injection resistance, accredited testing, threat intelligence and documented use-case compliance need to be ready before the regulatory transition becomes an audit failure.

The quiet shift: identity proofing became infrastructure

For years, many trust-service discussions treated identity proofing as the opening ceremony of the certificate lifecycle. The applicant appears, the document is checked, the face is compared, the certificate is issued, and the serious cryptographic business begins afterwards. That mental model no longer matches the risk environment.

ETSI TS 119 461 V2.1.1 makes the opposite point. Identity proofing is not a preliminary formality. It is a trust-service component. It can be performed by the QTSP itself or by a specialized Identity Proofing Service Provider acting under the QTSP’s responsibility, but either way the relying trust service inherits the integrity of that proofing process. If the proofing process is weak, the certificate chain is not merely administratively incomplete; it is anchored to the wrong human being.

That is why the standard organizes identity proofing around evidence, validation, binding and proof issuance. The applicant is not just asked to submit identity data. The system has to collect authoritative evidence, validate the evidence, bind it to the applicant, and produce a result that can be defended later. The architecture has to survive hindsight.

The deepfake problem is not only a deepfake problem

The market often describes the new risk as “deepfakes.” That is understandable, but incomplete. A deepfake is content. The more important question is how that content enters the identity-proofing process.

A presentation attack happens in front of the capture device. A person may present a printed face, a screen replay, a mask, a manipulated document or another artefact to the camera. Presentation Attack Detection exists to determine whether the biometric sample is being captured from a real, live person present at the point of capture.

An injection attack is more architectural. The attacker does not necessarily need to fool the camera, because the camera may never see the attack. Instead, the attacker injects recorded, manipulated or AI-generated content into the data capture process. In practical terms, that can mean bypassing the camera feed with a synthetic video stream, replaying a previously captured onboarding session, or injecting a generated identity document into a remote verification workflow.

This distinction matters for QTSPs because traditional liveness checks were largely designed for the first problem. The second problem attacks the trust boundary between the applicant device, the capture process and the environment where the identity-proofing decision is made. In a remote process, that boundary is now one of the most important parts of the service.

What ETSI TS 119 461 actually asks for

The standard defines two outcomes: Baseline LoIP and Extended LoIP. Baseline is intended to reach a substantial level of confidence, while Extended is intended to reach a high level of confidence. The level claimed affects the risk model. For Baseline, the risk assessment must consider attackers with at least moderate attack potential. For Extended, it must consider attackers with at least high attack potential.

Compliance is not claimed in the abstract. An identity-proofing service has to identify the specific use case or use cases it supports, such as physical presence, attended remote identity proofing, unattended remote identity proofing, use of eID means or use of a digital signature with certificate. It then has to meet the requirements for the chosen use case and the claimed level of identity proofing.

For remote identity proofing with identity documents and face capture, the standard becomes especially consequential. The process must capture a video stream of the applicant’s face. It must apply presentation attack detection to ensure the stream is of a live person present in front of the camera at the time of the proofing. It must detect artificially generated or manipulated face appearance. It must protect the video stream’s authenticity, integrity and confidentiality. And it must apply biometric injection attack prevention and detection so that neither the applicant nor an external attacker can inject a previously recorded or artificially generated stream without detection.

That is the architectural turn. Face matching alone is not enough. Document validation alone is not enough. Liveness alone is not enough. The capture channel itself has to be defended.

The timeline turns technical debt into audit risk

The timeline matters because QTSPs do not have the luxury of treating these controls as future enhancements. The transition path introduces a sequence of compliance pressure points. Existing QTSPs for remote QSCDs and new QTSPs for qualified certificates face a 21 May 2026 conformity assessment report milestone for Article 24 compliance. ETSI TS 119 461 then sets an explicit technical preparation point before the end of 2026 for accredited laboratory testing of biometric injection attack detection and PAD evaluation. The broader QTSP transition reaches full framework completion in May 2027, followed by further Article 24 identity-verification alignment and the sunset of legacy SSCD certifications in August 2027.

This compresses the practical window. A QTSP cannot wait until the end of 2026 to discover whether its biometric provider can support injection detection, whether its PAD has been independently evaluated, whether its use case maps to Baseline or Extended LoIP, or whether its evidence-retention model can withstand conformity assessment. These are procurement, architecture, legal, operational and audit questions, not just model-performance questions.

The hidden operational burden: staying compliant after the test

The testing requirement is not the end of the story. ETSI TS 119 461 requires the IPSP’s risk assessment to be updated yearly, when identity-proofing processes change, and when findings from threat intelligence require it. The service has to adapt to new threats. Personnel training has to be reassessed when the threat landscape changes. PAD and injection-detection evaluation must be repeated at least every second year.

That matters because the attack surface is not static. Deepfake generation improves. Document manipulation improves. Device compromise methods improve. Attackers shift from visible presentation attacks to invisible injection attacks when the economics make sense. A biometric stack that passes a test once but does not evolve becomes a compliance liability over time.

For QTSPs, this changes the vendor question. The issue is not only whether a provider has face matching, liveness, document capture or an SDK. The issue is whether the provider can support a defensible identity-proofing component: documented use cases, attack-potential assumptions, PAD testing, injection-detection testing, evidence retention, operational threat intelligence and repeatable conformity support.

Why this is bigger than remote onboarding

The regulatory pressure around Article 24 is about identity verification, but the architectural lesson is broader. Trust services depend on the quality of the first binding between a legal identity and a human subject. If that binding can be created through a synthetic face, a replayed session or an injected stream, then every later cryptographic assurance inherits a human-assurance failure.

This is why remote identity proofing cannot be treated as a UX feature. It is part of the security perimeter of the trust service. In the eIDAS 2.0 environment, where wallets, qualified attestations, qualified certificates and remote signing services increasingly converge, the identity-proofing layer becomes the place where possession must be converted into ownership.

A device may be present. A credential may be presented. A document may be uploaded. A video may exist. None of that is enough unless the system can prove that the right person is present, alive, unmanipulated, connected through a trusted capture path and bound to the authoritative evidence.

Where Youverse fits architecturally

The direction of travel is clear: identity verification has to combine security with privacy, and it has to do so without creating new centralized biometric risk. That is where decentralized biometric architecture becomes strategically important.

Youverse approaches this problem from the premise that high-assurance identity should not require uncontrolled biometric centralization. YouID supports identity verification and onboarding flows. YouLive addresses liveness and attack resistance, including the problem space around spoofing, deepfakes and injection. YouAuth extends the logic into decentralized authentication, where the goal is to anchor a credential to the rightful face and make future use dependent on the correct person, not mere possession of a device or credential.

For QTSPs, the strategic question is therefore not whether biometrics are needed. ETSI TS 119 461 makes that question increasingly concrete in remote identity proofing. The real question is what kind of biometric architecture is acceptable for a trust-service future: one that accumulates sensitive identifiers in centralized systems, or one that proves identity and presence while reducing the concentration of biometric power.

Conclusion: the compliance clock is also an architecture clock

ETSI TS 119 461 should not be read as a checklist added to remote onboarding. It is a signal that identity proofing is becoming a regulated, testable and continuously monitored trust-service capability. PAD, injection detection, documented use cases and accredited evaluation are not decorative controls. They are becoming part of the foundation on which qualified trust is built.

For QTSPs, the immediate challenge is compliance. The deeper challenge is architectural. The next generation of trust services cannot rely on weak capture channels, static liveness, opaque vendor claims or biometric centralization. It needs identity proofing that can resist synthetic media, defend against injection, prove legitimate ownership and preserve privacy by design.

The clock is already running.

FAQ

What is ETSI TS 119 461?

ETSI TS 119 461 is a technical specification defining policy and security requirements for identity proofing as a trust-service component. It supports Baseline and Extended Levels of Identity Proofing and is relevant to QTSPs and identity proofing providers operating under eIDAS-related trust-service contexts.

Why does it matter for QTSPs?

QTSPs rely on identity proofing to bind certificates, attestations or trust-service subjects to the correct person or legal entity. If the identity-proofing layer fails, the downstream qualified trust service may be technically valid but anchored to the wrong identity.

When is presentation attack detection required?

Presentation attack detection is required in remote identity proofing where a natural person uses an identity document and the process captures the applicant’s face. The process must ensure that the video stream represents a live person present at the time of identity proofing.

When is injection detection required?

Biometric injection attack prevention and detection is required for remote face capture where attackers could inject a previously recorded or artificially generated video stream into the process. For Baseline LoIP, TS 18099 level Substantial testing applies; for Extended LoIP, level High testing applies.

What should QTSPs do now?

QTSPs should map their identity-proofing use cases, determine whether Baseline or Extended LoIP is required, assess PAD and IAD readiness, confirm accredited-testing pathways, update threat-intelligence procedures, and ensure that subcontracted identity-proofing providers can support conformity assessment evidence.