Microsoft Teams and Copilot URL Changes: IT Admin Checklist
Microsoft is moving Teams and Copilot's web apps to new addresses this month, and organizations with locked-down firewalls could lose legitimate access if network teams don't update their allowlists first, Computerworld reported this week. The Microsoft Teams and Copilot URL changes are landing in stages through early October, and Microsoft has published two Message Center notices spelling out what admins need to check before then.
This isn't a consumer feature update. Personal Teams accounts at teams.live.com sit entirely outside this change, according to Microsoft's Message Center notice on the redirect (MC1465764). If you're an employee without admin rights and something breaks in October, the fix isn't yours to make: report the new domain to your IT desk rather than troubleshooting it yourself.
Here's what's actually moving. Teams web traffic is shifting from teams.microsoft.com to teams.cloud.microsoft, while the Copilot web app is moving from m365.cloud.microsoft to copilot.cloud.microsoft, per Microsoft's Message Center archive (MC1462915) and the MWPro breakdown of MC1465764. Teams reaches its remaining tenants by September 30, 2026; Copilot's remaining redirects land in early October, per the same notices. Two separate deadlines, one underlying cause: both services are consolidating under the *.cloud.microsoft domain, and any network control that blocks that domain now blocks a legitimate Microsoft service.
What's changing, and who can ignore it
The cloud.microsoft domain isn't some new island Microsoft is asking admins to trust overnight. It's been part of standard Microsoft 365 network guidance since April 2023, according to MWPro's summary of the notice, so this rollout extends an endpoint strategy that's already documented rather than introducing something unfamiliar. Microsoft has said it plans to consolidate Microsoft 365 and Copilot web experiences under *.cloud.microsoft, according to Microsoft's network requirements documentation.
For Teams, this is a domain change, not a feature change. Existing teams.microsoft.com links and bookmarks keep working through automatic redirects, and Teams functionality itself doesn't change, per Microsoft's notice.
That leaves one audience that actually has to act: network and security admins responsible for firewalls, proxies, and secure web gateways. Everyone else can treat this as background noise until IT says otherwise.
Copilot.cloud.microsoft firewall configuration: what Microsoft requires
Microsoft's guidance for Copilot is specific, and it comes with a rule most companies will need to redraw around. The company is telling customers to review the controls on client devices, proxies, firewalls, and secure web gateways for anything that could interfere with *.cloud.microsoft traffic, according to Microsoft's Message Center archive.
The part that trips people up: Microsoft's documentation states plainly that allowing only select application URLs within *.cloud.microsoft is unsupported and can break the redirect. Admins need to allow the full wildcard domain, not a curated list of endpoints, per the same notice. That granular rule is documented for Copilot specifically; the available sources don't confirm it applies identically to Teams' redirect.
Copilot also depends on WebSocket (WSS) connectivity to *.cloud.microsoft and *.office.com for its enterprise experiences, according to Microsoft's network requirements page. Microsoft's own documentation warns that perimeter blocks on the WSS protocol, TLS-inspecting devices sitting in the traffic path, and proxies with aggressive connection timeouts can all cause Copilot failures even after the domain is allowed. That's worth testing separately from a basic allowlist check: a domain that loads fine in a browser tab can still fail once Copilot tries to hold open a persistent WebSocket connection through the same proxy.
Microsoft points admins toward its Connectivity Test tool to validate access to *.cloud.microsoft and copilot.cloud.microsoft ahead of the redirect reaching their organization, per the Message Center notice. Given the WSS warning in Microsoft's own documentation, it's worth going further than a passing connectivity result and confirming sign-in actually completes, that Copilot responds inside Word, Excel, and PowerPoint Online, and that nothing times out mid-session, rather than assuming a green checkmark on the domain test covers those scenarios too.
Organizations already following Microsoft's recommended Copilot network configuration shouldn't need to change anything further, according to the Message Center notice, but that exemption only covers orgs already compliant with that configuration, not everyone running Copilot today.
One deadline has already passed. Microsoft's notice told organizations still blocking copilot.cloud.microsoft to contact their account representative before September 10, 2026 to discuss options (Message Center archive). That date is now behind us, and the cited notice doesn't say what happens for organizations that missed it. If that's your organization, contacting your Microsoft account representative directly is still the only documented path forward, rather than assuming a standing exception will appear on its own.
Teams' compatibility risk, and the redirect opt-out
Teams carries a different kind of risk than Copilot's domain rule. Microsoft's notice warns that some embedded Teams web apps, particularly ones built on older Teams JavaScript SDKs or configured with restrictive Content Security Policy or X-Frame-Options settings, may fail to render once the domain switches over, according to MWPro's breakdown of the notice.
Microsoft's documented workaround for that specific problem is the Teams desktop client, which the notice says organizations can use when an app has a web-specific domain compatibility issue. That's a fix for a broken embedded app, not for a network connection actively blocking *.cloud.microsoft; a desktop client won't rescue anyone whose firewall rule hasn't been updated, since desktop Teams still depends on the same cloud endpoints.
Admins get a temporary lever too. A tenant admin can disable the automatic redirect through December 31, 2026, which buys time to fix broken embedded apps rather than functioning as a permanent opt-out, per Microsoft's notice. Starting January 1, 2027, that control is retired and the redirect can no longer be disabled at all. Whatever compatibility issue isn't resolved by then stays broken.
Before leaning on that fallback, test Teams web sign-in and a representative sample of embedded apps directly, rather than assuming one working app means the rest are fine. Microsoft also recommends updating internal documentation that still references teams.microsoft.com and briefing help-desk staff that teams.cloud.microsoft is an expected, Microsoft-owned address, so a routine domain switch doesn't turn into a flood of confused support tickets.
When security policy is the reason Copilot is blocked
Some organizations block copilot.cloud.microsoft on purpose, specifically to stop employees from signing into personal Microsoft accounts on managed devices. That's a reasonable security goal, but a blanket domain block also cuts off legitimate Copilot access once the redirect takes effect, Computerworld reported this week.
Microsoft's suggested alternative is TenantRestrictions, an identity-layer control that blocks personal-account authentication on managed networks or devices while still letting the Copilot service URL load, according to Microsoft's Message Center notice. It swaps a network-layer block for an identity-layer one.
The cited notice doesn't go further than that description. It doesn't spell out TenantRestrictions' licensing prerequisites, how it behaves across every device type, or whether it can fully stand in for existing DLP or egress policies, so those specifics remain open questions rather than settled facts. Admins with strict compliance requirements should pilot TenantRestrictions with a small group before rolling it out tenant-wide, not swap it in as a drop-in replacement for a firewall rule that's worked for years.
What to do this week
If your network already follows Microsoft's recommended Copilot configuration, you likely don't need to change anything, but running the Connectivity Test and confirming WSS behavior is still worth ten minutes to be sure.
If Copilot is currently blocked and the September 10 deadline already slipped past, contact your Microsoft account representative now rather than waiting for an automatic exception the available guidance never promises.
If an embedded Teams app breaks after the switch, use the temporary redirect-disable control while you fix the app, but treat December 31, 2026 as a hard wall, not breathing room.
And if you're a personal Teams user or an employee without admin access, there's genuinely nothing to configure. If something breaks in October, tell IT it's the teams.cloud.microsoft or copilot.cloud.microsoft redirect and let them take it from there.
Comments
Be the first, drop a comment!