If you wired Duo, RSA or another third-party MFA into Conditional Access, Microsoft freezes that configuration in September 2026. And Microsoft says that mechanism does not satisfy its own MFA requirement.
Custom controls are how institutions plugged a non-Microsoft second factor into Conditional Access. Microsoft is replacing them with External MFA. There are two dates, Microsoft calls the first one retirement when it is really a configuration freeze, and the part that matters most to a regulated institution is attached to neither date.
- Both dates in Microsoft's own words, with the vocabulary decoded
- Why your sign-in logs may not record MFA even though users performed it
- The inventory that tells you whether any of this applies to you
What actually happens in September 2026
Custom controls are how a Microsoft 365 tenant sends a user out to a non-Microsoft multifactor provider in the middle of a Conditional Access evaluation. The browser redirects to the provider, the provider does its check, and the user comes back. If your institution bought Duo, RSA or a comparable product and asked for it to be enforced through Conditional Access, this is very likely the mechanism that was used, because for a long time it was the only supported route.
Microsoft is retiring it. The notice appears in an identical box on two Microsoft Learn pages and reads in full:
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.
Read that carefully, because the first sentence and the second sentence describe different events. September 2026 is when the configuration freezes. You cannot add a custom control and you cannot edit one. What you already have carries on working. Full retirement, which Microsoft describes as the controls being no longer supported, comes in 2027.
Why this date gets missed
Nothing visible happens when the freeze lands. No user is signed out, no policy stops evaluating, no alert fires. An institution that does nothing at all that week will notice nothing at all that week. The cost lands later, and it lands on whoever next needs to change the configuration.
And Microsoft has not published a day. Both Learn pages and the Message Center notice say the block begins "starting September 2026" without naming a date. Only the Entra blog names 30 September 2026, and it uses that date for deprecation rather than for the create and modify block. Since the two statements differ in precision, the safe reading is the earlier one: assume the freeze can land at any point during September rather than planning around the 30th.
Microsoft calls the first date retirement, and it is only the date the configuration freezes
| Microsoft source | Date on the source | What it says |
|---|---|---|
| Learn: Custom controls in Microsoft Entra Conditional Access | Page date 19 May 2026 | Adding and editing blocked starting September 2026. "Full retirement is scheduled for early 2027." |
| Learn: Migrate from custom controls to external MFA | Page date 19 May 2026, later updated | The identical box, word for word. |
| Microsoft Entra blog: External MFA is now generally available | 24 March 2026 | "External MFA replaces Custom Controls, which will be deprecated on September 30, 2026. Existing configurations will continue to work during the transition period." |
| Message Center MC1422061 | Published 9 July 2026 | "September 2026: Administrators will no longer be able to create new Custom Controls or modify existing Custom Controls." And: "May 2027: Custom Controls will be fully retired and no longer supported." The archived copy we read also carries a structured Act by field reading Apr 30, 2027, which we could not confirm against a tenant notice. |
There is one more marker worth knowing about, with a caveat about where we read it. The archived copy of MC1422061 that we read carries a structured Act by field reading Apr 30, 2027. We read that in a public Message Center archive rather than in a tenant, so treat it as a strong signal to confirm rather than as a field we observed in your notice. If it is present in your tenant, it is not a third change to the service. It is the date Microsoft asks you to be finished by, a month ahead of the May retirement month, and it is the more useful date for a project plan than one you pick yourself.
Put together, the substance is consistent. September 2026 freezes the configuration, and full retirement follows in 2027. The two readings that cost money are the two obvious ones. Reading "retire September 30" as "it stops that day" produces a panic project against a date that is not the deadline. Reading "May 2027" as the only date produces a comfortable eight-month plan that walks straight past a freeze three weeks away. One point of precision worth keeping: Microsoft says custom controls will be fully retired and no longer supported. We have not found a Microsoft statement that they cease functioning on a given day, so treat 2027 as the end of support rather than as a documented switch-off, and plan as though the two are the same thing.
One thing Microsoft has published two answers to
Learn says end of life is early 2027. Message Center MC1422061 says May 2027. Those are not the same statement, and this page will not average them. Plan against the earlier one. If you are right, you finished early. If Learn is right and you planned for May, you are running an unsupported identity control through a quarter you did not budget for.
Does any of this apply to you? Start with the inventory.
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:
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, StateThat command is read-only. It changes nothing, and the scope it asks for is Policy.Read.All. Most tenants have never had a custom control, so an empty result is the common and welcome answer.
Treat an empty result as a starting inventory rather than a clean bill of health, 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 currently referenced by a policy will not appear. Confirm the empty result a second way, in the Microsoft Entra admin center under Protection, Conditional Access, and the custom controls list, before recording that you have none.
The same answer is available without PowerShell. 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 own migration guide adds a caution worth repeating: large tenants may have dozens or hundreds of policies, so export the result and track it rather than reading down the list once.
What to record for each policy you find
Microsoft's guide asks for five things per policy, and they are the five that decide how much work the migration is: the policy name and ID, the users and groups it targets, the cloud apps it targets, which custom control provider it references, and any conditions such as locations or device platforms. Collecting that first is the difference between a migration you can schedule and one you discover halfway through.
Microsoft says custom controls do not satisfy the MFA requirement
On the page where Microsoft explains its mandatory multifactor authentication enforcement, there is one sentence about custom controls:
The legacy Conditional Access custom controls preview doesn't satisfy the MFA requirement. You should migrate to external MFA to use an external solution with Microsoft Entra ID.
Read plainly: a user can complete a Duo push, an RSA token, or whatever second factor your institution licensed, and Microsoft does not count that toward its own MFA requirement. The user did MFA. Microsoft did not record it as MFA.
Microsoft's migration guide sets out the full picture as a comparison table, and every row is a capability the custom control never had:
| Capability | Custom controls | External MFA |
|---|---|---|
| Satisfies the Conditional Access Require MFA grant | No | Yes, native MFA claim |
| Sign-in log accuracy | MFA not reflected | Full MFA reporting |
| Privileged Identity Management | Not supported | Supported |
| Risk-based Conditional Access | Not supported | Supported |
| Intune device registration | Not supported | Supported |
The custom controls documentation carries a longer list of the same shape. Microsoft states that custom controls cannot be used with Microsoft Entra ID Protection automation requiring multifactor authentication, self-service password reset, satisfying multifactor authentication claim requirements, sign-in frequency controls, elevating a role in Privileged Identity Management, Intune device enrollment, cross-tenant trusts, or joining devices to Microsoft Entra ID.
Custom controls were always a preview feature
Microsoft opens the custom controls page with the words "Custom controls are a preview capability of Microsoft Entra ID", and the mandatory MFA page calls it "the legacy Conditional Access custom controls preview". That is worth knowing rather than worth blaming anyone for. Institutions bought a commercial second factor and integrated it through the route Microsoft supported at the time. Its replacement, then called external authentication methods, ran as a public preview of its own before it became generally available as External MFA on 24 March 2026.
A control that runs, and a record that does not show it ran
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 rather than merely 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 was genuinely challenged, and the log does not carry it in the field a reader would look at. The control is real and the evidence of it is thin.
To be clear about the boundary of the claim: this is about what Microsoft Entra ID records and what Microsoft's own grant controls accept. It is not a statement about any regulator's requirements, and nothing on this page should be read as saying that a custom control puts an institution out of compliance with a rule. Three practical consequences follow inside Microsoft, and none of them wait for either date, because all three are true today:
- 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 rather than inheriting it.
- 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.
- 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.
Why we keep writing about this shape of problem
A security control can be present, switched on, correctly targeted, and doing nothing that its name implies. Custom controls are that pattern documented by the vendor. The right test is never whether a control exists in the policy list. It is what the control does when it fires, and whether the record afterwards proves it fired.
We will read your Conditional Access policies and tell you what each one actually enforces
A free security assessment answers the question this page raises, in writing: which of your policies use a custom control, which grant each policy actually applies, and what your sign-in logs record when it fires.
Get a free security assessmentThe freeze turns the documented way to edit a custom control into a one-way door
Microsoft's custom controls page has a short section headed "Editing custom controls". It reads, in its entirety:
To edit a custom control, delete the current control and create a new one with the updated information.
There is no edit operation. There never was. Changing a custom control means deleting it and creating its replacement, and the same page says creation is blocked starting September 2026.
ABT's reading, not a Microsoft statement
Microsoft does not spell out what those two sentences mean together, so this paragraph is our reasoning rather than a quotation. After the freeze, deleting a working custom control in order to change it removes the only step you can still take and blocks the one you were relying on to finish. Do not delete a working custom control from here on. Microsoft has not named a day inside September, so there is no safe window earlier in the month to rely on. If the provider's JSON needs to change, if a certificate rotates, or if you switch MFA vendors, plan that as a migration to External MFA rather than as an edit.
This is what turns a quiet freeze into a real deadline. The institutions most exposed are not the ones ignoring the change. They are the ones who will need an ordinary configuration change during the transition window and will discover the door has closed behind the only procedure they were given.
When MFA happens and the tenant does not count it
What the migration to External MFA actually takes
External MFA reached general availability on 24 March 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: rather than a block of provider JSON pasted into a text box, the provider publishes standard endpoints and Microsoft Entra ID validates real tokens against them.
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 licence.
- 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. Ask your vendor for those values rather than deriving them.
The sequence Microsoft publishes
- Audit the existing custom control policies and record the five fields per policy listed earlier.
- Configure the external MFA authentication method policy with the provider metadata, and grant admin consent. Until consent is granted the method stays disabled.
- Target a test group only, not all users, and set up exclusions for break-glass accounts at the same time.
- Register the test users for the external method and confirm registration before assuming it happened.
- Create a parallel Conditional Access policy using the standard Require multifactor authentication grant, in report-only mode first.
- Exclude the test users from the old custom control policy so they are not subject to both.
- Verify in the sign-in logs that the new policy evaluated and that the external method is named as the authentication method.
- Expand in phases and only then switch the old policy off.
Do not delete the old policy the day you finish
Microsoft's guidance is explicit on this point: keep the old custom control policy disabled rather than deleted for at least two weeks as a rollback option, and monitor sign-in logs for one to two weeks to confirm there are no regressions.
Keep the two objects separate in your head, because the freeze treats them differently. A Conditional Access policy can be created and recreated at any time, so deleting one is recoverable work. The custom control definition it points at is the object that cannot be recreated once adding is blocked. Microsoft's final rollout step asks you to remove the custom control definition from the tenant, and that specific step is the irreversible one after September. Do it last, and only once the replacement has run clean for a fortnight.
The two mistakes Microsoft warns about by name
External MFA is not satisfied by an authentication strength grant, including the built-in multifactor authentication strength. Microsoft says this in two places, and instructs that policies be configured with the plain Require multifactor authentication grant instead. This one is easy to get wrong precisely because authentication strengths are the more modern control and the natural thing to reach for. If your institution has standardised on authentication strengths, this is a design constraint to know before you write the policy, not after.
External MFA and custom controls can operate in parallel during a migration, which is what makes a phased rollout possible. The trap is a user who ends up in both policies. Microsoft describes the result plainly: that user has to satisfy MFA during sign-in and also satisfy the custom control, which redirects them to the external provider a second time. Two prompts, same provider, same person. The fix is the exclusion step in the sequence above, and skipping it is how a pilot generates help desk tickets that look like a product fault.
One further detail worth planning around: Microsoft 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. Testing a policy five minutes after saving it and concluding it does not work is a common false alarm.
We read the policies and hand back the answer in writing
The free security assessment starts with the inventory on this page, run against your tenant rather than described to you. 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, along with which of the two traps above your configuration is exposed to.
Two things about that engagement. It is a technical review rather than legal or compliance advice, 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 rather than an occasional project. ABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies.
Where the facts on this page come from
The Conditional Access questions behind this one
Conditional Access Policies for Financial Institutions: 2026 Best Practices
The policy set an institution should have in place, and what each one is actually for. Start here if the inventory on this page turned up more than you expected.
Read the article ›
Phishing-Resistant MFA for Financial Institutions
If you are rebuilding the MFA policy anyway, this is the argument for what to rebuild it around rather than simply reproducing what you had.
Read the article ›
Conditional Access Exclusions: The List Nobody Reviews
The migration on this page asks you to add exclusions deliberately, and then to take them back out. This is what happens to the ones nobody takes back out.
Read the article ›Answered from Microsoft's own documentation
The configuration freezes. Microsoft states that adding new custom controls and editing existing custom controls will not be allowed starting September 2026. Note the precision: Microsoft does not name a day. Both Learn pages and Message Center MC1422061 say only starting September 2026, and only the Entra blog names September 30, 2026, using it for deprecation rather than for the create and modify block. Existing custom controls keep working, and the Microsoft Entra blog confirms that existing configurations continue to work during the transition period. Nothing signs out, no policy stops evaluating, and no alert fires that day. Full retirement, when Microsoft says custom controls are no longer supported, comes later, in 2027.
No, and treating it that way is the most common misreading. September 2026 is when you lose the ability to change the configuration. Full retirement, which Microsoft describes as the controls being no longer supported, is in 2027. The reason September still matters is that once adding and editing are blocked, any change you later need to make to a custom control cannot be made, so the practical planning deadline for anything that touches the configuration is September rather than 2027.
Both are Microsoft statements and they do not agree. The two Microsoft Learn pages say full retirement is scheduled for early 2027. Message Center notice MC1422061, published July 9, 2026, says May 2027, and the archived copy we read also carries a structured Act by field reading Apr 30, 2027, which would be the date Microsoft asks you to be finished rather than a third change to the service. We read that field in a public archive rather than in a tenant, so confirm it against the notice in your own Message Center. This page does not average the two retirement statements. Plan against the earlier one, because being early costs you nothing and being late means running an unsupported identity control through a quarter you did not budget for. Check your own Message Center for the notice as it appears in your tenant.
One read-only Microsoft Graph PowerShell command lists every Conditional Access policy that uses one. Connect with the Policy.Read.All scope and filter Get-MgIdentityConditionalAccessPolicy on the CustomAuthenticationFactors grant control. The same answer is visible in the Microsoft Entra admin center under Protection, then Conditional Access, then Policies, by reading the Grant controls on each policy. Most tenants have never had a custom control, so an empty result is the common answer. Treat it as a starting inventory rather than proof: the command only sees what your permissions allow, a Graph error can resemble an empty result, and it reports controls attached to policies rather than a control defined but not currently referenced. Confirm an empty result a second way in the admin center before recording that you have none.
No. Microsoft states on its mandatory multifactor authentication planning page that the legacy Conditional Access custom controls preview does not satisfy the MFA requirement, and instructs customers to migrate to external MFA to use an external solution. Its migration guide adds that custom controls do not satisfy the Conditional Access Require MFA grant either. To be precise about the scope, that is a statement about Microsoft's own requirement and Microsoft's own grant control. It is not a statement that your third-party provider is weak or that your users went unauthenticated, and it is independent of both retirement dates.
Not through a custom control. Microsoft's own capability comparison lists sign-in log accuracy for custom controls as MFA not reflected, against full MFA reporting for external MFA. The redirect to the provider happens and the user is genuinely challenged, but the sign-in record does not carry it as MFA. That matters for anyone who uses sign-in logs as the evidence that a control is operating rather than merely configured.
Microsoft lists them as unsupported with Privileged Identity Management, risk-based Conditional Access, and Intune device registration. The custom controls documentation adds Microsoft Entra ID Protection automation requiring multifactor authentication, self-service password reset, satisfying multifactor authentication claim requirements, sign-in frequency controls, Intune device enrollment, cross-tenant trusts, and joining devices to Microsoft Entra ID.
There is no edit operation to fall back on. Microsoft documents the edit procedure as deleting the current control and creating a new one with the updated information, and creation is blocked from September 2026. ABT's reading of those two statements together, which Microsoft does not spell out, is that deleting a working custom control after the freeze removes the only step still available and blocks the one needed to finish. Do not delete a working custom control once the September 2026 freeze is in force. Treat any needed change as a migration to External MFA instead.
External MFA lets users satisfy a multifactor requirement with a third-party provider while Microsoft Entra ID remains the identity control plane. It reached general availability on March 24, 2026 and was previously called external authentication methods. The substantive difference is that it is built on OpenID Connect, so the provider publishes standard endpoints and Microsoft Entra ID validates real tokens against them, rather than relying on a block of provider JSON pasted into a configuration box.
Microsoft's prerequisites are a Microsoft Entra ID P1 or P2 license, the Authentication Policy Administrator role or Global Administrator, and the Privileged Role Administrator role to grant admin consent for the provider's application. From your MFA vendor you need an Application ID, a Client ID, and an OIDC discovery URL that uses HTTPS and ends with the well-known openid-configuration path with no query string or fragment. You also need a test group and an inventory of every policy that uses a custom control.
Yes, and Microsoft recommends a parallel set of policies for exactly that reason. The trap is a user who ends up inside both policies. Microsoft describes the result plainly: that user must satisfy MFA during sign-in and also satisfy the custom control, which redirects them to the external provider a second time. The fix is to exclude your test group from the old custom control policy as you add them to the new one.
No. Microsoft states that grant controls based on authentication strengths, including the built-in multifactor authentication strength, are not satisfied by the external MFA method, and instructs that policies be configured with the plain Require multifactor authentication grant. This catches institutions that have standardised on authentication strengths, because that is the more modern control and the natural one to reach for. It is a design constraint to know before writing the policy.
Find out what your Conditional Access policies actually enforce.
Tell us roughly how many users you have and whether third-party multifactor authentication is in the picture. Our engineers read the tenant and come back in writing on the scope set out above: which policies use a custom control, which grant each policy applies, what the sign-in logs record when it fires, and what the migration to External MFA needs from you and from your MFA vendor. Confirming which applications depend on which policy needs your records too, and we name exactly which ones to pull.
ABT manages Microsoft 365 tenants and hosts Azure environments for more than 750 financial institutions. The assessment is a technical review and is not legal or compliance advice.
Get a free security assessment
A read of your Conditional Access policies, and a written answer on where you stand before the September freeze.
