Malik Haidar has spent years inside multinational enterprises tracking how collaboration features can both accelerate business and accidentally open doors for adversaries. In this conversation, he unpacked the “cross-tenant blind spot” in Microsoft Teams guest access, where protections follow the host tenant, not the user’s home org. We explored how default-on features and invite flows reshape the threat surface, practical steps to harden without breaking the business, and the often-overlooked email angle where Microsoft-originated messages slip past SPF/DKIM/DMARC. Themes include testing and validation of guest scenarios, layered controls for B2B, SOC detections for external message requests, procurement strategies that account for attacker licensing, and how to build out-of-bound visibility with partners when attacks live in someone else’s tenant.
Ontinue’s Rhys Downing calls this a “cross-tenant blind spot,” where protections follow the host tenant, not the home org. Can you walk through a real case where that mattered, share the steps an attacker took, and quantify impact using metrics like click rates or time-to-detection?
We handled a case where an attacker spun up a bare-bones Microsoft 365 tenant, disabled safeguards, and targeted a finance team with Teams guest invites. The email invite came from Microsoft infrastructure, slid past our mail checks, and the conversation shifted into the attacker’s tenant where our Safe Links and Safe Attachments didn’t apply. The attacker sent follow-up chat messages with links to a fake invoice portal; the victim’s organization never saw a policy violation because all traffic lived outside its boundary. The meaningful metrics we tracked were the interval between email invite and first click, and the time from first risky guest join to SOC awareness; the latter required correlating external message requests with identity telemetry to close the gap.
Microsoft is rolling out email-based Teams chats to anyone, globally by January 2026. How do you see that changing the threat surface, what early indicators would you monitor, and can you share anecdotes or metrics from pilots or similar rollouts?
Email-based chats broaden the funnel by allowing outreach to people who don’t even use Teams, and by design, those invites look highly legitimate. I monitor spikes in external message requests, first-contact conversations with new domains, and clusters of invites from newly created tenants. In pilots, the earliest tell was a sudden concentration of invites sourced from similar naming patterns and newly registered domains, followed by rapid acceptance from users with external-facing roles. The key is building baselines before the rollout is complete so deviations stand out quickly rather than weeks later.
Guest access differs from external access in Teams. How do you explain this distinction to executives, what step-by-step checks do you use to verify which path is in play, and where have you seen this misunderstood in the field?
I tell executives that external access is like a phone call across company boundaries, while guest access is like handing a visitor a badge to walk inside your building. To verify, I check the chat thread context, tenant IDs in Teams client details, and whether Azure AD B2B objects were created. I also review Teams policies to see if the session is governed by guest permissions or external federation rules. The common misunderstanding is assuming any “external” chat remains under home-tenant protections; in guest scenarios, that assumption breaks.
The setting UseB2BInvitesToAddExternalUsers=false stops sending invites but not receiving them. How do you compensate for that asymmetry, what layered controls have worked in practice, and can you share metrics showing reduction in risky guest joins?
We compensate by enforcing trusted domain allowlists for B2B, applying cross-tenant access policies that restrict who can add our users as guests, and gating risky roles behind approvals. Conditional Access is scoped to guest and external identities, and we alert on any guest object creation from non-trusted tenants. After implementing these layers, we observed a clear downward trend in unsolicited guest joins coupled with faster analyst triage times because noise from unknown tenants dropped. The combination of allowlists and event-based alerts drove the most visible reduction.
Attackers can spin up low-cost tenants (e.g., Teams Essentials, Business Basic) without Defender. What playbook do you recommend to detect such “protection-free zones,” how do you validate them, and which telemetry or block rules have yielded measurable risk drops?
The playbook starts with discovery: flag external invites from tenants with minimal security signals, recently created domains, or missing advanced protection hints. We validate by checking tenant IDs against known reputation sources and by examining policy responses when interacting in lab conditions. On the control side, we block or challenge tenants that lack required safeguards via cross-tenant access settings and domain trust. We then track the decrease in invites from those tenants and the lowered rate of risky guest object creations as evidence of risk reduction.
Since invite emails originate from Microsoft, SPF/DKIM/DMARC checks won’t flag them. What additional email controls or detections do you deploy, how do you tune them to avoid false positives, and can you share step-by-step triage for such invites?
We add behavioral detections that look for unsolicited collaboration invites at scale, unusual sender-tenant patterns, and time-of-day anomalies. Tuning hinges on allowlisting known partners and using historical user interaction baselines to avoid flagging legitimate project kickoffs. In triage, we confirm the tenant ID, check if the domain is trusted, look for sudden bursts of similar invites, and verify if the recipient has a business need. Only then do we quarantine, notify the SOC, or let it pass with an advisory.
Safe Links and Safe Attachments might not apply once the user is a guest in the attacker’s tenant. How do you recreate that scenario in testing, what outcomes do you measure, and which compensating controls or user prompts have proven effective?
We stand up a lab tenant with protections minimized, invite test accounts as guests, and simulate the attacker’s chat, file share, and link delivery. We measure whether links are scanned, what telemetry reaches our SOC, and how quickly a user clicks without an in-line warning. Compensating controls include browser isolation for unknown tenants, prompts that warn users when entering untrusted tenants, and policy-driven download restrictions. User-facing banners that clearly state “You are operating in an external tenant” help reduce impulsive clicks.
Walk me through the attacker’s reconnaissance to guest-invite flow: what signals do they gather, how do they personalize outreach, and where can defenders disrupt the chain? Please include concrete indicators, timing, and examples from red team exercises.
Attackers map org charts via public bios, conference materials, and supplier listings, then target roles that routinely accept external invites. Personalization leans on project names, vendor references, and meeting cadences scraped from social posts or press releases. The initial invite lands fast after recon, with a follow-up chat that mirrors expected business language and file types. Defenders can disrupt with trusted domain controls, external message request monitoring, and targeted user prompts that slow acceptance and drive reporting.
Microsoft says the feature is enabled by default. How do you manage default-on releases in collaboration tools, what change-control steps do you follow, and can you share metrics or anecdotes showing the cost of late hardening versus day-zero hardening?
We treat default-on like a fire drill: rapid risk assessment, policy review, and pilot in a small cohort before enterprise-wide exposure. We pre-stage detection rules, update user prompts, and have rollback guidance ready. When hardening lags, we’ve seen a spike in external requests and a backlog in SOC triage as analysts chase context across tenants. Day-zero hardening avoids that surge by establishing baselines immediately and narrowing the attack window.
When a target already uses Teams, they get an in-app external message request. How should SOCs monitor and analyze these events, what event fields matter most, and what thresholds or behavioral patterns have flagged abuse in your experience?
SOCs should log and alert on external message requests, capturing tenant ID, domain, time, recipient role, and acceptance outcome. Patterns that matter include bursts of requests from the same external tenant and sudden outreach to exec assistants or finance. We also track first-contact sessions that jump straight to file sharing. Thresholds trigger when we see multiple requests from unknown tenants within a short window or acceptance followed by link clicks without prior history.
What cross-tenant access policies and B2B restrictions (e.g., trusted domains) do you prioritize first, how do you roll them out without breaking business workflows, and which dashboards or metrics tell you the controls are actually working?
We prioritize a trusted domain allowlist, restrict guest invitations to vetted partners, and enforce Conditional Access for guest sessions. Rollout starts in monitor mode with near-real-time alerts, then moves to enforced blocks as exceptions are handled. Dashboards should show guest object creation trends, external request acceptances, and policy denials over time. When legitimate partner flows remain steady while unknown tenant interactions fall, you know you’re on the right track.
For organizations that can’t disable external Teams communication, what minimal viable guardrails do you recommend, how do you phase them, and can you share before-and-after incident metrics or real stories that show their effect?
Start with a curated partner allowlist, visible user prompts for external tenants, and automated alerts on first-time guest joins. Phase two adds download restrictions, session controls for untrusted tenants, and stronger review for high-risk roles. In practice, we’ve seen incident queues calm after deploying prompts that remind users when they cross tenant boundaries. The combination of prompts and allowlists cuts down accidental acceptances while preserving legitimate collaboration.
How do you train users to spot risky Teams invites that look legitimate due to Microsoft infrastructure, what scripts or examples resonate, and how do you measure training effectiveness beyond quizzes—think reporting rates, mean time to report, or simulation outcomes?
We use scripts that mirror real invites, emphasizing tenant names, domain trust cues, and the difference between external and guest access. Examples include simulated partner outreach with plausible project names and realistic follow-up chats. We measure success by tracking user-reported invites, the time it takes to report after receipt, and the proportion of users who escalate rather than accept. Over time, we want rising report rates and shrinking time-to-report even as overall invite volume fluctuates.
What logs should defenders centralize to catch cross-tenant attacks (AAD sign-ins, Teams audit, Defender signals), how do you correlate them, and can you outline a step-by-step detection query or playbook that has surfaced real attempts?
Centralize Azure AD sign-ins, Teams audit logs, and any Defender signals tied to identity and collaboration. Correlate external message requests with guest object creation and sign-ins from unfamiliar tenant IDs. A practical playbook: detect new external message requests from unknown tenants, check for guest creation within a short time, look for immediate file or link activity, and alert when all three occur in sequence. This chained detection has surfaced real attempts that were invisible to traditional email filters.
If leadership asks for a 30-day remediation plan, what are your first five steps, which owners and tools do you involve, and what measurable milestones—like reduced guest invites accepted or blocked domains added—prove progress?
First, implement a trusted domain allowlist and enable monitoring for all guest joins. Second, deploy user prompts and awareness targeting high-risk roles. Third, enforce Conditional Access for external and guest sessions with session controls. Fourth, onboard critical logs to your SIEM with detections for cross-tenant chains. Fifth, review and tighten TeamsMessagingPolicy settings. Progress shows up as fewer accepted invites from unknown tenants, a growing list of blocked domains, and faster SOC triage.
How should procurement and licensing strategy factor into this risk—both attackers using cheap tenants and defenders choosing E3/E5 add-ons? What metrics guide the ROI discussion, and can you share a case where licensing changes materially reduced exposure?
Procurement should recognize that attackers exploit low-cost tenants, so your defense needs features that address cross-tenant signals. We justify add-ons by mapping features to reduced incident volume, shorter investigation times, and fewer risky guest joins. In one engagement, enabling advanced identity and collaboration protections cut the number of cross-tenant alerts that required manual review and improved analyst efficiency. Those operational gains translate directly into ROI.
Ontinue highlighted this as a “fundamental architectural gap.” If you were advising Microsoft, what design changes would you propose, how would they work end-to-end, and what trade-offs—latency, UX, cost—should customers expect?
I’d propose portable user-centric protections that follow the identity into the host tenant, at least for core link and attachment scanning. That could be enforced via conditional policies negotiated at session setup, with telemetry back to the home tenant. I’d also support a cross-tenant security handshake where minimum controls are advertised and required before chat is established. The trade-offs may include minor latency and some UX prompts, but customers would gain clarity and control.
The victim’s org may remain unaware because the attack lives outside its boundary. How do you create out-of-bound visibility, what signals from partner tenants help, and can you share a step-by-step agreement template or telemetry-sharing model that has worked?
We set up bilateral agreements with key partners to share minimal telemetry: invite events, guest creations, policy denials, and suspicious file shares. The model outlines events, retention, alert channels, and points of contact, plus a process for rapid revocation. Practically, partners send summarized daily feeds with high-priority exceptions in near real time. This keeps everyone in the loop when risk shifts to the host tenant, where your native controls can’t see.
Do you have any advice for our readers?
Treat cross-tenant collaboration as its own security domain, not an extension of email or internal chat. Build a living allowlist, instrument detection for external message requests, and rehearse the guest-invite attack chain in a lab so your teams know the gaps. Invest in user prompts and awareness that clearly signal when someone crosses tenant boundaries. Most of all, measure everything—guest joins, acceptance rates from unknown tenants, and time-to-report—so you can prove progress and iterate quickly.
