Microsoft Conditional Access June 2026: Action Guide

If your organization runs Microsoft 365, two Conditional Access enforcement changes are about to land in the same month — and neither one is optional. On June 15, 2026, Microsoft Entra ID begins enforcing Conditional Access policies that target "All resources" against a category of sign-ins that previously slipped past them. Two weeks later, on June 30, 2026, Microsoft retires the "Require approved client app" grant control entirely, and any policy that depends on it without a migration in place will silently stop protecting what it was designed to protect [Microsoft Learn]. Both changes were announced through the Microsoft 365 Message Center — MC1223829 and MC1220751 — and both will affect virtually every Microsoft 365 tenant in the Dallas–Fort Worth metroplex with any meaningful mobile device population or Conditional Access estate.

The Message Center notices have been sitting in admin inboxes for months. Most internal IT teams have not read them. The few that have are still treating them as future-quarter problems rather than as a sixty-day implementation deadline. This guide is the audit-and-migrate plan: how to find the affected policies in your tenant, how to migrate "Require approved client app" to "Require app protection policy" without breaking mobile access, how to identify which sign-ins are about to start hitting your "All resources" policies, and how to test every change in report-only mode before flipping enforcement on.

The Two Changes Coming in June 2026

Both changes are part of Microsoft's broader effort to close enforcement gaps in Conditional Access — the policy engine that sits between every Microsoft 365 sign-in and the underlying resource. They are technically independent, but they will land in the same fortnight and affect overlapping pieces of the same policy estate. Understanding each one separately is the foundation for the audit that follows.

Change 1: "Require Approved Client App" Grant Retires June 30

The "Require approved client app" grant was Microsoft's original way of enforcing that users on mobile devices accessed corporate data only through Microsoft-developed apps — Outlook, Word, Excel, OneDrive — rather than through arbitrary third party clients that could exfiltrate data without restriction. It paired with a built-in list of "approved" Microsoft client apps and was the default mobile data protection grant for years.

The grant was originally scheduled to retire in March 2026. Microsoft extended the deadline to June 30, 2026 to give administrators additional time to migrate [Microsoft Learn]. The extension is not an extension of optionality. After June 30, Microsoft will stop enforcing the grant, and any Conditional Access policy that relies only on "Require approved client app" will behave as if no client-app restriction is configured. Mobile devices that should have been blocked from non-approved clients will be permitted through, and the data loss prevention assumption built into the policy will quietly disappear. The replacement is the "Require app protection policy" grant, which integrates with Microsoft Intune's app protection policies to enforce the same — and stronger — controls.

Change 2: "All Resources" Policy Enforcement Expands June 15

The second change closes a more subtle gap. Conditional Access policies that target "All resources" (formerly "All cloud apps") with one or more resource exclusions previously did not enforce on sign-ins where the client application requested only a narrow set of low-privilege scopes. The affected scopes include the standard OIDC set — openid, profile, email, offline_access — plus directory scopes like User.Read, User.Read.All, User.ReadBasic.All, and several Microsoft Graph variants including People.Read, People.Read.All, GroupMember.Read.All, and Member.Read.Hidden [AdminDroid].

The behavior change is straightforward but consequential. Beginning June 15, 2026, those sign-ins will be evaluated against the matching "All resources" policy. Users who previously connected to a custom application — an internal SSO portal, a directory lookup tool, a contact-sync utility, a third-party SaaS that requests only profile data — without seeing a Conditional Access challenge may now face MFA prompts, device compliance evaluation, or block decisions, depending on what the policy actually requires [Help Net Security]. The rollout began on March 27, 2026 and reaches full enforcement on June 15. The exposure is greatest for tenants running mature Conditional Access estates that have multiple "All resources" policies with carefully-curated exclusions.

Two enforcement deadlines, fifteen days apart: "All resources" enforcement begins June 15, the "Require approved client app" grant retires June 30.

Why This Matters If You Do Nothing

