Happy new fiscal year! Part 2

Welcome back! In part 1 I went through everything Microsoft dropped on us in July. If you skipped it, go read that one first, because a couple of the things below are the second half of stories that start there.

This post was supposed to be the calm one. The September and October stuff with the deadlines you can plan for properly instead of scrambling like a madman. Then I sat down to write it, checked the calendar, and ooops! I realized one of them is about two weeks away. 😱

So I’ve reordered things. The EWS allow list deadline comes first, because that’s the urgent one. Everything else follows in date order after it.

✏️ First, a correction to part 1

In part 1 I told you the SSPR registration campaign would begin on July 6th, with enforcement following on September 7th. Both of those dates are now wrong. Microsoft has revised MC1325414 twice since I wrote that post, and has pushed everything out by another two months.

🚨 The current dates are October 5, 2026 for the registration campaign and November 7, 2026 for enforcement. The campaign did not begin in July at all.

There’s a lesson in it though: Check the MC numbers in your own Message Center rather than trusting a blog post, including this one. Message Center notices get revised quietly and often. The tenant-specific notice is the only thing that’s actually authoritative for your environment.

Check the MC numbers in your own Message Center rather than trusting a blog post, including this one.

On to the main event

End of August: The EWS date that really matters

📖 Exchange Online EWS, your time is almost up – Microsoft Tech Community
📖 Deprecation of Exchange Web Services in Exchange Online – Microsoft Learn
📖 Update to EWS Access for Kiosk / Frontline Worker Licensed Users – Microsoft Tech Community
📖 Set-OrganizationConfig – Microsoft Learn

EWS has been “going away” for so many years that plenty of people quietly stopped believing it ever would. Microsoft first put it on the glide path in 2018. Then in 2023 they named October 1st 2026 as the date it gets disabled. Well, here we are, and this time it’s real. But October 1st is when the damage happens, not when you can prevent it. 😮

🚨 The date that actually protects you is the end of August. That’s roughly two weeks from when this post goes live, so if EWS is anywhere in your environment, stop reading the rest of this post and go deal with this one first.

Here’s the mechanic. Today EwsEnabled is almost certainly sitting at Null in your tenant, and Null is currently treated as True, which is why everything still works. On October 1st, Microsoft starts flipping every Null to False, tenant by tenant. Once that happens, EWS is blocked for every application you have.

The one and only way to be excluded from that automatic flip is to configure an AppID Allow List and set EwsEnabled to $true, before the end of August. Do that, and October 1st is a non-event for you.

If you don’t do this, Microsoft builds an allow list for you in September based on what it observes your tenant actually using. Which might be fine. It will also likely miss anything that only runs quarterly, because it simply won’t have seen it. Either way, Microsoft is now making that call instead of you.

⚠️ Two ways to get the configuration wrong

The allow list does nothing on its own. Microsoft’s Set-OrganizationConfig reference is explicit: When EwsEnabled is blank (Null, not configured), the EwsAllowedAppIDs parameter has no effect. So if you populate your allow list and stop there, feeling productive, you have changed nothing at all. You need both, and you need the switch.

There are two completely different allow-list mechanisms, and they get confused constantly. The old one filters on user agent string (EwsApplicationAccessPolicy with EwsAllowList and EwsBlockList). The new one filters on Entra application ID (EwsAllowedAppIDs), and that one is what the retirement actually uses. If you follow an older blog post and configure EwsAllowList with something like "OWA/*", you have carefully prepared for the wrong thing. The parameter names are close enough that I don’t blame anyone for mixing them up.

Connect-ExchangeOnline

# Where are you now?
Get-OrganizationConfig | Select-Object EwsEnabled, EwsAllowedAppIDs

# Name the apps that get to keep using EWS
Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

# And throw the switch, or the line above does nothing
Set-OrganizationConfig -EwsEnabled $true

If you miss the August deadline

You are not completely stuck, but you will take the hit first. After October 1st there are two ways back:

1. Set EwsEnabled to $true and configure your AppID Allow List. The same thing you should have done in August, just done under pressure with users already on the phone.
2. Set EwsEnabled back to $null. This re-enables EWS with no restrictions at all and buys you time until the final deprecation, which is April 1st 2027. Microsoft documents this route explicitly, and it needs Exchange Online PowerShell.

