Microsoft scheduled its freeze on Conditional Access custom controls for September 2026. Keep every working custom control in place until its replacement is working.

Microsoft publishes the check itself. A custom control shows up on a Conditional Access policy as a value in the CustomAuthenticationFactors grant control, and one Microsoft Graph PowerShell command lists every policy that has one, along with the custom control each policy references:

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 "," }
}

That command is read-only. It changes nothing, and the scope it asks for is Policy.Read.All. An empty result is a welcome answer, and one worth confirming.

Treat an empty result as a starting inventory and confirm it, for three reasons. The command only sees what your permissions let it see, so a run without the right role can return nothing for a reason that has nothing to do with your configuration. A Graph error can look like an empty result if nobody checks the exit. And it reports custom controls attached to policies, so a control defined in the tenant but not referenced by any policy will not appear. Before recording that you have none, open the Custom controls list in the Manage section of the Conditional Access page in the Microsoft Entra admin center.

The policy side of the answer is available without PowerShell too. In the Microsoft Entra admin center, go to Protection, then Conditional Access, then Policies, and look at the Grant controls on each policy. Microsoft's migration guide adds a tip worth repeating: large tenants might have dozens or hundreds of policies, so export the results and track migration status per policy.

The April 30, 2027 date comes from the notice as it appears in ABT's own tenant, read through Microsoft Graph on September 30, 2026, where Microsoft records it as the action-required date. It is the date Microsoft asks you to be finished by, and it falls before the May retirement month begins. Administrators can read the same notice in their own Message Center in the Microsoft 365 admin center.

One point of precision about what retirement means. Microsoft describes it as the end of support for custom controls. Its Message Center notice adds that existing custom controls continue to function until retirement, that organizations using them must migrate affected policies to External MFA before it, and it answers yes to whether the change will modify, interrupt, or disable Conditional Access policies. Plan as though retirement ends the control, and finish before it.

Take the second row of that table on its own. "Sign-in log accuracy: MFA not reflected." Microsoft Entra sign-in logs are where an institution goes to answer the question of whether multifactor authentication actually happened on a given sign-in. It is the record an incident responder reconstructs a timeline from, and the record you reach for when somebody asks for evidence that a control is operating as well as configured.

On a tenant using custom controls, that record does not show the second factor as MFA. The redirect happened, the provider did its job, the user completed the challenge, and the log does not carry it in the field a reader would look at. The control is real, and the Microsoft Entra record of it is thin. The MFA provider keeps its own logs, which are a separate record from the tenant's.

The scope of that point is Microsoft Entra ID: what it records, and what Microsoft's own grant controls accept. How any regulator views a custom control is a question for your compliance team. Three practical consequences follow inside Microsoft, and all three hold today, whatever the date:

1. A Require MFA policy is not being satisfied by your second factor. Microsoft states this directly. If you built a Conditional Access policy on the Require MFA grant expecting the custom control to meet it, check that assumption before relying on it.
2. Risk-based Conditional Access does not work with it. Policies that respond to a risky sign-in or a risky user cannot use a custom control, so a tenant that bought third-party MFA and also bought Microsoft Entra ID P2 for risk-based policies has two products that do not meet in the middle.
3. Privileged Identity Management does not work with it. Role elevation is the single moment where a strong second factor matters most, and it is on Microsoft's unsupported list.

External MFA reached general availability on March 24, 2026, and was previously called external authentication methods, so older documentation and older internal notes may use that name. It is built on OpenID Connect, which is the substantive difference: the provider publishes standard endpoints and Microsoft Entra ID validates real tokens against them, where a custom control relied on a block of provider JSON pasted into a text box.

What you need before you start

Microsoft's prerequisites list is short and every item on it has an owner in most institutions:

• A Microsoft Entra ID P1 or P2 license.
• The Authentication Policy Administrator role, or Global Administrator.
• The Privileged Role Administrator role, to grant admin consent for the provider's application. This is frequently a different person, and it is the step that stalls migrations.
• Three pieces of metadata from your MFA vendor: an Application ID for their app registration, a Client ID, and an OIDC discovery URL.
• A test user group, and the policy inventory from earlier on this page.

The discovery URL has a strict shape. Microsoft requires it to use HTTPS and to end with /.well-known/openid-configuration, with no additional path segments, query string, or fragment after that. The issuer value must match character for character across the configuration, the discovery document, and the tokens the provider issues. Get those values from your vendor.

The sequence, following Microsoft's migration guide

1. Audit the existing custom control policies and record the five fields per policy listed earlier.
2. Configure the external MFA authentication method policy with the provider metadata, and grant admin consent. Until consent is granted the method stays disabled.
3. Target a test group only, not all users, and set up exclusions for break-glass accounts at the same time.
4. Register the test users for the external method and confirm registration before assuming it happened.
5. Create a parallel Conditional Access policy using the standard Require multifactor authentication grant, in report-only mode first.
6. Review the report-only results in the sign-in logs. Report-only evaluates the new policy on each sign-in without enforcing it or prompting anyone, so this step shows which sign-ins the policy would cover. The proof that External MFA works comes after the policy is on.
7. Switch the new policy from report-only to On, before anyone is taken out of the old policy.
8. Exclude the test users from the old custom control policy so they are not subject to both, and confirm with the What If tool that only the new policy applies to them.
9. Test sign-ins, and confirm in the sign-in logs that the new policy granted access and that the MFA requirement was satisfied by the external method.
10. Expand in phases, and only then switch the old policy off.

Microsoft's guide sets out four rollout phases: a test group of five to ten users, then fifty to one hundred IT staff and early adopters, then department by department, and then all users. Microsoft also notes that because of caching and replication it can take up to a few hours for a new Conditional Access policy to take effect at authentication time, so a policy tested five minutes after saving can look broken when it is still propagating.

The free security assessment starts with the inventory on this page, run against your tenant. For each Conditional Access policy we report which grant control it actually applies, whether a custom control is in the chain, which provider it references, and what the sign-in logs record when the policy fires. Where a custom control is present, we set out what the migration to External MFA needs from you, from your MFA vendor, and from us, which of the two traps above your configuration is exposed to, and how to sequence the work so every working custom control stays in place until its replacement has run clean.

Two things about that engagement. It is a technical review, and the written output is yours whether or not you engage us for the work that follows. Deciding a change window and confirming which applications depend on which policy needs your records as well as your tenant, and we name exactly which ones to pull.

ABT manages Microsoft 365 tenants and hosts Azure environments for more than 750 financial institutions, so Conditional Access in a regulated setting is the environment we work in daily. ABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies.