Maor Dahan, Chief Technology Officer at Trustifi, leads the company’s technology strategy and product innovation, drawing on years of cybersecurity and software architecture experience to build scalable, enterprise-grade email and collaboration security solutions.
Your clients trust Microsoft 365 with their most sensitive work. Attackers are counting on that trust.
Most email security tools cannot see what happens inside Microsoft Teams, OneDrive, and SharePoint, because those platforms have no inspection checkpoint the way email does.
Sensitive data, malicious links, and risky sharing settings are created directly inside the collaboration layer, where email security was never designed to look. Closing that gap requires protecting the place where the files live, not just the inbox they travel through.
Microsoft Teams has more than 320 million monthly active users, making it one of the most widely used business collaboration platforms in the world. As work has moved into Teams, OneDrive, and SharePoint, security risks have moved there too.
That is the shift I want to walk through, because it changes where your risk lives, and most security stacks have not caught up to it.
Why email security stops at the inbox
Email security works because of a checkpoint. Every message passes through it on its way to the inbox, and that is where we inspect it and stop the malicious ones. The entire model depends on the fact that, when mail arrives, it moves to a place where we are standing guard.
Teams, OneDrive, and SharePoint have no such checkpoint. A message is posted directly into a channel. A file with PII lands in a shared library the instant someone hits save. A folder goes public the moment someone flips it to “anyone with the link.” There’s nothing in transit to intercept. The risk does not come through the door; it is created inside the house.
Why is Microsoft 365 collaboration a security blind spot?
Attackers have already moved beyond the inbox.
Microsoft Teams attacks increased by 41% over the past year as threat actors increasingly targeted collaboration platforms.
And it’s not only about where files and links end up. Threat actors are now running full social-engineering campaigns natively inside Teams, with no email or attachment involved at all. Microsoft has documented intrusions where an attacker, operating from an external tenant, impersonates IT helpdesk over a Teams chat invite, then talks the target into granting remote access through a tool like Quick Assist. In Microsoft’s lab replication, first contact to interactive endpoint access took 21 minutes. From there, attackers have used native protocols like WinRM to move laterally toward domain controllers.
Separately, ReliaQuest has tracked the ransomware group Black Basta running a similar playbook at scale: after bombarding a target with a flood of spam email (in one case, roughly 1,000 messages inside 50 minutes) the group’s operators, posing as “Help Desk” from external onmicrosoft.com tenants, message the user directly in Teams, place a call, and talk them into installing a remote-access tool. In the incidents ReliaQuest observed, the attackers were pulling credentials and staging follow-on tools within minutes of gaining access, on the way to a ransomware deployment.
Neither of those attacks touches an inbox. Both ride on the same trust users extend to a native Teams notification, and neither leaves a trace anywhere an email-security tool would look.
Most of what happens in the collaboration layer never touches email at all. A link is pasted into a channel message. A spreadsheet with PII is uploaded straight to a SharePoint library. A OneDrive folder is opened to ‘anyone with the link’ during a meeting and stays that way for a year. Sensitive data is created, copied, and re-shared inside the tenant, between people who already have access, on surfaces email security was never built to watch.
That is the real exposure. PII, PCI, and PHI now move through Teams chats, channel messages, meetings, and shared libraries as routinely as they once moved through the inbox, and the permissions settings that govern them change constantly, silently, and without anything resembling an inspection point.
We have built good mitigations at the email layer, and they catch a lot. But there is a hard limit: you cannot fully inspect a file you are not permitted to open, and you cannot inspect a file that never traveled through email in the first place. The only complete answer is to detect sensitive data, malicious links, and risky sharing where the collaboration happens.
The question you never want to answer with “we don’t know”
When something goes wrong in the collaboration layer, the questions that follow are painfully specific. Who saw this file? How did this data leave? Who has access right now?
For most MSPs, there is no unified way to answer them. The data is scattered across tenant audit logs, and reconstructing a timeline takes forensic work, hours per incident, multiplied across every tenant you run. “We don’t know” is not a sentence any security provider wants to say to a client. That is not a visibility gap; it is an accountability gap. This is a gap that could cost you the customer relationship.
Why collaboration needed its own security layer
When we looked at the market, we saw two options and neither fit the MSP.
On one end were enterprise data security platforms built to monitor and protect data across Microsoft 365 and other cloud applications. They were genuinely capable but designed for enterprise budgets. On the other side, email vendors with a ‘Teams support’ checkbox that turns out to be a log feed with a dashboard. For an operator running thirty tenants, or a mid-market client with no SOC, there was nothing built for how you work.
We already had the hard parts: DLP classification, URL and file analysis, and reviewer workflows. We do these every day with email. Collaboration Shield points those same detection engines at the other place your clients’ data moves. One classification model, one set of policies, covering both surfaces.
How does Collaboration Shield protect Teams, OneDrive, and SharePoint?
The architecture reflects the MSP reality. It connects through the Microsoft Graph API, with no agents, no mail flow changes, and no deployment project. Onboarding a tenant requires only API consent, which takes just minutes and enables Microsoft to push events to us as they happen. That approach scales across dozens of tenants without requiring a separate rollout for each one.
Because we are inside the tenant, we scan the file at the source. That recipient-locked file the email scanner couldn’t access is no longer a blind spot because we inspect it where it lives. The difference isn’t a smarter email scanner. It’s protecting collaboration content at the source instead of trying to inspect it from the wrong side of the wall.
Why access mapping matters more than detection alone
Knowing a file contains PHI is useful. Knowing who can open that file right now allows you to act.
For every risky finding, Collaboration Shield resolves the live access picture: users, groups, and every shared link and its scope. The finding is not ‘this file contains PHI’. It is ‘this file contains PHI, it is shared externally, and here are the individuals or groups who can currently open it’. Policies can then quarantine the file, revoke the link, notify the owner and reviewer, and escalate high-severity events. When a client asks who had access, that becomes a question you answer in minutes, with an audit trail, not a forensic project.
In practice, that means automatic quarantine of risky files, revocation of dangerous sharing links, real-time alerts to owners and reviewers with escalation on high-severity events, and bulk remediation across every tenant you manage, not just the one where an incident was found.
See where the threats actually moved
The shift I have described is easy to nod along to and hard to feel until you watch it happen live.
On our upcoming webinar, you’ll see how a threat moves through Teams, OneDrive, and SharePoint. We’ll show exactly what Microsoft 365 leaves exposed, including the recipient-locked file scenario that native tools miss entirely. You’ll also see how detection, live access mapping, and remediation come together.
Date / Time: August 13th, 1 PM ET
Speaker: Zack Schwartz
The threats have already moved beyond the inbox. It’s time our protection did, too.
