How can IAM teams reduce fraud without making onboarding unusable?

Use risk-based verification so low-risk users get lighter checks and high-risk journeys get stronger proofing. Then measure both acceptance quality and user drop-off, because one without the other gives an incomplete picture. IAM teams should also ensure that identity verification outcomes feed access policy, not just registration completion.

Why This Matters for Security Teams

Fraud controls that slow every applicant are expensive, but weak onboarding is equally costly because attackers only need one low-friction path to create trusted accounts, take over real ones, or inject synthetic identities. The right question is not whether to add more checks, but where to add them based on risk, journey stage, and expected abuse patterns. NIST frames this as a continuous governance problem in the NIST Cybersecurity Framework 2.0, not a one-time registration decision.

For IAM teams, the operational issue is that fraud signals rarely arrive neatly at the start of the journey. They often emerge when device intelligence, velocity patterns, document quality, or account recovery behaviour are combined across steps. That makes static, one-size-fits-all onboarding rules fragile. NHI Management Group has also shown how weak identity governance can cascade into access abuse, including exposure patterns described in Azure Key Vault privilege escalation exposure. In practice, many security teams discover onboarding fraud only after suspicious accounts have already passed verification and started interacting with production systems.

How It Works in Practice

The most effective pattern is risk-based verification tied directly to policy. Low-risk users should see the lightest possible path, while higher-risk journeys trigger stronger proofing, step-up checks, or manual review. That means the verification outcome must become an input to access decisions, not just a registration status flag. Current guidance from the NIST Cybersecurity Framework 2.0 supports this kind of risk-informed control selection, especially where onboarding leads to privileged or regulated access.

In practice, teams usually combine several signals:

• Device and network reputation to spot disposable or proxy-heavy enrollment patterns
• Document and biometric proofing only where the expected fraud impact justifies the friction
• Velocity controls to stop repeated signups, retries, and synthetic identity loops
• Post-onboarding monitoring so high-risk accounts are not treated as fully trusted by default

NHIMG research shows why this matters: 96% of organisations store secrets outside secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that identity compromise often becomes access compromise fast. The lesson applies to onboarding too: once an identity is accepted, its downstream entitlements need to reflect the quality of proofing. That is why access policy should consider assurance level, not only whether the user completed enrollment. Teams should also measure both acceptance quality and drop-off, because a “successful” funnel that admits fraud is not success, and a highly secure funnel that loses legitimate users is operationally broken. These controls tend to break down when policy logic is isolated from identity lifecycle systems, because verification results never reach the access layer.

Common Variations and Edge Cases

Tighter fraud controls often increase abandonment and manual review load, requiring organisations to balance conversion against risk reduction. Best practice is evolving here, and there is no universal standard for the exact threshold at which stronger proofing should trigger. The right design depends on customer segment, regulatory exposure, and how costly a fraudulent account would be if it later gains access.

Some journeys justify heavier friction from the start, such as accounts that can move money, access sensitive records, or request privileged system actions. Others should rely on progressive trust, where low-risk users pass quickly but face step-up checks only when behaviour changes. This is also where identity proofing and workforce onboarding diverge: a consumer account that only needs basic service access should not receive the same controls as a contractor account with administrative reach. The practical test is whether the policy can distinguish legitimate fast paths from attack paths without creating blind spots. NHIMG’s research on The 2024 Non-Human Identity Security Report shows the broader pattern: 88.5% of organisations say their non-human IAM practices lag behind or match their human IAM efforts, which is a warning that immature identity governance often spills into onboarding and access design. Fraud controls work best when assurance, access, and monitoring are managed together rather than as separate teams or tools.

Related resources from NHI Mgmt Group

• How should security teams reduce insider fraud without undermining employee trust?
• How should dating platforms reduce fraud without making signup unusable?
• How can teams reduce Office 365 identity sprawl without disrupting users?
• How should security teams reduce cloud identity risk without overcomplicating access management?