Your service accounts are the breach you haven't found yet

Ask a room of security leaders how many human accounts they have. Most can answer to the hundred. Ask how many service accounts — the non-human identities that run jobs, move data, and talk to APIs — and the room goes quiet.

That silence is the problem.

Service accounts accumulate. A vendor integration here. A migration script there. A scheduled task someone set up in 2021 and left running. They rarely get offboarded, they almost never rotate credentials, and they hold standing privilege that would make a domain admin blush. Worst of all, no single person owns them. They are infrastructure, and infrastructure is somebody else’s job.

Attackers know this. An identity with high privilege, no MFA, a password that has not changed in three years, and no human watching its behaviour is not a hard target. It is the path of least resistance. This is not a sophistication story. It is a deferred-maintenance story — a known gap, left open because closing it is tedious and nobody’s KPI.

What this changes for you

Stop thinking of identity threat detection as a tool you buy. Think of it as answering one question: who can do what, and would we notice if they suddenly did something different? For human accounts you probably have some answer. For service accounts, you likely have none — and that is where the attack will come from.

One thing to do before Monday

Pull a list of every non-human identity with privileged access. Then sort it three ways:

• Last credential rotation. Anything older than a year is a finding.
• MFA or conditional access coverage. Most service accounts have neither. Note which ones genuinely cannot take it, and which ones simply never had it applied.
• Owner. Not the team. A name. If you cannot put a name next to an account, you have just found the riskiest entries on the list.

You will not fix it this week. But you will know the size of the problem — and that number is the one to put in front of the board, because they have never seen it.