Every conformity assessment comes down to a list of questions, and the eIDAS audit questions a QTSP faces on identity proofing got harder with ETSI TS 119 461 v2.1.1. The reason is the testing behind it. Your attack detection now has to be evaluated by an accredited laboratory against a defined attacker, under ISO/IEC 19989-3 for presentation attacks and CEN/TS 18099 for injection, and that testing has to be repeated every two years. Injection is where the bar rose furthest, on the face and on the document. If you are a compliance or eIDAS lead preparing for your next assessment, this post is the auditor's list, answered in advance, so you can close the gaps and walk in already knowing what you will be asked.

In a Nutshell

• eIDAS Article 20 requires every QTSP to be audited by a conformity assessment body at least every 24 months, and ETSI TS 119 461 is the yardstick for the identity proofing part.
• On presentation attack detection, auditors look for an independent evaluation under ISO/IEC 19989-3, built on ISO/IEC 30107-3 testing and graded by the attack potential it resists.
• Injection is where the testing bar rose most, for the face and for the document, with accredited lab testing against CEN/TS 18099.
• A supplier's mapping to a standard and a certificate issued against it carry very different weight in an audit.
• ETSI TS 119 461 expects attack detection to be independently retested every second year, with the first test due before the end of 2026.
• You can self-assess against the same questions before the auditor arrives.

How does an ETSI TS 119 461 conformity assessment work?

Two layers sit on top of each other. The first is the audit eIDAS already requires of every qualified trust service provider. Under Article 20(1), as amended by Regulation (EU) 2024/1183, a QTSP is audited at its own expense at least every 24 months by a conformity assessment body. The audit confirms that the provider and its qualified services meet the Regulation and the cybersecurity risk-management measures of Article 21 of the NIS2 Directive. The resulting report goes to your supervisory body within three working days of receipt. Article 20(1a) adds that you inform the supervisory body at least one month before a planned audit, and it can ask to observe.

The second layer is the yardstick for identity proofing. Article 24 requires a QTSP to verify a person's identity before issuing a qualified certificate or a qualified electronic attestation of attributes, and Commission Implementing Regulation (EU) 2025/1566 names ETSI TS 119 461 v2.1.1 as the reference standard for that verification. The ETSI specification states in its scope that conformity assessment bodies can use it as the basis for confirming that an organization's identity proofing is trustworthy, and points to ETSI EN 319 403-1 for how assessors evaluate trust service providers.

In practice, the assessor reads your policies and practice statement, then your risk assessment, then samples evidence that your controls work as described. Two details in ETSI TS 119 461 shape everything that follows. Your risk assessment has to be updated every year. And the level of identity proofing you claim sets the bar for attack detection, with Baseline requiring you to consider attackers of at least moderate attack potential, and Extended requiring at least high. Our complete guide to remote identity proofing for QTSPs covers the wider process if you want the full map.

What evidence do auditors expect on presentation attack detection?

Presentation attack detection is the most familiar part of the list, but the evidence bar has moved. ETSI TS 119 461 makes both ISO/IEC 30107-3 and ISO/IEC 19989-3 normative references, and it sets the bar by the attacker your proofing has to resist. That is the language of ISO/IEC 19989-3, which takes the 30107-3 test method and adds an independent Common Criteria evaluation against a defined attack potential. So the evidence an assessor looks for is a 19989-3 evaluation, which builds the 30107-3 test method into an independent judgment of the attacker your presentation attack detection can resist.

Expect to be asked for four things. The evaluation result under ISO/IEC 19989-3, with the attack potential it resists and the attack instruments used. The scope, meaning which product version, which capture flow, and which platforms were tested. The laboratory and its accreditation. And the test date.

The attack potential has to match your claim. A result that shows resistance to moderate attack potential supports Baseline proofing, while Extended expects high. A lab's own level label, such as "Level 2" on a 30107-3 certificate, does not answer that question on its own. ISO/IEC 30107-3 sets out how to test and report, but it leaves levels undefined, so labs built their own schemes with their own attack sets and pass thresholds. Two "Level 2" results can rest on quite different tests, which leaves an assessor with no way to map either one to moderate or high attack potential. ISO/IEC 19989-3 closes that gap by grading every evaluation on the same attack potential scale, set out in ISO/IEC 19989-1 Annex F.

Scope is where well-prepared teams still lose points. A result can be valid and still fail to cover what you run in production, for example because it tested an older SDK version, or the web flow only while most of your applicants onboard on mobile. If you rely on a supplier's result, the auditor checks that its scope matches what you deployed. Our post on ISO/IEC 19989-3 and ISO/IEC 30107 explains how the two standards fit together.

What do they ask about injection, for the face and the document?

These are the newer questions, and the testing behind them is the most demanding on the list. ETSI TS 119 461 defines an injection attack (clause 3.1) as injecting content controlled by the attacker into the data capture process, with the example of bypassing the camera to feed in a recorded or generated video stream. That definition covers any capture step, so the assessor's questions follow both paths, the selfie and the photograph of the identity document.

Expect questions like these. How do you detect a virtual camera, an emulator, or a tampered SDK feeding your capture flow? Does that detection cover document capture as well as the face? Which standard was it tested against, and by whom? At what attack potential? CEN/TS 18099 is the reference here, and a normative reference in ETSI TS 119 461. Under clause 4.5, the standard expects your injection attack detection to be tested by an accredited laboratory, which attacks your capture flow and grades the result by the attack potential it resists, up to High. A demo or an internal test report will not carry the same weight, because the assessor is looking for that independent result.

