Happy new fiscal year! (now go check your tenant)

So this will be a little different than my normal blog posts.

Every year around this time Microsoft’s fiscal year rolls over, and every year it drags a pile of changes along with it. Most of the chatter you’ll see is about the price hikes, and yes, those are real. But my focus is rarely the licensing line on someone’s invoice. I care more about the stuff that quietly breaks your tenant, locks out your admins, or kills a sync you didn’t know was fragile. And there is plenty of that this time around. 😱

So let’s skip the pricing noise and go through some of the changes that actually matters. This is part 1, covering everything that lands in July. Part 2 takes the September and October deadlines, and trust me, some of those need work starting in August.

A quick map before we dive in, so you can see what’s coming:

The July deadline map

Right, let’s get into it.

July 1: Hard-match hardening phase 2

📖 Hard-match takeover blocking and InvalidHardMatch recovery – Microsoft Learn
📖 Microsoft Entra releases and announcements – What’s New
📖 Set-EntraDirSyncFeature – Microsoft Learn

If you sync identities from on-prem, pay attention to this one. If you don’t, you can skip ahead.

Quick refresher first. Hard-matching is when Entra ties an incoming on-prem AD object to an existing cloud account, usually on something like the immutableId or source anchor. It’s a normal part of hybrid life, and it’s also been a lovely little attack path for years. Manipulate the right attribute on-prem, and you can hijack a cloud account that you were never supposed to touch. Including, in the worst case, a Global Admin. That attack even has a name: SyncJacking. Semperis disclosed it back in 2022, and Microsoft finally confirmed it as an Important privilege escalation vulnerability in May 2025.

Microsoft is now closing the door in two phases. Phase 1 went live June 1st and blocks hard-matching an incoming object to a cloud user that already holds an Entra role. Phase 2 is the one that arrives July 1st.

🚨 Phase 2, July 1st 2026: Once a synced user has its OnPremisesObjectIdentifier set, that’s it. It’s locked. You can no longer remap that user to a different on-prem identity. And this is enforced on the service side, so it does not matter which version of Connect you’re running. You can’t dodge it by staying on an old build.

For most of you running steady-state sync, this changes absolutely nothing. You’ll never notice it. But if you’re in the middle of a tenant migration or an AD forest consolidation, this is exactly the kind of operation you might be relying on, and it’s about to stop working.

If phase 1 already blocked something for you, you’ll have seen this in the sync log: Hard match operation blocked due to security hardening.

What to do:

1. Get on Connect Sync 2.5.79.0 or later. You need this version for the phase 1 protections anyway, and it becomes mandatory for sync to keep working at all by September 30th (more on that in part 2). The installer now lives inside the Entra admin center under Microsoft Entra Connect, not the Download Centre.
2. Turn on the feature flag if it isn’t already:

Connect-Entra -Scopes 'OnPremDirectorySynchronization.ReadWrite.All'
Set-EntraDirSyncFeature -Features 'BlockCloudObjectTakeoverThroughHardMatch' -Enable $true -Force

3. If you have a migration in flight that hard-matches privileged accounts: Strip the Entra roles off the target cloud object first, do the match, then put the roles back afterwards. And no, flipping the feature flag back to $false doesn’t save you here. For an account with admin roles assigned, the block stays put regardless, so stripping the roles first is the only way through.
4. Check your audit logs for recent changes to OnPremisesObjectIdentifier. Microsoft beefed up the logging around this, so use it.

July 1: Copilot Cowork billing grace period ends

📖 Copilot Cowork is now generally available – Microsoft 365 Blog
📖 Usage-based billing and cost management for Copilot Credits – Microsoft Learn

This one isn’t Entra, and yes, I know I said I’d skip the pricing noise. I’m making an exception, because Cowork is the first time I’ve looked at Copilot and thought it’s really useful. So it earns a mention, billing change and all.

Copilot Cowork went GA on June 16th, and with GA came the end of the free ride. If you had users in the Frontier preview between March 30th and June 16th, you’ve got a grace period until July 1st to sort out billing before access gets cut off. Weren’t in Frontier? Then billing already kicked in at GA.

Here’s the part that matters: Cowork is off by default in every tenant. If you do nothing, nothing happens and nothing gets billed. So this is only urgent if your users were already playing with Cowork in the preview and you haven’t set up billing yet. For them, July 1st is a hard stop.

How does it cost you? Cowork rides on top of a normal M365 Copilot license and bills separately in Copilot Credits, at a cent per credit, pay-as-you-go. Every task burns credits depending on the model, how much of your data it has to read, how many tools it calls, and how long it runs. Microsoft buckets tasks into light, medium and heavy, which is a polite way of saying “the more you ask it to do, the more it costs.”

What I’d do:

1. Open the Microsoft 365 admin center → Cost Management dashboard and check whether billing is actually configured.

2. Set spending limits before you let anyone loose. Tenant, group and user level. And remember Cowork shares its credit pool with Copilot Studio, so budget for both or you’ll drain it faster than you expect.

3. Use the Customer Cowork Estimator to get a feel for the numbers before you flip it on.

4. Not ready for any of this? Leave it switched off. There’s no penalty for waiting until you’ve actually decided how you want to use it.

July 6 to 13: Conditional Access enforcement during credential registration

📖 Microsoft Entra ID security updates: What organizations need to do now

