eIDAS 2.0 high confidence certification raises the bar for IAM

At a glance

What this is: SumSub's reconfirmed eIDAS 2.0 High Level of Confidence certification centres on certified verification modules for individuals and businesses.

Why it matters: It matters because regulated IAM and onboarding teams need assurance models that reduce friction without weakening verification, especially where human identity, business identity, and downstream fraud controls intersect.

👉 Read SumSub's certification update on eIDAS 2.0 high confidence verification

Context

eIDAS 2.0 High Level of Confidence certification is a formal assurance marker for digital identity verification, not a product feature. For regulated onboarding flows, the issue is whether verification controls can satisfy European requirements for both natural and legal persons while still supporting usable customer journeys.

This matters to identity programmes that span human identity verification, business verification, and fraud controls. When assurance requirements rise, teams must separate convenience claims from evidence-backed compliance posture and align verification design with audit expectations and regulated onboarding paths.

Key questions

Q: How should regulated businesses use eIDAS-certified identity verification in onboarding?

A: Use eIDAS-certified verification as a scoped assurance control for specific onboarding journeys, not as a blanket statement that all identity risk is solved. Match the certification scope to the customer or business flow, then confirm how exceptions, manual reviews, and evidence retention are handled for audit and regulatory review.

Q: Why does high-assurance identity verification matter for compliance teams?

A: Because regulated onboarding decisions must stand up to scrutiny, especially where fraud, AML, and digital trust are linked. High-assurance verification reduces the chance that weak proofing becomes an access or transaction problem later, but only if the organisation can show the evidence behind each trust decision.

Q: What should security teams check before trusting an automated verification module?

A: Check whether the automation is certified for the exact journey, what documents or signals it reads, how failures are escalated, and whether human review is still required for exceptions. The important control question is not whether automation exists, but whether its boundaries are governed and auditable.

Q: Who should own business verification when KYB supports regulated access decisions?

A: Ownership should sit across identity, compliance, and the business function that relies on the decision, because KYB affects account creation, contractual trust, and downstream risk. If no one owns the evidence chain, the organisation can pass onboarding without being able to defend it later.

How it works in practice

eIDAS 2.0 assurance levels and verification modules

eIDAS 2.0 defines assurance expectations for digital identity verification across use cases such as person identification, business verification, and qualified trust services. In this case, the certified scope includes Auto Identification, Video Identification, e-ID Verification, KYB Verification, and a Fully Automated module that reads eMRTDs without manual agent review. The key technical distinction is that certification is tied to specific modules and standards, not to an entire platform by default. Practitioners should read the certificate as scoped assurance, then map that scope to their own onboarding and signature journeys.

Practical implication: validate the exact certified modules against your onboarding and compliance requirements before treating the platform as eIDAS-ready.

Automated identity verification and human review boundaries

A Fully Automated verification flow changes the operating model because machine reading of travel documents replaces manual review in at least part of the decision chain. That shifts risk from reviewer inconsistency to the integrity of document capture, validation logic, and exception handling. For regulated environments, the architectural question is where human review remains mandatory, where automation is acceptable, and how failures are escalated. This is especially relevant when verification is used as an access gate for regulated services, not just as a customer onboarding convenience.

Practical implication: define which verification exceptions still require human intervention and document the escalation path before automation is expanded.

KYB verification and legal-person assurance

KYB verification is about establishing that a business exists, is what it claims to be, and can be linked to accountable parties and documentation. That is different from authenticating a person and often involves company records, registry checks, and evidence that can survive audit. The technical challenge is not only identity proofing but also maintaining traceability across entities, documents, and ongoing risk checks. Where business onboarding feeds AML, fraud prevention, or contractual trust decisions, KYB becomes part of a broader identity governance chain rather than a standalone control.

Practical implication: align KYB evidence retention and traceability with your audit, AML, and vendor-risk review requirements.

NHI Mgmt Group analysis

