If you issue qualified certificates, Article 24 of eIDAS 2.0 has quietly changed your job. It moves the identity proofing question from “can we onboard this user remotely” to “can we defend the evidence behind the certificate we just issued.” A qualified certificate is not just a credential. It is a legal trust instrument, and it is only as strong as the proofing that sits underneath it.

This piece stays on what Article 24 forces you to prove. For the transition calendar, see our QTSP deadline deep dive.

In a Nutshell

• Article 24 of eIDAS 2.0 turns identity proofing into the evidence behind every qualified certificate, not a routine onboarding step.
• A qualified certificate is only as trustworthy as the proofing behind it. Bind the wrong person to it, and the legal instrument rests on a false identity.
• PAD and IAD defend different things. PAD catches attacks shown to the camera. IAD catches synthetic or replayed evidence injected into the capture channel.
• Injection is not only a face problem. The identity document runs through the same channel and needs the same protection.
• For QTSPs, the vendor question is what has been tested, to what standard, and by whom. Certified PAD and injection detection across face and document is the evidence that holds up in a conformity assessment.

Article 24 is really an assurance test

On the surface, Article 24 reads as a simple procedure. When issuing a qualified certificate, the QTSP must verify the identity of the person it is issued to. True enough, but that misses what the clause really demands. In practice, the QTSP has to rely on identity verification methods strong enough to carry the legal weight of qualified trust.

The regulation describes several routes. Identity may be verified through an electronic identification means or EUDI Wallet at Level of Assurance High, through an existing qualified certificate or qualified electronic signature, through in-person identification, or through another method whose compliance is confirmed by a conformity assessment body. Every one of them has to support a high-confidence answer to the same question. Is the subject receiving the qualified certificate genuinely the person being identified?

That is where many QTSP proofing programs need to reframe the problem. The question is no longer whether a remote flow can collect an ID document, compare a selfie, and produce an onboarding decision. Those are components. Article 24 pushes the QTSP toward a higher standard, where the process has to be defensible as a trust-service control. In other words, it turns identity proofing into evidence engineering.

The right person problem sits beneath every route

Every Article 24 route has a hidden dependency. Wallet, notified eID, qualified certificate, e-signature, in-person verification or a separately assessed method, the relying assumption is the same. The credential must be linked to the rightful person at the moment it matters.

That sounds obvious, until you attack a remote flow. An attacker does not need to beat the legal framework. They only need the weakest link between the identity evidence and the certificate, and there are several. A genuine document can be stolen. A real face can be replayed. A live-looking video can be synthetic. A valid document image can be swapped for another before it reaches the system. A clean-looking capture can hide a biometric stream that was injected below the app layer.

This is why “identity verification” is too broad a phrase for what QTSPs now manage. The more precise requirement is rightful presence. The process has to establish that the legitimate subject is present, live, participating, and bound to the issuance event. That is a much harder problem than confirming that a set of identity attributes exists, and it is the bridge between Article 24 and biometric assurance.

PAD and IAD answer different questions

Presentation Attack Detection and Injection Attack Detection are often discussed together, but they protect different parts of the process.

PAD focuses on attacks presented to the capture system. An attacker may hold up a printed face, replay a video on another device, use a mask, present a manipulated screen image, or attempt a deepfake-style visual presentation. PAD is about whether the system can tell that the biometric sample comes from a live human rather than an artifact. This is what ISO/IEC 30107-3 is for. The standard sets out principles and methods for assessing PAD mechanisms, reporting test results, and classifying known attack types. A provider that can show Level 2 PAD performance under ISO/IEC 30107 gives a QTSP something stronger than a claim of “liveness.” It gives a tested basis for saying the presentation layer has been evaluated against realistic spoofing pressure.

IAD addresses a different weakness. Injection attacks do not try to fool the camera. They bypass it. Instead of presenting a fake face to the sensor, the attacker replaces, replays, synthesizes or manipulates biometric data inside the digital pipeline. The system receives evidence that looks plausible, but the capture path has been compromised. A flow can have strong PAD and still be weak if the evidence can be injected after capture. PAD asks whether the face was presented live. IAD asks whether the evidence actually came from the trusted capture process. For qualified certificate issuance, both questions matter.

Can your stack catch an injected document, not just a face?

Most of the injection conversation focuses on the face. The identity document deserves the same scrutiny, because it travels through the same remote channel. If an attacker can inject a synthetic face stream, they can inject a generated or altered document image just as easily. A stack that defends the selfie but trusts whatever document arrives is only half secure.

ETSI TS 119 461 treats this as one requirement, not two. Injection detection has to cover both the biometric capture and the document capture, so neither a face stream nor a document image can be substituted without being caught. For QTSPs, the practical takeaway is simple. Ask whether a provider’s injection defense stops at the face, or whether it extends to the document your entire proofing decision depends on.

What does high confidence mean for vendor selection?

Article 24 does not reward vague assurance language. A QTSP has to explain why a proofing method is appropriate, how it is controlled, how it resists foreseeable attacks, and how the evidence can be examined during conformity assessment. That changes what vendor evaluation should look like.

