Preparing for Conditional Access approved client app retirement

Microsoft has confirmed that the Conditional Access grant Require approved client app will be retired on 30 June 2026. The deadline has moved, but the requirement to act has not.

After this date, the grant is no longer enforced. Policies that reference it continue to evaluate, but the grant itself is ignored. Access is permitted without applying the intended restriction.

If your Conditional Access estate still relies on this control, those policies need to be updated.

What’s changing in Conditional Access

Microsoft is retiring the Require approved client app grant as part of a broader move toward application-level data protection within Microsoft Entra ID.

The legacy grant was designed to allow or deny access based on whether a client appeared on a predefined list of approved applications. While useful at the time, it does not assess how applications handle corporate data, whether protection policies are applied, or whether data remains governed after access is granted.

The replacement, Require app protection policy, ties Conditional Access enforcement directly to application behaviour and configuration. Access decisions are now based on whether a supported app is governed by an active app protection policy, including controls such as encryption, data transfer restrictions, save-as behaviour, and selective wipe.

Microsoft recommends that organisations:

• Stop relying solely on Require approved client app.
• Use Require app protection policy as the long-term replacement.
• Where needed, apply both grants together during transition to avoid disruption.

From 1 July 2026, the legacy grant is ignored during policy evaluation. The policy still runs, but the approved client app condition is treated as if it does not exist.

What the approved client app retirement means in practice

Nothing breaks. Users can still sign in. Applications still open.

The difference is that the control you expected to apply does not.

Unless policies are reviewed and updated, this change results in access being granted without the protection you designed into the policy. There is no automatic fallback to another grant.

What organisations should do now

This is a straightforward change, but it requires deliberate work.

A sensible moment to review Conditional Access more broadly

If you are touching Conditional Access anyway, it’s worth checking the fundamentals:

• Enforce phishing-resistant MFA where appropriate.
• Block legacy authentication across the estate.
• Use sign-in risk policies via Identity Protection.
• Review session controls such as token protection and sign-in frequency.
• Ensure baseline policies cover guests and service accounts, not just employees.

These are not new ideas, but this change is a practical prompt to confirm they are applied consistently.

How Kocho helps modernise Conditional Access

Kocho helps organisations review and modernise Conditional Access with a focus on correctness and maintainability.

That includes identifying legacy dependencies, migrating policies safely, implementing app protection properly, and validating that enforcement behaves as intended. Where required, our SOC teams can also monitor sign-in behaviour to confirm that controls are operating as expected after the change.

If you want a clean migration without unintended exposure, this is work worth doing deliberately rather than leaving until the deadline.

For more detail on how we can help, please contact our team today.