# The blunt instrument: Unrestricted EWS again, no allow list needed
Set-OrganizationConfig -EwsEnabled $null

Be clear-eyed about what that Null route truly is, though. It is not a clever way to dodge the August deadline, because Null is exactly the value that gets flipped on October 1st. You cannot pre-emptively sit at Null and be safe. It’s a recovery move you make after the outage, and it carries you to April 1st 2027 and no further. On that date EWS is gone for everyone, allow list or not. So the Null route buys you a few months at the cost of an outage you didn’t need to have, and it does nothing whatsoever about the actual work of getting off EWS.

🚨 Keep these two dates apart in your head. The end of August is about not having an outage in October. April 1st 2027 is the deadline that matters, because that’s the day EWS stops existing for everyone and nothing brings it back. An allow list gets you past October 1st, but only migrating to Graph gets you past April 1st 2027.

⚠️ One more trap: Frontline licences

I’m far from a licensing expert, so this one caught me out. It’s completely separate from everything above, and your allow list does not help you with it at all.

Exchange Online Kiosk, Microsoft 365/Office 365 F1 and F3 licences never actually included EWS access rights. Microsoft’s wording on this is refreshingly blunt: As stated in the Service Descriptions, these licenses do not provide access to mailboxes via EWS, but these restrictions were never enforced. From October 1st, they start enforcing it. Affected requests come back as HTTP 403.

The important nuance: This applies to mailboxes carrying only those licences. If a mailbox has an F3 plus something that grants EWS rights, it keeps working. So don’t panic on behalf of every frontline user in your tenant, check what’s really assigned.

The fix: Assign a licence that includes EWS access rights to the affected mailboxes. Exchange Online Plan 1 or Plan 2, or a Microsoft 365 or Office 365 E3 or E5 plan. If you’re only doing it to get a migration finished, you can reassign the original frontline licence afterwards.

💡 And here’s a nice illustration of why I keep telling you to watch your own Message Center: This deadline has already moved twice. It was March 1st, then June 30th, and MC1191578 was updated on June 10th to push it to October 1st. Three dates for one change, and the only place you’d reliably catch that is the notice in your own tenant.

What to do

1. Go to Microsoft 365 admin center → Reports → Usage → Exchange → EWS usage and find out what’s actually still calling EWS in your tenant.
2. For each one, decide whether it can move to Microsoft Graph before the end of August, or whether it needs a place on the allow list to survive October. Just be clear that the allow list is a stay of execution and not a destination: Everything has to be off EWS by April 1st 2027 regardless, because that’s when it goes away for good with no way to re-enable it.
3. Before the end of August, populate your AppID Allow List and set EwsEnabled to $true. Both, not either. That combination is the only thing that excludes you from the October 1st flip.
4. Separately, check whether any Exchange Online Kiosk, F1 or F3 mailboxes are involved in EWS workflows, and fix the licensing on those. The allow list won’t save them.
5. Ask your vendors. Archiving tools, migration tools, backup, eDiscovery, calendar sync. Most of them have published a position by now. The ones that haven’t are the ones to worry about.

😉 And then there are those classic in-house scripts. You know the ones. Written in 2017 by somebody who left in 2019, and nobody has looked at them since. Those are the ones that break at 2am. Go and find them now!

September: Custom controls in Conditional Access stop accepting changes

📖 Custom controls in Microsoft Entra Conditional Access – Microsoft Learn
📖 Migrate from custom controls to external MFA in Conditional Access
📖 External MFA GA announcement

If you’ve ever wired a third-party MFA provider into Conditional Access, Duo, Okta, RSA, that sort of thing, you almost certainly did it with Custom controls. And Custom controls are on their way out.

From September 2026 you can no longer create new Custom controls or edit the ones you already have. Your existing setup keeps working, so nothing breaks that month. But your ability to fix, tweak or adjust anything disappears. Which means from September onwards, if something goes wrong with your third-party MFA integration, your only move is a full migration under pressure.

🤔 When does it actually die? Microsoft doesn’t agree with itself

Here I found a small discrepancy

• The Microsoft Learn page on custom controls says full retirement is scheduled for early 2027.
• MC1422061, published July 2026, and the Entra blog both say Custom controls continue to function until retirement in May 2027.

