Upgrade Entra Connect Sync before April 2027 and move users off Microsoft's SMS codes
Entra Connect Sync servers must run 2.6.84.0 or later with application-based authentication by 7 April 2027, and Microsoft stops sending its own SMS and voice MFA codes on 1 February 2027. Here's what breaks, which build to install and how to move users off text codes.
part 22 of 25 · Platform releases, explained from scratchthe ideaTwo Entra deadlines in early 2027: SMS codes end, then legacy sync sign-in.
after reading, you can- Spot the sync servers that still sign in the old way, even ones that auto-upgraded
- Upgrade Entra Connect Sync to 2.6.92.0 and switch it to application-based authentication
- Move SMS and voice users to passkeys, and keep a telephony provider only for those who need it
Two Microsoft Entra changes land in the same few months, and both can stop people working. Entra Connect SyncdefinitionThe Windows program that copies users, groups and password hashes from on-premises Active Directory to Entra ID. You'll still see its old name, Azure AD Connect, in plenty of places. servers have to run version 2.6.84.0 or later, signed in with application-based authenticationdefinitionThe new way Connect Sync signs in to Entra ID: an app registration with a certificate credential instead of the Sync_ user account and its password., by 7 April 2027. Microsoft also stops sending its own SMS and voice MFA codes from 1 February 2027. Upgrade your sync servers to 2.6.92.0 and switch them to application-based authentication this quarter, then move every SMS and voice user to a passkey or a telephony provider you contract yourself.
Your sync server's old login and Microsoft's own text-message codes are both going away
Many companies that use Microsoft 365 keep their staff list in an on-premises Active Directory. A small program called Entra Connect Sync copies that list to the cloud every half hour, so people can sign in to email and Teams with their work password. Older servers sign in to the cloud with a username and password of their own. Microsoft wants it to use a certificate instead, and from 7 April 2027 the old login stops working. If nobody acts, new starters don't get accounts, leavers keep theirs, and password changes stop flowing to the cloud. Separately, the text and phone-call codes many staff use for MFA will stop coming from Microsoft on 1 February 2027.
Think of a courier who carries your staff list to head office every half hour. Head office has stopped accepting the courier's handwritten pass and wants a proper badge. Same courier, same route, new badge. Meanwhile the reception desk is ending its free text-message door codes and asks visitors to carry a key fob.
- Anyone running Entra Connect Sync
- Microsoft 365 admins in hybrid setups
- Helpdesk and service desk leads
- Staff who get MFA codes by text
- IT managers at smaller firms
- Security and compliance teams
Why it matters to you
The sync deadline is the one that hurts quietly. Microsoft says synchronization services will stop working after 7 April 2027 if a server is still on an older version or still using the legacy account. Nothing breaks on screen. Cloud accounts just stop changing, so the first sign is usually a new hire who can't sign in on day one, or a leaver whose mailbox still works.
The SMS change hits people directly. After 1 February, a user whose only MFA method is a Microsoft-sent text or call gets a blocking prompt at sign-in and has to register a passkey before they can carry on. Microsoft's FAQ says nobody gets locked out outright, but a whole office meeting that prompt on the same Monday morning will still reach the helpdesk. Self-service password reset by text is in scope as well, so the password reset flow changes at the same time.
There's a security side to both. A sync account with a password that never expires is a credential worth stealing, and a text message can be intercepted or redirected with a SIM swap. Microsoft gives both reasons for the changes, so this is a chance to close two old gaps on a deadline you'd struggle to argue with.
-
01 Server on 2.5.x
The sync server is on a 2.5 build and logs in to Entra ID as the Sync_ account, using a password stored on the box. It works, so it rarely gets looked at.
-
02 Auto-upgrade stops short
Auto-upgrade can carry an eligible server to 2.6.3.0, the last build released for it. That's still below the 2.6.84.0 floor, so someone has to upgrade it by hand.
-
03 Support date passes
Support for each 2.x build runs out a year after the next one ships. A server on 2.5.79.0 lost support on 23 October 2026, and one on 2.5.190.0 loses it on 2 February 2027. Microsoft warns a retired build might stop working without notice.
-
04 Legacy sign-in retired
After 7 April 2027 a server below 2.6.84.0, or one still on the Sync_ account, stops synchronizing.
-
05 Cloud drifts from AD
Joiners, leavers, group changes and password hash sync stop reaching Entra ID until someone upgrades and switches the sign-in.
For engineers: the new sign-in is a single-tenant app registration with a certificate credential. By default Entra Connect creates the app, makes a certificate with a 90-day lifetime and rotates it for you through the sync scheduler. Microsoft recommends a TPM on the server so the private key sits in hardware. Without one, the key goes to the software key storage provider marked non-exportable.
What changed in Connect Sync
Connect Sync changes that affect this upgrade
Servers need 2.6.84.0 or later and an app plus certificate sign-in by 7 April 2027. The username-and-password Sync_ account is being retired.
Since 2.6.84.0, existing servers stay on the legacy account after an upgrade. Some older builds switched servers in the background, so check each one, and run the wizard task Configure application-based authentication to Microsoft Entra ID where it's needed.
If application-based authentication fails during setup, the wizard now stops with an error. It used to fall back to the legacy account without saying so.
PHS no longer turns its cloud feature flag back on by itself. If someone disables it, an admin has to enable it again.
Since 2.6.91.0, admins sign in to the setup wizard through Windows Web Account Manager. Passkeys and FIDO2 keys work there by default, so the admin running the upgrade doesn't need a weaker method.
2.6.91.0 adds a workflow that assesses your setup, installs the provisioning agent and moves you to Entra Cloud Sync in stages. Public Azure cloud only.
2.6.84.0 could fail with error 0xE0474352 when an ADSync database already existed. 2.6.91.0 fixed it, and 2.6.92.0 fixed a Pass-through Authentication setup bug on top.
From 2.6.84.0, auto-upgrade merges your changes to miiserver.exe.config instead of overwriting them. No build with this change has been released for auto-upgrade yet.
The second item catches people out. Plenty of teams leave auto-upgrade on and assume Microsoft keeps them compliant. Today auto-upgrade stops at 2.6.3.0, below the floor, and even a server upgraded by hand to 2.6.92.0 stays on the old account until someone runs the wizard task. So check the sign-in on every server, not just the version.
Picking the target build is simple once you read the known issues. 2.6.84.0 is the floor Microsoft names, but it can fail to install over an existing ADSync database, and its own support ends on 16 September 2027. 2.6.79.0 was pulled after release, and Microsoft tells anyone who installed it to move to the latest build. Go straight to 2.6.92.0.
| Version | End of support | Meets the April 2027 rule? | Notes |
|---|---|---|---|
| 1.x (any) | Already ended | No | Microsoft says 1.x doesn't sync at all now |
| 2.5.76.0 | 1 Sep 2026 | No | Out of support |
| 2.5.79.0 | 23 Oct 2026 | No | Out of support since last week |
| 2.5.190.0 | 2 Feb 2027 | No | Known miiserver.exe.config upgrade issue |
| 2.6.1.0 | 10 Mar 2027 | No | Same config-file issue as 2.5.190.0 |
| 2.6.3.0 | 7 Jul 2027 | No | Last auto-upgrade build; below the floor |
| 2.6.84.0 | 16 Sep 2027 | Yes, with app-based sign-in | Can fail over an existing database |
| 2.6.91.0 | 23 Sep 2027 | Yes, with app-based sign-in | Adds the guided Cloud Sync move |
| 2.6.92.0 | Current | Yes, with app-based sign-in | Hotfix with security fixes; the one to install |
The dates in order
- 1 Sep 2026Passkeys switched on for SMS users
Anyone enabled for SMS or voice had passkeys switched on and began seeing a nudge to register one. They can snooze it as often as they like, so don't count the nudge as progress.
- 23 Sep 2026Connect Sync 2.6.92.0
Install this one. It's a hotfix with security fixes, and it's the build we'd put on every server.
- 23 Oct 20262.5.79.0 out of support
Servers on it should already be moving.
- 30 Oct 2026Own telephony provider goes live
Workforce tenants in global Azure can now send SMS and voice through Soprano, Telesign or Infobip. You pay the provider directly.
- 1 Feb 2027Microsoft SMS and voice end
For everyone except Global Administrators and external users. Internal guests are in this wave.
- 2 Feb 20272.5.190.0 out of support
That's the day after the SMS change. If both jobs are still open, the first week of February gets busy.
- 7 Apr 2027Legacy sync sign-in retired
Servers below 2.6.84.0, or still on the Sync_ account, stop syncing.
- 1 Jul 2027SMS ends for the last group
Global Administrators and external users lose Microsoft-sent codes too. Admins should be on passkeys long before this.
What changes for SMS and voice MFA
Microsoft is ending the texts and calls it sends itself. It isn't banning SMS as a method. You can keep codes going for the people who really need them through Choose Your Own Telephony Provider, which Microsoft calls CYOTdefinitionChoose Your Own Telephony Provider. Your company signs up with a provider in Microsoft Security Store, and Entra keeps sending texts and calls through them after Microsoft stops., and it went live for workforce tenants in global Azure on 30 October. Everyone else should move to a passkey, or at least to an authenticator app.
- It's phishing-resistant, so it passes Conditional Access that asks for strong methods. Texts never will
- No extra cost from Microsoft
- Each person registers once, on their phone or laptop or on a security key. After that there's no code to type
- Password change for passwordless users is only planned so far, so plan SSPR on its own
- Each person needs a phone, laptop or key that can hold a passkey. Microsoft warns that's patchy in places, Android phones in China for one
- Codes keep coming by text or call, the way they always have. Nobody needs retraining
- You pay the provider for each message. The integration runs in your own Azure subscription, so that's on your bill too
- Someone on your team keeps the Azure Function running and renews its certificates. If they forget, codes stop
- Can't be used for SMS as the first sign-in step
- Still phishable, so keep it to users with a real need
Turning CYOT on takes more than a tick box. Microsoft hands each request to an endpoint you deploy in your own Azure subscription, and your team keeps that running and renews its credentials. The provider only delivers the messages. So budget for message charges and Azure hosting, and decide who gets paged when codes stop arriving at 2am.
| User group | Microsoft SMS and voice end | What they see afterwards | Watch out for |
|---|---|---|---|
| Employees and contractors | 1 Feb 2027 | Blocking passkey registration if SMS or voice was their only method | Shared or desk phones used for codes |
| Internal guest users | 1 Feb 2027 | Same blocking prompt | They're not in the July group |
| Global Administrators | 1 Jul 2027 | Same blocking prompt, five months later | Break-glass accounts that still use a phone |
| External (B2B) users | 1 Jul 2027 | Same blocking prompt | Partners you can't train directly |
| Users on an authenticator app code | No change | Can keep using TOTP after February | TOTP isn't phishing-resistant |
| Users routed through your CYOT provider | No change | Codes keep coming from your provider | Provider outages are now yours to handle |
| Azure AD B2C tenants | Out of scope | No change from this notice | External ID gets its own notice later |
What to do now, by role
Who does what before February
- Ask IT which sync servers you run, which version each is on, and whether they've switched to the new sign-in.
- Ask how many staff still get MFA codes by text or call, and who will tell them about the change.
- Decide whether any group truly needs SMS after February. That's a paid provider contract.
- Book extra helpdesk cover for the first week of February. That's when people who snoozed the nudges meet the blocking prompt.
- Inventory every Connect Sync server, staging ones too, and record the version and sign-in type.
- Upgrade to 2.6.92.0, staging server first, and run Configure application-based authentication on each server.
- Check for app-scoped Conditional Access policies that target the sync service, since 2.6.91.0 added Microsoft Graph permissions.
- Run Microsoft's SMS and voice policy scanner to see which policies and groups still target those methods. Then expand those groups into a user list yourself, because the scanner doesn't.
- Write the helpdesk a short script for the day someone calls about the blocking passkey prompt. Cover why it can't be skipped, then how to register on each kind of phone and on Windows.
- Decide now how the desk proves who's calling when someone has lost their only passkey. A text code was the easy fallback, and after February it's gone.
- Keep a stock of FIDO2 keys for people who can't use a phone passkey.
- List any rule or contract that really requires an out-of-band text. Keep CYOT for those users and move everyone else to passkeys.
- Make sure break-glass and Global Administrator accounts use a passkey or certificate, and test them.
- Confirm the sync server's private key sits in a TPM. The wizard's configuration export shows Microsoft Platform Crypto Provider when it does.
# example: run on each Entra Connect Sync server Import-Module ADSync Get-ADSyncEntraConnectorCredential Get-ADSyncAutoUpgrade -Detail # example output (illustration, layout varies) ConnectorIdentityType : ServiceAccount Suspended UpgradeNotSupportedNonLocalDbInstall
Read that output as two problems. ServiceAccount means the server still uses the legacy Sync_ login, so it needs the wizard task whatever version it runs. If auto-upgrade is suspended and the detail says UpgradeNotSupportedNonLocalDbInstall, the server runs on full SQL Server and will never upgrade itself. Someone has to do it by hand.
The upgrade, step by step
Before: sync signs in as a user with a password
Sync logs in as the Sync_ account with a password that never expires. After 7 April 2027 Entra ID refuses that login and exports stop.
After: sync signs in as an app with a certificate
Connect Sync 2.6.92.0 uses its own app registration and a 90-day certificate it rotates itself, ideally with the key in a TPM.
The order we'd do it in
- 01List every server and its state
Run the check script on each sync server, active and staging. Note the version, ConnectorIdentityType, database type, TPM status and whether auto-upgrade is suspended. Count Sync_ accounts in the tenant too; Entra ID allows 20, and old ones from dead servers eat that allowance.
- 02Back up the config
Export the configuration from the wizard with View or export current configuration, and copy miiserver.exe.config. If you edited that file for FIPS or proxy settings, you'll need the copy when the upgrade leaves it alone.
- 03Choose in-place or swing
If a server hasn't been upgraded in 12 to 18 months, or its Windows Server needs replacing too, Microsoft suggests a swing migration. You build a new staging server on 2.6.92.0, check it and then make it active. One small server under about 100,000 objects can be upgraded in place, and Microsoft suggests a weekend for that.
- 04Upgrade the staging server first
Download 2.6.92.0 from the Entra admin center, since it's no longer on the Download Center. Check .NET Framework 4.7.2 and TLS 1.2 first. Let the staging server finish a full import and sync, then compare its pending exports with the active server's.
- 05Switch the sign-in
Open the wizard, go to Additional tasks and run Configure application-based authentication to Microsoft Entra ID. You need a Hybrid Identity Administrator. Then run Get-ADSyncEntraConnectorCredential again and confirm it says Application.
- 06Swap roles and repeat
Turn off staging mode on the upgraded server and turn it on for the old one, then upgrade and switch that one as well. Every server needs its own sign-in switched, staging servers included.
- 07Clean up and watch
Once both servers are on application-based authentication, remove the leftover Sync_ accounts in a change window. Keep the scheduler running, because certificate rotation only happens when it is. Then watch the first few export cycles and the sync health alerts.
Harden it while you're in there
- 01Treat the sync server as a tier 0 asset
It holds a credential that can write to your whole directory. Limit who can log on to it, patch it with your domain controllers, and keep it off general-purpose admin jump boxes.
- 02Put the key in hardware
Use a TPM 2.0, or an HSM if you bring your own certificate, so the private key can't be copied off the box. With your own certificate, Connect logs warning event 1014 when no TPM is used, so alert on it.
- 03Drop the Hybrid Identity Administrator afterwards
Microsoft says the role isn't needed after setup. Lower the account's role instead of deleting it, so you can raise it again for the next wizard run.
- 04Make phishing-resistant MFA the default
Once SMS users are on passkeys, add a Conditional Access authentication strength that asks for phishing-resistant methods on admin roles first, then on everyone else.
- 05Put upgrades in the calendar
Every 2.x build has a 12-month clock that starts when the next one ships. Check the version history each quarter and upgrade staging first, so the next deadline is routine.
If it goes wrong
When sync stops, or sign-ins jam after February
Here most failures are outages. Sync problems show up as drift between AD and the cloud, and MFA problems show up as a queue at the helpdesk. Treat anything stranger as a security incident.
- 01Spot itfirst hour
- Check the Synchronization Service Manager for failed export runs and the error text.
- Run Get-ADSyncEntraConnectorCredential to see whether the server is still on ServiceAccount.
- For MFA, check the sign-in logs for people stuck at passkey registration, then call the ones who can't finish it.
- 02Restore servicesame day
- Upgrade to the latest build and run the application-based authentication task. That's Microsoft's own fix for a stopped sync. Then run a sync cycle and watch the exports clear.
- If the upgrade broke sync with the DiagnosticSource error, add the binding redirect and restart ADSync.
- If a staging server is already upgraded and switched, promote it. Take it out of staging mode and sync picks up from there.
- 03Catch upfirst day
- Let a full sync run, then check joiners and leavers from the outage window by hand.
- Disable any leaver accounts in Entra ID directly if the gap was long.
- Confirm password hash sync is on; it no longer turns itself back on.
- 04Help usersthis week
- Sit with the first users who hit the blocking prompt and get a passkey onto their own device. Write down what tripped them up.
- Hand a FIDO2 key to anyone who can't use a phone passkey. Keep a few spares at the desk.
- Move anyone who really needs texts onto the CYOT provider. Everyone else stays on passkeys.
- 05Learnthis month
- Put the sync version and sign-in type on the monthly health check, so nobody has to remember them next year.
- Record which servers were missed and why.
- Retire any Sync_ accounts left from old servers.
What this looks like in practice
Three typical estates
- the setup
- An express install from years ago runs on a single VM with LocalDB and auto-upgrade on. Most staff get MFA codes by text.
- what happens
- Auto-upgrade took the server as far as 2.6.3.0 and stopped there, still below the floor. In February staff hit a blocking passkey prompt on a Monday, and in April sync stops.
- what to do
- Upgrade to 2.6.92.0 by hand, check the sign-in and switch it if needed, and run a passkey registration campaign in December so February is quiet.
- the setup
- Two servers, active and staging, on 2.5.190.0 with a SQL Server database. Auto-upgrade has been suspended for years, and custom sync rules handle contractors.
- what happens
- Support for 2.5.190.0 ends on 2 February, a day after the SMS change. The last upgrade, to 2.5.190.0, broke sync with the DiagnosticSource error because someone had edited the config file, and nobody wants a repeat.
- what to do
- Upgrade the staging server first with a copy of miiserver.exe.config kept aside, switch its sign-in, then swap roles and repeat on the old active server.
- the setup
- Several forests, a dozen sync servers across regions, and branch staff whose policy requires an out-of-band SMS code. Partners sign in as B2B guests.
- what happens
- Passkeys roll out for office staff, but branch staff and partners would hit the blocking prompt on different dates.
- what to do
- Contract a CYOT provider for the branch group only, test it in evaluation mode, and plan partners for the July wave. Swing each sync server to 2.6.92.0.
How Cohash helps
We start with an inventory: every sync server with its version, database and sign-in type, plus every user still enabled for SMS or voice. Then we upgrade staging first, switch each server to application-based authentication and plan the passkey rollout around your helpdesk. Our Microsoft Entra ID page covers the wider hybrid identity work, the identity and access management practice covers MFA and Conditional Access, and you can bring in engineers for the migration itself. If you'd like a second opinion first, ask for an assessment. Teams still moving scripts off user logins can read our guide to Azure mandatory MFA for automation.
What to take from this
- 01
Each sync server has to be on 2.6.84.0 or later and signing in with application-based authentication by 7 April 2027. Miss either and it stops syncing, and the first sign is usually a new starter who can't log in.
- 02
Auto-upgrade won't get you there. It stops at 2.6.3.0 and doesn't switch the sign-in, so upgrade by hand, run the wizard task on every server and confirm it says Application.
- 03
Install 2.6.92.0, not the 2.6.84.0 minimum, and upgrade the staging server first.
- 04
Microsoft's own SMS and voice codes stop for most users on 1 February 2027. There's no opt-out from that date, so move people well before it, not on the day.
- 05
Move most people to passkeys and keep your own telephony provider for the few who need texts.
01Does Azure AD Connect stop working in April 2027?
If a server isn't on 2.6.84.0 or later and signing in with application-based authentication by 7 April 2027, yes, it stops syncing. Microsoft's fix is to upgrade to the latest build and switch the sign-in, which you can still do after the fact. Any 1.x server you still have already doesn't sync, so look for those first.
02Which Entra Connect Sync version should we install?
Install 2.6.92.0. 2.6.84.0 is the minimum for the April rule, but it can fail to install over an existing database, and its own support ends on 16 September 2027. You'd just be upgrading again next year. Get the installer from the Entra admin center.
03Does auto-upgrade take care of this for us?
No. The last build released for auto-upgrade is 2.6.3.0, below the 2.6.84.0 floor, so every server needs a manual upgrade. Since 2.6.84.0, upgrades also leave an existing server on the Sync_ account. Run the wizard task on each server, then check that Get-ADSyncEntraConnectorCredential says Application.
04Do we have to move to Entra Cloud Sync instead?
No. Connect Sync is still supported if you keep it on a supported build. Microsoft does suggest checking whether Cloud Sync would do the job before you upgrade, and builds from 2.6.91.0 include a guided move to it in the public Azure cloud. If your setup is simple, run the assessment step and see what it finds.
05Will anyone get locked out on the day Microsoft's texts stop?
Microsoft says no. Users whose only method is Microsoft-sent SMS or voice get a blocking prompt to register a passkey before they can carry on. That prompt can't be skipped, so expect helpdesk calls from anyone without a suitable device.
06Can we keep SMS codes after 1 February 2027?
Yes, through Choose Your Own Telephony Provider. You subscribe to Soprano, Telesign or Infobip in Microsoft Security Store, host the integration in your Azure subscription and route users through it. You pay the provider and the Azure costs, and SMS can't be the first sign-in step.
07When do admins and guests lose SMS codes?
Global Administrators and external users keep Microsoft-sent codes until 1 July 2027. Internal guest users are in the 1 February 2027 wave. Move admin accounts to passkeys first anyway, since they're the accounts attackers want.
08Does the SMS change hit self-service password reset too?
Yes. Microsoft says the retirement covers self-service password reset as well as sign-in. Anyone who resets by text and has nothing else set up needs a passkey, an authenticator app or a slot on your own telephony provider before the cutoff.
Three questions, about a minute
Pick an answer and we'll tell you if it's right, and why it is or isn't. The score stays in this browser.
-
Q1You upgraded your sync server to 2.6.92.0 by hand last month and haven't touched it since. Is it ready for the April cutoff?
show the answer
B. Only once Get-ADSyncEntraConnectorCredential reports Application on that server Since 2.6.84.0, upgrades don't switch an existing server off the legacy Sync_ account. It needs the wizard task, and the credential type should read Application.
-
Q2Someone in accounts only has a text from Microsoft as their MFA method. What happens the first time they sign in after the SMS cutoff?
show the answer
C. They're asked to set up a passkey right there, and they can't skip past it Microsoft says anyone in the February wave whose only method is SMS or voice has to register a passkey during sign-in. The prompt can't be skipped, though nobody is locked out.
-
Q3Branch policy says tellers have to get their codes by text. What keeps them signing in once Microsoft stops sending its own texts?
show the answer
A. Contract a telephony provider through Microsoft Security Store and send their codes through it CYOT keeps SMS and voice working through a provider you contract. The opt-out only pauses the nudges, and enforcement has no opt-out.