What ETSI TS 119 461 requires from QTSPs for remote identity proofing

If you are a QTSP issuing qualified certificates or running a trust service, the rules for proving who someone is remotely have shifted under you. ETSI TS 119 461 V2.1.1 rewrote what a remote identity check has to withstand, and Article 24 put a clock on it. The harder question is the one your next conformity assessment will ask. Can your identity proofing satisfy an assessor and shut out an attacker at the same time?

In a Nutshell

• ETSI TS 119 461 V2.1.1 reframes identity proofing as a trust-service component with two levels of confidence, Baseline and Extended, and makes the security of biometric capture part of compliance.
• Remote onboarding is no longer checking a document, matching a face, and storing the result. The capture channel itself now has to be defended.
• Injection is now a first-class threat across both the face and the identity document. The attacker skips the camera and feeds synthetic content straight into the capture flow, whether a face stream or a generated document image.
• Baseline aims for a substantial level of confidence and Extended for a high level. The higher the level, the stronger the attacker it must withstand and the tougher its CEN/TS 18099 testing.
• For QTSPs, PAD, injection resistance, accredited testing, and documented use cases have to be ready before the transition becomes an audit failure. The immediate deadline runs to the end of 2026.

Identity proofing is now security infrastructure

For years, many trust-service discussions treated identity proofing as a formality to clear before the real work started. The applicant appears, the document is checked, the face is compared, the certificate is issued, and the cryptography takes over. That mental model no longer matches the risk environment.

ETSI TS 119 461 V2.1.1 makes the opposite point. Identity proofing is a trust-service component in its own right. It can be performed by the QTSP itself or by a specialized Identity Proofing Service Provider (IPSP) 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 result has to hold up when an auditor looks back on it.

How does a deepfake get into identity proofing?

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 artifact 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.

The document example deserves as much attention as the face one. Injection is not only a face problem. The identity document is captured through the same remote channel, so a manipulated or fully generated document image can be injected just as a face stream can. A stack that defends the selfie but trusts whatever document image arrives leaves half the process exposed.

This matters for QTSPs because traditional liveness checks were largely designed for the presentation problem. The injection 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 does ETSI TS 119 461 actually require?

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 never a general claim. 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.

The same protection extends to the document-capture path. Where the process relies on a captured image of an identity document, that capture has to be defended against injection too, so an attacker cannot substitute a generated or altered document image for a genuine one. Injection detection is therefore a requirement across both biometric capture and document capture, not a face-only control.

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

QTSPs do not have the luxury of treating these controls as future enhancements. The transition path introduces a sequence of compliance pressure points, and several are now close.

The first has already landed. Existing QTSPs for remote QSCDs and new QTSPs for qualified certificates faced a conformity assessment report milestone in May 2026 for Article 24 compliance. The next one is nearly here. ETSI TS 119 461 sets an explicit technical preparation point before the end of 2026 for accredited laboratory testing of biometric injection attack detection and PAD evaluation, now only months out. The broader QTSP transition then 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 biometrics, built in-house or supplied by a vendor, can support injection detection across face and document, 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.

Compliance does not end when the test passes

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.

The attack surface is not static. Deepfake generation, document manipulation, and device compromise all keep improving. 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. It is no longer whether a provider has face matching, liveness, document capture or an SDK. It is whether the provider can stand behind a defensible identity-proofing component. That means documented use cases, attack-potential assumptions, PAD testing, injection-detection testing across face and document, evidence retention, operational threat intelligence, and repeatable conformity support.

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.

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 across face and document, 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 structural. The next generation of trust services cannot rely on weak capture channels, static liveness or opaque vendor claims. It needs identity proofing that can resist synthetic media, defend against injection on both the face and the document, prove legitimate ownership and hold up under repeated evaluation.

Where Youverse stands

We are certified to ISO/IEC 30107-3 Level 1 and 2 for presentation attack detection, and our face matching is NIST-recognized. We build injection attack detection for both the face and the identity document, a capability aligned with CEN/TS 18099, and we are taking the stack through certification against CEN/TS 18099 and ISO/IEC 19989-3, pursuing the higher testing level for the extended path. We are also working toward the ETSI TS 119 461 standard that makes this the baseline for QTSPs. Our stack runs across iOS, Android and web, and it secures the capture itself, not just the match. We handle identity data in line with GDPR, CCPA and PSD2.

Across our stack, YouID captures and validates the identity evidence, YouFace binds the person to that evidence, YouLive confirms genuine presence and resists spoofing, deepfakes and injection, and YouAuth secures the credential after issuance so future use depends on the correct person rather than mere possession of a device.

For QTSPs, the question is no longer whether biometrics are needed. ETSI TS 119 461 has settled that for remote identity proofing. What counts now is whether the biometric component can withstand an attacker and satisfy an auditor at the same time.

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 capture where attackers could inject a previously recorded or artificially generated stream into the process, and it applies to the identity document capture as well as the face. For Baseline LoIP, TS 18099 level Substantial testing applies. For Extended LoIP, level High testing applies.

What should QTSPs do now?

QTSPs should start by mapping their identity-proofing use cases and determining whether Baseline or Extended LoIP applies. Next, they should assess PAD and injection-detection readiness across face and document, and confirm their accredited-testing pathways. Finally, they should update their threat-intelligence procedures and make sure any subcontracted identity-proofing providers can support conformity assessment evidence.