Custom controls: the third-party MFA that Entra does not count as MFA

The Microsoft Learn page on Conditional Access custom controls has a box listing eight things that control cannot do. The third one reads, literally: "Satisfying multifactor authentication claim requirements". The user passes your provider's second factor and gets in, but the token they carry from there does not hold the mark that MFA was done.

It is worth narrowing the headline before going on, because this does not apply to all third-party MFA. A federated provider issuing the right claim does count. The External MFA that Microsoft now offers as the replacement counts too. What does not count is the specific custom controls mechanism, the one wired into a lot of tenants back in the day and still working every morning in quite a few.

We build and maintain Conditional Access in customer tenants, so this page lands close to home. We are bringing it up now for a calendar reason: the same documentation says that starting September 2026 — this month — no new custom controls can be created and existing ones can no longer be edited.

First, check whether you have one

Almost nobody knows off the top of their head whether their tenant carries a custom control, because whoever has one usually inherited it with the tenant. You can see it in the portal, under the "Custom controls" section of Conditional Access, but that only tells you it exists; what matters is which policies reference it. That is a question for Microsoft Graph.

The Graph v1.0 conditionalAccessGrantControls resource has a property called customAuthenticationFactors, described as "List of custom controls IDs required by the policy". If it comes back populated on any policy, there is your answer. With the PowerShell SDK and the Policy.Read.All permission:

Connect-MgGraph -Scopes Policy.Read.All

Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object { $_.GrantControls.CustomAuthenticationFactors } |
  Select-Object DisplayName, State,
    @{n='CustomControls'; e={ $_.GrantControls.CustomAuthenticationFactors -join ', ' }}

If it returns nothing, this post is not about you and you have saved yourself the rest. If it returns something, write down the names of those policies: they are the ones to review, and the interesting part is not that they are expiring but what they have been covering until today.

What a custom control is, and why that explains everything

The documentation describes it like this: the user's browser redirects to the external service, does whatever it has to do there, and comes back; Entra verifies the response and, if it checks out, the user carries on through the Conditional Access flow. A redirect and a return — and that is the explanation for all eight limitations: Entra does not receive an authentication assertion it can fold into the token, but a "this user came back and the provider said yes", good enough for that access decision in that particular policy and for nothing else.

The first line of the page, incidentally, says something that will surprise plenty of people: "Custom controls are a preview capability of Microsoft Entra ID". It never left preview, and it has been holding up the second factor for entire organisations for years.

The eight, and what each one means in your tenant

These are the eight excluded uses, in the order Microsoft lists them, translated into what happens in a real tenant:

Read it again with a compliance matrix in mind. These are not edge cases: they are privilege elevation, device onboarding, account recovery, automated risk response, session expiry and third-party relationships. The control exists, it shows up in the portal, it redirects and it works every single day, and it covers none of those six things.

It is the same pattern we have written about here before: a ticked box is not an enforced control. We saw it with a zero-impact report that only measured what it knew how to look at and with a connected app's token that never asks for MFA again.

The date: the month, not the day

The Learn page, reviewed on 19 May 2026, puts it like this: "Adding new custom controls and editing existing custom controls will not be allowed starting September 2026. Full retirement is scheduled for early 2027". The Microsoft 365 message centre post — MC1422061, published 9 July 2026, visible only from inside your own tenant — agrees on September 2026 for the freeze, but places full retirement in May 2027 with an act-by date of 30 April 2027.

Two official sources, two different wordings: "early 2027" and "May 2027" are not the same thing, and we plan against the earlier of the two, because the cost of being wrong in that direction is finishing the work early. There is also a detail almost nobody looks at: neither source gives a day in September. If you are counting on one last adjustment before the window closes, you do not know which morning you will find the button greyed out.

"Editing" means deleting and creating again

This is where September's freeze stops being a bureaucratic nuisance. The "Editing custom controls" section of the documentation is one sentence long: "To edit a custom control, delete the current control and create a new one with the updated information". And to delete it, says a few lines earlier, "ensure that it isn't being used in any Conditional Access policy".

Chain the three rules together: from September you cannot create, to edit you must delete, and to delete you must unlink it from every policy. The control you are running is single-use. If your provider changes the JSON block — a certificate renewal, an endpoint change, a migration of theirs — you cannot apply it, and if you delete it to try, it does not come back. That is not a migration deadline: it is a part that can no longer be repaired.

What the documentation does NOT say

We are missing a fact, and we would rather say so than fill the gap: neither of the two official pages we read explains what happens to a Conditional Access policy that references a custom control on the day the feature is fully retired. Does the grant stop applying and the user simply walk in? Does it block? Does the policy become invalid? It does not say. The claim that it fails open — that the user passes with no challenge and no alert — is circulating out there, but we could not anchor it to a Microsoft source, so we are not treating it as fact. And a security control whose failure mode is undocumented is a reason to move before the date, not after it.

The replacement comes with its own small print

The replacement is called External MFA (formerly "external authentication methods") and it works differently: you configure it with a Client ID, an Application ID from the provider's multitenant app, and a Discovery URL, which is the OIDC discovery endpoint. It is managed from the authentication methods policy, the documentation says, "just like built-in methods". That fixes the underlying problem: the page itself states that these users "can use an external MFA to satisfy MFA", and describes how they are redirected to the provider based on the freshness requirements configured in sign-in frequency policies. The two things the old mechanism could not do.

That said, it is not free. What we write down before touching a tenant:

For the transition, the most useful part of the whole set is the side-by-side guidance: Microsoft recommends two Conditional Access policies — one enforcing the custom control and one requiring MFA — with a test group in each, but not in both. If a user lands in both they have to satisfy both, and end up redirected to the external provider twice in a row. After that comes the part that actually justifies the project and that almost nobody writes down, because they believe they already had it: putting MFA back on PIM elevation, on device enrollment and on risk policies.

What to take away

A control being switched on tells you nothing about its scope. This one redirects users to an MFA provider, earns its licence fee and shows green on the report, while the vendor's own page lists, in small print, eight uses it is no good for. Nobody lied; nobody read the box. Which is why we keep insisting that Zero Trust is audited by effect and not by configuration: the question is not whether the policy is in place, but what exactly happens to someone trying to get through.

The identity plane, as we wrote back then, is not just another application in the catalogue. If you are going to review one thing in your tenant this month, look as well at what changed on 1 September with passkeys: they are two moves of the same piece.

And if the answer to "do we have a custom control?" in your shop is "someone should check", the query is up there. We look at this as part of our Microsoft 365 and cybersecurity work, and the normal outcome, thankfully, is to find none.

Sources (verified on 3 September 2026): literal list of limitations, preview status, September 2026 freeze, "early 2027" retirement, editing and deletion procedure and the JSON warning — Microsoft Learn, "Custom controls in Microsoft Entra Conditional Access" (reviewed 19 May 2026). May 2027 and 30 April 2027 dates and migration steps — Microsoft 365 message centre post MC1422061, published 9 July 2026 (visible only from inside the tenant). External MFA configuration, roles, the base64 kid note, exclusion from registration reports, behaviour when consent is lost, side-by-side guidance with two policies and the Windows 10 OOBE limitation — Microsoft Learn, "How to manage external MFA in Microsoft Entra ID" (updated 15 June 2026). The customAuthenticationFactors property — Microsoft Graph v1.0, "conditionalAccessGrantControls". We could not find, in Microsoft sources, the behaviour of a policy referencing a custom control after retirement; that is why we do not state it.