Entry is not the same as damage
An unpatched server gives an attacker one server. That is a bad day. It is a contained bad day.
A privileged identity is different. Cloud security is usually drawn as separate areas — identity, network, encryption, logging, backup, incident response. Each one gets its own tool, its own budget line, sometimes its own team. A sufficiently privileged identity can touch all of them from one place.
Here is what that means in practice. An identity with enough permissions can:
- Turn off log collection and delete the audit trail
- Open firewall rules and remove network segmentation
- Grant itself decryption rights over data it was never meant to read
- Revoke the access of the people who would respond to the incident
- Switch off the policy guardrails and suppress the compliance findings that would have flagged any of this
- Delete or encrypt the backups before anyone reaches for them
Every one of those is a control someone paid for. Every one of them can be switched off by something that is already inside and already trusted.
This does not mean the other areas do not matter. It means identity needs attention first, because of how far it reaches once it is compromised.
Only the first step is a break-in
I find it useful to lay out the sequence, because the shape of it surprises people.
- A privileged identity is compromised
- Logging and monitoring are disabled
- Alerts and detections are silenced
- Identity and network rules are rewritten
- Data is taken, and a way back in is left behind
Step one requires a way in. Steps two through five do not. They are not new attacks. They are the permissions that identity already held, used exactly as the system was told to allow.
That is what makes it hard to detect. Nothing anomalous happens. An account that is permitted to change logging configuration changes the logging configuration. The system does what it was designed to do.
The most common example is an IAM role or even worth an IAM user that is used by the continuous integration tool. In case if a user is used its credentials are saved in the “hidden” CI variables. The keys can be easily revealed. If the keys rotation is never done the keys can later be used for accessing cloud infrastructure by an attacker. As far as the role or the user are considered as secured (people do not use them) the cloud administrators are giving them the Admin permissions that increases the blast radius.
Why this shows up in the cost numbers
There is a second-order effect, and it appears in the money.
IBM’s 2026 report puts the average time to identify and contain a breach at 247 days — which reversed several years of steady improvement. Breaches that ran past 200 days cost an average of $5.65 million. Those contained sooner averaged $4.32 million.
I want to be careful here. That is an association between duration and cost, not a controlled comparison. Longer breaches are probably also worse breaches in other ways.
But the direction is not really in doubt. And an identity that can switch off your detection is an identity that keeps that clock running.
What this changes about where you look
If entry frequency were the right measure, the answer would be simple: patch faster. That is good advice and you should do it.
But if reach is the measure, the question becomes different. Not “how did they get in” but “once someone is in, how far can they go, and what can they turn off on the way?”
That question has an answer in your account today. It is sitting in your permissions, and it is knowable.
Which is why I keep asking people six questions:
- How many identities are in your cloud, in total?
- How much external trust do you have?
- How many identities are dormant?
- How many service account keys exist?
- How many of those are unused?
- How many admin identities do you have?
Most security leaders I ask can answer one or two. Getting all six usually takes days, and by the time the answers arrive they have moved.
In the last environment I audited I found more than 1300 cloud Service Account keys, more than 700 of them weren’t used. We removed them without any service disruptions.
What I am not saying
I am not saying your tools are bad. AWS IAM Access Analyzer will find external access at no charge and unused access for twenty cents per identity per month, and it is good at it. Most of the accounts I look at have it available.
The problem is not that nobody can find this. It is that finding it produces a list, and a list needs a person — someone who understands entitlements, has the time this quarter, and can explain to a board what changed.
At a company of five hundred or two thousand people, that person usually does not exist. Not because anyone made a bad decision, but because cloud identity ended up as part of three different jobs and the whole of nobody’s.
That is the gap I work on.
