The EUDI & Wallet Playground: test real wallet flows in your browser for free. Try it now
Helena Suska

Helena Suska

What does "verified" mean in identity verification? | Identity Infrastructure Explained

Assurance level, data source and audit trail: what stands behind a "verified" result and what you can still prove years later.

"Verified" in identity verification means that a user's identity was confirmed with a method of known assurance level, and that the business can show when, with which method and from which source. A "yes" result or a document image does not prove this. Three things decide the value of a verification: the method's assurance level, the reliability of the data source and a retained record of the process.

Written by Helena Suska (Head of Customer Success), Authologic.

Title card reading "What "verified" means" with the line "Identity Infrastructure Explained"

Key takeaways

  • The eIDAS Regulation sets 3 assurance levels for electronic identification means: low, substantial and high.
  • Article 22(6) of the AMLR, which generally applies from 10 July 2027, recognises electronic identification means at assurance level substantial or high together with relevant qualified trust services, alongside an identity document together with, where relevant, information from reliable and independent sources.
  • Not every method has an eIDAS assurance level. A method that is not notified in the EU can have a basis in national law and be recognised in that country for the purposes set out in that law, but it does not benefit from mutual recognition under Article 6 eIDAS. Document photo and selfie verification has no eIDAS level; a provider may give it its own indicative mapping to the same scale and should say so clearly.
  • Proof that a verification took place is a reliable data source and a record of how it ran: identifier, time, method and result. An image of a document is easy to manipulate today.
  • The provider's record shows what happened during the verification. The reason a business accepted the result comes from its own methodology.

What is an assurance level in identity verification?

An assurance level (level of assurance) is the grade assigned to an electronic identification means. The eIDAS Regulation sets three levels: low, substantial and high.

A notified electronic identification scheme states which level its means meet. Level low provides a limited degree of confidence in the claimed identity. Level substantial provides a substantial degree of confidence, with safeguards that substantially decrease the risk of misuse of the identity. Level high goes further: its safeguards are meant to prevent such misuse.

The technical requirements for each level, from identity proofing to authentication, are set out in a separate implementing act under the eIDAS Regulation.

Related: EUDI Wallet & eIDAS 2.0 Glossary, part 4: What is a level of assurance under eIDAS?

Who sets the assurance level of a verification method?

The assurance level of a notified electronic identification means is set by the Member State, but not at will: the Member State must base it on the criteria in Commission Implementing Regulation (EU) 2015/1502 and show that they are met in the scheme's notification documentation. The Member State notifies its electronic identification scheme to the European Commission under Article 9 eIDAS and states its level under Article 8: low, substantial or high. Before notification, the scheme is, as a rule, subject to a review by the other Member States, and the Commission publishes the list of notified schemes.

Notification gives an electronic identification scheme legal effect beyond the Member State that notified it. Under Article 6 eIDAS, public online services in other Member States that require level substantial or high must recognise notified electronic identification means at the required or a higher level.

Bank ID differs from country to country. Some bank schemes are notified; others operate under national law or banking sector frameworks. A service that is not notified can have a basis in the rules of its own market; this is currently the case in Poland with mojeID, which is not notified in the EU but operates as a system connected to the national electronic identification node by decision of the minister responsible for digital affairs. For every bank ID, it is worth checking whether it is notified and at what assurance level, and if it is not, on what legal basis it operates in that market.

The EUDI Wallet is one of the electronic identification means, so under the AMLR it belongs to the same verification route as other such means. How the wallet fits into KYC procedures is covered in How will the EUDI Wallet change KYC?

Methods outside eIDAS, such as document photo and selfie verification, have no eIDAS assurance level. A provider may give them its own indicative mapping to the same scale. Such a mapping is not an eIDAS level, and the provider should say so clearly. What a notification proves, and what a provider certificate proves, is covered in Which certifications should an identity verification provider hold in the EU?

What assurance level does the AMLR recognise?

Article 22(6) of the AMLR recognises two routes to verifying identity: an identity document together with, where relevant, information from reliable and independent sources, or electronic identification means at assurance level substantial or high together with relevant qualified trust services. The AMLR generally applies from 10 July 2027.

Article 22(6) of the AMLR refers to the assurance level and does not mention notification directly. When choosing a method for the AMLR, a business should therefore check at what assurance level the method operates. How to choose methods in each country is covered in How do you choose identity verification methods for each country?, and what changes in remote verification under the AMLR in How to verify customers remotely under AMLR.

Related: AML and KYC Glossary: What is remote identification under the AMLR?

Why doesn't an image of a document prove that a verification took place?

Businesses that introduce digital verification usually already have analogue processes based on document scans. That is why, during implementation, they often ask what counts as proof of verification and expect it to be an image of the document.

An image of a document does not prove on its own that a verification took place, because a photo or scan is easy to manipulate today, including with generative AI tools. The image shows what the document looked like, but not where it came from, when it was created or whether anyone changed it.

An identity document remains one of the two verification routes under the AMLR, but Article 22(6) lists it together with, where relevant, information from reliable and independent sources.

The identity document itself should also be checked by more than the human eye. A person will not notice, for example, a different font or a hologram in the wrong position, so the document's security features need automated verification.

