Accountability spans collaboration security, third-party access governance, and identity lifecycle management. The team that owns external access, the team that monitors the channel, and the team that approves vendor connectivity all have a role. Shared responsibility only works when ownership is explicit and reviewed.
Why This Matters for Security Teams
A malicious message arriving through a vendor account is not just a messaging issue. It is a third-party access and identity problem that can turn into phishing, malware delivery, data exfiltration, or privilege misuse if the account is trusted by default. The accountable team is often unclear because collaboration tools blur ownership between vendor management, platform operations, and security monitoring. NHI Management Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which makes vendor-linked identities a common attack path rather than an edge case.
This is why a clean ownership model matters. The vendor relationship owner may approve access, the platform team may operate the channel, and the security team may detect abuse, but none of those functions should rely on implied responsibility. Current guidance suggests that accountability should follow control of access, monitoring, and revocation authority, not just contract ownership. The broader identity posture described in the NIST Cybersecurity Framework 2.0 reinforces that access governance and monitoring must be assigned to explicit roles with reviewable controls. In practice, many security teams discover the gap only after a vendor account has already been abused to send the message, rather than through intentional control testing.
How It Works in Practice
Accountability becomes practical when the organisation separates three questions: who approved the vendor identity, who owns the technical control of that identity, and who is responsible for detecting abuse. A vendor account should be treated as a non-human identity with a defined lifecycle, not as a shared mailbox or informal communication channel. That means the owner must be able to explain why the account exists, who can authenticate to it, what systems it can reach, and how quickly it can be revoked.
In operational terms, the following controls reduce ambiguity:
- Assign one business owner for the vendor relationship and one technical owner for the account.
- Use least privilege so the vendor account can only access the specific channel or system it needs.
- Log authentication, message activity, and privilege changes so abuse can be attributed quickly.
- Review offboarding and rotation steps so access does not survive contract end or role change.
This is also where NHI governance becomes concrete. The Ultimate Guide to NHIs — The NHI Market shows how widespread third-party exposure is, which is why ownership must include revocation authority and monitoring obligations. For teams formalising this model, the NIST Cybersecurity Framework 2.0 is useful for mapping accountability across identify, protect, detect, and respond functions. These controls tend to break down when vendor access is inherited through legacy collaboration tools because no single team can revoke, observe, and investigate the account end to end.
Common Variations and Edge Cases
Tighter vendor access control often increases operational overhead, so organisations must balance speed for business partners against containment of abuse. The main edge case is when the malicious message originates from a vendor account that was compromised externally, not intentionally misused by the vendor. In that situation, the vendor may be responsible for their account hygiene, but the organisation still remains accountable for how its own environment handled the message and whether its controls stopped the spread.
There is no universal standard for this yet, but current guidance suggests using a shared responsibility matrix that names the control owner, the approver, the monitor, and the revoker. That matrix should also distinguish between content abuse, credential compromise, and workflow abuse, because each failure mode requires a different response. If the vendor identity is federated or automated, the account may also need stronger lifecycle governance than a normal human account, including explicit expiry and re-approval. In mature programmes, accountability is not debated after the incident; it is documented before the vendor is allowed to connect.
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 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-01 | Vendor accounts are NHIs and need clear ownership and lifecycle control. |
| NIST CSF 2.0 | PR.AC-1 | Third-party access must be governed by explicit identity and access rules. |
| NIST AI RMF | Accountability for automated message handling requires governance and oversight. |
Document responsibility, monitoring, and escalation paths for all externally connected identities.
