Talk to usTry the demo

ETSI TS 119 461: Identity Proofing for Trust Services

Regulation and standards

For: Compliance lead or product owner of a provider that proves identities remotely for trust services or regulated onboarding

What the ETSI technical specification on identity proofing requires: two levels of identity proofing, evidence, remote document validation, face binding, attack testing and evidence retention.

You lead compliance or product at a provider that proves identities remotely, and you keep meeting one reference: the ETSI technical specification TS 119 461. This article answers a narrow question: what does the specification ask of an identity proofing process, which parts of it are requirements for remote capture of documents and faces, and how does European law point to it?

For information; not legal advice.

The article reads version 2.1.1 of the specification, dated February 2025, together with the two European legal texts that connect to it. It describes requirements in the words of the specification, using short quotations where the exact wording matters, and it does not state that any product conforms to the specification.

What the specification is and who it is for

The full title is "Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service components providing identity proofing of trust service subjects". Its introduction defines identity proofing as the process of verifying with the required degree of reliability that the purported identity of an applicant is correct. The scope is the identity proofing of applicants who are to be enrolled as subjects or subscribers of a trust service provider.

Two actors matter. The trust service provider can carry out the identity proofing itself as an integral part of its service. It can also hand the task to a specialised identity proofing service provider that acts as a subcontractor and can serve several trust service providers. The specification applies to both arrangements, and it explains why: neither version of the eIDAS Regulation defines identity proofing as a trust service on its own, so a specialised provider is not a trust service provider as such but acts under the responsibility of the one that subcontracted the work. That is why the document speaks of a "trust service component".

The specification can be used by conformity assessment bodies as the basis for confirming that an organisation is trustworthy and reliable in its identity proofing process. It also says that the document may have wider applicability than its defined scope, while any application for purposes other than trust services is out of its scope. For a bank, a payment institution or an exchange that is not a trust service provider, the specification is therefore a reference to study, not a rule that applies to its onboarding by its own force.

The two levels of identity proofing

The specification provides requirements for two Levels of Identity Proofing, called Baseline and Extended. It defines the Baseline level as reaching a substantial level of confidence on the basis of good practice minimum requirements for the identity proofing process. It defines the Extended level as reaching a high level of confidence on the same basis. The Baseline level is considered suitable for issuing qualified certificates under the original eIDAS Regulation, Regulation (EU) No 910/2014, while the Extended level is considered suitable for qualified certificates and qualified electronic attestations of attributes under the amended Regulation.

The levels are not an overall rating of a company. The result of an identity proofing process conveys the level achieved for the identity attributes required to identify the applicant uniquely in the context at hand. A provider that wishes to claim compliance has to identify the use cases it applies and fulfil all relevant requirements for each use case.

Five tasks and an identity proofing context

The specification breaks identity proofing into five tasks. They are initiation, attribute and evidence collection, attribute and evidence validation, binding to applicant, and issuing of the identity proofing result. The tasks need not run as consecutive steps, and a process can be synchronous, with every step in one continuous run, or asynchronous, with validation, binding and issuing done later.

Binding to applicant is defined as the part of the process that verifies that the applicant is the person identified by the presented evidence. Validation is defined as the part that determines whether attributes are validated by the presented evidence and whether the evidence is genuine, authoritative and valid.

The specification covers initial identity proofing of a new applicant. It does not consider simplifications for a known subject, for example where identity proofing is repeated regularly, and continuous identity proofing, where the behaviour of a subject over time shapes the likelihood that the identity is correct, is out of scope.

Around the five tasks sits what the document calls the identity proofing context. It is the set of external conditions, in particular the regulatory requirements for the purpose at hand, that can restrict the level required, the attributes to collect, the evidence to use, the means of validation and binding, and what may be retained as evidence of the process. The specification gives an example: in some countries retaining a photocopy of an identity document is required as part of the evidence, and in others it is prohibited.

