Every forced platform migration leaves behind non-human identities that still hold full permissions but no longer do anything. Here is why that keeps happening, and what has to be true before you can safely turn any of them off.
The short version
- A ghost NHI is a non-human identity that retains its permissions after the system it was created to access has been retired. It is dead, and it is not gone.
- Microsoft has forced at least one identity-affecting migration every 12 months since 2022. Basic Auth, Azure AD Graph, legacy Exchange tokens, ACS, and now EWS. See the timeline below.
- The EWS deadline is more urgent than most teams think. The allow list has to be configured by the end of August 2026, not April 2027. Disablement begins October 1, 2026.
- The five questions come in a fixed order: visibility, ownership, intent, business impact, risk. Most organizations answer them out of order, or not at all.
- The tool is only the first step. Nothing will ever tell you what an identity was created to do. Behavioral visibility tells you what it is doing, which is the input every one of those five questions depends on.
There has not been a 12-month window since 2022 where a migration wasn’t forced on us by one of the three major providers. ACS was this past April. EWS is the one sitting on your desk right now. There will be another one after that.
I did not see that pattern for a long time. I was sitting in a practitioner functional role, being told what to do, and then every six months being told I had to do this thing again. That keeps you in a specific mindset. You are staring at your monitor working the ticket in front of you, and you do not have the visibility your leadership has. It took getting out of that siloed seat and looking at a grander scope before I understood that this is an industry norm and not a run of bad luck.
That distinction matters more than it sounds like it should, because it changes what you go build.
A migration is not a cleanup, it’s a change
People like to think of these as cleanups, and in fairness they do decrease tech debt and they do add capacity as technology evolves. But at the basis of it, a migration is a change. You are changing from one system to another, from one product to another, or from one version of the same product to another version of the same product.
It is daunting because it is usually a lot of work. It is usually a lot of work because most teams have not taken the mindset of solving this problem forever. The thinking is: get through this migration, then get on with the rest of our lives. So nothing continuous gets built, and the next one lands on a team with the same gaps it had last time.
You cannot budget for something you will not admit is recurring. You cannot plan for it either. You cannot be proactive if you do not believe there is a trend.
It is not that teams and leaders are not thinking about migrations. They are thinking about the one in front of them. What is missing is the work that has to happen in advance of the next one, and the one after that. If I know exactly what problem I have, getting a tool is a matter of convincing whoever holds the money to let me do it, and the people in these roles are very good at that.
The gap sits upstream of the budget conversation. As long as a migration is treated as six months of work followed by six months of quiet, nobody is going to build for the next one before it lands.
Why legacy service accounts become unownable
The legacy NHI problem was already there before the migration showed up.
Service accounts have existed for 15, maybe 20 years. Tokens have been around at least that long, and letting those tokens keep doing what you told them they could do is generally good for productivity. That is not the problem.
The problem is what happens once the owners cycle out. Once the people who had the context, the purpose, the intent, the actual knowledge of what this thing was built to do are gone, what happens to those non-human identities?
When I was in cloud IAM at CVS, I dealt with millions of service accounts. That is not an overstatement. They existed and they were doing things that needed to be done. I have to catch myself there, because I was about to say they would not be doing things that were not needed, and that is exactly the assumption that gets people in trouble. A lot of them are probably not doing anything at all anymore, and nobody knows.
As the years pass, the documentation gets worse. The general knowledge of what these identities are doing gets worse. The questions only expand:
- What is it actually doing?
- Can we do anything with it?
- Do we just leave it?
- What happens if we turn it off?
- Does anybody here own it?
The answers get blurrier every year, and if nobody has evidence, you cannot act. You get frozen in fear. Without something watching the behavior of the identity, there is no way out of that.
Then migrations land on top of it. The products these identities were created to talk to get deprecated, and once that happens you cannot even go look at what they were doing. Maybe they still work. Maybe they do not. You cannot determine which without a tool that can see it.
What the ACS retirement actually left behind
On April 2, 2026, Microsoft fully retired Azure Access Control Service for SharePoint Online. It had already been unavailable to new tenants since November 1, 2024. There was no extension. They have since moved to a newer and better model.
Here is what the process looked like in practice:
- First, they asked for a list of the identities that would be affected. If you gave them one, they did what they could with it.
- Then they inferred what they could on their side about which identities the change would touch.
- Come April, they turned it off.
If your list was incomplete, or if theirs was, you now have fully privileged service accounts living inside your environment that are no longer doing anything at all. And if you are not watching activity, you cannot see that. They are ghosts. They are dead, and they are not gone.
Something like this has happened every 12 months for four or five years running.
EWS is not special. It is just next.
EWS is the one everybody is talking about now, and the reason is timing. But the timeline is more compressed than the headline date suggests, and this is worth getting exactly right:
- End of August 2026: your allow list has to be in. Get it in on time and you skip the October cutoff entirely.
- October 1, 2026: Microsoft starts switching EWS off. If you missed the list, your apps stop working. You can get access back after this, but not without an outage.
- April 1, 2027: gone permanently. No exceptions, no getting it back.
I do not think EWS is special. It is special because it is new, and it is the thing you have to deal with right now. Beyond that, it is the next forcing function in a trend that has been running for years and is only going to accelerate as the timelines get shorter.
Can you see how this continues to compound? It just does not end.
The five questions, in order: visibility first, risk last
Every time one of these hits, the same sequence of questions has to get answered, and most organizations are answering them out of order or not at all. The order is not arbitrary. Each one is unanswerable until the one before it is done.
- Visibility: what exists? Do you know what non-human identities live inside your organization? A lot of companies have spent real money and real effort on controlling what gets created, and some of them are very good at it, but it is close to impossible to be 100% sure unless something is watching for it specifically.
- Ownership: who is accountable? This only becomes answerable once you have visibility. If an NHI has existed for 10 years and nobody is tied to it, what do you do? Maybe it has an owner and that owner has moved into a role where they no longer have any context on it. That is common.
- Intent: what is it doing? Not just that the identity exists, but what it is doing and where that sits in the business.
- Business impact: what breaks? If you shut it off, how does that affect the rest of the ecosystem? You have to make that call for every single identity in scope for the migration, which is why this takes so many hats.
- Risk: what are you accepting? If we turn this thing off and it breaks and nobody in North America gets paid, is that okay? That is not a question an engineer should be answering alone. Leadership has to be in that conversation.
The hats this requires almost certainly already exist inside your organization. They just have to be put in a different order for this problem than for the ones your team is used to.
The tool is only the first step
Nobody is ever going to be able to tell you what your NHI was created to do. That is a question you will always have to answer yourself. That is not a flaw in any product, that is just technology.
So the operating model matters as much as the tooling. You can have the smartest people on the best team, and without the tools and without the model behind them, you are going to have six-month headaches every year for the rest of your career.
On the tooling side, I understand the skepticism. Behavior analytics carries a stigma because it was not what everybody hoped it would be when it first showed up 15 years ago. SIEMs are noisy, and even with all that noise they do not give you visibility into everything. Both of those objections are earned. What has changed is that newer behavioral tools can actually show you what the identities living in your ecosystem are doing, which is the input every one of those five questions depends on.
Is this a new compensating control?
A compensating control is a fancy way of saying a tool fills a gap you are already liable for. This is a framing we’ve been hearing from several security leaders.
They are not scoping a behavior analytics tool as a line item on the next migration. They are scoping it as the control that covers a gap they cannot close with people or process, because no amount of headcount is going to tell you what an identity nobody owns has been doing for the last two years.
The value of that control is not limited to migration season, which is the smallest version of it. What it gives you is a standing answer to what every identity in your environment is actually doing, human and non-human, on a normal Tuesday.
Once you have that, three things get easier at the same time:
- You can separate live identities from dead ones. Which ones are still doing real work, and which ones stopped months ago without anybody noticing.
- You can detect drift. When an identity that has behaved one way for two years starts behaving differently, you see it.
- You can build a defensible deprecation list instead of a list of accounts nobody is willing to touch.
That is the difference between reacting and being ready. The next forced migration becomes a filter you run against something you already have rather than a discovery project you start from zero. And when an audit turns up hundreds of fully permissioned NHI sitting in your environment doing nothing, you are not finding out at the same time the auditor does.
And the next set of identities coming into your environment is not going to make this easier. AI tools and agents authenticate with real credentials and real permissions, and they act at speeds no human owner is reviewing. Same inherited entitlement problem, moving faster.
Then you wait for the next migration.
