An unexpected Teams call from “IT support” arrives in the same place as your colleagues, meetings and everyday work. That familiarity is part of the opportunity for impersonation.
Staff awareness matters, but it works best alongside deliberate choices about who can contact your people, which authentication flows are available and what the applications inside Teams may access.
What the latest research tells us
In its first-half 2026 reporting, Ontinue found that around 30% of organisations it monitored experienced at least one attempt at IT-support impersonation over Teams. Around one in 990 external contacts showed an impersonation indicator. These figures describe its monitored customers, not every organisation using Teams; a contact means an employee paired with an external person, rather than an individual message.
The reported pattern includes an unsolicited chat or call, a support pretext and a request to use Quick Assist, another remote-access tool or a PowerShell command. Separately, Ontinue confirmed ten device-code phishing compromises across five customer tenants in May and June. Those incidents should not all be assumed to have started in Teams.
Make external access a business decision
Organisations need to collaborate with partners, suppliers and clients. The question is which external communication they need, and how they manage it.
Microsoft documents separate controls for external organisations and unmanaged, personal Teams accounts. External domains are allowed by default; organisations can choose an allowlist or blocklist. Unmanaged accounts have additional settings, including whether they can initiate contact.
Start by identifying real partner relationships and the people who need them. A maintained allowlist may suit some teams; others need broader collaboration with stronger monitoring and verification. Give exceptions an owner and a review date.
Review guest access, shared channels and meeting participation separately. External chat settings are not a single switch controlling every route into collaboration.
A genuine sign-in page can still serve the wrong request
Device-code phishing does not require a counterfeit Microsoft login page. An attacker obtains a legitimate code and persuades the victim to enter it at the real sign-in service. The resulting tokens can then give the attacker access. Microsoft’s research on Storm-2372 explains this pattern.
The practical question is whether your organisation needs the device-code flow, and where. Inventory legitimate workflows before making changes. Microsoft recommends restricting it through an explicit Conditional Access policy, moving towards blocking it except for documented, secured uses. Validate the policy in report-only mode and consider emergency-access arrangements before enforcement.
For staff, the verification rule should be memorable: do not complete an unexpected code-based sign-in because someone claiming to be support asks you to. Contact the help desk through an established route that you already know.
Review the apps inside Teams as well
Impersonation and third-party app access are different risks, but both belong in a Teams security review. An approved app or bot may request access to information that extends beyond the immediate chat where someone uses it.
Microsoft distinguishes application permissions, delegated access and resource-specific consent. Review the actual scope and business purpose of grants. An app manifest alone is not a complete inventory of all Microsoft Entra permissions.
Assign an owner to each approved application. Check who can consent, which Graph permissions have been granted and what resource-specific access exists. Revisit the decision when the app requests more access. Microsoft’s consent-management guidance provides the administrative routes for those checks.
Test the guidance on a phone
Many people respond to Teams away from their desks. Test your verification instructions on the clients they actually use, including mobile. Ask staff to identify an external participant and find the genuine help-desk contact without relying on a display name.
Teams provides trust indicators for people outside the organisation. Check how these appear in your environment; do not assume that noticing a badge proves a request is legitimate.
Your quarterly Teams review
- Review partner domains, unmanaged inbound contact and meeting access.
- Check device-code use, policy coverage and documented exceptions.
- Review installed apps, Graph grants, resource-specific permissions and consent rules.
- Rehearse support verification on desktop and mobile.
- Confirm who investigates suspicious remote access and sign-ins, and how access is contained.
Bring Teams applications into view
OpenGates, embedded in MobSTR, supports the application-assessment part of this review through manifest, configuration, permission and data-handling analysis. Use it alongside your external-access controls, identity policies and support-verification procedures.