Evidence: authoritative and supplementary

An identity proofing process under the specification uses authoritative evidence, which is issued by an authoritative source and is trusted for the identity attributes it conveys. For a natural person, at least one of four types must serve as authoritative evidence: a physical identity document, a digital identity document, an electronic identification means used in an authentication protocol, or the certificate of a digital signature. A digital identity document is one issued in a machine-processable form that is digitally signed by the issuer, and the document notes that the electronic part of a passport or national identity card, the eMRTD, counts as one.

Supplementary evidence strengthens the result or evidences attributes that the authoritative evidence does not. The specification names three kinds: a trusted register, proof of access, in particular to a bank account, and documents and attestations. A national population register can be the authoritative source for information about the applicant, but only when the applicant's identity is also proven by one of the authoritative evidence types.

For physical identity documents, the specification accepts only passports, national identity cards and other official documents that offer the same or higher reliability in the identity proofing context. Comparable reliability is to be judged by comparing the security features and issuance process of the other document with those of a passport or identity card. Where an electronic identification means serves as evidence, the specification asks for the assurance level "substantial" under eIDAS, or a comparable framework, for the Baseline level and the level "high" for the Extended level.

Threats the requirements answer

The requirements address four main kinds of threat. The first is an impostor who uses falsified or counterfeited evidence, and the second is an impostor who uses genuine evidence associated with another person. The third is an attack on the information systems used for identity proofing, and the fourth is social engineering of the legitimate owner of the evidence.

For remote identity proofing that uses identity documents, the specification names two attack types of particular concern.

Presentation attack, where use of falsified or counterfeited evidence or impersonation is attempted in front of the camera used to capture evidence.

Injection attack, where camera or other sensors are bypassed injecting recorded or artificially generated video streams as falsified or counterfeited evidence or impersonation.

It adds that artificially generated content, called deep fakes, is increasingly used by impostors, either as a deep fake of a victim's face or as a generated representation of a physical identity document. According to the document, an attacker needs to combine such content with a presentation or injection attack, and protection includes both prevention and detection of those attacks and of deep fakes.

Operational requirements for the provider

Before the process steps, the specification sets requirements for the provider itself. The risk assessment of the identity proofing service shall be updated yearly and whenever an identity proofing process is changed. It shall cover at least the risks related to identity fraud and the risks related to information systems security. The provider shall have a documented and effective procedure for threats intelligence, so that the service adapts to new threats.

The attacker the provider plans for depends on the level claimed. If the Baseline level is claimed, the risk assessment shall consider at least attackers with moderate attack potential, and if the Extended level is claimed, at least attackers with high attack potential. The provider shall also state in its practice statement goals for quality and security in terms of resilience to false acceptance and false rejection of applicants, and perform regular testing of its performance against these goals.

Management and operation requirements are mostly inherited from the general policy requirements for trust service providers. One addition is specific to identity proofing: the information system making the identity proofing decision shall be logically or physically separated from non-critical information systems, such as office support systems.

Initiation and attribute collection

The applicant has rights before anything is captured. The applicant shall be informed of, and shall actively accept before the process starts, the purpose of the identity proofing and the related terms and conditions. The applicant shall also receive clear guidance on how the process will be carried out, on the identity information that will be collected, on what data is kept and for how long, on the evidence to present and on any tool to be used. Where alternative processes exist, the applicant should be allowed to select among them, and at least one process shall be available to persons with disabilities in accordance with applicable legislation.

For a natural person, the minimum attributes are the family name or names and the first name or names, together with whatever further information is needed to identify the applicant uniquely in the context. The attributes to collect are otherwise determined by the identity proofing context.

The identity proofing process shall not collect identity attributes that are not included in the result of the identity proofing, except when such attributes are required for attribute and evidence validation and/or binding to applicant.

This is a data minimisation rule written into a technical specification. It means that fields read from a document that play no part in the result, in validation or in binding are not to be collected at all.