In my mind, May is not early 2027. The Message Center notice is newer and more specific, but if you’re building a project timeline, assume the worst and finish before “early 2027”.

The replacement is much better

Custom controls were never really integrated in the first place. Entra bounced the user out to the provider, got a “satisfied” token back, and accepted it without ever seeing what actually happened. That blindness is why Microsoft’s own documentation lists things Custom controls simply cannot do: ID Protection automation requiring MFA, SSPR, satisfying the MFA claim, sign-in frequency controls, PIM role elevation, Intune device enrollment, cross-tenant trusts, and joining devices to Entra ID.

My favourite detail: There is no edit function. To change a Custom control you delete it and build a new one from scratch.

External MFA is built on OIDC and registers as a proper authentication method in the authentication methods policy, which means Entra can finally see it happen. PIM activation, risk-based policies, sign-in frequency, the MFA claim. All of it works now.

⚠️ One gap remains: External MFA still doesn’t support Authentication strength, so use the plain Require multifactor authentication grant when you build your policy. In fairness, Custom controls never supported authentication strengths either, so you’re not giving anything up.

What to do

1. Find every CA policy using a Custom control. In the Entra admin center, go to Conditional Access → Policies and check the Grant section on each one. Write down what you find. This inventory step is the part people underestimate.
2. Register your external provider under Authentication methods → Policies → Add external method.
3. Build a parallel test policy using “Require multifactor authentication”, scoped to a small pilot group. Not everyone. A pilot group.
4. Pull that pilot group out of the old Custom control policy, so they’re only hitting the new one and you can see clearly what happens.
5. Test properly before rolling wider.

Set yourself an internal deadline well before September. Once that door closes you lose the ability to adjust anything, and you really don’t want to be discovering a problem in October with no way to edit your way out of it.

September 30: Connect Sync below 2.5.79.0 simply stops

📖 Microsoft Entra Connect: Version release history

Short section, because it’s a short message.

📢 If you’re not on Connect Sync 2.5.79.0 or later by September 30th, your synchronization stops.

This is the same version I was banging on about in part 1 for the hard-match hardening, so if you took that advice you’re already covered and you can move on with a smug little smile. If you didn’t, this is your second reminder in two posts. The installer lives in the Entra admin center under Microsoft Entra Connect now, not the Download Centre.

Go and upgrade. It takes less than an evening and then you avoid the uncomfortable discovery that your sync has stopped.

October 1: Legacy risk policies retire

📖 Risk policies – Microsoft Entra ID Protection | Microsoft Learn
📖 Microsoft Entra ID Protection risk-based access policies – Microsoft Learn

I wrote a full post about this one back in November, Yet another deadline and this one is RISKY!, so I won’t repeat the whole thing. But it’s close now, and I’d rather nag you twice than let it slip past you.

🚨 Legacy user risk and sign-in risk policies under Entra ID Protection retire October 1st, and there is no automatic migration. That’s the scary part. When the authentication methods changes happened, Microsoft (ususally) moved things for you. Not this time. If you don’t recreate your risk policies in Conditional Access before October 1st, your users simply lose risk protection from that day.

And the failure mode here is silent, which is what makes it genuinely dangerous. Nothing errors out. Nothing appears in a log saying “protection removed.” Your risky sign-in challenges and risky user password resets just stop firing, and accounts that ID Protection is actively flagging as compromised carry on with normal access. You won’t notice until it matters.

Are you affected? There’s a quick way to check

Microsoft sent individual Message Center notifications in early August to every tenant with an affected policy enabled. One per policy:

• MC1448338 covers the legacy user risk policy
• MC1448340 covers the legacy sign-in risk policy

Search those two IDs in your own Message Center. A hit means you’re on the list and you have work to do. No hit means you’re either already migrated or you never had them enabled.

The short recipe

• One CA policy for user risk. A separate one for sign-in risk. Do NOT put both in the same policy, because Conditional Access uses AND logic and the policy will then only fire when both risks are present at once. Which protects nobody.
• Use the Require risk remediation grant. It brings session revocation and authentication strength along with it automatically.
• Report-only first, then a pilot group, then validate, then enforce. In that order.
• You need Entra ID P2 for risk conditions. Check your licensing before you start building.

The November post has the full walkthrough with all the gotchas if you want the details.

October 5 and November 7: SSPR stops being forgiving (again)

