Allowlist copilot.cloud.microsoft Before the August 18 Redirect — the Old Intune Mobile Key Will Not Save You

Most IT managers still treat Copilot on the corporate network as a solved allowlist problem. They put m365.cloud.microsoft on the proxy years ago, locked Copilot Chat on phones with an Intune app-config key, and moved on. That version is about to fail even if nothing else in the tenant changed.
Here's what we're walking tenants through this week, 48 hours before the URL moves, and the three places the old controls actually break.
The URL that moves whether the proxy knows the new name
Partner Center and Message Center item MC1454108 are explicit: starting August 18, 2026, the Microsoft Copilot web, desktop, and mobile apps pick up a simpler name and icon, clearer work-vs-personal indicators (including the Entra green shield and a Work label), and a new web host. The URL moves from m365.cloud.microsoft to copilot.cloud.microsoft. Users are redirected automatically unless the new host is blocked.
Desktop is a preview on August 18, with broader Windows and Mac rollout in mid-September. The web redirect itself starts on the standard ring later this month and hits deferred tenants in late September. The date that matters for a blank page is the first time a user is sent to a host your proxy has never seen.
Microsoft's line is that security, compliance, and governance controls remain unchanged. That is true of Conditional Access, app IDs, and Tenant Restrictions. It is not true of a PAC file or SSL-inspection rule that still names the old host.
What breaks it:
- Allowlist
copilot.cloud.microsoftand*.cloud.microsoft— Partner Center's own next step. If you already followed the recommended Microsoft 365 Copilot network config, you may already have the wildcard. Confirm it; don't assume it. - Test the redirect from a normal workstation — not from a jump box that bypasses the proxy. A blank page or a certificate warning is the failure mode, not an Entra error.
- Leave Tenant Restrictions alone if they already do the job — they still limit personal Microsoft accounts in the Copilot app. That control did not move.
The proxy still aimed at m365.cloud.microsoft
The pattern we see in assessments is not a missing Copilot license. It is a user who clicks Copilot on Monday and gets nothing, because SSL inspection, a forward proxy, or a tenant-restriction hostname list was built against m365.cloud.microsoft and never revisited.
MC1454108 tells admins that customers who followed the recommended Copilot network configuration inherit the new host under *.cloud.microsoft and do not need additional network changes. That sentence is doing a lot of work. It describes the tenants that already allowlisted the domain, not the ones that allowlisted one hostname from a 2024 runbook.
What breaks it:
- Inventory proxy, SSL inspection, and any hostname allowlists for Copilot before August 18 — search for
m365.cloud.microsoftand see whethercopilot.cloud.microsoftis next to it. - Tenant Restrictions — still the supported way to keep personal Copilot off work devices. Use it if that is the actual requirement.
- Skip Domain Exclusion. Microsoft rolled that control back on August 4. Spending this week on a control that already died is how the redirect gets missed.
The Intune key that used to block Copilot Chat on mobile
A second change lands in the same window. MC1454386 (mid-August through late September, including GCC): two legacy mobile-only controls stop restricting Copilot Chat inside the Microsoft 365 Copilot mobile app.
The Intune app-configuration key is com.microsoft.office.officemobile.BingChatEnterprise.IsAllowed. The other is the Analyze content privacy control. Both stop being a mobile Copilot Chat gate. The change is on by default. Users who were blocked on the phone and allowed on the desktop get the desktop experience on the phone.
That is the helpdesk ticket. Someone in finance opens the Copilot mobile app on August 20, Copilot Chat is there, and the ticket says "Intune isn't blocking Copilot anymore." The key is still in the policy. It just no longer does what the policy comment says it does.
What breaks it:
- Review whether you currently rely on that Intune key or Analyze content to restrict Copilot Chat on iOS/Android. Microsoft's own note: update the internal doc that names those controls as the block.
- Integrated Apps — if you still need Copilot Chat off, block Copilot across web, desktop, and mobile from Integrated Apps, or block the Microsoft 365 Copilot mobile app if the requirement is mobile-only.
- Brief the helpdesk before the first ticket, not after. The rollout is default-on.
What "good" looks like: the five-item baseline
If you do nothing else this week, these five moves catch the redirect and the dying mobile block in order of impact:
- Allowlist
copilot.cloud.microsoftand*.cloud.microsofton proxy, firewall, and SSL inspection — then confirm the wildcard is actually hitting. - Force the redirect from a standard user workstation and watch for a blank page or a cert error. That is the test, not a green Message Center checkbox.
- Confirm Tenant Restrictions if personal Copilot should not land on work devices. App ID is not changing; existing policies keep working.
- Inventory the Intune Office Mobile key and Analyze content. If those were your mobile Copilot Chat block, replace them with Integrated Apps or an app block before late September.
- Update the runbooks that still say
m365.cloud.microsoftor cite that Intune key as the control. Stale docs are how this repeats in October.
None of this requires a new Copilot SKU. It is network readiness plus an honest read of which mobile control you thought you still had.
The uncomfortable question
The question worth asking this week is not "did Microsoft change Copilot security?" Message Center already answered that, and the answer is the one that lets people skip the proxy check. The question is: if a user opens Copilot tomorrow, does our allowlist still know the name, and does our mobile block still exist?
Your proxy logs for m365.cloud.microsoft versus copilot.cloud.microsoft, and the Intune app-configuration profile that still lists BingChatEnterprise.IsAllowed, will tell you before the helpdesk does.
The same week, tenants still on SMS or voice have a Sept 1 passkey campaign decision — the Graph opt-out lives in the FAQ, not the email. The identity-side baseline these controls sit on is in how Microsoft 365 tenants actually get breached in 2026.
Our Copilot Readiness engagement audits permission sprawl and data governance before Copilot ever sees your content.
See the readiness engagement →Get the next Insights post by email.
Keep reading
Autopilot ESP stuck at Apps (Identifying): find the Win32 that fails with 0x81036502
When Autopilot ESP sticks on Apps (Identifying), the blocker is usually one tracked Win32—wrong detection, a failed install returning 0x81036502, or apps racing ahead of their dependencies. Here is how to find that app and stop the permanent ESP ticket queue.
Read the article →Intune app packaging: PSADT v4 to .intunewin without another Claude skill
Intune PSADT intunewin packaging is a folder wrap with IntuneWinAppUtil, then install/uninstall commands, independent detection, and a SYSTEM vs interactive choice—not another AI packaging skill.
Read the article →Autopilot device association: export the DeviceLink CSV, stamp UEFI, then enroll
Autopilot device association binds a physical Windows 11 device to your tenant before enrollment via a TPM-backed DeviceLink CSV and UEFI tenant affinity—not a classic hardware-hash upload. Here is the admin loop and what still breaks it.
Read the article →