One further requirement concerns the quality of attributes. The provider's practice statement shall also specify how differences in name attributes between evidence and other sources are handled, for example differences caused by transcription between alphabets, by national characters or by truncation to fit a document.

Validating a physical identity document remotely

This clause carries the most detail for teams that capture documents with a camera. In a remote process the provider shall ensure that the applicant has the document in hand and presents it in real time in front of a camera. A pre-recorded photo or video stream of an identity document is considered not to meet the requirements for the Baseline or the Extended level. The applicant's presentation shall include a recording at the time of the identity proofing of a video sequence that shows the physical characteristics of the document and its security features, covering each relevant side. A still photo alone is not considered sufficient with the current state of technology.

The specification gives an example of sufficient quality: a frame rate of 25 frames per second and a resolution of 1280 by 720 pixels or 960 by 720 pixels in landscape. Whatever the figures, the process shall assess the usability of the video and images, for example lighting conditions, reflections and sharpness, and reject captures that are not usable with instructions to repeat under better conditions. There shall be an upper limit on the number of retries on the video capture before the process is aborted with a failed result.

The security feature rules are specific. A sufficient number of, and at least three, different security features of physical identity documents shall be reliably verified considering an attacker with the relevant attack potential. For a remote process, at least two of the security features verified shall be optically variable features. The document draws the consequence itself: a document with fewer than two optically variable features cannot be used in remote identity proofing. The selection of which variable elements to verify should have some randomness, to hamper attackers who target the falsification of specific elements.

Four more controls complete the picture. If the document has a machine readable zone, its information shall be extracted, validated and compared with the information from the visible part of the document. If an online status service to confirm the validity of the document exists and is practically available, the process shall use it to verify that the document is currently valid. The process shall protect against the injection, by the applicant or an external attacker, of a previously recorded or artificially generated video stream. It shall also apply means that are reliably able to detect identity documents that are artificially generated or have been manipulated by an attacker with the relevant attack potential.

On the choice between human and machine, the text is direct. Automated means and machine-learning technology should be used to analyse documents against their expected appearance, including security elements and potential manipulation. If such algorithms are used, they shall be systematically tested against reference datasets and kept updated to cope with changes in the threats and risk situation. When validation is manual, the registration officer shall have received training in fraud prevention, data protection, the tools used, verification of documents and their security elements, and the detection of presentation and injection attacks, repeated or refreshed at least annually. Authoritative sources on document appearance are to be at the officer's disposal, and the specification names the Public Register of Authentic Travel and Identity Documents Online as an example. That register is a public information source on the security features of authentic documents, and it takes into account employers, banks, notaries and others who need to check identity documents.

Binding the applicant to the document

Binding starts from two verifications: that the applicant is the legitimate holder of the authoritative evidence, and that the evidence is in the applicant's possession. For a natural person using an identity document in a remote process, the specification asks for a video stream of the applicant's face. The video capture shall apply presentation attack detection to ensure that the stream shows a live person present in front of the camera at the time of the identity proofing, and a pre-recorded video is considered not to meet the requirements. The document gives as an example of active detection the instruction of the applicant to perform actions where the specific actions or their sequence are unpredictable to the applicant. The capture shall also apply means to detect an artificially generated or manipulated face appearance, which the text relates to deep fake attacks.

Injection is treated in its own requirement. The process shall apply biometric injection attack prevention and detection means to ensure that neither the applicant nor an external attacker can undetectably inject a previously recorded or artificially generated video stream. The specification then sets an external testing schedule. For the Baseline level, the injection attack detection means shall be tested by a laboratory whose competence is formally attested by a national body, according to the European technical specification CEN/TS 18099 at its level Substantial, at the latest before the end of 2026, and for the Extended level at its level High. The same kind of laboratory is to repeat the evaluation at least every second year. The CEN document that the schedule refers to gives guidance on injection attack detection systems and on a test plan for evaluating them, and it has been valid since 16 December 2024.

