They bypass gateways because the link often points to a legitimate cloud service, even though the content behind it is malicious. The message may look safe at the URL layer while still collecting credentials or session tokens. Security teams need identity-aware inspection of new tenants, external invites, and unusual login paths.
Why This Matters for Security Teams
Collaboration-platform phishing works because email security is still tuned to inspect message origin, attachment reputation, and known malicious URLs, while the lure itself often lives inside a trusted SaaS tenant. The first hop can look clean: a shared file, an external invite, a team message, or a support request routed through a legitimate domain. That means the risk shifts from message filtering to identity abuse, tenant trust, and session theft. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that detection must extend beyond the perimeter and into access governance and identity monitoring. NHI Management Group has also documented how collaboration tools become high-impact leakage paths, with The State of Secrets Sprawl 2025 showing that 38% of secrets incidents in collaboration and project management tools are classified as highly critical or urgent. In practice, many security teams encounter the compromise only after a user has already authenticated through a trusted workspace invite, rather than through intentional malicious-link blocking.
That is why gateway-only thinking fails: the platform is legitimate, but the interaction is not.
How It Works in Practice
Traditional gateways excel when they can score a URL, file, sender, or attachment before delivery. Collaboration-platform lures bypass that model by using the trust properties of the service itself. An attacker may create a tenant, send an invite from a real account, post a malicious file in a shared workspace, or chain a message into a consent or login flow that captures credentials or session tokens. The malicious step often happens after the gateway has already allowed the message through.
Defence therefore needs to move to identity-aware inspection and runtime policy. Security teams should watch for:
- New tenants or external workspaces appearing outside normal partner patterns.
- Invites that trigger uncommon login paths, especially from unmanaged devices.
- Requests for re-authentication, OAuth consent, or token exchange during collaboration sessions.
- Cross-tenant sharing that exposes sensitive files, secrets, or admin workflows.
Practically, this means combining CASB-style visibility, identity provider telemetry, and session-level controls with phishing detection. The NIST identity guidance and zero trust principles support evaluating access at the point of use, not just at delivery. For collaboration environments, that also means treating shared links, channel memberships, and external guests as high-value trust decisions, not routine admin noise. NHI Management Group’s DeepSeek breach analysis is a useful reminder that trust boundaries collapse quickly once a legitimate platform is used to move users into unsafe workflows.
These controls tend to break down when collaboration is unmanaged across multiple tenants and shadow IT accounts because the identity signals needed for runtime scoring are fragmented or missing.
Common Variations and Edge Cases
Tighter collaboration controls often increase user friction, requiring organisations to balance phishing resistance against partner usability and business speed.
Not every lure is a credential-harvesting page. Some are designed to trigger consent grants, file downloads, or downstream conversation hijacking. Best practice is evolving on how much automation should be allowed for external invitations, so there is no universal standard for this yet. The safest approach is to treat high-risk collaboration events as policy decisions, not just security alerts. That includes flagging first-time external tenants, unusual geo or device context, and links that resolve to reputable cloud domains but originate from untrusted senders.
One useful operational lens is the identity chain behind the message. If the sender, tenant, invite path, and session context do not line up with known business relationships, the message should be treated as suspicious even when the URL is clean. This is especially important for teams using shared workspaces for procurement, legal review, or incident response, where a legitimate platform is exactly what attackers prefer to exploit. For broader NHI context, the Ultimate Guide to NHIs — The NHI Market is helpful for understanding how trust expands once identities are allowed to act across systems. That same pattern applies to collaboration lures: the platform is trusted, but the workflow is not.
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 | Covers identity misuse when trusted services are abused for phishing and token theft. |
| NIST CSF 2.0 | PR.AA-3 | Identity verification and authentication are central to stopping trusted-platform phishing. |
| NIST AI RMF | Governance is needed where automated scoring and trust decisions depend on context. |
Add identity-aware controls for external invites, reauthentication, and session trust decisions.