A provider may claim “AI liveness,” “anti-spoofing,” “deepfake protection,” or “secure onboarding.” Those claims may be useful, but they are not enough on their own. QTSPs should ask what has been tested, against what standard, under what configuration, by which independent body, and with what scope. The gap between a product claim and assessment evidence is exactly where compliance risk accumulates.

A few questions worth putting to any provider, ours included:

• Does PAD have independent testing under ISO/IEC 30107, and at what level?
• Is injection detection independently certified, and to what level, or only mapped to a standard on paper? A mapping is a claim. A certification is evidence.
• Does injection detection cover the identity document as well as the face?
• How does the system distinguish live capture from replayed, synthetic or substituted input?
• What logs and artifacts are available for a conformity assessment?
• How are fallback reviews handled when a check is inconclusive?

The strongest demo is not always the strongest evidence. A smooth selfie flow may convert well, but Article 24 forces a different lens. What can be defended when the onboarding decision becomes the basis for issuing a qualified certificate?

ETSI TS 119 461 makes identity proofing an operational discipline

ETSI TS 119 461 V2.1.1 takes the Article 24 problem into the operational world of policy and security requirements for identity proofing components. It is not only about whether a person can be identified. It is about how the proofing process is structured, controlled and evidenced inside a trust-service context.

QTSPs do not run ordinary onboarding systems. They operate inside a trust infrastructure where the issuance process has to stay credible to relying parties, conformity assessment bodies and regulators. Identity proofing cannot be a black-box vendor step. It becomes part of the QTSP’s assurance perimeter. A serious Article 24 program maps the process layer by layer: identity route, subject binding, biometric capture, PAD, IAD across face and document, evidence preservation, human fallback, and logging. The output is not only a working user journey. It is a defensible control system, and certified biometric providers are what let a QTSP replace vague confidence with specific evidence.

Verified identity is not the same as verified transaction

A common weakness in digital identity architecture is the assumption that once an identity is verified, future use of it is automatically trustworthy. Qualified certificate issuance is not only about the identity record. It is about the transaction in which that identity is used.

A stolen document image, a live device session, a credential sitting in a wallet, none of these prove ownership on their own. A biometric match means nothing if the sample can be injected. Ownership exists only when the rightful holder is bound to the moment the credential is used. This is why holder binding is the real test. The certificate should not simply be issued to data that appears correct. It should be issued through a process that links the correct person to the issuance event. Remote proofing therefore has to combine identity evidence, liveness, anti-spoofing, anti-injection, session integrity and auditability into a single proof story.

Why this matters beyond compliance teams

The Article 24 shift affects more than legal and certification teams. It changes product design, fraud operations, security architecture and vendor management. For product teams, high-assurance proofing cannot be bolted on after the user journey is designed. The assurance flow is the product. For fraud teams, attack detection has to cover both presentation and injection, across the face and the document. For security teams, the biometric session becomes a protected path, not just a media upload. For executives, the risk is strategic. A QTSP that cannot defend its identity proofing cannot confidently scale qualified certificate issuance.

The companies that understand this early will not treat PAD and IAD as narrow technical controls. They will treat them as structural trust controls.

What you can prove is what counts

The compliance clock has started. The real question is what a QTSP can prove when an assessor looks back at how a certificate was issued.

The teams that treat biometric assurance as part of the trust service, rather than a late-stage integration, are the ones who will answer that comfortably.

Where Youverse stands

We built YouID, YouFace, YouLive and YouAuth for exactly this problem. 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 working toward the ETSI TS 119 461 standard that frames all of this for QTSPs. The stack runs across iOS, Android and web, and it secures the capture channel itself, not just the match. We handle identity data in line with GDPR, CCPA and PSD2.

In the proofing process Article 24 describes, YouID captures and validates the identity evidence, YouFace binds the person to that evidence, YouLive confirms genuine presence and resists spoofing, deepfakes and injection across both the face and the document, and YouAuth secures the credential after issuance so future use depends on the rightful person, not possession of a device.

FAQ

Why does Article 24 matter for QTSP identity proofing?

Article 24 requires QTSPs to verify the identity of the person receiving a qualified certificate or qualified attestation. In practice, that means relying on identity proofing methods that can support high-confidence, defensible issuance.

What is the difference between PAD and IAD?

PAD detects presentation attacks shown to the capture system, such as masks, printed images or replayed videos. IAD detects attacks that inject, replace or manipulate biometric data inside the digital pipeline.

Why is ISO/IEC 30107 relevant?

ISO/IEC 30107-3 defines principles and methods for assessing biometric presentation attack detection. Level 2 PAD performance gives QTSPs stronger evidence than a generic claim of liveness.

Why is injection attack detection becoming so important?

Remote attackers increasingly target software paths, virtual cameras, emulators and media streams. IAD helps prove that biometric evidence came from the trusted capture process rather than being substituted or injected.

Does injection detection apply to the identity document too?

Yes. The identity document is captured through the same remote channel as the face, so a generated or altered document image can be injected in the same way. Under ETSI TS 119 461, injection detection is required across both the face and the document.