I want to tell you about a security incident. The details are anonymised, but it happened at a Nordic company, and they have given me permission to share the broad outline.
It started with a contractor account.
The contractor had worked with the company for about a year, helping with a data migration project. Good work, no issues. When the project ended, the contractor's manager sent a mail to IT saying the engagement was finished.
IT disabled the contractor's laptop. Collected the access badge. Closed the ticket.
But nobody disabled the Active Directory account (which synced to Entra ID via Entra Connect). And nobody revoked access to the three SaaS applications the contractor had been using.
Eight months of nothing
For eight months, the account sat there. Active. Unmonitored. The contractor never logged in during that time. No suspicious activity. No activity at all.
Then the contractor's personal email was compromised in an unrelated data breach. The password they had used for personal accounts happened to be similar to the one they had used for work. Not identical, but close enough to guess from. MFA was configured on the Entra ID account, but the session had been set to "remember this device for 60 days," and the session tokens had never been revoked.
The attacker found the work credentials. Tried them. Got in.
What happened next
The attacker had the same access the contractor had when they were actively working. That included read access to a SharePoint site with customer project files, write access to a Teams channel that was still active (the team had never archived it), and admin-level access to an internal tool used for parts of the data pipeline.
The attacker was not particularly sophisticated. Opportunistic is more accurate. They looked around, found data worth taking, exfiltrated what they could, and moved on. The whole thing went on for about two weeks before someone noticed unusual sign-in patterns and raised an alarm.
The cleanup
The incident response was expensive. Not catastrophic for the company, but expensive.
They had to bring in a forensics firm to determine exactly what was accessed. They had to notify affected customers whose data had been on that SharePoint site. They had to review every account with similar characteristics — former contractors, former employees, stale accounts — to check for other exposure. Legal got involved. The board got involved.
Total cost, including forensics, legal, customer notifications, and remediation: somewhere between 200,000 and 300,000 EUR. For a mid-sized Nordic company, that is a painful figure.
All because one account was not disabled when it should have been.
The pattern I keep seeing
I have encountered this pattern so many times that it stopped being surprising. Not the breach itself (that was a worst case), but the conditions that made it possible.
When I look at companies' Active Directory and Entra ID environments, I almost always find accounts that should have been deprovisioned months ago. Former contractors, former employees, test accounts, demo accounts, accounts created for a specific project that ended long ago. In hybrid setups it is often worse, because a stale account in AD means a stale account in the cloud too, and people tend to only check one side.
Each one is a door nobody remembers leaving open.
The typical response is "those accounts are probably fine, nobody is using them." And in most cases that is true. Most stale accounts will never be exploited. But the argument is not about probability. It is about the effort involved. Disabling a stale account takes seconds. Dealing with the consequences of a compromised stale account takes months.
One rule would have stopped it
Here is what makes this story so frustrating: a single automated rule would have prevented the entire incident.
If the company had a rule that said "when a contractor engagement ends in the HR system, automatically disable the Active Directory account (which disables the synced Entra ID account) and revoke all application access," the account would have been deprovisioned on the same day the contractor left. No manual step. No reliance on someone remembering to file a separate ticket. No eight-month window.
The rule is not complicated. It does not need machine learning or a sophisticated security platform. It needs two systems connected with a simple trigger: status changes from active to terminated, account gets disabled.
That is the fix.
What you can do today
Open your Entra ID tenant. Filter for accounts that have not signed in for 90 days or more. Cross-reference that list against your current employees and active contractors.
Any accounts that do not match a current person should be disabled now. Not next week. Not during the next quarterly review.
Then set up the automation so it happens on its own going forward. Whether you use Entra ID Lifecycle Workflows, a dedicated identity governance tool, or even a scheduled script that checks HR status against account status. The method matters less than the outcome.
The fixes are almost always simple. The consequences of not applying them are not.