By NHI Mgmt Group Editorial TeamPublished 2026-06-08Domain: Breaches & IncidentsSource: SumSub

TL;DR: Forrester named it a Leader in the Wave Identity Verification Solutions Q3 2025 report, with the vendor also citing 20-second onboarding, 50-plus languages, 14,000 document types, 220-plus countries and territories, and 4,000-plus customers, according to SumSub. The governance question is not ranking alone but how identity verification now sits inside the full customer lifecycle, from onboarding through closure.


At a glance

What this is: This is Sumsub’s summary of Forrester Wave recognition, paired with claims about broad identity verification coverage across onboarding, login, transactions, and account closure.

Why it matters: It matters because identity verification is now an identity governance control point, not just a front-door fraud tool, and IAM teams need to understand where IDV connects to lifecycle, compliance, and risk decisions.

By the numbers:

👉 Read Sumsub's report on Forrester Wave identity verification recognition


Context

Identity verification is one control layer in a broader identity programme, not a standalone fraud feature. For IAM teams, the key question is how verification signals are used across onboarding, account recovery, transaction approval, and offboarding without creating gaps between assurance and lifecycle governance.

Sumsub’s Forrester recognition is being used here as a trigger to examine what modern IDV platforms claim to cover: speed, coverage, and fraud prevention across the customer journey. The operational issue for practitioners is whether those claims align with verification policy, risk tiering, and downstream access decisions.

For teams building customer identity, these claims should be read alongside NHI and workforce governance because the same programme often manages human users, third-party actors, and automated account activity. The challenge is not just proving who a user is, but maintaining that assurance as access context changes over time.


Key questions

Q: How should IAM teams evaluate identity verification platforms for lifecycle governance?

A: Start by mapping where verification outcomes change a real control decision, such as onboarding, step-up access, recovery, or closure. Then test whether the platform applies the same policy logic across markets, document types, and exception paths. If it only improves user flow without changing governance outcomes, it is helping operational efficiency more than assurance.

Q: When does broad IDV coverage create governance risk instead of reducing it?

A: Broad coverage becomes a risk when it outpaces policy consistency. Supporting many languages, countries, and document types can create fragmented review standards, inconsistent manual escalation, and weak evidence retention. In that case, the platform may scale activity faster than the organisation can govern it, which increases audit and fraud exposure.

Q: What should organisations look for beyond analyst recognition in an IDV report?

A: They should look for evidence of control fit. That means checking whether the product supports the organisation’s risk tiers, exception handling, reviewer workflow, and downstream identity decisions. Analyst recognition can help shortlist vendors, but it should never replace validation against your own assurance model.

Q: How do identity verification and identity governance fit together in practice?

A: Identity verification establishes an initial level of trust, while identity governance decides how that trust is maintained, challenged, or removed over time. In practice, the two must be connected through lifecycle events, case management, and access policy. Without that link, verification becomes a one-time check that does not protect the full identity journey.


Technical breakdown

Identity verification across the customer lifecycle

Identity verification platforms increasingly extend beyond registration into login, transaction review, and account closure. That matters because assurance is not a one-time event. The real control question is whether the system preserves enough context to treat the same subject consistently as risk changes. In practice, this blends document checks, device or behavioural signals, and policy rules into a single workflow. If those signals are not tied to downstream access and case-management decisions, verification becomes a front-end exercise with limited governance value.

Practical implication: Map each verification signal to a lifecycle decision, not just an onboarding screen.

Coverage, language, and document breadth in IDV pipelines

Breadth claims in IDV usually reflect how many document types, languages, and jurisdictions the workflow can handle. That is operationally useful, but it is not the same as governance maturity. A broad verification layer can still fail if exception handling, manual review, or risk escalation is inconsistent across markets. Practitioners should distinguish availability of checks from policy quality, because scale without standardised decisioning tends to create uneven assurance and audit friction.

Practical implication: Validate that multi-market coverage is matched by consistent policy and review rules.

Forrester Wave scoring and what it actually signals

Analyst scoring can indicate market fit, product breadth, and execution maturity, but it does not replace control validation. For identity teams, a vendor’s position in an analyst matrix should trigger due diligence on evidence quality, coverage limits, and operational fit with internal risk models. The practical value is in using the report as a starting point for comparison, not as a proxy for your own assurance requirements.

Practical implication: Use analyst recognition to narrow options, then test the control fit against your own risk model.


  • Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
  • DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Identity verification is now part of lifecycle governance, not just fraud prevention. The article frames IDV as spanning account creation, login, transactions, and closure, which is the right boundary for modern identity programmes. Once verification reaches into the whole customer journey, teams have to treat it as an assurance control with lifecycle consequences, not a point solution for onboarding. Practitioners should evaluate IDV in the same governance conversation as access, recovery, and offboarding.