Presentation attack detection follows a similar logic. The provider shall state goals for the attack presentation classification error rate and the bona fide presentation classification error rate in its practice statement, at a level that matches prevailing industry practice, and shall keep them updated. The detection means and the error rates shall be systematically tested against updated reference datasets and against the goals the provider has set. The detection means shall also be evaluated by a laboratory whose competence is formally attested by a national body, according to part 3 of the ISO and IEC standard 19989 on the security evaluation of presentation attack detection, at the latest before the end of 2026, with repetition at least every second year. The text adds that no specific number is specified for the attack error rate, because rapid technology improvement can change what counts as prevailing practice even in the short term.

When the binding is by automated face biometrics, the comparison runs between the face image extracted from the identity document and the face image captured under the video requirements. Biometric signal processing, comparison, data storage and decision shall be carried out in an environment controlled by the actor responsible for the identity proofing process, while data capture and a preliminary quality assessment may take place on the applicant's equipment. The provider shall state goals for the false acceptance rate and the false rejection rate, test the algorithms against updated reference datasets, and reach the false acceptance goal in testing. The biometric face recognition should also apply means to detect morphed photos in identity documents, meaning photos that merge the faces of two or more persons.

Manual binding is possible and has its own rules. The registration officer compares the face image from the document with the applicant's appearance and performs a morphological analysis according to a defined feature list, after training that is repeated at least yearly. For the unattended remote case, manual-only binding can only reach the Baseline level.

The result and the record of the process

The result of the identity proofing shall be delivered securely to the trust service provider with regard to authenticity, integrity and confidentiality. The specification places no requirement on the format and lists as examples a document, structured data such as XML or JSON, an identity assertion and an electronic attestation of attributes. The result may even be a simple statement of success or failure, meaning that identity attributes supplied by the trust service provider at the start were verified or not against the applicant to the required level.

Alongside the result, the provider keeps evidence of the process itself. That evidence shall document the authoritative and supplementary evidence used and its issuer or source. It should document the whole process, and the specification observes that retaining images of a human applicant can be required, allowed, forbidden or limited in time, depending on the context. It shall be retained for the necessary retention time given by the context, stored in a tamper-proof way, stored so that confidentiality is guaranteed, and stored so that the result can be searched, retrieved and re-verified. The time of completion of the process shall be part of the evidence.

At the end of the retention time defined by ISS 8.5.2-04, the evidence of the identity proofing process and all personal data on the applicant shall be deleted.

Retention and deletion are therefore built into the specification, in tension with the demand for a complete and re-verifiable record. A design has to decide, for each context, what the record contains, how long it lives and who deletes it.

Use cases and what they can reach

The specification combines the building blocks into use cases and states which level each can reach. With physical presence the same requirements apply to both levels. For an identity document in an attended remote session, where the applicant talks to a registration officer in real time, manual operation is accepted only for the Baseline level. For an identity document in an unattended remote session, manual validation of a physical document and manual-only binding can reach only the Baseline level. Hybrid manual and automated operation, and automated operation, can reach the Extended level, and fully automated remote operation requires a digital identity document and face biometrics for binding.

In the hybrid unattended case with a physical document, automated analysis of the document is mandatory in combination with the manual validation. Binding can then run manual and biometric verification in parallel, or biometrics with fallback to manual verification, and if the two disagree when run in parallel the process shall be aborted. The text says that the hybrid use case is strongly encouraged over the manual one.

Other use cases cover identification through an existing electronic identification means, through a digital signature with a certificate, for a legal person, and for a natural person representing a legal person.

How European law points to the specification

The amended eIDAS Regulation, Regulation (EU) 2024/1183, rewrote the identity verification duty of qualified trust service providers in Article 24. Paragraph 1 requires such a provider, when issuing a qualified certificate or a qualified electronic attestation of attributes, to verify the identity and, if applicable, specific attributes of the person concerned. Paragraph 1a lists the methods.

