That’s Not the Story. The Story Is You’ve Never Seen config.office.com.
MC1330892 landed in the Message Center on June 1, 2026. Its headline: starting with Intune’s June 2606 release, the Apps → Policies for Microsoft 365 apps page inside the Intune admin center is being removed. A redirect link will take admins to the Microsoft 365 Apps admin center at config.office.com instead.
Microsoft’s verdict: “No action required. Update your documentation.” And technically they’re right, your existing policies won’t change, won’t break, and won’t need to be recreated.
But reading that message at face value and moving on would be a mistake. Because the real story isn’t the UI removal. It’s that the Cloud Policy service for Microsoft 365, the backend powering these policies is fundamentally different from every other policy mechanism in your Intune toolkit, and a surprising number of admins who’ve configured these policies through Intune have never fully understood what they were deploying.
This post covers the change itself, then goes deep on what the Cloud Policy service actually is, how it applies policies in a way no Intune config profile can, what’s waiting for you at config.office.com that you’re probably not using, and what this means specifically if you manage multiple tenants as an MSP.
What’s confirmed from MC1330892
Source: Message Center MC1330892, published June 1, 2026. Tag: Admin Impact.
Effective: Intune June 2606 service release.
Change: Apps → Policies for Microsoft 365 apps in Intune admin center replaced with a redirect link.
Impact on existing policies: Zero. No policy recreation, no reconfiguration, no permission changes. New home: config.office.com → Customization → Policy management (identical UI).
What Exactly Is Changing (and What Isn’t)
Let’s be precise. Intune has two very different ways of managing settings for Microsoft 365 Apps. This change only touches one of them.
| Policy type | Intune path | Affected by MC1330892? |
| M365 Apps Cloud Policies (Cloud Policy service) | Apps → Policies for Microsoft 365 apps | Yes – moving to config.office.com |
| Intune Config Profiles (Settings Catalog) | Devices → Configuration → + Create → Settings Catalog | Not affected – stays in Intune |
| Security Baselines (Microsoft 365 Apps for Enterprise) | Endpoint Security → Security Baselines | Not affected – stays in Intune |
| App Protection Policies (MAM) | Apps → Protection → App protection policies | Not affected – stays in Intune |
That distinction matters because Settings Catalog profiles that configure M365 Apps settings also exist in Intune and are entirely unaffected. If you’ve been using Settings Catalog to enforce Word or Excel behaviors on enrolled devices, nothing about that workflow changes.
The one operational change that will catch people off guard
Any admin who navigates to Apps → Policies for Microsoft 365 apps after the 2606 release will find a redirect page, not the policy list. If you have runbooks, SOPs, knowledge base articles, or onboarding documentation referencing the Intune path, those need to be updated to point to config.office.com before your next junior admin spends 20 minutes wondering where the page went.
The Real Story: What Is the Cloud Policy Service, Really?
Most admins who’ve configured M365 Apps policies through the Intune portal have treated them like a more granular config profile. You pick settings, you assign a group, you move on. But the Cloud Policy service works on a completely different model from every other policy mechanism in Intune and the difference is fundamental.
It’s Not a Device Policy. It’s a User Policy.
An Intune configuration profile is applied to a device. The device checks in with Intune, receives its assigned profiles, and the settings are enforced on that machine. If the user signs out and a different user signs in, the device still has those profiles. If the device is never enrolled in Intune, the profiles never apply.
A Cloud Policy service policy works entirely differently. It’s applied to a user. When a user signs into any Microsoft 365 App – Word, Excel, Outlook, Teams, the Click-to-Run client checks in with the Cloud Policy service, retrieves the policies assigned to that user, and enforces them. The device’s enrollment status is completely irrelevant.
This is the capability most admins don’t realize they have
A user opens Outlook on their personal unmanaged laptop. Cloud Policy still applies.
A contractor uses their own MacBook with M365 apps. Cloud Policy still applies.
A user logs into Office for the web on a hotel computer. Cloud Policy still applies (for supported web policies). An Intune Configuration Profile does none of these things. It requires the device to be enrolled.
How the Policy Check-In Actually Works
Understanding the enforcement cycle helps you troubleshoot when policies don’t apply as expected. The Cloud Policy service uses the Click-to-Run service, not the Intune management channel to deliver policies.
Here’s the exact flow:
- First sign-in: Click-to-Run immediately calls the Cloud Policy service to retrieve policies for the signed-in user.
- Subsequent sign-ins: Check-in only occurs if the check-in interval has elapsed.
- Policy assigned to user’s group: Service returns policies and tells Click-to-Run to check back in 90 minutes.
- User not in any assigned group: Service tells Click-to-Run to check back in 24 hours.
- Policy application: Policies take effect the next time the Office app is restarted (same behavior as Group Policy). Privacy-related policies are an exception and apply without a restart.
- No apps running: The scheduled check-in defers until the next time any Office app is launched.
Registry locations for troubleshooting
Cloud Policy writes to specific registry locations on Windows devices that you can use during troubleshooting:
# Applied policy settings (overwritten each check-in)
HKCU:\Software\Policies\Microsoft\Cloud\Office\16.0
# Check-in status and next scheduled fetch
HKCU:\Software\Microsoft\Office\16.0\Common\CloudPolicy
# Force an immediate re-check (delete this key and restart an Office app)
Remove-Item -Path 'HKCU:\Software\Microsoft\Office\16.0\Common\CloudPolicy' -Force
# FetchInterval value (minutes) — 90 = policy assigned, 1440 = no policy
Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Office\16.0\Common\CloudPolicy' -Name FetchInterval
Platform Coverage: Windows, Mac, iOS, Android, and Web
Another capability that’s underappreciated: Cloud Policy service is genuinely cross-platform. The same policy configuration can enforce settings across all the platforms your users work on, from a single location.
| Platform | Supported? | Notes |
| Windows | Full support | All policy settings. Registry-based delivery via Click-to-Run. |
| macOS | Supported | Subset of Windows policies. plist-based delivery. |
| iOS / iPadOS | Supported | Mobile app policies. Requires M365 Apps on iOS. |
| Android | Supported | Mobile app policies. Requires M365 Apps on Android. |
| Office for the web | Supported | Subset of policies. Also supports anonymous guest users. |
| Loop | Supported | Scoped policy support for Loop components. |
| Volume licensed (LTSC/2019/2021) | Not supported | Cloud Policy requires Click-to-Run subscription apps, not volume licensed. |
One important constraint: Cloud Policy only applies to user objects. A group might contain both user and device objects, but device objects are silently ignored. Nested groups are supported up to three levels deep.
Precedence: Where Does Cloud Policy Sit in the Hierarchy?
When multiple policy mechanisms are in play, knowing which one wins is critical. Cloud Policy sits at the top of the user-policy stack:
| Precedence order | Mechanism | Scope |
| 1 (highest) | Cloud Policy service | User-based, any device, cloud-delivered |
| 2 | Group Policy (ADMX) | Domain-joined devices only, computer or user scope |
| 3 | Intune Settings Catalog (MDM CSP) | Enrolled devices only |
| 4 | Local policy / registry preferences | Local machine only |
| 5 (lowest) | Office application defaults | Baseline behavior |
The implication: if you’ve deployed the same setting via both a Cloud Policy configuration and a Group Policy Object, the Cloud Policy setting wins even on domain-joined managed devices. This is a common source of confusion when admins migrate from GPO-based Office management and wonder why their GPO settings aren’t taking effect for some users.
What’s Waiting for You at config.office.com
If you’ve only ever touched these policies through the Intune portal, you’ve been using them through a narrow window. The full Microsoft 365 Apps admin center at config.office.com is a richer environment, and it’s where this feature has always lived natively.
Policy Volume: 2,000+ Settings Across Every M365 App
The Cloud Policy service exposes essentially the complete set of Group Policy ADMX settings for Microsoft 365 Apps but without any infrastructure requirement and with automatic updates. There’s no ADMX template download, no schema update cycle. When Microsoft adds new settings, they appear automatically.
The policy library spans every major M365 app and component:
- Word, Excel, PowerPoint, Outlook, OneNote, Publisher, Project, Visio
- Teams (client behavior and integration settings)
- OneDrive (sync client behavior)
- Access, InfoPath (legacy)
- Office for the web (subset)
- Core Microsoft 365 Apps platform settings (privacy, diagnostic data, connected experiences)
The Security Baseline Filter – Your Fastest Path to Hardened M365 Apps
Cloud Policy includes a built-in Security Baseline filter. Every policy in the library that Microsoft recommends for a secure enterprise deployment is tagged with a Recommendation column value, and you can filter the policy table to show only baseline-tagged settings.
The most recent version is Security Baseline v2512 (December 2025), published as part of the Microsoft Security Compliance Toolkit. Key additions in v2512 include:
- Block Insecure Protocols: Blocks all non-HTTPS protocols when opening documents. Eliminates downgrade paths and unsafe connections. Aligns with Microsoft’s broader TLS enforcement push.
- Block OLE Graph: Prevents MSGraph.Application and MSGraph.Chart (classic OLE Graph components) from executing. M365 Apps renders a static image instead, mitigating a historically risky automation interface.
- Excel and PowerPoint hardening: Updated settings targeting macro and external data connection security in both apps.
Why use Cloud Policy for the security baseline instead of Intune Settings Catalog?
Settings Catalog policies only apply to enrolled devices. Cloud Policy applies everywhere the user signs in.
For a security baseline focused on Microsoft 365 App behavior (macros, protocols, connected experiences, privacy), Cloud Policy provides broader enforcement coverage for the same configuration effort. Both can coexist, use Settings Catalog for device-level settings and Cloud Policy for user-level M365 App hardening.
The Accessibility Baseline
Less talked about but equally useful: Cloud Policy also includes an Accessibility Baseline, a set of policies that configure Microsoft 365 Apps to encourage accessible content creation and prevent users from disabling the Accessibility Checker. For organizations working toward AODA, WCAG, or Section 508 compliance, this is a low-friction way to enforce accessibility standards at the app level across all user devices.
Priority Ordering and Conflict Resolution
When a user is a member of multiple Entra groups and those groups have conflicting policy configurations, priority determines which setting wins. Priority 0 is highest. You set this via Reorder Priority on the Policy configurations page.
One important nuance: the priority system is tenant-wide. A user in Group A (priority 3) and Group B (priority 1) gets the Group B settings for any setting where there’s a conflict. Settings that only appear in Group A’s configuration still apply. It’s not winner-takes-all, it’s setting-by-setting resolution using the highest-priority configuration that includes that setting.
Purview Audit Trail
Cloud Policy service is fully integrated with Microsoft Purview auditing. When auditing is enabled, the following operations are logged to the unified audit log:
- Policy configuration created, modified, or deleted
- Individual policy settings changed within a configuration
- Priority order adjusted
- Policy configuration exported
This means every policy change at config.office.com is auditable with the same tooling you use for Exchange, SharePoint, and Entra ID changes. For organizations with change management requirements, this is important to know especially because the Intune audit log and the Purview audit log are separate. Changes made directly at config.office.com were already going to Purview, not Intune audit, even before this change.
Roles and Permissions: Who Gets Access
One of the most useful things about Cloud Policy service is the RBAC separation it enables. Because config.office.com is a separate surface from Intune, you can grant policy management access to an M365 Apps administrator without giving them any Intune access at all.
| Entra ID role | Access level | Recommended for |
| Office Apps Administrator | Full: create, edit, delete policy configurations | M365 Apps admins, desktop support leads, security engineers managing Office hardening |
| Security Administrator | Read security info + manage configuration | Security team members who need visibility across M365 security settings |
| Global Reader | Read-only access to most features | Auditors, compliance reviewers (note: doesn’t support cloud update or Modern App Settings) |
| Global Administrator | Full access to everything | Break-glass accounts only – use Office Apps Administrator for day-to-day work |
Separation of duties scenario
Your Microsoft 365 Apps admin is not your Intune admin. Before this change, the Intune portal path required Intune admin access to get to Office app policies an over-privileged path for someone who only needs to manage app settings. After this change: assign the Office Apps Administrator role to your M365 Apps team. They work at config.office.com with no Intune access needed. Least privilege achieved.
The MSP and Multi-Tenant Angle
If you manage Microsoft 365 environments across multiple client tenants via CSP/GDAP as most MSPs and partner-side admins do this change has a specific workflow implication that’s worth thinking through carefully.
GDAP Access to config.office.com
Access to config.office.com for a client tenant follows standard GDAP delegated access. When you navigate to the Microsoft 365 Apps admin center for a client tenant, you authenticate through your partner credentials with GDAP just as you would for any other admin portal.
The key difference from Intune is context switching. The Intune admin portal allows you to switch between tenants within the same browser session via the account picker. At config.office.com, you’re working in the context of a single tenant per session. Switching clients means navigating to the tenant-specific URL or re-authenticating.
Workflow update for MSPs
If your team uses runbooks that reference the Intune admin center path for M365 Apps policy management in client tenants, those runbooks need updating to reflect the config.office.com path.
The tenant-specific URL format is: https://config.office.com, then authenticate with your GDAP credentials for the target tenant. Consider adding config.office.com to your standard set of bookmarked admin portals for each client. The URL doesn’t change per tenant — authentication context determines which tenant you’re in.
Per-Tenant Policy Consistency
One limitation of Cloud Policy service that’s relevant for MSPs: there’s no cross-tenant policy template export/import mechanism built into the portal. If you want to deploy a consistent M365 Apps security baseline across 20 client tenants, you’re either doing it manually in each tenant’s config.office.com, or you’re scripting it.
The Export button on any policy configuration downloads a CSV of the configured settings. That’s your audit trail and your reference for recreating the configuration in other tenants. Microsoft’s Graph API also exposes Cloud Policy service endpoints for programmatic management worth investing in if you’re managing this at scale.
Licensing Check Across Client Tenants
Cloud Policy requires that users have a supported Microsoft 365 subscription that includes M365 Apps. Most commercial M365 and O365 plans qualify, but there are exceptions:
- Not supported: M365 operated by 21Vianet (China)
- Not supported: Volume licensed Click-to-Run (Office LTSC 2021, Office 2019 Standard), these use perpetual licensing, not subscription
- Limited support: M365 Apps for Business plans, only privacy control policies are supported, not the full policy library
If a client tenant has a mix of subscription and volume-licensed Office deployments, Cloud Policy will enforce on the subscription users and have no effect on the volume-licensed machines. This is a common scenario in mid-market environments and worth auditing before deploying the security baseline.
Troubleshooting: When Policies Don’t Apply
Cloud Policy troubleshooting follows a different path than Intune profile troubleshooting because there’s no Intune Management Agent, no device check-in event, and no compliance report. Here are the most common failure modes and how to diagnose them.
| Symptom | Most likely cause | Diagnosis / Fix |
| Policy applies in Intune (Settings Catalog) but not via Cloud Policy | Group Policy or Settings Catalog policy is taking precedence | Cloud Policy wins over GPO for user settings, but check if the Intune Settings Catalog profile has the same setting. CSP-delivered settings may not be overridden by Cloud Policy in all cases. |
| Policy applied to Entra group but user isn’t seeing it | User not in group / group sync not complete / FetchInterval not elapsed | Confirm group membership in Entra ID. Delete HKCU CloudPolicy registry key and restart Office app to force an immediate check-in. |
| Multiple conflicting policies — wrong one winning | Priority order misconfigured | Review Reorder Priority at config.office.com. Lower number = higher priority. |
| Policy applies on Windows but not on Mac | Setting not supported on macOS | Check platform column in the policy configuration. Not all settings are cross-platform. |
| FetchInterval stuck at 1440 (24 hours) | User not in any assigned group | Verify group assignment for that user at config.office.com. 24-hour interval is expected behavior when no policy applies. |
| cmdlet Get-TenantPrivateChannelMigrationStatus not found | Wrong module – Cloud Policy is not managed via PowerShell cmdlets in the Teams module | Cloud Policy is managed via config.office.com UI or the Graph API. There’s no equivalent PowerShell cmdlet for Cloud Policy status. |
Force a Policy Re-Check on Windows
# Delete the Cloud Policy check-in registry key
Remove-Item -Path 'HKCU:\Software\Microsoft\Office\16.0\Common\CloudPolicy' -Force -ErrorAction SilentlyContinue
# Close all Office apps, then reopen any Office app to trigger immediate check-in
# Verify the FetchInterval after re-open:
(Get-ItemProperty 'HKCU:\Software\Microsoft\Office\16.0\Common\CloudPolicy').FetchInterval
# 90 = policy assigned and retrieved
# 1440 = no policy configuration assigned to this user
# View the applied policy settings in the registry:
Get-ChildItem 'HKCU:\Software\Policies\Microsoft\Cloud\Office\16.0'
What to Do Before the June 2606 Release
The operational impact of this change is low. The documentation and process impact is higher. Here’s your checklist.
- Bookmark config.office.com now – and share it with your team. After the 2606 release, the Intune path is gone. Don’t let anyone burn time looking for a page that no longer exists.
- Update your runbooks and SOPs – any documentation that references Apps → Policies for Microsoft 365 apps in the Intune admin center needs to be updated to the config.office.com path.
- Review your Entra ID role assignments – if team members have Intune admin access primarily because they needed it to manage M365 Apps policies, consider downscoping them to Office Apps Administrator and removing Intune access. Least privilege.
- Run the security baseline filter – open config.office.com → Customization → Policy management, open or create a policy configuration, and filter by Security Baseline. Compare what’s already configured against Microsoft’s v2512 recommendations. You’re likely missing some.
- Check your audit coverage – confirm that Purview auditing is enabled in each tenant where Cloud Policy is used. Changes to policy configurations at config.office.com go to the Purview audit log, not Intune audit. If you rely on Intune audit for change tracking, your Cloud Policy changes were already falling through the gap.
- For MSPs: update per-tenant documentation – note which tenants have Cloud Policy configurations, their current settings, and the group assignments. Export each policy configuration as a CSV for your records.
- Review volume-licensed devices – if any client tenants run Office LTSC or perpetual-licensed Office builds alongside M365 Apps, understand that Cloud Policy policies have no effect on those devices. Ensure Settings Catalog profiles or GPOs cover those endpoints separately.
No deadline pressure on this one
Unlike the Teams private channel purge (June 5, 2026), this change carries no data loss risk, no hard deadline for remediation, and no functionality break for existing configurations. The Intune path will redirect, not disappear entirely on day one. You have time to do this properly.
The Bigger Takeaway
MC1330892 is a small housekeeping change. But the reason it’s worth a deep post is that the Cloud Policy service has been hiding in plain sight inside the Intune portal, and many admins have underused it precisely because it felt like “just another way to do what Intune already does.”
It isn’t. A user-based, device-agnostic, cross-platform policy mechanism that follows your users everywhere they sign into Microsoft 365 Apps with over 2,000 settings, a built-in security baseline, an audit trail, and RBAC separation that works independently of Intune is a genuinely different tool. Moving it out of the Intune portal and into its own dedicated admin center is, in that light, the right call.
Go to config.office.com today and look at what’s there. You’re probably not using all of it.