Entra custom controls stop accepting edits in September

If your Conditional Access setup includes custom controls — the mechanism for sending users out to a third-party MFA provider mid-sign-in — there is a change coming this month, and its shape is unusual enough to be worth reading carefully.

Microsoft's deprecation notice:

“Custom controls are deprecated. Adding new custom controls and editing existing custom controls will not be allowed starting September 2026. Full retirement is scheduled for early 2027. Start planning your migration now.”

⛔ Note what Microsoft did not say. There is no day in September, and "early 2027" is a season. We are not going to invent either, and neither should a vendor telling you the deadline is a specific Tuesday. Month precision is all that exists today.

The edit freeze is worse than an edit freeze

Read the deprecation notice next to Microsoft's own instructions for editing a custom control, which sit further down the same page:

“To edit a custom control, delete the current control and create a new one with the updated information.”

There is no in-place edit. Editing is deletion followed by creation. So when creating new custom controls stops being allowed, the consequence is larger than "you cannot make changes":

After the freeze, deleting a custom control is permanent. The normal, documented, entirely reasonable procedure for changing one — delete it, recreate it — becomes a one-way door, and the second half of it fails. Anyone who follows the documented editing steps out of habit, without noticing the deprecation notice at the top of the same page, deletes a working control and cannot put it back.

That is the operational risk here, and it lands on the person least likely to have read a lifecycle announcement: whoever is on shift when the provider's JSON needs updating.

It was a preview capability the whole time

Microsoft's own description opens with it: “Custom controls are a preview capability of Microsoft Entra ID.”

This is the second Entra retirement this autumn where production identity infrastructure turns out to be resting on something Microsoft classified as preview — the memberOf rule operator is the other, and it retires on November 3. The pattern is worth naming, because it suggests a useful audit question that has nothing to do with either specific feature: which parts of our identity configuration are previews we adopted because they were the only thing that worked?

What a custom control actually does, which explains the limits

Microsoft's description of the mechanism is worth having in mind, because every limitation below follows from it: “users are redirected to a compatible service to meet authentication requirements outside of Microsoft Entra ID. To meet this control, a user's browser redirects to the external service, performs any required authentication, and then redirects back to Microsoft Entra ID.”

So Entra does not observe a second factor. It observes a successful round trip. The provider asserts that something happened; Entra verifies the response and lets the sign-in continue. That is enough to gate access on a Conditional Access policy, and it is not the same thing as Entra recording that the user performed multifactor authentication — which is precisely why the MFA-claim limitation exists rather than being an arbitrary product gap.

The limitation list deserves a slow read

Before planning the migration, it is worth checking what custom controls were actually doing, because Microsoft's constraints are more restrictive than the mental model most teams carry. Microsoft states custom controls can't be used with:

• Entra ID Protection's automation requiring multifactor authentication
• Entra self-service password reset (SSPR)
• Satisfying multifactor authentication claim requirements
• Sign-in frequency controls
• Privileged Identity Management role elevation
• Intune device enrollment
• Cross-tenant trusts
• Joining devices to Microsoft Entra ID

The third one is the one to stop on. A custom control does not satisfy an MFA claim. So an organisation that answers "yes, we enforce MFA — we use a third-party provider through Conditional Access" may be describing something that does not register as multifactor authentication to the parts of Entra that check for it. That gap exists today; the retirement simply forces the conversation.

For a firm filling in a cyber-insurance questionnaire or writing a control narrative, that distinction is worth confirming rather than assuming — and the migration to external authentication methods is a natural moment to confirm it.

What we would do this week

• Look in Conditional Access > Manage > Custom controls. Most tenants have none. Five minutes settles it, and a nil result is worth writing down.
• If you have any, freeze the editing procedure now. Tell whoever administers them that delete-and-recreate is no longer a safe operation, before September makes that true rather than cautious.
• Find out which policies reference them. A custom control cannot be deleted while a policy uses it, so the dependency map is also the migration plan.
• Check whether the control is doing what people believe. Specifically whether anything in your environment depends on that provider satisfying an MFA claim — because per Microsoft, it does not.
• Plan against September, not early 2027. The retirement is the visible date; the freeze is the one that changes what you are allowed to do, and it is first.

Sources

All quotations are from Custom controls in Microsoft Entra Conditional Access on Microsoft Learn (ms.date 2026-05-19), read in full on September 5, 2026. Microsoft's deprecation notice links onward to an External MFA general-availability announcement on its community blog; we have not quoted that post because that platform does not serve its body text to automated retrieval, and we do not cite pages we have not read.

If you would rather have the custom-control inventory, the policy dependency map and the migration to external authentication methods handled as a bounded piece of work, scope it with us.