(a) by means of the European Digital Identity Wallet or a notified electronic identification means which meets the requirements set out in Article 8 with regard to assurance level high; (b) by means of a certificate of a qualified electronic signature or of a qualified electronic seal, issued in compliance with point (a), (c) or (d); (c) by using other identification methods which ensure the identification of the person with a high level of confidence, the conformity of which shall be confirmed by a conformity assessment body; (d) through the physical presence of the natural person or of an authorised representative of the legal person, by means of appropriate evidence and procedures, in accordance with national law.

Paragraph 1c required the Commission to establish, by 21 May 2025, a list of reference standards for the verification of identity and attributes.

The Commission did so in Implementing Regulation (EU) 2025/1566 of 29 July 2025. Its annex states that the standard ETSI TS 119 461 V2.1.1 (2025-02) for conformance with Annex C clause C.3 applies, with a list of adaptations. One of the adapted clauses is the use case of the specification for identity proofing by other identification means. The Regulation applies from 19 August 2027, and its recitals explain that a transitional period of 24 months from entry into force was provided to give qualified trust service providers time to comply and to allow audits.

The adaptations are few and concrete. For fully automated processes, the provider shall establish target values for the false acceptance rate and the false rejection rate, based on a risk analysis and its threats intelligence procedure, and these shall be equal to or lower than those set for hybrid use cases where they exist. For the remote validation of a physical document, the effectiveness of the measures for secure transmission of the capture, injection protection, detection of manipulated documents, usability checks and security feature verification shall be tested by a laboratory whose competence is formally attested by a national body, or by a national competent authority whenever one is designated, at the latest by 19 August 2027 and then every second year. A reader should note that the specification and the Regulation set different dates for different tests, and should read both before planning an evaluation.

A comparison with another reference text

The identity proofing volume of the US Digital Identity Guidelines, Special Publication 800-63A-4, addresses the same attack classes. It says that a biometric comparison performed with a captured sample does not prevent injection attacks, and that live document capture and presentation attack detection make injection of viable forged media more challenging without addressing all cases. It requires providers to implement technical controls that increase confidence that media come from a genuine sensor and to analyse all submitted media for signs of modification, test the analysis against available attack artifacts, and document the artifact types tested and the corresponding false negative rates. The two texts therefore agree on the structure of the problem, namely capture control, media analysis and measured error rates, and differ in vocabulary and in where they apply. A separate article describes the US publication in detail, under the title of its identity proofing requirements for remote onboarding.

The European Union Agency for Cybersecurity has also published on the subject. Its report on remote identity proofing, dated 11 March 2021, gives an overview of the most common methods, the legal and standards landscape and a practical approach to risk management, and the specification cites it as the source of its threat overview.

Questions to put to your own design

  • Which use case of the specification do you apply, which level do you target, and does your practice statement say so?
  • Do you collect only the attributes that appear in the result or are needed for validation and binding?
  • Does the applicant accept the purpose and terms before capture, and are they told what data is kept and for how long?
  • Does your remote document capture record video of each relevant side, and verify at least three security features, two of them optically variable?
  • Is the machine readable zone extracted and compared with the visible data, and is an online status service used when one is available?
  • What are your stated goals for the attack and bona fide presentation error rates and for false acceptance and false rejection, and against which datasets are they tested?
  • When and by whom is your injection and presentation attack detection evaluated, and how often is it repeated?

Where this sits in a verification flow

The steps that the specification describes have counterparts in a verification session on NeuroVision KYC, which gathers the identity part of the process in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. The document step detects, classifies and reads IDs, including printed and handwritten text and the machine readable zone with its checksum. The liveness step is active: the person moves the face closer through two ovals. Deepfake and face-swap detection works inside the selfie and liveness steps. Retention in days is a setting of each scenario, and erasure endpoints and an erasure confirmation webhook are available. To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us