Microsoft is moving Teams and Copilot web traffic 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 on September 11.
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 Teams notice, MC1465764.
If you're an employee without admin rights and something breaks after the redirects, the fix isn't yours to make. Report the new domain to your IT desk rather than troubleshooting network policy yourself.
Here's what's moving:
Teams web:
teams.microsoft.comredirects toteams.cloud.microsoft.Copilot web:
m365.cloud.microsoftredirects tocopilot.cloud.microsoft.
Microsoft plans to redirect the remaining Teams enterprise tenants by September 30, 2026. Copilot tenants that weren't redirected during the first September wave are scheduled for early October.
Two separate deadlines, one underlying change: both services are moving further under the *.cloud.microsoft domain, and network controls that block that domain can block legitimate Microsoft services.
What's Changing, and Who Can Ignore It
The cloud.microsoft domain isn't a new island Microsoft is asking admins to trust overnight.
Microsoft says the domain has been part of its standard Microsoft 365 network guidance since April 2023, and the company has been consolidating authenticated Microsoft 365 experiences under it.
For Teams, this is a domain change, not a feature change.
Existing teams.microsoft.com links and bookmarks will continue to work through automatic redirects, and Microsoft says Teams functionality itself isn't changing.
Personal Teams experiences at teams.live.com aren't affected.
That leaves one audience that actually has to act: network, security, and application admins responsible for firewalls, proxies, secure web gateways, browser policies, and embedded Teams apps.
Everyone else can treat this as background infrastructure until IT says otherwise.
Copilot.cloud.microsoft Firewall Configuration: What Microsoft Requires
Microsoft's current Copilot network guidance is specific.
Organizations should confirm that copilot.cloud.microsoft isn't blocked and add *.cloud.microsoft to their allowlists.
Microsoft explicitly says it doesn't support allowing only selected Microsoft 365 application URLs inside *.cloud.microsoft.
Admins should allow the full wildcard domain rather than building a hand-picked list of individual Copilot endpoints.
That granular warning is documented for Copilot specifically. The Teams notice separately tells organizations to make sure *.cloud.microsoft isn't blocked, but doesn't repeat the same partial-FQDN warning in the same detail.
Copilot also relies on WebSocket, or WSS, connectivity.
Microsoft's current network documentation tells admins to verify full WSS connectivity from Microsoft 365 apps to:
*.cloud.microsoft*.office.comcopilot.cloud.microsoft
Microsoft warns that several common network configurations can interfere with those connections:
Blocking the WSS protocol at the network perimeter.
TLS inspection or decryption devices in the traffic path.
Proxy servers with aggressive connection timeouts.
That matters because simply loading the Copilot domain in a browser doesn't prove the full application path will work.
Microsoft's Connectivity Test is more useful than a basic browser check. It can test Copilot HTTP connectivity, WebSocket enablement, and latency to major Copilot endpoints.
After the network test passes, it's still worth validating the actual user workflows your organization depends on, including sign-in, Copilot Chat, Microsoft 365 app integration, and longer sessions through your normal proxy path.
Organizations already following Microsoft's recommended Copilot network configuration shouldn't need additional network changes for this redirect.
That exemption applies to environments already aligned with the recommended configuration, not simply to any tenant where Copilot happens to work today.
The September 10 Copilot Deadline Has Passed
MC1462915 still contains a specific instruction for organizations that discover *.cloud.microsoft is blocked: contact the Microsoft account representative before September 10, 2026 to discuss available options.
That date has passed.
The same notice, updated on September 21, also says organizations that can't complete the required configuration before the early-October redirect should contact their Microsoft account representative to discuss available options.
So organizations that missed September 10 shouldn't assume they're out of options or that Microsoft will automatically preserve the old route.
Contact the Microsoft account representative now and resolve the network configuration before the remaining October redirect.
Teams' Compatibility Risk, and the Redirect Opt-Out
Teams carries a different compatibility risk.
Microsoft's MC1465764 notice warns that some Teams web apps may fail to render or launch correctly after the domain changes if they depend on:
Older Teams JavaScript SDKs.
Restrictive domain configuration.
X-Frame-Options.Content Security Policy settings.
Authentication configuration.
Redirect settings.
Microsoft's documented workaround for a web-specific application compatibility issue is to use the Teams desktop client while the app owner fixes the affected integration.
That workaround has limits.
The desktop client isn't a substitute for fixing network controls that block required Microsoft endpoints. If the organization's network blocks traffic needed by Teams or other Microsoft 365 services, moving from a browser to the desktop client doesn't remove the underlying network problem.
Admins also get a temporary compatibility lever.
A Teams tenant administrator can disable the automatic redirect through December 31, 2026.
While the redirect is disabled, users continue going to teams.microsoft.com.
Microsoft says this control is intended only as a temporary troubleshooting mechanism while application owners remediate compatibility problems.
Starting January 1, 2027, the control is retired and the redirect to teams.cloud.microsoft can no longer be disabled.
Before using that fallback, test Teams web sign-in and a representative sample of embedded apps directly.
Microsoft also recommends updating internal documentation that still references teams.microsoft.com and telling help-desk staff that teams.cloud.microsoft is an expected Microsoft-owned address.
That can keep a routine domain transition from turning into unnecessary security alerts and support tickets.
When Security Policy Is the Reason Copilot Is Blocked
Some organizations block Copilot URLs deliberately because they don't want employees signing in with personal Microsoft accounts on managed devices or networks.
The security goal is legitimate, but Microsoft now warns that blocking copilot.cloud.microsoft itself can also disrupt legitimate work Copilot access.
Microsoft's recommended alternative in MC1462915 is Tenant Restrictions.
Instead of blocking the Copilot service URL, Tenant Restrictions can restrict authentication with personal Microsoft accounts while allowing the service endpoint itself to remain reachable.
Microsoft's broader Tenant Restrictions v2 documentation supports several deployment approaches, including:
Universal Tenant Restrictions through Microsoft Entra Global Secure Access.
Enforcement through a corporate proxy.
Enforcement on managed Windows devices.
Those deployment models aren't identical, and their coverage differs.
Tenant Restrictions also shouldn't automatically be treated as a drop-in substitute for every existing DLP, egress-control, Conditional Access, or compliance policy.
Organizations with strict security requirements should test the intended Tenant Restrictions configuration against their actual account, device, browser, and data-protection requirements before removing an existing network block.
IT Admin Checklist Before the Redirects Finish
For Copilot:
Confirm
copilot.cloud.microsoftisn't blocked.Allow
*.cloud.microsoftrather than only selected Copilot subdomains.Confirm WSS connectivity to the domains Microsoft requires.
Check for TLS inspection and aggressive proxy timeouts.
Run the Microsoft 365 Connectivity Test.
Test actual Copilot sign-in and application workflows.
If personal-account access is the reason for the block, evaluate Tenant Restrictions instead.
If the environment still can't be made compliant before the October redirect, contact the Microsoft account representative.
For Teams:
Confirm
*.cloud.microsoftisn't blocked.Test
teams.cloud.microsoftbefore September 30.Check embedded Teams apps for older SDK or CSP/domain restrictions.
Update internal documentation and help-desk guidance.
Use the desktop client only as a temporary workaround for web-specific app compatibility problems.
If necessary, temporarily disable the redirect while affected apps are repaired.
Complete remediation before December 31, because the opt-out disappears January 1, 2027.
What to Do This Week
If your network already follows Microsoft's recommended Copilot and Microsoft 365 configuration, the redirects should require little or no network work.
Run the Connectivity Test anyway and verify the real workflows your users depend on.
If Copilot is currently blocked and the September 10 contact date already passed, contact your Microsoft account representative now rather than waiting for the October redirect.
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 deadline rather than a permanent escape hatch.
And if you're a personal Teams user or an employee without admin access, there's nothing to configure.
If something breaks, tell IT whether the failure involves teams.cloud.microsoft or copilot.cloud.microsoft and let the network or Microsoft 365 team take it from there.
Comments
Be the first, drop a comment!