This post explains why cleaning up a hybrid Active Directory and Microsoft Entra ID environment is a security project rather than routine administration, and why the organizations treating it as housekeeping have been accumulating risk against a platform that kept moving. It covers the hard deadline arriving at the end of this month, what actually accumulates in a long-lived directory and why each item is dangerous, what Microsoft lets you detect and which licensing tier each detection sits behind, where the tooling stops and human judgment has to take over, and the sequencing mistakes that turn a cleanup into an outage. If you run accounts on-premises and synchronize them to the cloud, the first section is time-critical.
First, the Deadline at the End of This Month
Before anything else in this post, check what version your sync server is running.
Microsoft’s documentation carries a mandatory upgrade notice: all synchronization services in Microsoft Entra Connect Sync will stop working on September 30, 2026 if you are not on at least version 2.5.79.0. The version was released in May 2025 with a back-end service change that hardens Microsoft’s services. If you cannot upgrade before the deadline, all synchronization services will fail until you do.
Read the verb. Not lose support. Fail.
This is not a support policy change with a grace period attached. It is a back-end service change, and the documented outcome is that synchronization stops. New starters do not appear in the cloud. Leavers stay enabled. Password changes stop flowing. Group membership drifts. Everything that quietly depends on directory sync being current stops being current, and in most organizations nobody notices for days.
One nuance worth knowing so you do not do the job twice. Version 2.5.79.0 is the floor, not the destination. Its own support ends October 23, 2026, three weeks after the cutoff. Go to the current release rather than to the minimum.
Many tenants are already fine, because automatic upgrades have been available for years. But automatic upgrades do not always complete, and organizations that opted out or blocked them will not know until sync stops. Checking takes minutes. The alternative is an identity outage discovered by a user.
Checking your sync version takes minutes. An identity outage discovered by a user doesn’t.
We can confirm your Entra Connect Sync version and get you current before September 30, not just past the minimum.
Why This Is a Security Project, Not Housekeeping
The deadline above is the urgent item. The rest of this post is the important one, and it rests on a belief worth dismantling: if an account has not caused a problem yet, it is harmless.
That gets the logic exactly backwards. A dormant credential is a valid credential that nobody is watching.
Think about how detection actually works. Monitoring flags deviation from a baseline. An active user has a baseline: where they log in from, at what hours, against which systems. An account nobody has used in two years has no baseline at all, so there is nothing for anomalous activity to look anomalous against. An attacker who obtains that credential through password spray, a prior breach dump, or phishing does not trip the signals a security team associates with a compromised user, because there is no normal to deviate from.
Microsoft’s own guidance states that inactive accounts represent a security risk and that cleaning up unused or over-privileged accounts should be a priority to reduce security risk.
And Microsoft treats this as a security control rather than tidiness in the product itself. Defender for Identity ships posture assessments named for exactly these problems: removing stale Active Directory accounts, removing stale service accounts, and dormant entities in sensitive groups. Each carries a stated security impact. Identity cleanup actions carry score value in Identity Secure Score.
Which matters for how the work gets funded. Housekeeping competes for attention with every other backlog item and loses. A security control with a documented posture assessment behind it is a different conversation with a different budget.
On why identity specifically: Microsoft reports that customers face more than 600 million identity attacks every day, that password-based attacks make up over 99 percent of them, and that it blocked 7,000 password attacks per second over the past year. Microsoft also states that multifactor authentication can block more than 99.2 percent of account compromise attacks.
The mechanism underneath those numbers is simple. A valid credential bypasses perimeter controls entirely. The attacker logs in rather than breaks in. If that credential belongs to a dormant or service account excluded from MFA and outside monitoring, there is no second factor to stop it and no behavioral baseline to alert on.
What Accumulates, and Why Each Item Matters
Former Employees Who Are Only Half Gone
Disabling an on-premises account does not automatically revoke cloud sessions, tokens, or licenses. So a leaver can be disabled in Active Directory on Friday and still hold an active licensed cloud identity with valid refresh tokens on Monday. Lifecycle workflows automate leaver deprovisioning properly, but they sit behind Entra ID Governance licensing. Without that automation, the gap between disabled and actually gone is manual, and manual means inconsistent.
Inactive Service Accounts, Which Are the Hardest Item
Microsoft’s own posture assessment states that unused service accounts create significant security risks because some carry elevated privileges, and that stale service accounts might retain high or legacy permissions.
It also names why they are uniquely difficult: service accounts are not tied to a specific user and often lack interactive monitoring, so malicious activity performed under them might go unnoticed. Add the common configuration of excluded from MFA, non-expiring password, and interactive sign-in rights they never needed, and you have a credential with privilege, without a second factor, and without an owner.
Defender for Identity now discovers these automatically, identifying group managed, standalone managed, and user accounts that carry a service principal name and a password that never expires, then presenting them as an inventory with their authentication protocols, sources, destinations, and criticality. That closes the discovery half of the problem. It does not tell you what any of them are for.
Privilege That Was Granted Once and Never Removed
Roles granted for a one-off task become permanent. Nested group membership means a user can inherit privileged access through a chain nobody has audited. Standing assignments stay active around the clock whether or not anyone is using them.
Privileged Identity Management converts standing roles into eligible ones that must be activated, are time-bound, and can require approval. It requires Entra ID P2 or Entra ID Governance.
The Synchronization Bridge Itself
This is the item most often left out of a cleanup scope, and it is the one with the largest blast radius.
The sync account is the crux. An express installation scopes the on-premises connector account to the whole forest, which is more permission than the job needs. In password hash synchronization mode that account can read credential material, which makes the sync server a tier zero asset whose compromise can bridge from on-premises to cloud regardless of what cloud controls are in place.
Microsoft has been hardening this directly, and two enforcement dates have already passed. Since June 1, 2026, Entra ID blocks Connect Sync or Cloud Sync from hard-matching a new Active Directory user object to an existing cloud-managed Entra object that holds Microsoft Entra roles. Since July 1, 2026, Entra ID enforces broader hard-match security hardening automatically, blocking the match where the target cloud user already has an on-premises object identifier set, holds a privileged role, or is eligible for one.
The attack this closes is real and named. Manipulate the right attribute on an on-premises object you control, and a legitimate sync operation hands you a privileged cloud account. That is why the enforcement is cloud-side and applies regardless of client version.
The practical consequence for anyone planning identity work: legitimate migration and re-anchoring operations that used to work now fail, and they fail in the middle of a project rather than in planning.
What You Can Detect, and What Detection Costs
Most of what you need exists natively. The catch is that the useful detections sit behind licensing tiers, and one default will quietly cost you an investigation.
That default is log retention. Sign-in and audit logs are kept for 7 days on the free tier and 30 days on P1 and P2. Risky sign-in data runs 7, 30, and 90 days across free, P1, and P2. The part that catches people: retention changes are not retroactive. Upgrading your licensing does not recover data that has already expired. If an investigation starts two months after the event, the record is gone unless logs were being exported to Log Analytics all along.
Which is why exporting logs is the first thing to do in any identity program, before any cleanup. Every day of delay is a day of forensic history you cannot get back.
One detail worth knowing about inactivity, because it produces false confidence. There is no built-in inactive user report. Inactivity is derived from the last sign-in date, and non-interactive sign-ins from background service authentication can make an account look active when no human has touched it in years. Interactive sign-in has to be examined separately or the report will reassure you about accounts that are genuinely abandoned.
Want the specific list, not just the categories?
A hybrid identity assessment shows you exactly which accounts, service principals, and standing roles are exposed in your tenant — and whether your log retention would actually support an investigation today.
What Goes Wrong When Organizations Do This Themselves
Almost every failure in this work is a sequencing failure rather than a technical one.
Enforcing controls before mapping dependencies. Turning on MFA or a Conditional Access policy before you know which service accounts and applications depend on the old behavior is the classic self-inflicted outage. Microsoft’s own mandatory MFA enforcement for Azure resource management operations began in October 2025 and covers command line, PowerShell, and infrastructure-as-code tooling. User-based service accounts doing resource management work are in scope and can break.
Deleting the on-premises source of a synced object. For a synced user, Entra ID is not the source of authority. Delete the on-premises object and the cloud object is soft-deleted at the next sync cycle, recoverable for 30 days if the Active Directory Recycle Bin is enabled and the source anchor is preserved. Recreate the on-premises object without the same source anchor and you do not restore anything. You create a brand new cloud object, and the licenses, group memberships, and access assignments attached to the old one are orphaned.
Removing privilege without a way back in. Removing standing access before break-glass accounts are configured and excluded can lock administrators out of their own tenant.
Cleaning up in the wrong order generally. Disable before deleting. Treat the 30-day soft-delete window as a deliberate hold rather than a countdown. Nothing on this list is difficult, but the cost of getting it wrong is asymmetric: a cautious cleanup takes a few extra weeks, and an incautious one takes out a business process nobody documented.
Where to Start
Check your sync version today. That one has a date on it and everything else can wait behind it.
Then start exporting sign-in and audit logs somewhere with real retention, before you touch anything. Cleanup without history is cleanup you cannot audit afterwards, and the default window is shorter than most investigations.
Then inventory rather than remediate. Run service account discovery, because that is consistently the hardest gap and the one organizations cannot close by hand. Pull standing privileged assignments. Identify accounts with no interactive sign-in, and treat that as a list of questions rather than a list of deletions.
Remediate in dependency-safe order after that: map what a service account touches before enforcing anything on it, convert standing roles to eligible ones, review privileged group membership, and bring the sync account down to least privilege.
Then automate the part that regenerates the problem. Leaver deprovisioning done by hand will drift again within a year, which is how the estate got here in the first place.
WME runs hybrid identity assessments covering account and privilege inventory, service account discovery, sync configuration hardening, and a remediation plan sequenced so that nothing breaks on the way.
A dormant credential is a valid credential that nobody is watching.
WME runs hybrid identity assessments covering account and privilege inventory, service account discovery, sync configuration hardening, and a remediation plan sequenced so that nothing breaks on the way.