Analyst recognition does not resolve assurance design. A Leader position in a Wave-style evaluation may reflect market maturity, but it does not answer whether a programme’s verification decisions are consistent across jurisdictions, risk tiers, and exception paths. The issue is control alignment, not ranking. Practitioners should treat external scoring as a signal to test internal policy coherence, not as a substitute for it.

Coverage breadth is useful only when it is operationally governable. Support for many languages, document types, and countries expands reach, but it also increases the number of edge cases security and compliance teams must absorb. That raises the bar for review consistency, evidence retention, and escalation policy. The practitioner conclusion is simple: scale in IDV only matters when governance scales with it.

Account takeover risk shifts when verification is embedded across the journey. If identity proofing is tied to login and transaction decisions, the governance question moves from static identity assurance to continuous contextual assurance. That is where customer identity, fraud operations, and IAM begin to overlap. Practitioners should design for that overlap explicitly rather than letting each team own a separate slice of the same risk.

Customer identity and NHI governance are converging around assurance reuse. The same organisations that verify people also depend on service accounts, API keys, and automation to route, approve, and remediate identity events. That creates a shared governance problem: assurance signals must be trusted by downstream systems without becoming blind spots themselves. The implication is that identity programmes now need a common control language across human and non-human actors.

From our research:

  • NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity governance breaks down once ownership and lifecycle tracking weaken.
  • That visibility gap is why practitioners should pair verification controls with broader lifecycle discipline, as covered in Ultimate Guide to NHIs , What are Non-Human Identities.

What this signals

Identity assurance is becoming a cross-domain control problem. Teams that manage customer identity, workforce identity, and NHI lifecycle in separate silos will keep finding gaps between proofing, access, and closure. The better programme design is to treat assurance as a reusable control signal that must survive transitions, exceptions, and delegation paths.

Verification breadth should be measured against governance consistency, not volume of supported documents. A platform can handle thousands of documents and still fail the organisation if reviewer decisions, escalation paths, and audit evidence are inconsistent. For practitioners, the signal to watch is whether broader coverage reduces exception drift or simply hides it behind scale.

Coverage is only durable when it fits the identity model you already operate. If your programme already struggles with lifecycle visibility, then adding faster verification can widen the gap between identity proof and identity control. The next step is to connect verification events to access policy, offboarding, and review workflows so that assurance does not disappear after the first check.


For practitioners

  • Define where IDV feeds access decisions Document which verification outcomes can trigger onboarding approval, step-up review, transaction blocking, or account closure. If the result never changes a downstream decision, the control is informational rather than governed.
  • Test policy consistency across jurisdictions Review whether document acceptance, manual escalation, and exception handling differ by country or product line. Inconsistent rules are a common source of audit findings and uneven customer assurance.
  • Separate coverage claims from control evidence Ask for proof of how multilingual, multi-document, and multi-country support is enforced in practice. Operational breadth matters only when the review path, evidence retention, and escalation logic are demonstrably stable.
  • Align customer identity with broader identity governance Bring fraud, IAM, compliance, and operations into the same lifecycle model so that verification, recovery, and closure are not managed as isolated events.

Key takeaways

  • The main governance question is not whether IDV works at the front door, but whether it influences access decisions throughout the customer lifecycle.
  • Broad language, document, and country support is useful only when policy, escalation, and evidence handling stay consistent across all those variations.
  • Practitioners should treat analyst recognition as a shortlist signal and then validate the control fit against their own assurance model.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-1IDV decisions affect whether a user gets trusted access.
NIST SP 800-63Digital identity assurance fits the article's verification focus.
NIST Zero Trust (SP 800-207)PR.AC-4Continuous verification aligns with zero-trust access decisions.

Use assurance levels and identity proofing evidence to standardise verification outcomes.


Key terms

  • Identity Verification: Identity verification is the process of establishing that a person or entity is who it claims to be before trust is extended. In practice, it combines document, data, and risk signals into a decision that should influence downstream access, recovery, and lifecycle handling.
  • Customer Identity Lifecycle: Customer identity lifecycle is the sequence of events from account creation through login, transaction activity, and closure. Good governance connects each stage to policy, review, and revocation logic so identity assurance does not end after onboarding.
  • Assurance Signal: An assurance signal is any verified fact or risk indicator used to decide whether to trust an identity event. It may come from documents, device context, behaviour, or manual review, but it only matters when a system uses it to change an identity decision.

Deepen your knowledge

Identity verification as a lifecycle control is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building assurance models that span people, systems, and automated workflows, it is worth exploring.

This post draws on content published by Sumsub: Report Sumsub recognized as a Leader in the Forrester Wave Identity Verification Solutions, Q3 2025 Report. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-08.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org