Microsoft is forcing the Copilot URL change in early October 2026: here's what IT admins need to check now

Microsoft has been moving the Copilot web app from m365.cloud.microsoft to copilot.cloud.microsoft since early September 2026. For many organisations, that redirect will have already happened quietly with no disruption. For others, specifically those whose network controls block the new address, the early October 2026 cutover is a hard deadline with real consequences: users lose access to the Copilot web app entirely until the block is lifted. There is also a separate, easy-to-miss problem with Windows Recall filters that deserves its own attention.

This post covers both issues and what you need to do before early October arrives.

What is actually changing

The Microsoft 365 Copilot app has been renamed to the Microsoft Copilot app. It has a new icon, a simplified interface that works across both personal and work accounts, and a new web address: copilot.cloud.microsoft.

The old address, m365.cloud.microsoft, now redirects to the new one. Microsoft began moving users in early September 2026, starting with tenants where copilot.cloud.microsoft was already reachable. The second wave, covering tenants that had the new domain blocked, is completing in early October 2026.

The change is documented in two Message Centre posts: MC1454108, which covers the rename and URL update, and MC1462915, which is specifically addressed to admins whose tenants are blocking copilot.cloud.microsoft.

The lockout risk is real

Microsoft is direct about what happens if your proxy, firewall, Conditional Access policy, or web filter blocks copilot.cloud.microsoft after the redirect completes: users “may be unable to use the Copilot web app.” The redirect happens at Microsoft’s end. If the destination is blocked, the user hits a dead end.

The fix sounds simple, but there is a specific requirement worth noting. Microsoft does not support partial allow-listing within *.cloud.microsoft. You cannot selectively permit only copilot.cloud.microsoft and leave everything else under that wildcard blocked. The entire *.cloud.microsoft wildcard domain must be permitted. If your organisation already follows Microsoft’s recommended network configuration for Microsoft 365 and has *.cloud.microsoft open, you are likely fine and no changes are needed.

If you are not sure, the Microsoft 365 Connectivity Test tool is a good starting point for checking your position.

Where admins often get caught out

Beyond the obvious firewall rule, several other places can silently block or mis-categorise the new address:

• CASB and SSE products often classify Copilot as a named application rather than a URL pattern. If your Cloud Access Security Broker has a rule for “Microsoft Copilot” or “Microsoft 365 Copilot” as an app entity, that definition may not have been updated to reflect the new domain. Check your product’s app library.
• DNS filtering tools that block m365.cloud.microsoft explicitly, or that have Copilot listed as a blocked category, need reviewing.
• DLP rules, SIEM detections, and dashboards referencing the old URL will produce gaps or false negatives once the redirect completes. Update them to include copilot.cloud.microsoft alongside m365.cloud.microsoft during any transition period.
• App-control allow-lists on managed devices may reference the old app name. Check those too.

If you had been blocking the new Copilot address specifically to prevent employees from signing in with personal Microsoft accounts, Microsoft’s recommended alternative is Tenant Restrictions, which lets you control which tenants and identities can authenticate through your network without blocking the domain outright. Organisations that cannot complete network changes before early October 2026 should contact their Microsoft account representative.

The Windows Recall problem is separate and needs manual action

This one is easy to overlook because it arrives quietly. If your organisation uses Windows Recall and you configured a group policy to filter the Microsoft Copilot app from being saved in Recall snapshots, that filter will stop working after the app rename.

The policy in question, “Set a list of apps to be filtered from snapshots for Recall,” identifies apps by their Application User Model ID (AUMID) or executable name. Because the app has been renamed, the old identifier no longer matches the new app. The filter simply stops applying.

Microsoft is explicit that this does not carry over automatically: “If you applied a group policy that filters the former Microsoft Copilot app from being saved in snapshots for Recall, this policy will not automatically carry over to the new Microsoft Copilot app.”

The fix is to re-apply the filter using the new app’s identifier. Microsoft’s guidance on managing Recall for Windows clients covers the updated steps. If Recall privacy compliance is important in your environment, this needs to be done before the rename lands in your tenant, not after.

A quick action checklist

If you manage Microsoft 365 for your organisation, here is what to work through before early October 2026:

1. Confirm *.cloud.microsoft is reachable from managed devices. Run the Microsoft 365 Connectivity Test if you are unsure. Remember that the whole wildcard must be allowed, not just the individual host.
2. Search your proxy, firewall, web filter, and DNS filtering for references to m365.cloud.microsoft, copilot.cloud.microsoft, copilot.microsoft.com, and any bare “copilot” string. Update or remove blocks as appropriate.
3. Check CASB and SSE app definitions for Copilot. If your product uses named-app rules rather than URL rules, verify those definitions have been updated by your vendor.
4. Re-create the Windows Recall filter if your organisation uses Recall and had the old Copilot app filtered from snapshots. Use the new app’s AUMID or executable name.
5. Update any DLP rules, SIEM queries, or dashboards that reference the old URL so monitoring does not develop blind spots.
6. If you were blocking the domain to control personal account access, switch to Tenant Restrictions instead and then unblock the domain.

The underlying migration stays within the *.cloud.microsoft domain, so the security, compliance, and enterprise properties of the app do not change. For organisations that have followed Microsoft’s network guidance all along, this will pass without incident. The risk sits squarely with those who have tightened controls beyond the recommended baseline, particularly around the new domain or the Recall policy, and have not yet reviewed them.