Third-party fraud is fraud committed by an external attacker who steals, impersonates, or hijacks someone else’s identity. Common forms include account takeover, identity theft, and bot-driven abuse. The main control challenge is distinguishing legitimate user behaviour from an attacker operating inside a trusted account or session.
Expanded Definition
Third-party fraud occurs when an external actor uses stolen, replayed, or synthetic identity signals to behave like a legitimate customer, employee, contractor, or partner. In NHI and IAM operations, the term covers more than account takeover. It includes session hijacking, credential stuffing, bot-mediated abuse, consent abuse in delegated access flows, and fraud that rides through trusted integrations. Definitions vary across vendors, but the practical boundary is whether the attacker is operating inside an identity that the organisation already recognises as valid.
This matters because the defender must distinguish intent, not just authentication success. Strong passwords or MFA reduce risk, but they do not automatically stop abuse once an attacker has a valid token, cookie, API key, or compromised OAuth grant. Guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls becomes relevant where identity assurance depends on revocation, monitoring, and privilege containment after initial access. The most common misapplication is treating every successful login as trustworthy, which occurs when organisations ignore post-authentication behaviour and delegated-access abuse.
Examples and Use Cases
Implementing fraud controls rigorously often introduces friction in low-risk journeys, requiring organisations to weigh user convenience against stronger verification, tighter session policy, and more aggressive anomaly detection.
- A customer account is taken over through credential stuffing, and the attacker uses stored payment methods before the fraud team sees unusual velocity patterns.
- An AI agent or automation workflow abuses a valid OAuth grant to pull data or trigger transactions, which looks legitimate unless token scope and behaviour are inspected.
- A compromised partner API key is used to harvest records at scale, similar to incidents discussed in the Klue OAuth Supply Chain Breach and the 52 NHI breaches Report.
- Bot traffic rotates through residential proxies, repeatedly testing password resets, promo abuse, or checkout workflows while staying just below rate-limit thresholds.
- A malicious package or plugin steals browser sessions and secrets, as seen in the JetBrains Marketplace AI Plugin Campaign and the Shai Hulud npm malware campaign.
In these cases, the control problem is not only authentication but also trust decay, where a valid identity becomes the attacker’s vehicle after compromise. The response pattern usually combines behavioural analytics, token revocation, device and session binding, and limits on high-impact actions.
Why It Matters in NHI Security
Third-party fraud is especially dangerous in NHI security because external attackers often target the weakest trusted link: leaked secrets, over-permissioned service accounts, or partner integrations with poor lifecycle controls. NHIMG research shows that NHI Mgmt Group found 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. That pattern explains why fraud is rarely isolated to one compromised user. It often expands into lateral movement, data extraction, and automated abuse across systems that still assume the identity is trustworthy.
Practitioners should treat third-party fraud as an identity governance problem as much as a security monitoring problem. NHI controls such as secret rotation, offboarding, least privilege, and third-party exposure review reduce the chance that a stolen identity can remain useful. The issue also extends to machine-to-machine trust, where a service account or API key can be abused long after the original compromise if revocation is slow or detection is weak. Organisations typically encounter the real cost only after a fraudulent transaction, data exfiltration, or abuse campaign has already succeeded, at which point third-party fraud becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret misuse and identity abuse paths that enable external attackers to impersonate trusted entities. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and authentication states that third-party fraud exploits after initial trust is granted. |
| NIST SP 800-63 | Digital identity assurance guidance helps distinguish legitimate authentication from compromised sessions. | |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes trust must be re-earned, which is essential when attackers operate inside valid identities. | |
| NIST AI RMF | Risk management guidance applies to behavioural models used to detect fraud and identity abuse. |
Inventory, rotate, and revoke exposed secrets fast enough that stolen identities cannot be reused for fraud.
Related resources from NHI Mgmt Group
- Who is accountable when fraud begins on a third-party platform?
- Why do third-party email gateways lose effectiveness against business email compromise and vendor fraud?
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- What are the implications of using OAuth tokens in third-party integrations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