The default failure mode is silent. Neither change throws an alert when it lands. After June 15, an "All resources" policy that quietly stopped enforcing certain sign-ins will start enforcing them — your help desk will see calls about unexpected MFA prompts from custom apps and SSO portals that worked fine the week before. After June 30, the inverse: a Conditional Access policy that was protecting mobile access through "Require approved client app" will continue to appear active in the Entra admin center, will keep generating sign-in logs, and will keep showing up in compliance reports — while no longer enforcing the control it was created to enforce. Audits two quarters later will struggle to explain why mobile data started flowing through unmanaged client apps.

For organizations subject to HIPAA, CMMC, SOC 2, or any data protection regime where mobile device controls are a documented safeguard, the post-June-30 silent failure is a control gap that materializes the moment a regulator or auditor asks. The point of this guide is to make sure that does not happen — and that the changes land as a planned migration rather than a surprise.

Step 1: Audit Your Existing Conditional Access Policies

Every plan starts with an inventory. There are three views you need: which policies use the retiring grant, which policies target "All resources" with exclusions, and which applications and user populations sit behind each. The fastest path is Microsoft Graph PowerShell, which gives you a complete, exportable view of your policy estate in a single session.

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy |
  Where-Object {
    $_.GrantControls.BuiltInControls -contains "approvedApplication"
  } |
  Select-Object DisplayName, Id, State,
    @{N='IncludesAppProtection';E={$_.GrantControls.BuiltInControls -contains "compliantApplication"}},
    @{N='Operator';E={$_.GrantControls.Operator}}

Any row returned by the first query that does not also include compliantApplication (the internal name for "Require app protection policy") is a policy that needs to be migrated before June 30. Pay particular attention to the Operator column — if a policy uses "Require all of the selected controls" rather than "Require one of the selected controls," the migration plan needs to account for users who lack app protection policies on their devices.

Get-MgIdentityConditionalAccessPolicy |
  Where-Object {
    $_.Conditions.Applications.IncludeApplications -contains "All" -and
    $_.Conditions.Applications.ExcludeApplications.Count -gt 0
  } |
  Select-Object DisplayName, Id, State,
    @{N='ExcludedApps';E={$_.Conditions.Applications.ExcludeApplications -join ', '}},
    @{N='GrantControls';E={$_.GrantControls.BuiltInControls -join ', '}}

Every row returned by the second query is a policy whose behavior changes on June 15. The ExcludedApps column tells you which application IDs were being deliberately exempted; the GrantControls column tells you what enforcement is about to begin applying to sign-ins that previously slipped past. For organizations without PowerShell access, the same audit can be performed manually in the Microsoft Entra admin center: Entra ID → Conditional Access → Policies, then filter the list and inspect each policy's Target resources tab for "All resources" with exclusions, and the Grant tab for the approved-client-app grant.

Step 2: Migrate "Require Approved Client App" to "Require App Protection Policy"

The migration itself is mechanical, but the prerequisites take coordination. Each policy you migrate depends on having Intune app protection policies (APP) configured for the iOS and Android applications your workforce actually uses. If your environment does not yet have APP deployed, that becomes the gating dependency — APP needs to be live and targeted at the affected user groups before the Conditional Access change is enforced, or users will be blocked from the apps the policy now requires.

Microsoft's official migration sequence, summarized from the Entra documentation, is the safe pattern [Microsoft Learn]:

Step 3: Identify Sign-ins Affected by the "All Resources" Enforcement Change

The June 15 change is harder to audit because the affected sign-ins are, by definition, sign-ins your existing policies did not evaluate. There is no single list of impacted users — there is a list of applications that have been requesting only the low-privilege scopes, and a list of users who have been signing into those applications. The combination produces the population that will start seeing Conditional Access challenges on June 15.

The most practical audit path is:

