Customer verification is shifting from KYC to risk-based identity proofing

At a glance

What this is: This is an analysis of how customer verification is evolving from simple identity checks into layered, risk-based proofing with MFA, biometrics, and compliance controls.

Why it matters: It matters because IAM and identity architects must design verification flows that protect against fraud while supporting privacy, usability, and regulated access decisions across customer-facing programmes.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read 1Kosmos' analysis of customer verification, MFA, and fraud controls

Context

Customer verification is the process of confirming that a person or account is genuinely who it claims to be before allowing access, transactions, or age-restricted actions. In practice, that means identity proofing and authentication controls are doing more of the work once handled by manual review, and they now sit inside broader IAM and fraud-risk programmes.

For IAM teams, the problem is not whether to verify customers, but how to do it without over-collecting data, creating excessive friction, or weakening assurance. The article frames verification as a mix of security, privacy, and usability choices, which is the right lens for programmes that must support both customer trust and regulatory accountability.

Where verification relies on device checks, OTPs, liveness, or document capture, the governance question becomes whether the flow is proportionate to the risk and resilient against spoofing, reuse, or social engineering. The same discipline applies across customer identity, workforce access, and non-human identity controls: trust must be earned, not assumed.

Key questions

Q: How should organisations balance customer verification strength and user experience?

A: Use risk-based verification. Start with the lowest-friction method that meets the business requirement, then step up only when the transaction, device, or behaviour suggests greater risk. This approach preserves conversion while maintaining stronger assurance for sensitive actions, regulated flows, or suspicious activity.

Q: When do OTPs and MFA stop being enough for customer identity?

A: They stop being enough when the threat model includes phishing, SIM swap, device compromise, or high-value transactions. At that point, organisations need layered evidence such as device binding, document checks, liveness detection, or contextual risk scoring rather than relying on a single factor.

Q: What do security teams get wrong about customer verification?

A: They often treat verification as a one-time gate instead of an ongoing risk decision. That leads to static flows that either frustrate legitimate users or under-protect sensitive transactions. Effective programmes align verification depth with context, data quality, and regulatory purpose.

Q: Who is accountable when customer verification fails in a regulated flow?

A: Accountability usually sits with the business owner of the journey, supported by IAM, security, privacy, and compliance teams. KYC, AML, and privacy obligations mean the control cannot be owned by product alone. Governance needs clear decision rights for evidence, retention, and escalation.

Technical breakdown

Passive vs active customer verification

Passive verification works in the background by comparing user-provided data with external sources or behavioural signals. Active verification requires the user to do something, such as submit a selfie, enter a code, or present an ID document. The technical difference matters because passive methods reduce friction but depend on data quality, while active methods raise assurance but create new usability and accessibility failure modes. Modern identity programmes usually combine both, using passive checks to score risk and active checks only when the situation justifies more confidence.

Practical implication: build step-up flows that escalate verification only when risk increases, rather than forcing every customer through the same high-friction path.

MFA, OTPs, and liveness checks in customer identity

Two-factor and multi-factor authentication improve assurance by requiring evidence from more than one category, such as something known, possessed, or biometric. OTPs are time-limited proof of device control, but they are still vulnerable to phishing, SIM swap, and relay attacks. Liveness checks help distinguish a real person from a replayed image or deepfake, but their reliability depends on camera quality, anti-spoofing logic, and the broader trust chain around document capture and matching. These controls are most effective when treated as part of a layered identity proofing architecture, not as standalone guarantees.

Practical implication: treat OTP and selfie checks as one layer in a broader assurance model, not as proof that the identity problem is solved.

Compliance pressure in KYC, AML, and privacy-led verification

Customer verification sits inside a regulatory stack that often pulls in different directions. KYC and AML require organisations to know who the customer is and monitor risk, while privacy regimes such as GDPR demand data minimisation, purpose limitation, and strong handling of personal information. That creates a governance challenge: collect enough evidence to establish trust, but no more than necessary. The practical design task is to align verification depth with legal obligation, business risk, and retention rules so the programme remains defensible under audit and usable for real customers.

Practical implication: map each verification step to a specific legal or risk requirement so you can justify the data you collect and the checks you run.

Threat narrative

Attacker objective: The attacker’s objective is to obtain trusted customer access or complete a transaction while appearing legitimate to the verification system.

1. Entry occurs when an attacker or fraudster reaches the customer journey through signup, login, or transaction initiation and tests the weakest verification path.
2. Escalation happens when static knowledge checks, weak OTP delivery, or reusable identity evidence allow the attacker to prove control without proving personhood.
3. Impact follows when the fraudulent account is used to bypass age gates, commit account takeover, or complete regulated transactions under a false identity.

