Microsoft Copilot URL Is Changing: Organizations Must Allow copilot.cloud.microsoft Before October

Microsoft is preparing to change the web address used to access its Copilot experience for organizations, and IT teams have a relatively small but important window to make sure their networks are ready.

Beginning in September 2026, Microsoft will start redirecting users from m365.cloud.microsoft to copilot.cloud.microsoft. Organizations that already allow connections to the new Copilot address will be moved first, while users whose environments block the destination are expected to be redirected during October 2026.

For businesses that rely on Microsoft Copilot every day, the change may look simple from a user’s perspective. However, behind the scenes, a firewall, proxy, secure web gateway, URL filter, Conditional Access policy or other security control could prevent the new address from working.

That means the URL change is not simply a matter of Microsoft updating a webpage. It is also a network-readiness issue for organizations with tightly controlled internet access.

Microsoft’s current Copilot network guidance specifically says organizations should ensure that copilot.cloud.microsoft is not blocked and recommends allowing the broader *.cloud.microsoft domain. Microsoft also notes that Copilot relies on WebSockets in some experiences, meaning network devices must support the required WSS connectivity.

What is changing?

The main change is the destination users will reach when accessing the Copilot web experience.

Microsoft plans to transition users from:

m365.cloud.microsoft

to:

copilot.cloud.microsoft

The redirect is expected to remain within Microsoft’s *.cloud.microsoft domain. For organizations following Microsoft’s recommended Microsoft 365 network configuration, Microsoft says additional network changes should generally not be necessary.

The important issue is whether an organization has introduced its own restrictions that could interfere with the new destination.

Many enterprises use security policies that restrict websites and cloud services based on domains, URL categories, proxy rules or application controls. Those policies may have been created long before Copilot became a major part of the Microsoft 365 environment.

A company could therefore have a perfectly functional Microsoft 365 environment while still blocking the new Copilot endpoint.

That is precisely the scenario Microsoft wants administrators to identify before the redirect reaches affected users.

Why IT administrators should pay attention

For an individual user, a redirect normally feels like a routine website change. Click a link, the browser follows the redirect, and the service opens.

Corporate networks are often more complicated.

Internet traffic can pass through multiple layers of security before reaching a cloud service. Depending on the organization, those layers could include firewalls, forward proxies, secure web gateways, DNS filtering, URL filtering platforms, SSE or SASE services, tenant restrictions and application-control systems.

If one of those systems blocks copilot.cloud.microsoft, the redirect could leave users staring at an error page instead of Copilot.

Microsoft’s current network documentation specifically calls out legacy filtering rules, URL category restrictions, proxy policies, firewall rules, tenant restrictions, Conditional Access policies and application-control policies as areas administrators should review.

There is another technical consideration: WebSockets.

Microsoft says several Copilot integrations use the WebSocket Secure (WSS) protocol. Networks that block WSS, aggressively inspect encrypted traffic or impose restrictive proxy timeouts can cause Copilot failures even when ordinary HTTPS access appears to work.

In other words, simply being able to resolve the domain or open a basic web connection may not be enough to guarantee that the complete Copilot experience will work properly.

Microsoft has a two-stage rollout

The transition is planned in two broad stages.

In early September 2026, Microsoft will begin redirecting users in organizations where access to copilot.cloud.microsoft is already available.

That makes September particularly important for IT teams. Organizations that have already permitted the destination may experience the change without needing to do anything.

The second stage is expected in early October 2026.

Microsoft says the remaining users who were not redirected during the initial September phase will then be redirected. Organizations that still have restrictions preventing access to the new Copilot address therefore have a limited window to identify and resolve those issues.

For organizations that cannot complete the required configuration in time, Microsoft recommends contacting their Microsoft account representative to discuss available options.

What organizations should do now

The first step is straightforward: test connectivity before the redirect happens.

Microsoft provides a Microsoft 365 Connectivity Test tool that can test Copilot connectivity, including network connectivity and WebSocket-related requirements. Microsoft says the tool can help administrators identify connectivity problems and determine whether the relevant Microsoft 365 Copilot endpoints are reachable.

IT teams should then review their network and security configuration.

