Accountability usually sits across security operations, identity governance, and collaboration-platform owners because the failure spans platform trust, user validation, and endpoint response. Frameworks such as the NIST Cybersecurity Framework and NIST SP 800-63 help clarify control ownership, but organisations need an internal owner for support-identity verification as well.
Why This Matters for Security Teams
Teams impersonation is not just a phishing problem. When a trusted collaboration account is used to deliver malware, the organisation has already lost the benefit of the platform’s trust signal, and the blast radius often reaches identity, endpoint, and support operations at once. Accountability therefore spans the team that owns identity verification, the SOC that detects the abuse, and the platform administrators who manage tenant controls and conditional access.
The practical issue is that users often treat a familiar avatar or thread as proof of legitimacy, while attackers rely on that trust to push payloads or credential-harvesting links. NHI Mgmt Group’s research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is a reminder that trust failures in one system frequently become delivery paths in another. See the broader NHI risk context in Ultimate Guide to NHIs and the control framing in the NIST Cybersecurity Framework 2.0.
In practice, many security teams encounter the ownership gap only after a malicious message has already been forwarded internally and a workstation has already begun beaconing.
How It Works in Practice
Clear accountability starts by separating platform trust from security responsibility. The collaboration owner is typically accountable for hardening the tenant, enforcing conditional access, and limiting external impersonation paths. Security operations is accountable for detection, triage, containment, and evidence preservation. Identity governance is accountable for verifying whether the sender account was compromised, abused through delegated access, or falsely represented through display-name spoofing.
A workable operating model usually includes:
- Owner identification for the collaboration platform, mail gateway, and identity provider.
- Escalation criteria that define who disables accounts, revokes sessions, and blocks hashes or URLs.
- Support-identity verification steps so help desk staff can validate requests without relying on chat context alone.
- Logging that ties message delivery, file access, token use, and endpoint execution into one investigation path.
- Post-incident review that assigns corrective actions to the right control owner, not just the response lead.
For control alignment, the NIST Cybersecurity Framework 2.0 helps structure ownership across Identify, Protect, Detect, Respond, and Recover, while Ultimate Guide to NHIs provides the governance backdrop for privileged and service-linked identities that may be used in the follow-on stages of the attack. Current guidance suggests that support staff should never treat a chat message as proof of identity, even when it comes from a known internal account.
These controls tend to break down when collaboration platforms are administered separately from identity systems, because no single team can see the full path from impersonation to payload execution.
Common Variations and Edge Cases
Tighter verification of support and platform identities often increases friction, requiring organisations to balance user experience against the risk of social engineering and malware delivery. The right ownership model depends on how Teams is integrated with email, endpoint protection, and identity governance, and there is no universal standard for this yet.
One common edge case is a compromised internal account that is used for malware delivery without obvious impersonation markers. In that scenario, accountability may shift toward identity operations for stale credentials or weak MFA enforcement, while the collaboration owner remains responsible for tenant controls that failed to limit abuse. Another edge case is a third-party support channel or delegated admin role, where the internal owner must still define who verifies the sender and who can revoke access.
For organisations that want to reduce ambiguity, the most useful practice is a named control owner for “trusted-message abuse” incidents, backed by documented decision rights for containment, user notification, and tenant hardening. The Shai Hulud npm malware campaign is a useful reminder that trusted channels can become delivery mechanisms once an attacker reaches an authenticated environment.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Ownership and accountability are central to deciding who answers for impersonation-led malware delivery. |
| NIST SP 800-63 | AAL2 | Assurance and verification rules help determine when a message or request is not trustworthy enough. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Compromised non-human or service-linked identities often extend malware impact after impersonation. |
Assign a named control owner for collaboration abuse, then map response and recovery duties to that owner.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
