Microsoft Teams chat with anyone raises SaaS governance blind spots

At a glance

What this is: Microsoft Teams' new external chat flow creates guest users from email-only invites, widening collaboration paths and governance exposure.

Why it matters: IAM and NHI teams need to treat every new guest identity, chat thread, and shared file as a managed access pathway, not just a collaboration feature.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Valence Security's analysis of Microsoft Teams external chat and guest identity risk

Context

Microsoft Teams is adding a broader external collaboration path by allowing users to start chats with any email address, which means a simple invite can create a guest identity and extend access into the tenant. In practical terms, that turns a convenience feature into an identity governance issue because guest creation, conversation scope, and data sharing now move faster than many approval and review workflows.

For IAM and NHI practitioners, the key question is not whether collaboration should be easier, but whether the organisation can still see, classify, and retire the identities and access paths created by those conversations. The pattern is familiar across SaaS: features ship for usability, while lifecycle control, logging, and data handling catch up later. That gap is where shadow access forms.

The guest identity and lifecycle problem is a core NHI issue, not just a SaaS admin setting. The NHI Lifecycle Management Guide from NHI Mgmt Group is useful when teams need a control model for provisioning, review, and offboarding across external identities and service accounts.

Key questions

Q: How should security teams govern external collaboration in SaaS apps?

A: Security teams should treat external collaboration as an identity and data governance workflow, not just a messaging feature. Define who can invite guests, which domains are allowed, what information can be shared, and how guest accounts are reviewed and removed. The goal is to make external access temporary, traceable, and tied to business ownership.

Q: Why do guest accounts create more risk than internal users?

A: Guest accounts often appear quickly, inherit broad contextual visibility, and are forgotten after the immediate task ends. That creates dormant access, unclear ownership, and untracked data exposure. The risk is higher because the account was created for convenience, not through the same lifecycle discipline applied to internal identities.

Q: What is the difference between SaaS configuration and SaaS governance?

A: SaaS configuration is the on or off state of a feature. SaaS governance is the policy, ownership, monitoring, and cleanup process that determines whether the feature can be used safely. A disabled setting may reduce exposure, but only governance ensures identities, content, and exceptions are managed over time.

Q: How can organisations reduce the blast radius of external chat features?

A: Limit who can create external chats, require trusted domains, apply data controls to the conversation layer, and automate guest revocation when the business need ends. Also assign accountability for each guest identity so cleanup does not depend on memory or manual follow-up.

Technical breakdown

How email-only guest invites change the identity boundary

When a collaboration platform lets a user invite anyone by email, the identity boundary shifts from pre-provisioned access to just-in-time external onboarding. The guest account becomes a non-human identity in the sense that it exists for a specific access path and may persist beyond the original need. The security problem is not the invite itself, but the lack of strong lifecycle coupling between invitation, approval, scope, and retirement. If the platform auto-creates the account, the organisation needs compensating controls for validation, expiration, and review.

Practical implication: Treat email-only guest creation as an identity lifecycle event and require automated expiry and periodic revalidation.

Why chat content becomes an ungoverned data path

External chats often sit outside the controls that teams rely on for files and formal records, even when the underlying SaaS platform logs them. That means URLs, credentials, and sensitive business context can move through a channel that is easy to create and hard to inventory later. In governance terms, the issue is not only access, but data lineage. Once a guest account is active, every message thread can become a distribution point for sensitive content that was never intended to live outside managed repositories.

Practical implication: Map external chat channels into data loss prevention, retention, and eDiscovery scope before enabling broad guest access.

What makes guest sprawl different from ordinary access sprawl

Guest sprawl grows from user-driven collaboration rather than administrator-driven provisioning, which makes it harder to track with traditional IAM review cycles. The platform may create an identity for a conversation, but the risk persists when no one owns the cleanup. Over time, that produces a long tail of dormant guest users, orphaned permissions, and unclear accountability. For NHI governance, this is the same structural problem seen with service accounts and API keys: access is easy to create and hard to remove.

Practical implication: Build ownership, revocation, and inactivity controls into external collaboration workflows, not just into quarterly access reviews.

Threat narrative

Attacker objective: The attacker wants to use the trusted collaboration channel to gain context, data, or a foothold for impersonation and follow-on access.

1. Entry begins with an email-only external chat invitation that bypasses normal pre-approval workflows and creates a guest account inside the tenant.
2. Escalation occurs when the guest can participate in conversations, receive shared files, and inherit visibility into internal context that was never intended for broad exposure.
3. Impact follows when sensitive data, credentials, or trusted communication paths are used for phishing, impersonation, or compliance bypass through the external thread.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Guest collaboration is becoming an NHI governance problem, not a communications preference. When a platform can create external identities from an email address alone, the enterprise inherits a new class of access object that must be tracked, reviewed, and retired like any other identity. That shifts collaboration from a usability issue to a governance control surface. Practitioners should treat every externally invited guest as part of the NHI inventory, not a temporary exception.