What proves that a verification took place?

Two things show that a digital verification is reliable: the reliability of the data source and unique identifiers that make it possible to trace the process in the logs. Such a record shows when the verification took place, where the data came from and what the result was.

A reliable data source is one that can be named and checked, for example a notified electronic identification scheme, a bank or a public register. For some methods, the data comes directly from public databases, such as population registers or tax registers.

A record of how a verification ran is harder to forge than an image of a document, because it is created on the side of the source and the provider, out of the user's reach. A business should therefore store the verification identifiers and the information about the source together with the "verified" or "rejected" result.

When should a verification result show the method and the provider?

A verification result should always show the method, because the method determines the assurance level and the scope of data. Without this information, the business does not know what it has actually confirmed.

The provider is worth knowing where it affects how the result is read. In biometrics, the result depends on the engine that matched the face against the photo and assessed whether a live person was in front of the camera. Presentation attack detection test reports apply to a specific version of the engine. In open banking, the scope of data depends on the bank it comes from.

Every verification method relies on one or more providers, and their performance differs between markets. How this affects the choice of provider, and what happens when one stops working, is covered in What happens when an identity verification provider goes down? How a platform chooses the method for each user is covered in What capabilities should an identity orchestration platform provide for EUDI Wallet adoption?

What is recorded after a verification, and for how long?

After a verification, the data within the requested scope is recorded, together with logs showing how the verification ran. The scope of data is worth defining before choosing a method and limiting to what the business needs. How to do this is covered in How do you choose identity verification methods for each country?

How long records are retained follows from the business's legal obligations. The business should make sure that the records are available for the whole period in which it may be asked to show them: either with the provider that runs the verification or on its own side.

Can you still show years later why a verification was accepted?

Years later, a business should be able to reconstruct with which method a user was verified, when and with what result. The method, time and result are shown in the record kept by the verification provider.

Answering why a verification was accepted also needs information from the business's own methodology: which rules it applied and which assurance level it considered sufficient for the customer and product. Only the provider's record together with this information shows the full reasoning, for example to an auditor or a supervisor.

How does Authologic do it?

Authologic builds eID-native identity infrastructure that helps regulated businesses identify, onboard and authenticate their customers. One API connects 140+ identity methods across 250+ countries and territories.

The list of methods on the Integrations page shows the assurance level of each method in each country. For methods outside eIDAS, the level shown is Authologic's indicative mapping to the same scale and is not an eIDAS level.

Alongside structured user data, Authologic returns metadata: the verification identifier and information about its source. The result shows the method, and the provider where it affects how the result is read, for example in biometrics and open banking. Authologic also logs a wider set of method-specific metadata, which makes it possible to analyse how a verification ran separately from the user's data.

Authologic records the data within the scope requested in the verification and the logs of how it ran. The customer chooses one of two options: full retention of the information on Authologic's side, or short retention with only the log kept, when the customer stores the data on its own side. The retention period is set in the contract with the customer and reflected in the environment configuration. On this basis, the customer can reconstruct the method and result of every verification years later and, together with its own methodology, show why the verification was accepted.

What should you ask an identity verification provider?

  1. At what assurance level does each method operate, and is it an eIDAS level or the provider's own mapping?
  2. Are the bank IDs available in a given country notified, and at what level? If not, on what legal basis do they operate?
  3. Does the verification result show the method and, where it matters, the provider?
  4. Which identifiers and source information do you receive with the result?
  5. What does the provider record after a verification, and can the records be stored with the provider or on your side?
  6. Will you be able to reconstruct the method, time and result of every verification years later, for example for an audit?

FAQ

What does "verified" mean in identity verification?

"Verified" means that a user's identity was confirmed with a method of known assurance level and that it is possible to show when, with which method and from which source this happened. A "verified" result without information about the method, source and process tells an auditor or a supervisor very little.

Does every verification method have an eIDAS assurance level?

Not every verification method has an eIDAS assurance level. The levels low, substantial and high apply to electronic identification means, and for notified schemes the Member State sets them according to the criteria of the implementing regulation. A method that is not notified can be recognised under national law. Document photo and selfie verification has no eIDAS level; a provider may give it its own indicative mapping to the same scale and should say so clearly.

What assurance level does the AMLR recognise for electronic verification?

For electronic verification, Article 22(6) of the AMLR recognises electronic identification means at assurance level substantial or high together with relevant qualified trust services. The other route to verifying identity is an identity document together with, where relevant, information from reliable and independent sources. The AMLR generally applies from 10 July 2027.

Is a scan or photo of a document proof of verification?

A scan or photo of a document does not prove on its own that a verification took place. An image is easy to manipulate and does not show where the data came from or when it was created. Proof is a reliable data source and a record of how the verification ran: identifier, time, method and result, stored so that they can be reconstructed.

Who is responsible for explaining why a verification was accepted?

The business that accepted a verification is responsible for explaining why it accepted it. The provider's record shows the method, time and result of the verification. The reason for accepting it comes from the business's methodology, for example which assurance level it considered sufficient for the customer and product.

Sources

Changelog

  1. Initial publication.

Share article

Text of this article
Media in this article

Press Contacts