Article 24 is not just a legal clause. It is an assurance test.

The easy way to read Article 24 is procedural: when issuing a qualified certificate, the QTSP must verify the identity of the natural or legal person to whom the certificate is issued. That reading is accurate, but incomplete. The operational meaning is much sharper. Article 24 requires the QTSP to rely on identity verification methods that can carry the legal weight of qualified trust.

The regulation describes several possible 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 identification method whose compliance is confirmed by a conformity assessment body. The important point is not that Article 24 creates multiple routes. The important point is that every route must 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 identity proofing programmes 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: the process must be defensible as a trust-service control.

In other words, Article 24 turns identity proofing into evidence engineering.

The “right person” problem sits beneath every compliant route.

Every Article 24 route has a hidden dependency. Whether the QTSP uses a wallet, a notified eID, a qualified certificate, an e-signature, in-person verification or a separately assessed identification 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 remote identity proofing is attacked. Attackers do not need to defeat the entire legal framework. They only need to exploit the weakest step in the chain between identity evidence and certificate issuance. A document can be genuine but stolen. A face can match but be replayed. A video can look live but be synthetic. A capture session can appear clean while the biometric stream has been injected beneath the application layer.

This is why “identity verification” is too broad a phrase for what QTSPs now have to manage. The more precise requirement is rightful presence: the process must establish that the legitimate subject is present, live, participating, and bound to the issuance event. That is a much harder problem than verifying that a set of identity attributes exists.

For QTSPs, rightful presence is the bridge between Article 24 and biometric assurance. Without it, a remote identity flow can produce a confident-looking decision while failing the trust question that qualified certificate issuance actually depends on.

PAD answers one question. IAD answers another.

Presentation Attack Detection and Injection Attack Detection are often discussed together, but they protect different parts of the identity proofing 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 subject rather than from an artefact.

That is why ISO/IEC 30107-3 matters. The standard establishes principles and methods for assessing PAD mechanisms, reporting testing results, and classifying known attack types. For QTSPs, a provider that can show Level 2 PAD performance under the ISO/IEC 30107 testing framework gives the organisation something stronger than a claim of “liveness.” It gives a tested basis for saying that the presentation layer has been evaluated against realistic spoofing pressure.

IAD addresses a different weakness. Injection attacks do not necessarily try to fool the camera. They may bypass it. Instead of presenting a fake face to the sensor, the attacker attempts to replace, replay, synthesize or manipulate biometric data inside the digital pipeline. The system receives biometric evidence that looks plausible, but the capture path has been compromised.

This distinction is critical for QTSPs. A flow can have good PAD and still be weak if the biometric evidence can be injected after capture. A camera-facing defence is not enough when modern remote attacks increasingly target software paths, virtual devices, emulators, media streams and session integrity. 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.

The phrase “high confidence” should change the vendor conversation.

Article 24 does not reward vague assurance language. QTSPs need to be able to explain why an identity proofing method is appropriate, how it is controlled, how it resists foreseeable attack paths, and how the evidence can be examined during conformity assessment. That changes what vendor evaluation should look like.

A biometric provider may claim “AI liveness,” “anti-spoofing,” “deepfake protection,” or “secure onboarding.” Those claims may be useful, but they are not enough by themselves. 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.

For PAD, the practical benchmark is whether the provider can demonstrate Level 2 testing aligned with ISO/IEC 30107. For IAD, the question is whether the provider can demonstrate a high-assurance approach to biometric injection detection, including protection against manipulated or substituted biometric streams before the identity proofing decision is made.

The deeper lesson is that QTSP vendor selection should not be led by user-experience demos alone. The strongest demo is not always the strongest evidence. A smooth selfie flow may convert well, but Article 24 forces a different procurement 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 is important because it brings the Article 24 problem into the operational world of policy and security requirements for trust service components providing identity proofing of trust service subjects. It is not merely about whether a person can be identified. It is about how the proofing process is structured, controlled and evidenced inside a trust-service context.

That distinction matters because QTSPs do not operate ordinary onboarding systems. They operate within a trust infrastructure where the issuance process must remain credible to relying parties, conformity assessment bodies and regulators. Identity proofing therefore cannot be treated as a black-box vendor step. It becomes part of the QTSP’s assurance perimeter.

A serious Article 24 programme should therefore map the identity proofing process layer by layer: identity route, subject binding, biometric capture, PAD, IAD, evidence preservation, human fallback, logging, privacy controls and incident handling. The output is not only a working user journey. It is a defensible control system.

This is where certified biometric providers become strategically useful. They allow QTSPs to replace vague confidence with specific evidence: what was tested, which attack classes were considered, how detection works at capture and pipeline level, and how results can support the wider conformity assessment story.

