Editing a Conditional Access custom control means deleting it, and creation stops in September 2026

Conditional Access custom controls are deprecated. From September 2026 Microsoft blocks the creation of new controls and the editing of existing ones, and the only editing procedure it documents is to delete the control and create a replacement. After the block, the rebuilding half is gone. Whether the destructive half still runs is stated on no page read, so the one-way door is an inference from Microsoft's silence rather than a documented outcome.

Last verified: 2026-08-20.

What the vendor says

The banner on Microsoft's Conditional Access custom controls reference reads: "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." The same banner opens the migration guide to external multifactor authentication.

Further down the custom controls reference page, the whole editing procedure is one sentence: "To edit a custom control, delete the current control and create a new one with the updated information." Deletion carries its own precondition: "To delete a custom control, ensure that it isn't being used in any Conditional Access policy." Neither page says whether deletion still works after September, so reading a one-way door into that silence is inference.

Two Microsoft sources, two retirement dates

May is not early 2027. Learn holds the earlier date, so an estate planned against the Message Center could be months late against the documentation. Plan against Learn and treat May 2027 as the outer bound. Both put the administrative block in September 2026, and neither names a day.

flowchart TD
  accTitle: Custom control retirement dates and the edit loop that breaks in September 2026
  accDescr: Two Microsoft sources give different retirement dates, and the documented edit loses its rebuild step once creation is blocked, which by inference rather than by any vendor statement leaves deletion terminal.
  subgraph SRC[What each source dates]
    L1[Learn, Sept 2026, edits blocked] --> L2[Learn, early 2027, full retirement]
    M1[MC1422061, Sept 2026, no changes] --> M2[MC1422061, May 2027, fully retired]
  end
  subgraph EDIT[The documented edit, before and after]
    A[Control exists, policies use it] --> B[Stripped from every policy, definition still present]
    B --> C[Definition deleted]
    C -->|before September 2026| D[New control created with updated JSON]
    D --> A
    C -->|from September 2026| E[No create step, deleted is terminal by inference]
  end
  L1 -.-> A

Why the September block reads as safety

"Editing existing custom controls will not be allowed" reads as protection: the portal refuses risky changes, so a third-party integration sits frozen in a working state until retirement. The same page inverts that. Because editing is documented as delete plus create, the operation September removes is creation. The delete step has its own heading and no page read says it stops.

The cost falls on whoever follows that editing instruction after the block. The precondition dismantles the policies first: the control has to be stripped from the Grant block of every policy using it before the definition can be removed. Only then does the create step refuse. The policies are already rewritten, the definition that made those grants enforceable is gone, and no page read documents a restore.

How to check the tenant

The migration guide publishes a read-only Microsoft Graph PowerShell command listing every policy whose grant depends on a custom control. It connects, reads, filters and selects; nothing in it writes. A definition can be inspected in the portal, but never saved, because a save is an edit.

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

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and (
        @($_.GrantControls.CustomAuthenticationFactors) |
        Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }
    ).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }) -join "," }
}

Each row names a policy whose grant rests on a definition that cannot be recreated once creation is blocked. No rows means the September block reaches nothing in this tenant. Read the State column too, because a report-only or disabled policy still holds the reference. CustomAuthFactors returns control IDs, not provider names.

The permission is Policy.Read.All, which the Graph reference for listing Conditional Access policies marks as least privileged for delegated and application access alike. The portal equivalent is Protection, then Conditional Access, then Policies, inspecting the Grant block of each.

Recommendation

Act now, conditionally. The hinge is roughly two weeks from publication and the qualifying check is read-only, so the check runs this week. No rows drops the decision to ignore for that tenant: "If you don't use custom controls, no action is needed." Any rows makes migration to external multifactor authentication scheduled work that starts before September.

Parallel running makes the phased version practical. Microsoft states that "External MFA and custom controls can operate in parallel", and recommends two Conditional Access policies, one enforcing the custom control and one requiring the multifactor grant, with no user in both.

Trade-offs

Migrating early costs a rollout: P1 or P2 licensing, admin consent to the provider's application, per-user registration, and a report-only period, with the old policy kept disabled rather than deleted for two weeks as a rollback. Microsoft also states that "External MFA isn't yet compatible with authentication strength policies", so a policy built on Require authentication strength moves to the standard grant.

Migrating late costs optionality. After the block the configuration is fixed at whatever it was, and a provider-side change that editing the JSON would ordinarily absorb has no path except a full migration under pressure. Doing nothing is defensible only where the check returns no rows.

Where it does not apply

A tenant that never adopted a custom control has nothing to do here. The capability also never left preview: "Custom controls are a preview capability of Microsoft Entra ID." Microsoft lists what it never worked with, so the retirement removes nothing there. Among the exclusions: role elevation in Privileged Identity Manager, self-service password reset, sign-in frequency controls, Intune device enrollment and cross-tenant trusts. An Entra ID Free tenant sits outside the migration guide too, since P1 or P2 is a prerequisite.

Limitations

The check finds policies that reference a custom control. It does not enumerate control definitions, and no Graph endpoint for listing them appeared on any page read, so a control that no policy references will not appear.

Learn gives no day for the September block and no month for the 2027 retirement, and MC1422061 gives a month for retirement with an act by date of 30 April 2027, so a calendar entry naming a day for the block itself, or for the moment retirement lands, is manufactured rather than sourced. Whether deletion survives September is stated on neither Learn page. MC1422061 was read through a public archive, because the Microsoft 365 Message Center has no public address, so confirm the wording in the tenant.

A change that alters an administrative path rather than an authentication outcome leaves no trace in sign-in logs, which is why it needs a register. The Microsoft 365 tenant hardening service is where that register lives in this practice.