If you’ve been working on passkeys or FIDO2 (of course you have!), or you have any CA policy scoped to the Register security information action, this one is aimed straight at you.

Right now those policies fire in My Security Info and in Microsoft Authenticator, but they sit out the registration of Windows Hello for Business and macOS Platform SSO entirely. So you might think you’ve got registration locked down when you actually have two side doors wide open. That gap closes between July 6th and July 13th.

❗Can someone please tell Microsoft that summer vacation is a thing in Europe?

After that, if a user can’t satisfy your CA policy during credential registration, they’re not finishing WHfB provisioning or macOS Platform SSO setup until they do. Which is the behaviour you probably wanted all along, but it’s still a behaviour change, and behaviour changes break things you didn’t expect.

No CA policy on “Register security information”? Then relax, nothing changes for you. If you do have one, here’s the drill:

1. Find your CA policies scoped to “Register security information”. No such policy, no problem, move on.

2. Got one? Flip it to report-only and run a real WHfB provisioning on a test device. Watch the sign-in logs and see what would have been blocked.

3. Make sure your onboarding path still works end to end. If you onboard FIDO2 with a TAP (the way I walked through in the February passkey post), double-check that the TAP actually carries through these registration flows too. This is exactly the kind of thing that behaves differently per tenant, so test it in yours. Don’t take my word or the docs’ word for it.

July 6: The SSPR registration campaign begins

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

This is a two-parter. The campaign starts in July, the actual enforcement bites on September 7th. I’m covering the July half here and the September half in part 2.

Here’s the situation. 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 actually registered it as an authentication method. Microsoft has decided, quite reasonably, that this is sloppy. A number sitting in an attribute is just an administrative note. A number the user registered themselves is a security claim they stand behind. From September 7th, only the second kind counts.

On July 6th, Microsoft kicks off a registration campaign automatically. Users without a registered method get nagged to register one after they sign in. You don’t have to do anything to trigger it. This is your warning window, so use it instead of ignoring it.

Now, Microsoft reckons around 86% of SSPR verifications already use registered methods, so for most tenants this is just housekeeping. But that other 14% is exactly the population that will flood your service desk if you sit on your hands. And the people most likely to be in that 14%? Often the ones who were set up years ago and never touched since.

🚨 Your admins come first here. An admin who can’t reset their password because their only recovery path was an unregistered attribute is an incident, and it’ll happen at the worst possible moment.

So, before July 6th:

1. Head to Entra admin center → Protection → Authentication methods → User registration details and filter for SSPR-enabled users with no registered methods.

2. Or 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. Do your privileged accounts first. Any admin, or anyone eligible for a role, needs a registered method sorted before July 6th, not after.

4. Tell your users the prompts are coming. They’re going to get nagged whether you warn them or not, and a two-line heads-up from IT beats a confused “why is it asking me this” ticket every single time.

July 2026 onwards: Connect Sync to Cloud Sync migration notifications

📖 Migrate from Microsoft Entra Connect Sync to Cloud Sync FAQ
📖 Connect Sync to Cloud Sync decision guide

From July onwards, Microsoft starts telling organizations, via the Message Center, Connect Health, and email, what their individual window looks like for moving from the old Connect Sync to Cloud Sync.

Don’t panic, this is not a forced cutover in July. The notification is just the starting gun. The first wave goes to the tenants where Cloud Sync already does everything their current Connect Sync setup does. If you’ve got multiple forests, a big object count, or you lean on features Cloud Sync still doesn’t cover, you’re not in that first wave. You’ve got time.

Why is Microsoft pushing this at all? Because Cloud Sync is genuinely the better architecture for most people. Lightweight agents instead of a full server you have to babysit. Configuration that lives in the cloud. Multiple agents out of the box, so you don’t have that one sync server that takes the whole thing down when it falls over. And Microsoft has been clear that new sync features are going to Cloud Sync from here on, not back-ported to Connect.

Whenever your notification turns up, here’s what you should already have done:

1. Upgrade Connect Sync to 2.5.79.0 or later. Today. I keep banging this drum because it solves three problems at once: the hard-match hardening from earlier in this post, the mandatory-version deadline in September, and it sets you up cleanly for this migration. There is no reason to still be on an older build.

2. Run the Sync Tool Checker in the Entra admin center to see whether you’re even eligible for Cloud Sync yet.

3. Go through your current config with a critical eye. Custom sync rules, fancy filtering, Exchange hybrid writeback, these are the things that may not have a Cloud Sync equivalent yet. Find your gaps before Microsoft picks your date for you, not after.

4. Remember you can’t run both against the same objects at once. The migration moves users in batches scoped by OU, so plan the phasing rather than imagining a single big-bang switch.

So that’s July. None of it is particularly hard on its own, but it’s a lot of small things stacking up in the same few weeks, and that’s exactly how one of them slips through. I also assume many of us are on vacation when this stuff takes effect, and that’s not exactly helping anyone.

If you only do one thing after reading this, upgrade Connect Sync! That single move covers you on the hard-match hardening, keeps your sync alive past September, and clears the runway for Cloud Sync. One upgrade = three problems gone.✅

Part 2 is perhaps where the nastier ones live: SSPR enforcement, the EWS shutdown, Custom controls retiring, and the risk policy migration. Some of those need you moving in August, so don’t leave it too long.

Good luck, thank you for reading, stay safe out there and I’ll see you in part 2!