📖 Microsoft Entra ID security updates: What organizations need to do now
📖 Get-MgReportAuthenticationMethodUserRegistrationDetail – Microsoft Learn

As covered up top, these dates have moved twice and part 1 has the old ones. Here is where things stand.

The current dates, as of the August 4th revision of MC1325414:

• October 5, 2026: The registration campaign begins. Users without a registered method get prompted after sign-in.
• November 7, 2026: Enforcement begins. SSPR stops accepting directory-sourced contact information.

⚠️ Worth knowing: Microsoft’s own notice is not internally consistent on the enforcement date. The title says November 9th. The rollout schedule says November 7th. The “Act by” field says November 6th. so…yeah…. 😖 I suggest you treat early November as the deadline and be finished before it. If you need a single date for a project plan, use November 6th and you’re safe under all three readings.

What the change actually is

Today, SSPR will happily let a user reset their password using a phone number or email that’s just sitting in a directory attribute, even though they never registered it as an authentication method. Microsoft has decided this is sloppy, and honestly they’re right. A number sitting in an attribute is an administrative note and not a security claim. From November, they are treated as just that and so they no longer count in SSPR.

Think about what that means for a user who’s affected. Their only recovery path was a phone number in their profile that nobody ever formally registered. They forget their password, they go to reset it, and the door is shut. They discover this at the exact moment they’re already locked out and already stressed.

Microsoft reckons about 86% of SSPR verifications already use registered methods. That sounds reassuring right up until you remember the other 14% are all going to find out on the same morning. 😱

The silver lining

You’ve got until November now instead of September. Use it.

1. Go to Entra admin center → Authentication methods → User registration details and confirm every SSPR-enabled user has at least one properly registered method.
2. Pull the list with PowerShell:

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail `
  -All `
  -Filter "isSsprEnabled eq true and IsSsprRegistered eq false" | `
  Format-Table UserPrincipalName, IsSsprEnabled, IsSsprRegistered -AutoSize

3. For people who can’t or won’t sort themselves out, have your service desk ready to register a method on their behalf.
4. And once more, because I will keep saying it: Do your admins first. Finding out a privileged account has no working recovery path in the middle of an incident is the kind of discovery that turns a bad day into a truly memorable one.

Given how many times these dates have moved, I’d also suggest keeping an eye on MC1325414 yourself rather than trusting any blog post, including this one. 😉

October 28: PIM Iteration 2 beta APIs retire

📖 API concepts in Privileged Identity Management – Microsoft Learn

A small one, but it’ll catch a few people, so it earns a mention.

The Entra PIM Iteration 2 beta APIs, the ones under the /beta/privilegedAccess endpoint, stop returning data on October 28th. Any script or application still calling them will simply fail from that date.

The replacement depends on what you’re managing:

• Entra roles and PIM for Groups: Move to the Iteration 3 (GA) APIs in Microsoft Graph.
• Azure resource roles: Move to the Azure REST PIM API, not Graph. This one trips people up because they assume everything lands in Graph.

If you don’t automate anything against PIM, skip this section entirely. If you do, go and grep your scripts now rather than finding out when a scheduled job goes quiet and nobody notices for a fortnight.

And one bit of actual good news: Bigger passkey policies

📖 What’s new in Microsoft Entra: June 2026

It’s not all deadlines and doom, I promise. 🥳

The passkey (FIDO2) policy in authentication methods now gets its own dedicated 20 KB, instead of fighting every other authentication method for a single shared 20 KB. And the cap on passkey profiles per tenant goes up from 3 to 10.

If you’ve ever hit the policy size limit while doing granular AAGUID restrictions, that particular headache is over. And if you’re only now getting into passkey profiles, you’ve got room to build something properly segmented. Device-bound with attestation for your admins and break-glass accounts, synced for the general workforce where adoption matters more than provenance.

Wrapping up

So this post and part 1 are blog posts a little out of the ordinary, but I hope this helps you plan your activities ahead. I always prefer a proactive approach to changes, and not reacting when things have stopped working. None of this is technically difficult. The danger is entirely about timing, attention and most of all awareness. There are so many things going on and planned changes like these can more easily drown in all the other information-tsunamis out there.

Anyway, good luck and let’s hope these changes apply to your tenants without much noise and frustration.

Take care!