At a minimum, administrators should check whether copilot.cloud.microsoft is blocked anywhere in the traffic path.

That review should include:

Firewall policies
Proxy configurations
Secure web gateways
URL and category filtering
DNS or web filtering
SSE/SASE policies
Tenant restrictions
Conditional Access policies
Application-control policies
TLS inspection rules
WebSocket/WSS handling
Third-party filtering products

Microsoft recommends allowing *.cloud.microsoft rather than trying to create a narrowly targeted list containing only selected Microsoft 365 application URLs. The company says it does not support allowing only partial or selected Microsoft 365 application URLs within the *.cloud.microsoft domain, because doing so can create reliability and connectivity problems as services evolve.

This is an important point for security teams that prefer highly granular allow lists.

The instinct to permit only one or two known URLs can make sense from a traditional security perspective, but cloud services are dynamic. Microsoft says its large-scale cloud architecture makes maintaining individual feature-level FQDN lists impractical and recommends following the documented wildcard requirements where specified.

What about organizations blocking personal Microsoft accounts?

Some organizations may have blocked Copilot-related addresses because they want to prevent employees from signing into personal Microsoft accounts on corporate networks.

That is a different security objective from blocking access to the Copilot service itself.

Microsoft recommends considering Tenant Restrictions as a more targeted approach in this situation. The idea is to allow access to the Copilot service while controlling authentication to personal or unauthorized Microsoft account tenants. This can provide administrators with more precise control than simply blocking the Copilot domain at the network layer.

This distinction could become increasingly important as organizations expand their use of AI services while maintaining strict identity and data-governance policies.

Don’t forget WebSockets

One of the easiest things to overlook during a network review is WebSocket connectivity.

Microsoft’s current Copilot documentation says enterprise Copilot experiences can require WSS connectivity to domains including *.office.com, *.cloud.microsoft and copilot.cloud.microsoft.

A network may therefore appear to permit normal browser traffic while still disrupting Copilot functionality.

Security devices performing TLS inspection can also affect application behavior. Microsoft notes that network configurations involving TLS inspection and aggressive proxy connection timeouts can interfere with WSS connections.

For that reason, administrators should test the actual Copilot experience rather than relying exclusively on a simple domain lookup or basic HTTPS test.

Who needs to be involved?

This change should not sit exclusively with the Microsoft 365 administrator.

In many organizations, the people who manage Microsoft 365 and the people who control outbound internet traffic are different teams.

A successful readiness check may therefore require coordination between:

Microsoft 365 administrators
Network engineers
Firewall administrators
Security operations teams
Proxy administrators
Secure web gateway teams
Identity and Conditional Access administrators
SSE/SASE administrators
Third-party filtering vendors

Bringing these teams together early can prevent a familiar problem: everyone assumes another team has already approved the new endpoint.

Microsoft’s current documentation lists network endpoints as a required part of deploying Copilot and emphasizes that organizations should configure their networks to support the service.

A small URL change with a potentially big user impact

The actual change may be invisible to most employees. Users will simply be redirected to the new Copilot address.

But for an organization with strict network controls, the difference between a successful redirect and a broken experience could come down to one firewall rule or one outdated URL-filtering policy.

That is why administrators should treat the September and October 2026 rollout as a network-readiness exercise rather than waiting for users to report that Copilot has stopped working.

Microsoft’s broader guidance already recommends allowing the necessary Microsoft 365 and Copilot network endpoints, and its current requirements specifically include *.cloud.microsoft and copilot.cloud.microsoft.

The practical message for IT teams is simple: test first, update allow lists, verify WSS connectivity, and coordinate with security teams before the redirect reaches your users.

Organizations that already follow Microsoft’s recommended network configuration may have little or nothing to change. But organizations with legacy filtering, restrictive proxy policies or highly customized security controls should verify their configuration now.

With the first phase of the redirect beginning in September and the remaining users expected to transition in October, waiting until Copilot stops working is the worst time to discover that copilot.cloud.microsoft was blocked.

For Microsoft 365 administrators, this is one of those changes that is easy to overlook precisely because the end-user experience is designed to be seamless.

The safest approach is to make sure the network is ready before Microsoft makes the redirect.