Breaches seen in the wild

• 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

Customer verification is now an identity governance problem, not just a front-end UX problem. The article correctly shows that verification decisions shape fraud exposure, data collection, and user trust at the same time. That makes it part of IAM and governance design, not a narrow product choice. The practical conclusion is that verification flows should be managed with the same policy discipline as access controls and lifecycle events.

Risk-based verification is the only sustainable model when fraud, privacy, and friction collide. Static KBA and one-size-fits-all checks fail because they assume the same proof is suitable for every transaction and every user. A risk-adaptive model is better aligned to regulatory and operational reality, because it lets assurance rise when context changes. Practitioners should treat verification strength as a policy decision, not a fixed feature set.

Data minimisation and identity assurance are not competing goals if the architecture is sound. The article’s strongest point is that trust depends on handling customer data securely and transparently, but more data does not automatically create more trust. Excess collection creates retention, breach, and compliance risk. The governance implication is to prove identity with the fewest durable attributes possible and keep the rest under strict control.

Named concept: verification friction debt. Every unnecessary step, repeated prompt, or ambiguous challenge adds abandonment risk and support load, even when the security control itself is technically valid. Over time, that friction debt becomes a governance issue because users route around controls that are too burdensome. Practitioners should design for proportional assurance, not maximum challenge.

Customer-facing identity controls increasingly need to support fraud defence and customer trust in the same flow. The article shows that verification is doing double duty across compliance and user confidence. That is where many programmes fail, because they optimise for one outcome and damage the other. The practitioner takeaway is to align customer verification with policy, evidence quality, and experience design as one operating model.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to NHI Mgmt Group research.
• 52 NHI Breaches Analysis shows how exposed credentials and unmanaged access translate into repeated compromise patterns.

What this signals

Verification quality is becoming a shared governance signal across customer IAM and machine identity programmes. When customer journeys rely on device proof, OTPs, and document checks, the same control logic starts to resemble broader identity assurance work, including how non-human identities are governed. The organisations that mature fastest will be the ones that treat proof strength, retention, and step-up policy as part of one identity architecture, not separate teams.

Only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for customer-verification programmes as well. If identity teams cannot reliably see and govern machine accounts, they will struggle to apply the same discipline to proofing data, support-channel trust, and exception handling in customer flows. The operational pattern is the same: hidden trust dependencies become the control failure.

The next phase of customer verification will be judged less by how many checks it uses and more by how well it proves purpose, proportion, and durability. That means teams should expect closer scrutiny of retention rules, step-up policy, and the evidence chain behind each verification decision, especially where fraud controls intersect with privacy obligations.

For practitioners

• Segment verification by transaction risk Use low-friction checks for routine actions and step up to document or liveness verification only when the transaction value, fraud signal, or regulatory sensitivity justifies it.
• Replace weak knowledge checks with stronger proof signals Retire static KBA where exposed public data makes challenge questions predictable, and move toward possession-based, biometric, or device-bound evidence.
• Tie each verification step to a legal purpose Document which checks support KYC, AML, age gating, or fraud prevention so privacy, legal, and security teams can defend data collection and retention decisions.
• Measure abandonment against assurance outcomes Track where users fail, abandon, or need help, then compare that friction data against fraud rates and false positives to tune the flow.

Key takeaways

• Customer verification now sits at the intersection of fraud control, privacy governance, and customer experience, so it must be managed as an identity programme rather than a single control.
• Layered verification works best when assurance rises with risk, because static KBA, OTPs, and manual checks each fail in different ways.
• Practitioners should map every verification step to a specific legal or operational purpose, then measure friction against fraud outcomes.

Key terms

• Customer verification: Customer verification is the process of confirming that a person is who they claim to be before allowing access, transactions, or regulated actions. It combines identity proofing, authentication, and risk checks so organisations can reduce fraud, satisfy compliance obligations, and preserve trust.
• Identity proofing: Identity proofing is the set of checks used to establish that an identity claim belongs to a real person or account holder. It may include document review, data matching, biometrics, device signals, or liveness testing, and it is only as strong as the evidence chain behind it.
• Step-up verification: Step-up verification is a risk-based approach that asks for stronger proof only when the transaction, user behaviour, or environment warrants it. It reduces unnecessary friction while allowing organisations to raise assurance for sensitive actions, suspicious sessions, or regulated workflows.
• Liveness detection: Liveness detection is a biometric control designed to confirm that a real, present person is providing the sample rather than a photo, replay, mask, or deepfake. It improves assurance in remote onboarding and authentication, but it depends on anti-spoofing quality and a trustworthy capture process.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: customer verification, MFA, and the trade-offs between security and user experience. Read the original.