Require approved client app is retired on June 30: migrate now
Require approved client app is deprecated June 30. After that date, existing policies stop enforcing. Here is what to configure before the deadline.
If you have a Conditional Access policy with “Require approved client app” as its grant control, that policy stops enforcing on June 30, 2026.
Microsoft is retiring the option. It is already grayed out and unavailable for new policies. Existing policies that use it can still be disabled or deleted, but cannot be edited. After June 30, the grant loses its enforcement effect. If you have not migrated to “Require app protection policy” by then, the protection disappears without a warning.
Key Takeaways
- “Require approved client app” is deprecated June 30, 2026: grayed out now, unavailable for new policies
- Existing enabled policies continue to enforce until the deprecation date, but cannot be modified
- The replacement grant is “Require app protection policy”. It verifies Intune App Protection Policy status instead of relying on Microsoft’s fixed approved app list
- Prerequisites: App Protection Policies configured in Intune + Microsoft Authenticator or Company Portal as broker app on each device
- Admins can still disable or delete policies using the deprecated grant at any time
What was “Require approved client app” doing?
The grant restricted access to a fixed list of Microsoft-approved apps: Outlook, Teams, OneDrive, and a handful of others. The idea was that only apps Microsoft trusts get access to corporate data from an unmanaged device.
The approved app list is the limitation. It is hardcoded by Microsoft. You cannot add a third-party app to it. You have no control over what those approved apps do with your data once they have it. The control tells you which app is authenticating. It tells you nothing about what happens afterward.
“Require app protection policy” takes a different approach. Instead of a static app list, it verifies that an Intune App Protection Policy is active on the app before granting access. That policy is yours to configure: the data handling rules, the compliance conditions, and the actions that trigger when the device or app falls out of compliance.
| Require approved client app | Require app protection policy | |
|---|---|---|
| App list | Fixed by Microsoft | Your configured apps |
| Device enrollment required | No | No |
| Data handling control | None | Full (PIN, copy-paste, wipe) |
| Platforms | iOS, Android | iOS, Android, Windows (Edge only) |
| Broker app required | Yes (Authenticator or Company Portal) | Yes (Authenticator or Company Portal) |
| Status from June 30 | Deprecated | Current (replacement) |
What happens to existing policies?
Three scenarios, depending on your current setup.
Policy is enabled with the grant active. It continues to enforce until June 30. After that date, the grant condition is no longer evaluated. The policy remains visible in the Entra admin center and shows as enabled. Access that was previously controlled by this grant becomes unrestricted. You will not see a block where you expected one.
Policy is disabled. You can delete or fully remove it. You cannot re-enable it with the deprecated grant configured.
Creating a new policy. The option is not available. You cannot add “Require approved client app” to any new Conditional Access policy.
What are App Protection Policies?
App Protection Policies (APP) are Intune policies that sit between the app and your corporate data. They operate at the app layer. The device does not need to be enrolled in Intune. Only the app needs to be managed.
On iOS and Android, you can protect the full Microsoft 365 suite: Outlook, Teams, OneDrive, Edge, and more. On Windows, only Edge is supported. If your users open corporate data in Word or Outlook for Windows, those apps fall outside this scope.
What you can configure with an App Protection Policy:
- Require a PIN or biometric before the app opens
- Block copy-paste from managed apps to unmanaged apps
- Prevent screenshots within the app
- Block backups to personal cloud storage
- Wipe only corporate data from the app on demand, without touching the rest of the device
That is what makes this workable for BYOD organisations. You remove the corporate data from the app: email, files, Teams messages. The personal photos stay.
New to the distinction between device and app management? Intune MDM vs MAM: When to use which approach covers that decision in detail.
What do you need before you can migrate?
Two things must be in place before a Conditional Access policy using “Require app protection policy” can enforce anything.
Intune App Protection Policies must be configured. Create policies in Intune for the apps you want to protect, for each platform in scope. If a user’s app is not covered by an APP when the CA policy evaluates the sign-in, access is denied. There is no fallback.
A broker app must be present on each device. On iOS and Android, the broker is Microsoft Authenticator or Company Portal. The broker app is how Intune verifies that an App Protection Policy is active on the device. Without a broker, Intune cannot assess compliance. The CA grant evaluates against that compliance status. No broker means the check fails.
Users can have Outlook or Teams fully installed and configured. If Authenticator or Company Portal is missing, the sign-in is blocked. This is the most common failure point in migrations I have seen: the CA policy is live, the APP is configured, but nobody verified that the broker app is present on every device in scope.
For Android: Company Portal is required for App Protection Policies to be delivered on the device. Microsoft Authenticator can handle the brokered authentication side, but Company Portal must be present regardless.
For iOS: Microsoft Authenticator is the required broker. Company Portal is not needed for MAM-only scenarios on iOS.
More detail on the per-platform setup: Unmanaged Devices with Intune: iOS, Android, and Windows.
How do you migrate?
Four steps, in order.
1. Configure App Protection Policies in Intune for each platform in scope. The policy must be active and assigned, not report-only, before the CA grant can evaluate it. A policy that exists but is not assigned enforces nothing. For platform-specific configuration, the BYOD series covers each platform in detail: iOS, Android, and Windows.
2. Verify the broker app on every device. On iOS: Microsoft Authenticator must be installed. On Android: Company Portal must be present. Do this before the CA policy goes live. A missing broker produces a silent block. The user sees access denied with no indication of the cause.
3. Create new CA policies with “Require app protection policy” as the grant. Target the same users, apps, and conditions as your current “Require approved client app” policies. Start in report-only mode or with a pilot group. Check sign-in logs in the Entra admin center filtered on Conditional Access results before rolling out to all users.
4. Disable the old policies once the new ones are validated. Keep them as reference until after June 30, then delete.
What happens if you don’t act?
Until June 30: your existing enforcement stays intact. Nothing changes for your users.
After June 30: the grant condition is no longer evaluated. The policy remains in the portal, shows as enabled, and appears healthy. Sign-in logs do not flag this as a failure. The grant check simply does not run. Access that was previously restricted is no longer restricted.
Your dashboard shows the policy as enabled. Sign-in logs show no failures. The grant is not running. You will not know until access is granted where it should not have been.
Five days until the deadline. If App Protection Policies are not yet configured in your tenant, that is where to start.
Frequently asked questions
Do I need Intune licenses to use “Require app protection policy”?
Yes. App Protection Policies are an Intune feature. Users in scope need an Intune license. A Microsoft 365 or EMS license that includes Intune also qualifies. The license must be assigned before the policy applies to the user’s sign-in.
My users are on BYOD devices without Intune enrollment. Does this still work?
Yes. App Protection Policies do not require device enrollment. The policy applies at the app layer. Only the app is managed, not the device. That is the core advantage over MDM-based controls for BYOD scenarios.
What happens to my existing policy after June 30?
The policy remains in the Entra portal and appears enabled. The grant condition stops evaluating. Access that was previously restricted by this grant becomes unrestricted. There is no error, no alert, and no automatic policy disablement.
Which apps are covered by App Protection Policies?
On iOS and Android: the full Microsoft 365 app suite, including Outlook, Teams, OneDrive, SharePoint, and Edge. On Windows: Edge browser only. Third-party apps can be covered if they integrate with the Intune SDK.
Can I run both grants in the same CA policy?
No. You cannot combine “Require approved client app” and “Require app protection policy” in a single grant. You need separate CA policies. Run the new policy in report-only mode alongside the old one during the transition period.