The weak point is often the gap between “verified identity” and “verified transaction.”

A common weakness in digital identity architecture is the assumption that once an identity has been verified, future use of that identity is automatically trustworthy. But 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 is not ownership. A device session is not ownership. A credential in a wallet is not ownership unless the rightful holder is bound to its use. A biometric match is not enough if the sample can be injected. Article 24 forces QTSPs to narrow the gap between verified identity and verified transaction.

That is why the concept of holder binding matters. The certificate should not merely be issued to data that appears correct. It should be issued through a process that links the correct person to the issuance event. Remote identity proofing must therefore combine identity evidence, liveness, anti-spoofing, anti-injection, session integrity and auditability into a single proof story.

This also explains why relying exclusively on identity schemes that do not meet the required assurance level can become risky. If a route does not establish high-confidence rightful presence, QTSPs may need to supplement it with compliant identity verification methods or adopt a different route entirely.

Privacy cannot become the casualty of stronger proofing.

There is an obvious trap in this discussion: stronger biometric assurance can be misread as permission to centralize more biometric data. That would be the wrong lesson.

Biometrics are powerful precisely because they are hard to replace. That makes them dangerous when stored carelessly, aggregated unnecessarily or treated as ordinary authentication data. If a password leaks, it can be changed. If a biometric template is exposed or misused, the user cannot simply issue themselves a new face.

For QTSPs, the goal should not be “more biometrics.” The goal should be better biometric architecture. That means minimizing stored biometric data, avoiding unnecessary biometric honeypots, separating proofing from surveillance, using privacy-preserving designs, and ensuring that the identity proofing method proves rightful presence without creating a permanent biometric risk reservoir.

This is where the Article 24 conversation becomes larger than compliance. High-assurance identity proofing must be both secure and privacy-preserving. Otherwise, QTSPs solve the spoofing problem by creating a data-protection problem — and that is not a sustainable trust model.

What QTSPs should ask before choosing an identity proofing partner.

The most useful procurement questions are not generic. They should be tied to the assurance problem Article 24 creates.

A QTSP should ask: does the provider support identity proofing routes that can align with Article 24? Is PAD independently tested under ISO/IEC 30107, and at what level? What evidence exists for injection attack detection? Does IAD protect the capture pipeline or merely inspect media after the fact? How does the provider distinguish live capture from replayed, synthetic or substituted input? What logs and artefacts are available for assessment? How are fallback reviews handled? How is biometric data minimized? How are privacy and data protection risks controlled?

The purpose of these questions is not to make procurement harder. It is to stop QTSPs from discovering too late that a vendor solved the visible onboarding problem but not the qualified-trust problem.

In Article 24 terms, the right vendor is not the one that produces the nicest capture screen. It is the one that helps the QTSP prove the person, the presence, the channel and the evidence path.

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, vendor management and business continuity.

For product teams, high-assurance identity proofing cannot be bolted on after the user journey is designed. The assurance flow is the product. For fraud teams, attack detection must cover both presentation and injection. For security teams, the biometric session becomes a protected path, not just a media upload. For legal teams, evidence quality becomes part of the compliance posture. For executives, the risk is strategic: a QTSP that cannot defend 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.

The architectural direction: prove the person without creating a biometric honeypot.

The strongest future model for QTSP identity proofing is not merely remote, automated and fast. It is remote, automated, high-assurance and privacy-preserving.

That is the direction companies such as Youverse are pushing toward. YouID is relevant to identity verification and onboarding flows where the organisation must prove the person behind the transaction. YouLive is relevant to liveness, presentation attack detection, deepfake resistance and injection-aware biometric assurance. YouAuth is relevant where the longer-term problem becomes credential ownership: anchoring use of a credential to the rightful person, not merely to possession of a device or document.

The important point is architectural, not commercial. QTSPs need a model that can prove rightful presence and protect the biometric evidence path while avoiding unnecessary centralization of biometric data. That is the trust architecture Article 24 is pushing the market toward.

Conclusion: Article 24 makes identity proofing the core trust service control.

The compliance clock has already started ticking, but the most important question is not the clock. It is what QTSPs will be able to prove when the clock is inspected.

Article 24 raises the identity proofing bar because qualified certificates depend on more than correct identity attributes. They depend on rightful presence, secure capture, resistance to spoofing, resistance to injection, defensible evidence and privacy-preserving architecture.

That is why IAD High and ISO/IEC 30107 PAD Level 2 matter. They are not feature labels. They are signals that the biometric layer has been tested against the kinds of attacks that can undermine qualified trust.

The QTSPs that understand this shift will not frame biometric assurance as a late-stage integration problem. They will treat it as part of the trust service itself.