The gap between what users believe is a trusted internal interaction and what the underlying identity relationship actually is. In Teams phishing, the attacker uses platform trust, display names, and collaboration defaults to exploit that mismatch and bypass caution that would appear in other channels.
Expanded Definition
A collaboration trust gap is a trust-assumption failure inside chat, meeting, document-sharing, or ticketing platforms where the interface feels internal and familiar, but the underlying identity may not be the colleague, partner, or service the user expects. In practice, the gap appears when display names, tenant boundaries, guest access, forwarded invites, shared channels, or embedded links make an interaction look sanctioned even though the actual identity assurance is weak. This is especially important in collaboration suites because the security model often prioritises usability, rapid sharing, and persistent relationships. That convenience can obscure whether the sender, the workspace, and the content source are all equally trustworthy. NIST Cybersecurity Framework 2.0 helps frame this as an identity and access governance issue, not just a phishing problem, because trust must be continuously validated rather than inferred from the medium. The term is still evolving in industry usage, and some teams use adjacent labels such as collaboration phishing or trusted-channel abuse. The most common misapplication is treating any message inside a corporate collaboration app as inherently trusted, which occurs when users rely on platform familiarity instead of verifying the actual identity relationship.
Examples and Use Cases
Implementing controls against collaboration trust gaps rigorously often introduces friction, requiring organisations to weigh faster internal coordination against stronger identity verification and message scrutiny.
- A Teams message appears to come from a known executive profile, but the account is a lookalike created in a partner tenant or guest context.
- A shared-channel request arrives from a real employee name, yet the sender is actually operating from a compromised account with legitimate collaboration permissions.
- A document link posted in an internal chat opens a credential-harvesting site that benefits from the user’s assumption that platform location equals safety.
- A meeting invitation uses a familiar display name and calendar thread, but the join link routes the user to an attacker-controlled session or file drop.
- A workflow notification from a ticketing or automation tool is abused because recipients trust the application banner more than the authenticity of the originating identity.
For teams building a formal response model, the NIST Cybersecurity Framework 2.0 is useful for mapping where identity assurance, access governance, and user awareness need to reinforce one another across collaboration workflows.
Why It Matters for Security Teams
Collaboration trust gaps matter because they bypass the human checks that usually slow down suspicious requests. When the request lands in a known internal tool, users often suspend the skepticism they would apply to email, browser pop-ups, or direct messages from unknown sources. That makes this term especially relevant to identity security, where the real control question is not whether the channel is internal, but whether the identity, tenancy, and authority behind the interaction have been verified. For NHI governance, the same pattern can appear when service accounts, bots, or agentic workflows post content that users interpret as sanctioned without checking provenance or execution scope. Security teams need to align collaboration permissions, guest access, conditional access, and user training so trust is based on assurance rather than interface design. The concept also matters in incident response because lookalike identities and cross-tenant abuse can hide inside normal business communication until a payment, credential, or data loss event exposes the weakness. Organisations typically encounter the operational cost of a collaboration trust gap only after a convincing internal message has already triggered action, at which point identity verification and channel hardening become 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Identity and access assurance governs whether collaboration trust can be safely inferred. |
| OWASP Non-Human Identity Top 10 | Covers provenance and trust risks for non-human identities that post into collaboration tools. | |
| NIST SP 800-63 | AAL2 | Assurance levels help distinguish familiar interfaces from verified identity strength. |
| OWASP Agentic AI Top 10 | Agentic workflows can impersonate trusted internal interactions through tool-mediated communication. | |
| NIST AI RMF | Governance applies where AI-generated or AI-assisted content influences trust decisions in collaboration. |
Map collaboration controls to identity assurance, access governance, and awareness before users act on internal-looking messages.
