Should IAM and fraud teams use the same signals for bot defence?

Why This Matters for Security Teams

IAM and fraud teams are often looking at the same abuse pattern from different angles. Identity teams care about authentication risk, device trust, and session integrity, while fraud teams focus on fake signups, takeover attempts, and downstream abuse. If bot defence uses separate signal sets, attackers can stay just below the threshold of each control plane. shared signals reduce blind spots, but only when teams agree on what those signals mean and how they are scored.

That matters because customer abuse is rarely isolated to one workflow. A bot may probe login pages, reuse device fingerprints, trigger password resets, and then convert into account takeover or payment fraud. Current guidance suggests teams should treat bot activity as a cross-domain risk, not a point control problem. NIST SP 800-53 Rev. 5 frames the need for coordinated detection and monitoring across systems, which is exactly where IAM and fraud overlap most.

In practice, many security teams discover that their “best” bot indicators were useful only after the fraud loss or takeover event had already happened.

How It Works in Practice

The strongest model is not “one team owns all signals,” but a shared detection fabric with clear operational boundaries. IAM can contribute authentication telemetry, impossible travel, session anomalies, MFA fatigue indicators, and device binding failures. Fraud teams can add velocity checks, account age patterns, signup abuse, disposable email use, and behavioural clustering across campaigns. When those feeds are normalised into a common decision layer, teams can score the same entity differently depending on context.

A practical implementation usually includes:

• Shared entity resolution for user, device, IP, session, and payment instrument.
• Real-time scoring rules that can raise friction, step-up authentication, or block actions.
• Separate thresholds for login, enrollment, checkout, and account recovery.
• Feedback loops so confirmed fraud cases improve identity-risk models and vice versa.

This approach works best when policies are explicit about which signals are preventive, which are investigative, and which are only advisory. A bot fingerprint that is strong enough to deny a signup may be too noisy to deny a trusted customer during login, so context matters. The NHI Management Group notes that 97% of NHIs carry excessive privileges, which is a reminder that over-trusting a session or automation path can widen the blast radius when bot-driven abuse succeeds.

For teams building this out, NIST SP 800-53 Rev. 5 is useful for structuring monitoring, incident response, and access control expectations, while NHI security research such as the 2024 Non-Human Identity Security Report helps explain why short-lived, high-confidence signals are often more defensible than broad, static rules. The report’s finding that only 19.6% of security professionals are strongly confident in managing workload identities underscores how quickly identity telemetry can become fragmented.

These controls tend to break down in high-volume consumer environments where bot traffic, shared devices, and legitimate automation produce too many false positives for a single team to tune alone.

Common Variations and Edge Cases

Tighter shared bot controls often increase friction, requiring organisations to balance fraud reduction against customer experience and operational load. There is no universal standard for this yet, especially for businesses that serve anonymous users, partners, or heavily automated customer journeys.

One common variation is partial signal sharing: IAM uses high-confidence authentication indicators, while fraud keeps broader behavioural and commercial signals in a separate scoring model. Another is tiered actioning, where both teams see the same events but only fraud can block transactions, while IAM can only step up authentication or limit session scope. That division can work, but it must be documented or teams will create inconsistent outcomes for the same user.

Edge cases also appear in API-heavy or agent-assisted environments. A human customer may look like a bot if they use password managers, privacy tools, or browser isolation. Conversely, an automated account farm can look human if it rotates devices, IPs, and timing patterns carefully. Best practice is evolving toward contextual decisions instead of universal bot labels, because static thresholds age poorly as attacker tooling changes.

For organisations that need a concrete governance baseline, the right question is not whether IAM or fraud owns bot defence, but whether both teams share a common risk language and a documented escalation path when the same signal points to either abuse or compromise.

Related resources from NHI Mgmt Group

• How should security teams use IAST and RASP in NHI governance?
• How should security teams use shared signals in IAM response?
• How can fraud, payments, and IAM teams work from the same control model?
• Why do fraud and AML teams need to work from the same identity signals?