High-assurance verification is now an identity governance requirement, not a UX differentiator. eIDAS 2.0 certification signals that regulated onboarding is being judged against auditable assurance thresholds, not just conversion performance. For IAM and fraud teams, that means verification design has to satisfy compliance, traceability, and risk acceptance at the same time. The practitioner conclusion is that onboarding assurance must be treated as governance infrastructure.

Scoped certification matters more than platform claims. A certificate tied to specific modules tells practitioners where assurance exists and where it does not. That distinction matters because identity programmes often overgeneralise from one certified control to an entire workflow, then discover gaps in exception handling or adjacent business processes. The practical conclusion is to map certification scope to each identity journey before relying on it for regulated access decisions.

Automated verification changes the control boundary, not the compliance burden. When a module reads machine-readable travel documents without manual agent review, the assurance problem shifts to system integrity, document authenticity, and exception governance. That does not remove oversight, it relocates it into control design and audit evidence. The practitioner conclusion is that automation should be governed as part of the identity process, not treated as an exemption from scrutiny.

Identity verification, AML, and fraud prevention are converging into one decision chain. Regulated businesses no longer separate onboarding, fraud checks, and trust establishment as cleanly as they once did. eIDAS-aligned flows increasingly become the first control point for later access, signature, and transaction decisions. The practitioner conclusion is that identity teams must coordinate assurance policy with compliance and fraud operations rather than owning onboarding in isolation.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• That confidence gap is why the NHI Lifecycle Management Guide matters when onboarding, rotation, and offboarding all feed the same trust chain.

What this signals

High-assurance onboarding is becoming a governance baseline: regulated identity teams will increasingly need to prove that verification scope, exception handling, and evidence retention are aligned to the same control objective. As onboarding, fraud prevention, and compliance continue to converge, assurance decisions will be judged by auditability rather than by conversion metrics alone.

The practical signal for programmes is that certification scope must be mapped to each identity journey. If one module is certified but adjacent steps are not, the control story is incomplete and can fail at the point where downstream access or transaction decisions rely on it.

For teams managing human, business, and machine identities together, the real test is whether verification evidence can survive review across all three. That is why the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 remain relevant reference points when identity proofing feeds broader trust decisions.

For practitioners

• Map certification to specific journeys List every onboarding, KYB, and signature path that depends on eIDAS assurance, then verify which ones are covered by the certified modules and which rely on separate controls. Use the certificate scope as an input to control mapping, not a blanket approval.
• Separate automation from exception governance Document where Fully Automated verification is acceptable, where manual review remains required, and what evidence is captured when a case fails automated checks. Keep the escalation path explicit so auditors can see how exceptions are handled.
• Align identity evidence with audit and AML needs Retain the identity artefacts, verification outcomes, and business proof used in regulated onboarding so they can support later audit, AML review, or dispute handling. Treat evidence retention as part of the identity control, not an afterthought.
• Review business verification as a governance control If KYB feeds supplier onboarding, contracting, or payment approval, make sure the assurance level is understood by procurement, finance, and security teams. Business identity verification should be governed as a cross-functional risk control.

Key takeaways

• eIDAS 2.0 certification turns identity verification into a control-evidence problem, not just a user-experience problem.
• Scoped module certification matters because regulated assurance only holds where the exact journey and exception path are covered.
• Automated verification still requires governance over evidence, escalation, and auditability if it is to support compliant onboarding.

Key terms

• eIDAS 2.0 High Level of Confidence: A formal assurance level used in European digital identity verification to indicate that a process meets high trust requirements for identifying people or businesses. In practice, it means the verification method must be specific, auditable, and suitable for regulated use cases where evidence matters.
• KYB Verification: Know Your Business verification is the process of confirming that an organisation is real, accountable, and represented by the right legal entity. It often combines registry checks, document validation, and entity matching so regulated teams can reduce fraud and establish trustworthy business relationships.
• Verified onboarding: Verified onboarding is the identity control point where a new user or business is assessed before access is granted. It is not just a registration step, because the quality of the verification determines whether later authentication, transaction, or compliance decisions rest on trustworthy evidence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by SumSub: certification reconfirming eIDAS 2.0 High Level of Confidence for verification modules. Read the original.