The document path deserves the same attention as the face. Document checks have traditionally focused on authenticity, asking whether the passport is real, which is a different question from whether its image was really captured by the camera. ENISA's report on remote identity proofing covers attacks on both the face and the identity document, and a well-read assessor will ask about each. Our post on document capture injection attacks explains how injection works on the document path and what to ask a supplier.

How do auditors treat a mapping claim versus a certification?

This distinction decides more outcomes than any other on the list. A mapping is a supplier's own reading of how its product lines up against the clauses of a standard. It can be thorough and useful for design reviews. It is still self-declared.

A certification is a result an accredited laboratory produced by running the standard's attack methodology against the product, then recording the outcome at a stated level. The assessor's job is to confirm independent evidence. A certificate gives them something to verify. A mapping leaves them assessing the supplier's own account, with no lab result to point to, so expect follow-up requests.

Level is the second test. For Extended identity proofing, ETSI TS 119 461 expects your risk assessment to consider attackers of high attack potential, so the useful question is whether the evidence reaches High, on the path you are being asked about. Our post on why QTSPs need certification against CEN/TS 18099 and ISO/IEC 19989-3 sets out the full argument and the questions that separate the two on a supplier call.

Can you show current certification, not last cycle's?

A certificate answers the auditor's question only while it is current. ETSI TS 119 461 requires the means for biometric presentation attack detection and injection attack detection to be independently tested by an accredited laboratory every second year, and it sets the first round of that testing for before the end of 2026. That deadline is now weeks away.

The two-year testing cycle from ETSI and the 24-month audit cycle from eIDAS Article 20 run on similar rhythms, but they rarely start on the same day. A lab result dated 20 months before your audit will fall due for retesting well before the next one. So assessors ask when you last tested, when the next test is booked, which product version it will cover, and whether each platform you run is included. If a supplier provides your biometrics, ask for its retest dates so they line up with your audit cycle.

A readiness checklist you can self-assess against

Use the questions below as a dry run. For each one, the strongest answer is "yes, and here is the document." Anything you can only answer in words is worth closing before the assessment.

Scope and governance

1. Is your claimed level of identity proofing, Baseline or Extended, stated in your practice statement?
2. Was your identity proofing risk assessment updated within the last twelve months?
3. Does that risk assessment consider the attack potential your level requires, moderate for Baseline and high for Extended?
4. Have you scheduled your next Article 20 audit, with the supervisory body notified at least a month ahead?

Presentation attack detection

5. Is your presentation attack detection evaluated under ISO/IEC 19989-3, with the attack potential it resists stated?
6. Was that evaluation carried out by an accredited laboratory, and can you show its accreditation?
7. Does its scope match the product version, capture flow, and platforms you run in production?

Injection attack detection

8. Do you detect virtual cameras, emulators, and tampered SDKs in your capture flow?
9. Does that detection cover document capture as well as the face?
10. Has an accredited laboratory tested it against CEN/TS 18099, and at what level?
11. Can you show the result as a certificate, or only as a capability description or mapping?

Certification currency

12. When were your presentation and injection attack detection last independently tested?
13. Is your first ETSI TS 119 461 test complete or booked before the end of 2026?
14. Is the next two-year retest already on your calendar?

Supplier evidence

15. If a supplier provides your biometrics, can it hand you each report and certificate directly?
16. Will it carry the two-year retest across iOS, Android, and web for you?

Where Youverse stands

At Youverse, we build identity proofing for QTSPs to answer these questions with documents. Our presentation attack detection is certified to ISO/IEC 30107-3 at Levels 1 and 2, and our face matching is NIST-recognized. Our injection attack detection covers both the face and the identity document, a capability aligned with CEN/TS 18099. We are pursuing certification to CEN/TS 18099 at High and to ISO/IEC 19989-3, both in progress. That gives a certified 30107-3 foundation today and a route to certified answers on 19989-3 and 18099 High, across iOS, Android, and web.

Because ETSI TS 119 461 requires that testing to be repeated every two years, we carry the re-evaluation for you, so a QTSP building on Youverse inherits the evidence rather than standing it up in-house. On data protection, the stack supports compliance with GDPR, CCPA, and PSD2.

If your assessment is on the calendar, the best time to find a gap is before the auditor does. Book a readiness review and we will walk your identity proofing flow through the questions above, face and document.

FAQ

What does an ETSI TS 119 461 audit cover?

It covers how a QTSP proves identity before issuing a qualified certificate or attestation, including policies, the yearly risk assessment, evidence capture and validation, and binding the person to that evidence. The assessor checks that attack detection matches the claimed level, Baseline or Extended. That includes accredited lab evidence on presentation attack detection under ISO/IEC 19989-3 and injection attack detection under CEN/TS 18099, current within the standard's two-year testing cycle.

How often is a QTSP audited under eIDAS?

At least every 24 months. Article 20(1) of eIDAS, as amended by Regulation (EU) 2024/1183, requires a QTSP to be audited at its own expense by a conformity assessment body and to send the report to its supervisory body within three working days. Separately, ETSI TS 119 461 requires attack detection to be retested by an accredited lab every second year.

What evidence proves injection attack detection to an auditor?

The strongest evidence is a report or certificate from an accredited laboratory against CEN/TS 18099, stating the level, the product version, the platforms, and the test date. It should cover document capture as well as the face, since ETSI TS 119 461 defines injection as an attack on the data capture process as a whole. A capability description or mapping explains the design but remains self-declared.

What is the difference between a mapping claim and a certification in an audit?

A mapping is a supplier's own account of how its product lines up with a standard's clauses. A certification is an independent result an accredited laboratory issued after testing the product against the standard at a stated level. Auditors can verify a certificate directly, while a mapping usually leads to follow-up questions or a finding.