Who is accountable when a trusted vendor identity is used to trigger fraud?

Why This Matters for Security Teams

When a trusted vendor identity is used to trigger fraud, the failure is rarely a single login event. It usually reflects weak third-party governance, overly broad access, and poor visibility into who can act on behalf of the vendor. The practical question is not only who clicked or authenticated, but who defined the trust boundary, approved the access, and monitored the activity once it was granted.

This matters because vendor identities often sit inside business-critical workflows such as payments, provisioning, support, or API automation. If those identities are treated as harmless because they are “known,” organisations may miss the fact that trust was extended without enough verification, segmentation, or ongoing review. NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame this as a control ownership problem, not just an incident response problem.

Security teams also need to distinguish between identity compromise and process failure. A fraudulent action may be enabled by stolen vendor credentials, but it may also be made possible by excess privilege, weak segregation of duties, or a failure to revoke access when the vendor relationship changed. In practice, many security teams encounter the abuse only after money, data, or approvals have already moved through a trusted path, rather than through intentional third-party monitoring.

How It Works in Practice

Accountability should be split across operational ownership and control ownership. The enterprise owns the risk of allowing a vendor identity into its environment, while the vendor owns how that identity is issued, protected, and supervised. In mature programs, that split is documented in contracts, onboarding checks, access reviews, and incident response clauses. The goal is to make the trust relationship measurable rather than assumed.

For practitioners, the key is to map the full identity lifecycle:

• Provisioning: who approves vendor access, what level of privilege is granted, and whether the access is time-bound.
• Authentication: whether strong authentication is required for all vendor actions, especially those that initiate payments or change records.
• Authorization: whether the vendor identity can perform only the exact task needed, or whether it has reusable access across workflows.
• Monitoring: whether logs, alerts, and anomaly detection can tie an action back to a specific vendor identity and session.
• Revocation: whether access is removed quickly when a contract ends, staff changes, or suspicious activity appears.

Controls from NIST SP 800-53 Rev 5 Security and Privacy Controls are useful here because they support access control, auditability, and third-party accountability in a way that can be tested. Many organisations also align vendor identity oversight with CISA guidance on risk reduction when exposed systems or integrations could be abused as part of the fraud chain.

Where the vendor identity is tied to automation, API access, or service-to-service workflows, the identity should be treated as an operational credential with explicit ownership, not as a shared convenience account. This is especially important when the same vendor can trigger approvals, move data, and initiate financial or administrative actions. These controls tend to break down when access is granted through ad hoc integration shortcuts because the business treats vendor identity as a procurement issue rather than an enforceable security boundary.

Common Variations and Edge Cases

Tighter third-party controls often increase friction for operations, requiring organisations to balance fraud resistance against vendor responsiveness and process speed. That tradeoff becomes sharper when the vendor supports urgent business workflows, legacy systems, or high-volume automation.

One common edge case is shared vendor access. Best practice is evolving, but guidance consistently suggests that shared accounts reduce accountability and make fraud investigation harder. Another is delegated authority, where a vendor is allowed to act on behalf of employees or customers. In those cases, the organisation must define whether the vendor is a processor, a controller, or simply a technical intermediary, because the accountability model changes with the legal and operational role.

There is also a distinction between a vendor identity being compromised and a vendor workflow being misused within its intended permissions. The latter can still produce fraud even when authentication is working as designed. That is why fraud prevention should combine identity controls with transaction approval rules, behavioural monitoring, and periodic recertification. The NIST AI Risk Management Framework is relevant where automated systems or AI-assisted approvals are part of the trust chain, because accountability must cover both the human and machine steps that enable the action.

For high-risk environments, the strongest answer is not to ask who is “at fault” after the event, but who had authority to create, approve, and observe the vendor identity at each stage. That is the accountability model auditors, incident responders, and fraud teams can actually test.

Related resources from NHI Mgmt Group

• Who is accountable when travel fraud exploits trusted platform access?
• Who is accountable when identity data used for certification is wrong?
• Who is accountable when a verified identity is later used for fraud?
• Who is accountable when a digital identity platform is used for fraud or unauthorised changes?