External chat creates a data path that legacy DLP thinking often misses. Teams, files, links, and side conversations can all carry sensitive material, but the creation path is user-initiated and fast. Traditional controls often focus on storage locations and sanctioned repositories, while collaboration threads quietly become the real distribution layer. Security teams need to align collaboration policy with data classification and retention, or the platform will outpace the control model.

Identity blast radius is the right named concept for this pattern. A single external invite can expand the number of identities, message threads, shared artifacts, and retention obligations tied to one user action. That blast radius is not just technical, it is operational, because cleanup requires coordination across IAM, SaaS admin, and compliance teams. The practical conclusion is simple: limit the number of people who can create external collaboration paths and automate cleanup from the start.

Admin toggles are not governance. Disabling a feature with PowerShell may reduce exposure, but it does not solve ownership, review cadence, or data handling for the collaboration paths that remain. NHI governance fails when teams confuse configuration with control. Practitioners need policy, telemetry, and lifecycle enforcement together, otherwise the platform still generates unmanaged identities and unmanaged content.

Safer collaboration depends on making external access temporary by design. The broader SaaS trend is toward feature expansion, which means the default state will usually favor convenience. NHI and IAM teams should respond by making external identity creation, review, and revocation explicit business processes. If the organisation cannot retire the identity, it should not create it casually.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHI Lifecycle Management Guide is the most direct next step for teams building external identity offboarding and review workflows.

What this signals

Identity blast radius is now a measurable SaaS risk surface. With 92% of organisations exposing NHIs to third parties according to the Ultimate Guide to NHIs, the governance problem is not limited to service accounts or APIs. Collaboration features that create guest users on demand extend the same third-party exposure pattern into everyday messaging.

Security teams should expect more user-driven identity creation across SaaS platforms, and that will strain quarterly review processes that were designed for slower change. The programme response is to make external identity approval, telemetry, and retirement part of the same operating rhythm as access management. Without that integration, guest accounts will keep accumulating outside the control model.

The safer operating pattern is to align collaboration policy with Zero Trust Architecture and least-privilege access controls. NIST Cybersecurity Framework 2.0 can help structure that response by separating governance, protection, detection, and recovery tasks across IAM, SaaS admin, and data protection teams.

For practitioners

• Define an external collaboration policy Specify which domains are trusted, who may initiate external chats, and what data classes are prohibited in guest conversations. Tie the policy to approval thresholds and exception handling so users do not improvise access rules in the middle of a project.
• Automate guest lifecycle management Continuously monitor newly created guest users, set inactivity thresholds, and remove accounts when the collaboration purpose ends. Include ownership fields so every guest identity has a business sponsor for review and revocation.
• Extend DLP and retention to chat threads Classify external chat channels as governed data paths and apply retention, eDiscovery, and sensitive-data controls to both messages and attachments. Do not rely only on repository controls when the collaboration layer can become the distribution layer.
• Separate feature enablement from governance approval Require security review before enabling broad external chat capabilities and document compensating controls when the feature remains on. Administrative toggles should be treated as one control, not the control model itself.

Key takeaways

• External collaboration features can create guest identities faster than many IAM and SaaS governance workflows can review or remove them.
• The primary risk is not only access sprawl but also ungoverned data movement through chat threads, files, and external participants.
• Security teams should pair policy, telemetry, and automated offboarding so collaboration convenience does not become unmanaged exposure.

Key terms

• Guest Identity Sprawl: Guest identity sprawl is the accumulation of externally created accounts that are added for a specific collaboration need and then left behind. In SaaS environments, these identities often outlive the original purpose, creating review burdens, hidden access paths, and compliance exposure.
• Identity Blast Radius: Identity blast radius is the amount of access, data exposure, and downstream operational burden created by a single identity action. In collaboration tools, one external invite can generate multiple guest accounts, shared artifacts, and retention obligations that extend far beyond the original conversation.
• SaaS Security Posture Management: SaaS security posture management is the practice of continuously identifying, evaluating, and remediating risky SaaS configurations and access paths. It matters when platform features change quickly, because the control challenge is not only the setting itself but also the identities and data flows it creates.

Deepen your knowledge

External collaboration governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with guest identities, access review, and offboarding in SaaS platforms, it is worth exploring.

This post draws on content published by Valence Security: Microsoft Teams "Chat with Anyone" and the security blind spots it creates. Read the original.