Collaboration tools are only as safe as the boundaries you put around them. Microsoft Teams external access is designed to make it easy to work with people outside your organization, but the same openness that helps partners reach you also helps attackers reach your employees. This is the story of how one organization went from being overwhelmed by fake helpdesk impersonation to running a controlled, allow-listed, and self-sustaining Teams external access model.
The Attack: Fake Helpdesk Calls and Chats from Outside Tenants
The client came to us with a specific and escalating problem. Threat actors were using Microsoft Teams to impersonate internal IT support, reaching employees directly through calls and chat messages that originated from external tenants. The messages looked routine. They referenced “Helpdesk,” “IT Support,” or a pending ticket, and they asked users to click a link or approve a request to resolve an urgent issue.
Two factors made this campaign especially dangerous. First was the sheer volume: the attacks hit many people across the organization, not just a handful of executives. Second was susceptibility. Because the messages arrived inside Teams, a trusted internal tool, employees were far more likely to treat them as legitimate than they would a suspicious email. That combination worked. Several users clicked the links before the pattern was fully understood, turning a nuisance into a genuine security exposure.
Why Microsoft Teams External Access Is an Attractive Target
By default, Teams external access can allow federated communication with other Microsoft 365 tenants across the internet. For many organizations, that means anyone with a Teams tenant can initiate a chat or call with your users. Attackers know this, and they know that a message delivered inside Teams carries an implied trust that a cold email simply does not.
Helpdesk impersonation exploits that trust directly. The attacker does not need to breach anything. They only need a Teams tenant, a convincing display name, and a plausible reason for the user to act. When the target pool is large and the tooling feels internal, even a small click-through rate produces real incidents. For this client, the traditional advice of “train users and monitor” was not keeping pace with the volume, so we shifted the conversation from detection to prevention at the boundary.
The Decision: Block by Default with Approved Domains
After weighing the options, the client chose the most decisive control available: block external access by default and allow it only from a curated list of approved domains. Rather than trying to identify and stop malicious tenants one at a time, which is an endless game, we inverted the model. Communication is denied unless the sending domain is explicitly trusted.
This is a meaningful trade-off, and we want to be candid about it. A block-by-default posture can interrupt legitimate collaboration with a new partner whose domain has not yet been approved. For this organization, given the intensity of the attacks and the demonstrated susceptibility of the workforce, the security benefit clearly outweighed the friction. The key was making the approval process fast enough that the block did not become a barrier to doing business.
Building the Initial Approved Domains List
A block-by-default model is only as good as the allow-list behind it. To stand it up quickly, we helped the client mobilize organizational leaders to gather the domains that actually matter to the business. Department heads, account managers, and procurement contacts pulled together client lists, vendor lists, and other important partner domains that needed guaranteed access.
We consolidated those inputs, removed duplicates and obvious errors, and translated them into the approved domains configuration for Teams external access. In a short window, the organization went from accepting communication from the entire internet to accepting it only from a vetted set of trusted domains. The flood of external helpdesk impersonation attempts dropped sharply, because the attacker tenants were simply no longer able to reach users.
Making It Sustainable: Self-Service Domain Management
The initial block solved the immediate problem, but it created a predictable operational question: what happens the next time the business needs to add a new client or vendor domain? If every change requires an IT ticket and a manual edit in the Teams Admin Center, the list falls behind, users get frustrated, and pressure builds to loosen the control. That is exactly the failure mode we wanted to avoid.
To keep the model both secure and manageable, our team built a lightweight self-service solution. We created a SharePoint Communications Site where authorized business users can submit and review domains they need approved. Behind that site, a set of Power Automate flows validates the requests and syncs the approved entries so the Teams external access allow-list stays current automatically.
This design keeps IT in control of the guardrails while removing IT as the bottleneck for routine additions. Business owners who understand their own client and vendor relationships can request the domains they need through a simple, familiar interface, and the automation handles the rest. The approved domains list becomes a living, governed asset instead of a static configuration that quietly drifts out of date.
Three Lessons Learned
Three takeaways stand out from this engagement.
- When a collaboration channel becomes a reliable attack vector, boundary controls can be more effective than trying to out-train a high-volume social-engineering campaign.
- A block-by-default posture is only viable if the approval process is fast, which is why the self-service layer mattered as much as the block itself.
- The durable win came from pairing a security control with an operational process that the business could own over time.
Blocking external Teams access is not the right answer for every organization, and the approved domains model should be scoped to how a business actually collaborates. But for a client under sustained helpdesk impersonations, moving from open to allow-listed, and making that list easy to maintain, turned a recurring incident into a managed, low-noise part of their environment.
