THREAT BUCKLER | EPISODE 01

Microsoft Teams: What Are We Really Trusting?

Mapping the architecture before searching for gaps.

Research scope: A reference-architecture threat-modeling exercise using publicly documented Microsoft 365 functionality and fictional configurations. Potential risks are not confirmed product vulnerabilities or findings from a customer tenant.

Why start with Teams?

A file shared through Teams may involve multiple Microsoft 365 services. Understanding their relationships is the first step in understanding the security decisions behind a seemingly simple collaboration workflow.

The purpose of this episode is to map the logical architecture and identify where identity, content, and integration permissions meet.

Reference architecture

Employee or invited guest
↓
Microsoft Entra ID — identity and access policy
↓
Microsoft Teams — collaboration experience
↙   ↓   ↘
SharePoint / OneDrive   |   Microsoft Graph   |   Connected applications

This is a conceptual relationship map, not a literal sequential network or API flow. For example, Teams channel files are generally stored in SharePoint, while files shared in chats commonly reside in OneDrive; access behavior depends on the specific sharing workflow.

Assets and trust boundaries

Boundary	What crosses it	Question to validate
Identity	Employees, guests, authentication tokens	Are external users covered by appropriate access policies?
Collaboration to content	Team membership, sharing links, file permissions	Does the recipient have only the intended file access?
Apps and APIs	Delegated and application Graph permissions	Can an integration access more than its business purpose requires?
Administration	Configuration changes and audit events	Can we attribute and investigate permission changes?

Potential threat scenarios

• A guest remains a team member after a collaboration ends.
• A broadly shared document is accessible beyond the intended audience.
• A connected application receives overly broad consent.
• Security teams cannot correlate access changes across services because relevant logs or alerts are missing.

These are hypotheses. Effective permissions and actual controls must be tested in an authorized tenant before describing any of them as an exposure.

STRIDE lens

Category	Example to investigate
Spoofing	External identity or support impersonation
Tampering	Unauthorized changes to sharing settings or files
Repudiation	Insufficient audit trail for access changes
Information disclosure	Overshared documents or broad API read scopes
Denial of service	Abuse of collaboration or administrative workflows
Elevation of privilege	Unexpected privilege through misconfigured app consent

How to validate

• Document the exact collaboration workflow and storage location.
• Review Entra identity policies, guest membership, and lifecycle controls.
• Test effective SharePoint/OneDrive access using approved test identities.
• Review Graph scopes, app consent, and application ownership.
• Verify audit coverage and detection rules for changes in access.

Do not infer access solely from the presence of an enabled feature.

What comes next

Episode 02 will focus on how legitimate settings can combine into a risky exposure path. Episode 03 will examine whether AI can help connect these settings without creating a second information-disclosure problem.

One thing worth remembering

The security boundary is not always one application. It can be the relationship between identities, content, and connected services.

References and further reading

• Microsoft Learn — Teams guest access
• Microsoft Learn — SharePoint external sharing
• Microsoft Learn — Conditional Access assignments
• Microsoft Learn — Manage application permissions
• Microsoft Learn — Teams external access

Threat Buckler | Application architecture · Threat modeling · AI security