Microsoft Teams Went Insecure by Default, What That Means for Business Chat Compromise
Microsoft has been steadily extending Teams beyond its original role as an internal collaboration tool, and a recent update allows users to message anyone with an email address, even if that person does not have a Microsoft account, with the recipient receiving an invitation and the conversation continuing inside Teams once accepted.
This capability addresses real operational needs, particularly for teams that work daily with vendors, partners, and contractors who sit outside the organization’s tenant, and in isolation the feature itself is not unusual. What deserves closer attention is the way it was introduced and how that introduction shapes behavior before most organizations are aware a change has occurred.
The feature is enabled globally by default, meaning most organizations did not make a deliberate decision to allow it and many will not notice the change unless they actively review messaging and external access policies. In practice, defaults tend to influence usage patterns long before formal governance or training catches up.
Are we about to see the rise of Business Chat Compromise?
Why internal chat historically earned more trust than email
Internal chat platforms gained adoption not only because they were faster than email, but because they reduced friction in environments that already carried shared identity, shared context, and implicit organizational boundaries. Messages appeared in a space associated with coworkers and known workflows, which lowered skepticism and encouraged rapid response.
Email evolved under very different conditions. Years of phishing, spoofing, and routine account compromise gradually trained users to slow down, verify context, and assume that unexpected messages might be untrustworthy, making caution a normal part of everyday email use.
Teams and similar collaboration tools never experienced that same conditioning period because access was historically limited. Messages were assumed to originate from inside the organization or from explicitly configured external partners, allowing trust to be inherited from access controls rather than earned through experience.
When external identities are introduced into the same interface without a visible shift in context, user behavior does not automatically adjust, even though the risk profile has changed.
How this update expands the social engineering surface without introducing new exploits
From a technical perspective, the change does not introduce novel vulnerabilities or bypass existing security controls, but it does create new interaction paths that sit inside a highly trusted interface. External users can now appear within a communication environment that users associate with internal legitimacy, shared ownership, and operational urgency.
If a personal email account is compromised, that compromise can now extend into Teams conversations where requests benefit from the credibility of the platform itself. Messages that appear routine, time-sensitive, or operationally familiar are more likely to be acted on quickly, especially when they arrive in a space users associate with internal coordination.
This mirrors how Business Email Compromise scaled over time, not by defeating security systems directly, but by embedding itself inside normal workflows until malicious activity blended into everyday communication patterns and became harder to distinguish.
Default enablement matters more than the feature itself
Organizations adapt to tools based on how those tools are presented, and when a capability is enabled by default, users tend to assume it is expected, safe, and already accounted for by security and IT teams. That assumption influences behavior immediately, often before policies, guidance, or training are updated.
If the same feature required explicit configuration, approvals, or deliberate onboarding, it would be perceived differently and evaluated more carefully. The core issue is not whether external collaboration should exist, as many organizations depend on it, but whether that collaboration is introduced without forcing an intentional decision.
Once communication patterns become routine, they are difficult to unwind, and even when controls are tightened later, user expectations and habits often persist.
What structured friction actually accomplishes in real environments
Slack provides a useful comparison because it introduces structure around external communication through mechanisms like Slack Connect, which requires invitations, approvals, and clearly identified shared channels. These steps add modest friction, but they also make context visible at the moment interaction begins.
Users are consistently reminded when they are operating outside their organization, which influences how requests, links, and shared files are evaluated. That friction does not prevent collaboration, but it shapes expectations and reinforces boundaries in ways the interface itself supports.
Removing that friction shifts responsibility entirely onto users while leaving the visual and behavioral cues unchanged, increasing the likelihood that trust is applied where it no longer fully belongs.
Steps organizations can take before new behavior becomes permanent
Teams that want to preserve clarity around internal communication can act before usage patterns solidify and before external messaging becomes part of everyday workflow by default.
Disabling the feature tenant-wide prevents it from being normalized unintentionally and can be done through a straightforward policy change:
Set-CsTeamsMessagingPolicy-IdentityGlobal-UseB2BInvitesToAddExternalUsers $false
External communication can then be reintroduced selectively, tied to specific business cases, supported by guidance, and understood by support teams before it surfaces during incident response. These steps do not reduce flexibility, but they reintroduce visible boundaries that help users evaluate context more accurately.
What this shift signals about collaboration going forward
Microsoft is clearly prioritizing ease of cross-organizational collaboration, and for some environments that tradeoff may be acceptable. For others, the implications may only become visible after misuse or incident response reveals how behavior changed quietly over time.
The more important question is whether the organization made a conscious decision to accept that shift, or whether the decision was made implicitly by a default setting that went unnoticed.
In practice, security outcomes tend to follow intent more closely than tooling, and clarity around intent begins with understanding how defaults shape behavior long before policies are enforced.