What breaks when fraud detection relies only on known-bad indicators?

Why This Matters for Security Teams

Known-bad detection still matters, but it is a weak primary control when fraud campaigns are generated on demand and adapted mid-stream. AI-assisted fraud can reuse legitimate accounts, mimic approved workflows, and avoid the obvious markers that older filters were built to catch. That shifts the problem from signature matching to identity assurance, approval integrity, and behavioural deviation.

For NHI-heavy environments, this is especially important because service accounts, API keys, and automation tokens often sit outside the visibility of traditional fraud tooling. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — Key Challenges and Risks, which helps explain why known-bad lists miss so much abuse. The better framing is the one used by the NIST Cybersecurity Framework 2.0: focus on protecting assets, detecting anomalies, and responding to unusual activity, not just blocking previously seen indicators.

In practice, many security teams encounter fraud only after an apparently valid identity has already been used to move funds, approve transactions, or exfiltrate data.

How It Works in Practice

fraud detection becomes materially stronger when it treats identity, context, and behaviour as the signal, not just the content of a request. That means a transaction or login is evaluated against relationship patterns, timing, device posture, location drift, approval chains, and whether the action makes sense for that account in that moment. The same logic applies to NHI activity: a token, key, or service account should not be trusted only because it is valid; it must be checked for expected usage patterns and permission scope.

Operationally, teams often combine several layers:

• Behaviour baselines that look for unusual volume, timing, or sequence changes.
• Relationship analysis that flags new counterparties, new payout destinations, or novel API call paths.
• Approval anomaly detection that compares the request against normal review chains.
• Short-lived credentials and strong lifecycle controls so stolen access has less value.

That approach aligns with the NHI Lifecycle Management Guide, which emphasises visibility, rotation, and offboarding as core controls, not optional hygiene. It also fits the modern guidance in the NIST Cybersecurity Framework 2.0, where detection and response depend on telemetry that can surface abnormal use rather than only matching signatures. In short, a good fraud stack should ask whether the actor, path, and outcome are credible, not whether the message contains a known scam phrase.

These controls tend to break down when approval logic is embedded in legacy business workflows because the fraud pattern looks operationally normal until after the exception has been exploited.

Common Variations and Edge Cases

Tighter behavioural detection often increases alert volume and review overhead, so organisations have to balance sensitivity against analyst fatigue. That tradeoff is real, especially when customer populations are diverse or transaction patterns vary by season, geography, or product line. Current guidance suggests avoiding rigid thresholds that assume fraud always looks unusual in the same way.

There is no universal standard for this yet, but best practice is evolving toward layered detection that treats known-bad indicators as one input among many. For high-trust environments, the bigger gap is often not the scoring model itself but the lack of clean identity telemetry. The Top 10 NHI Issues highlights how excessive privileges and weak visibility make compromise easier to hide, which is why fraud controls must be paired with identity governance. For NHI-backed workflows, a secret or token can appear completely legitimate even while the underlying behaviour is malicious.

That distinction matters most in environments with automated approvals, agentic systems, shared accounts, or heavy third-party integration. In those cases, known-bad filtering fails because the abuse is technically valid, operationally plausible, and different only in intent.

Related resources from NHI Mgmt Group

• What breaks when fraud detection relies on login success alone?
• What breaks when identity security depends only on new detection rules?
• What breaks when a compromised internal mailbox is used for fraud?
• What breaks when organisations rely on static vendor lists for fraud prevention?