Microsoft shipped a security update for Entra Connect Sync on July 7, 2026, that breaks unattended PowerShell automation by requiring an interactive administrator sign-in whenever a script tries to change cloud-side synchronization settings. The new version, 2.6.84.0, introduces hardened authentication for sensitive configuration operations—a welcome security boost that also demands immediate attention from IT teams that rely on set-and-forget identity management runbooks.

What actually changed in 2.6.84.0

The update, pushed through the Microsoft Entra admin center, overhauls how Entra Connect authenticates when altering cloud configuration. Previously, cmdlets like Set-ADSyncAADCompanyFeature and Set-ADSyncAADPasswordSyncState could modify cloud-side settings without a live administrator present, using stored service credentials or inherited execution context. Microsoft now mandates interactive MSAL (Microsoft Authentication Library) authentication for such writes.

In practice, those two cmdlets now require an explicit -AADUsername parameter that triggers a human sign-in prompt. No pop-up, no change. The requirement extends to the Connect wizard’s cloud operations and—critically—to the uninstaller, which now demands administrator authentication before cleaning up cloud resources. If you skip the sign-in during uninstall, local components are removed, but Entra ID-side configuration remnants may persist.

Regular directory synchronization remains untouched. The scheduler and delta imports/exports that keep on-premises Active Directory in step with Entra ID continue to run silently. End users see no difference in sign-in behavior. Only the configuration plane—enabling, disabling, repairing, or removing sync features—is now guarded by interactive sign-in.

Another behavioral shift targets Password Hash Synchronization (PHS). PHS no longer self-heals its cloud feature flag if someone disables it. Earlier versions would quietly re-enable the flag in the background; version 2.6.84.0 leaves it off until an administrator explicitly turns it back on—again, with interactive authentication.

What it means for you

IT administrators and identity engineers

The change directly hits any environment where Set-ADSyncAADCompanyFeature or Set-ADSyncAADPasswordSyncState is called from unattended scripts, scheduled tasks, orchestration tools, or break-glass recovery procedures. Overnight password sync re-enablement, automated disaster recovery runbooks, and configuration-as-code pipelines that touch cloud-side Entra Connect settings will now stall mid-execution, waiting for an interactive login.

Even routine upgrades can hit a snag: a perfectly timed maintenance window may stall because the operator doesn’t have an account authorized to authenticate to Entra ID for the cloud-config portion of the upgrade. And when retiring a Connect server, a split outcome is possible—local uninstall succeeds but cloud cleanup doesn’t—leaving stale configuration objects in the tenant unless someone explicitly signs in.

Home users and small businesses

No direct impact. Home users don’t run Entra Connect. Small businesses using Microsoft 365 with simple sync setups likely interact with these settings only through the wizard, which now simply prompts for credentials where it didn’t before. As long as someone with appropriate Entra ID permissions is available during configuration changes, the impact is minimal.

Developers and automation engineers

Any CI/CD pipeline or infrastructure-as-code stack that manages Entra Connect configuration through PowerShell must be rearchitected. You can no longer treat cloud-side settings as fully automatable without a human in the loop. Automation can still prepare changes, detect drift, and verify outcomes, but the final write now demands an authenticated administrator.

How we got here

Microsoft has been progressively hardening on-premises identity infrastructure against token theft and unattended privilege abuse. The July 2026 update follows a broader push toward phishing-resistant authentication and away from persistent stored credentials. The new interactive requirement effectively kills a dangerous attack path: if an adversary compromised a Connect server, they could previously alter sync features without any additional authentication challenge. Now they must also have valid interactive credentials for a privileged account.

The change also aligns Entra Connect with Microsoft’s Secure Future Initiative principles, which favor human approval for sensitive operations. It is not unlike moving service accounts away from write access to high-value cloud configuration and toward a just-in-time approval model.

Earlier WindowsForum coverage highlighted risks like SyncJacking and urged tighter on-premises mapping controls. Version 2.6.84.0 directly addresses the cloud side of that coin: sensitive cloud writes are no longer possible from a background process alone. The removal of PHS self-healing—though disruptive—sits in the same camp. It eliminates a scenario where an accidentally or maliciously disabled feature could silently return, confusing auditing and compliance.

What to do now

Microsoft recommends upgrading to 2.6.84.0 “as soon as possible” for its security fixes. The real prep work, however, happens before the upgrade. Here’s a step-by-step plan:

  1. Inventory everything that touches these cmdlets. Search all PowerShell repositories, deployment shares, scheduled tasks, RMM platforms, and admin workstations for any script that calls Set-ADSyncAADCompanyFeature or Set-ADSyncAADPasswordSyncState. Don’t forget incident response runbooks and failover automation.

  2. Identify which scripts actually modify cloud configuration. Many scripts use these cmdlets to simply query state—those are unaffected. Flag only the ones that write settings (e.g., enabling a feature, changing PHS state).

  3. For every affected script, add and test the -AADUsername handling. This means rewriting the command to include the parameter and ensuring the execution context can pop an interactive authentication prompt. Test in a staging environment with a real sign-in. A syntax check isn’t enough—the script must demonstrably complete the cloud write after an administrator authenticates.

  4. Reassess scheduled and unattended workflows. Any job that runs without an administrator physically present cannot reliably complete a cloud-config change after the upgrade. Options:
    - Split the workflow: let automation detect drift and open a ticket, then have an engineer manually run the write.
    - Re-route alerts to trigger an on-call admin action, with clear documentation on who can authenticate and from where.
    - For environments with 24/7 operations center, schedule configuration changes during staffed hours.

  5. Update incident and disaster recovery docs. For break-glass scenarios where you might need to re-enable PHS or toggle a sync feature, explicitly note that an authorized admin must sign in interactively. Record which accounts have the necessary Entra ID roles and ensure they are reachable during an incident.

  6. Test uninstall and retirement procedures. Perform a dry run on a staging server. Confirm whether cloud cleanup completed by inspecting the Entra admin center afterward. Update your decommissioning runbook to include a post-uninstall cloud verification step and, if needed, a manual cleanup instruction.

  7. Adjust monitoring. After upgrading, monitor that PHS remains enabled (if you use it). Automate checks for the cloud feature flag and alert if it goes dark, but remember: repair still requires an interactive admin. Your monitoring can now safely verify the intended state without a stealth re-enablement confounding the picture.

  8. Upgrade. Once scripts and procedures are updated, apply the new version. Test a representative cloud-config change during a maintenance window to confirm the flow works end to end.

Avoid the knee-jerk reaction of delaying the update indefinitely. The security improvements are real, and the script refactoring, while tedious, isn’t technically complex. The faster you adapt, the sooner you gain the security benefit and the predictable administrative state.

Outlook

Microsoft’s direction is clear: high-privilege actions that could compromise identity infrastructure will increasingly require active, authenticated human involvement. Expect future Entra Connect releases to extend interactive gates to more cmdlets or to plug similar automation loopholes. The team that reworks its automation now—separating detect-and-report from execute-and-change—will be better positioned for whatever comes next. Meanwhile, independent monitoring and drift detection remain valuable; they just won’t silently fix things anymore. That’s the new normal, and it’s a net positive for security.