• Identify the policies at risk. Use the second PowerShell query above to enumerate every policy targeting "All resources" with one or more resource exclusions. These are the policies whose enforcement footprint expands on June 15.
• Find applications requesting only the listed scopes. In the Entra admin center, navigate to Identity → Applications → Enterprise applications, review the permissions granted to each application, and flag any that request only openid, profile, email, offline_access, User.Read, User.Read.All, User.ReadBasic.All, or the related Microsoft Graph variants. These are the applications whose sign-ins will be evaluated for the first time.
• Cross-reference sign-in logs. In Monitoring & health → Sign-in logs, filter by application name and review the volume and user population that signs in to each flagged app. This produces the rough estimate of how many users will face new challenges on June 15.
• Communicate to the affected populations. Brief help desk staff, and where the population is small enough, notify users directly that they may see new MFA prompts beginning June 15. Most are absorbed without incident; the noise is unforced calls to the help desk by users who do not know why a familiar app is suddenly asking for MFA.

The Entra admin center: where the audit, the migration, and the report-only validation all happen. Familiarity with the Conditional Access workbook is the highest-leverage admin skill of the next sixty days.

Step 4: Use Report-Only Mode for Every Change Before You Flip

Report-only mode is the single feature that turns a high-risk Conditional Access change into a routine one. Every Microsoft-recommended migration path for these enforcement changes — and every responsible internal process — runs the same loop: configure the change, set the policy to report-only, review the Conditional Access Insights workbook for "would-have-blocked" and "would-have-required-MFA" results, fix the gaps, then enable enforcement.

Two operational habits matter during the report-only window. First, give the policy enough time. A seven-to-fourteen-day sample window catches the long tail of mobile users who do not sign in daily, executives traveling on the road, contractors who only check in weekly. A one-day sample misses most of the population you actually need to evaluate. Second, look at the workbook by application and by user group, not just at the aggregate counts. The aggregate may be acceptable while a specific group — an executive assistant pool, a field engineering team, a satellite office — is about to be locked out. Filtering by user principal name and by application catches the cohort-level surprises before they become incidents.

The 21-Day Action Plan

For most Microsoft 365 tenants, a focused three-week effort closes both changes safely. Below is the sequence ITECS deploys for clients running through the migration — designed for a single primary admin with help desk support, scaled to mid-market environments.

Organizations in the DFW metroplex that lack the in-house Microsoft 365 expertise to execute this in three weeks have a small number of credible options: extend the timeline by accepting some overlap with the June deadlines (uncomfortable but recoverable), or bring in an experienced Microsoft 365 consulting partner to run the audit and migration in parallel with internal operations. ITECS performs these engagements for mid-market clients across the metroplex with documented playbooks and a 30-day post-migration review built into the scope.

What Comes After June 30

The two June changes are not isolated events. They are part of an accelerating Microsoft pattern of closing Conditional Access enforcement gaps and retiring legacy grants — the same pattern that drove the deprecation of basic authentication for Exchange Online, the move toward number-matching MFA, and the ongoing tightening of session and token management across Microsoft 365. Organizations that build the muscle to handle this migration cleanly are positioning themselves for the next round, not just clearing this one.

The practical posture for any Microsoft 365 administrator in 2026 is to subscribe to Message Center notifications, review them weekly, and treat each enforcement change as a sixty-day project — not a backlog item. The tenants in the strongest position next quarter will be the ones that operationalized this rhythm before they had to.

Sources

• Microsoft Learn — Migrate approved client app to application protection policy in Conditional Access: learn.microsoft.com
• Microsoft Message Center MC1220751 — Reminder: "Require approved client app" control in Microsoft Entra Conditional Access will be retired in June 2026: mc.merill.net/message/MC1220751
• Microsoft Entra Blog — Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions: techcommunity.microsoft.com
• Microsoft Message Center MC1223829 — Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions: mc.merill.net/message/MC1223829
• Help Net Security — Conditional Access enforcement change coming to Microsoft Entra: helpnetsecurity.com
• AdminDroid — New Conditional Access Change for Policy Targeting All Resources: blog.admindroid.com
• Petri — Microsoft Entra ID to Close Conditional Access Loophole: petri.com