Microsoft has renamed Microsoft 365 Copilot to Microsoft Copilot, and Microsoft 365 Copilot Chat to Microsoft Copilot Chat. Alongside the name change, Microsoft is moving the primary web address for the Copilot app to copilot.cloud.microsoft. For SMB administrators, this isn’t just a cosmetic update — it has direct implications for firewall rules, proxy configurations, Conditional Access policies, and tenant restriction settings. If your network or identity controls aren’t updated to reflect the new domain, users could lose access to Copilot without an obvious explanation.
This article explains what Microsoft documents about the rename and URL change, and summarizes the specific endpoints, network requirements, and access-control guidance admins need to review.
What’s changing
According to Microsoft’s current documentation:
- Microsoft 365 Copilot is now named Microsoft Copilot.
- Microsoft 365 Copilot Chat is now named Microsoft Copilot Chat.
- The primary URL for accessing the updated Copilot app is changing to
copilot.cloud.microsoft.
This applies across the experiences Microsoft documents under the Copilot umbrella, including the Copilot Chat (Basic) experience, Microsoft 365 Copilot (Basic), and Microsoft 365 Copilot (Premium) licensing tiers. Microsoft’s documentation also notes that it will begin a broad rollout of the updated Microsoft Copilot application to commercial customers, and advises admins to verify beforehand that their network allows access to the required Copilot endpoints.
A note on timing
The supplied Microsoft documentation confirms that the rename and URL change are happening, but it does not state a specific announcement date or a specific effective date for when copilot.cloud.microsoft became (or will become) the primary access point in every tenant. Admins should treat this as an active, in-progress change rather than a single fixed cutover date, and should verify their own tenant’s current behavior rather than assuming a universal rollout date.
Network and endpoint requirements
Microsoft documents several network-related requirements that directly affect whether users can reach Copilot after the URL change.
Allow the entire cloud.microsoft domain
Microsoft’s guidance is explicit: organizations should add *.cloud.microsoft to allow lists on both devices and network infrastructure, rather than attempting to allow only specific URLs within that domain. Microsoft states it does not support allowing only selected Microsoft 365 application URLs within *.cloud.microsoft, and recommends allowing the entire domain to maintain service reliability.
This means admins should check:
- URL filtering and proxy policies
- Firewall rules
- Tenant restriction configurations
- Conditional Access policies
- App control (application allow-listing) policies
Any of these, if misconfigured, could block copilot.cloud.microsoft or the Copilot app itself.
Allow the Microsoft Copilot endpoints
Separately from the *.cloud.microsoft domain, Microsoft documents a specific set of Microsoft Copilot endpoints (applicable to Microsoft Copilot version 152 or later) that need to be reachable through firewalls and similar security controls. These include:
- The update service endpoint (
https://msedge.api.cdp.microsoft.com) - The experimentation and configuration service (
https://config.edge.skype.com) - Multiple HTTP and HTTPS download locations for installing and updating the app (which Microsoft notes can be simplified using a wildcard such as
*.dl.delivery.mp.microsoft.com) - Sign-in endpoints for both personal Microsoft accounts and Microsoft Entra ID accounts, including
login.live.com,login.microsoftonline.com,login.microsoft.com,login.windows.net,graph.microsoft.com, and several related domains
Microsoft notes that this endpoint list isn’t exhaustive and may be updated over time, so admins should check current official documentation rather than treating any single list as permanent.
WebSocket (WSS) connectivity
Microsoft also documents a requirement for full WebSocket Secure (WSS) connectivity from user devices to *.office.com, *.cloud.microsoft, and copilot.cloud.microsoft. According to Microsoft, Copilot integrations can fail if a network perimeter blocks WSS traffic, if TLS inspection interferes with the connection, or if a proxy enforces aggressive connection timeouts. Admins who use network security appliances, secure web gateways, or SSE/SASE services should coordinate with the teams managing that infrastructure to confirm WSS traffic to these domains is permitted.
Test connectivity before assuming a problem
Microsoft provides connectivity testing tools that admins can use to check whether a tenant’s network correctly reaches the required domains:
- A dedicated connectivity test for the Copilot app
- A broader Microsoft 365 connectivity test tool covering other Microsoft products and services
Running these tests before escalating a “Copilot won’t load” issue can help confirm whether the root cause is network-related.
Tenant restrictions, Conditional Access, and blocking personal accounts
One area where Microsoft gives specific, documented guidance is how to prevent personal Microsoft account access to Copilot without breaking the service for work or school accounts.
Microsoft’s documentation is explicit that organizations should not block copilot.cloud.microsoft outright as a way to prevent personal account sign-in. Instead, Microsoft recommends using Tenant Restrictions v2, specifically the capability to block consumer or Microsoft account tenants, as the targeted control for this scenario.
This distinction matters for SMB admins who may be tempted to use a simple firewall or URL-filtering rule to stop personal account use. Based on Microsoft’s documentation, that approach risks blocking the entire Copilot experience for licensed, legitimate work or school users as well, because *.cloud.microsoft is meant to be allowed as a whole domain rather than selectively filtered.
Admins should also verify that existing Conditional Access policies don’t unintentionally block copilot.cloud.microsoft or the broader Copilot app, since Conditional Access is listed among the policy types Microsoft specifically calls out for review alongside proxies, firewalls, tenant restrictions, and app control policies.
Practical recommendations for SMB admins
The following guidance goes beyond what Microsoft documents as a required configuration step, and reflects practical operational recommendations rather than documented Microsoft defaults or requirements:
- Audit allow lists before user complaints arrive. Given that Microsoft is actively renaming the app and shifting the primary URL, it’s worth proactively checking proxy, firewall, and tenant restriction configurations now rather than waiting for a support ticket about Copilot being unreachable.
- Use the connectivity test tools as a first troubleshooting step. Since Microsoft provides dedicated connectivity testing for the Copilot app and for
*.cloud.microsoft, running these tests early can save time compared to manually reviewing every network device. - Review Tenant Restrictions v2 settings specifically, rather than relying solely on URL blocking, if your goal is to prevent personal Microsoft account sign-in while keeping work and school access functional.
- Revisit endpoint allow lists periodically. Because Microsoft notes its endpoint lists aren’t exhaustive and can change, treat allow-listing as an ongoing maintenance task tied to Copilot version updates rather than a one-time setup step.
Conclusion
The rename from Microsoft 365 Copilot to Microsoft Copilot, paired with the shift to copilot.cloud.microsoft as the primary access URL, is a documented change with real network and identity-management implications for SMB tenants. Microsoft’s guidance is clear on the mechanics — allow the full *.cloud.microsoft domain, add the specific Microsoft Copilot endpoints, confirm WebSocket connectivity, and use tenant restrictions rather than blanket URL blocking to manage personal account access — even though it doesn’t specify an exact announcement or cutover date for the change.
For SMB administrators, the practical takeaway is to treat this as an opportunity to review firewall, proxy, Conditional Access, and tenant restriction configurations now, using Microsoft’s official connectivity testing tools to confirm readiness, rather than waiting until users report that Copilot has stopped working. As with any in-progress Microsoft rollout, it’s worth periodically re-checking the official Microsoft Learn documentation for updates, since this article reflects the guidance available at the time of writing and remains subject to human review before any operational decisions are finalized.