Identity Creep: You'll Never Reach Least Privilege, So Instrument the Blast Radius

In 2021, attackers walked into Colonial Pipeline through an old VPN account nobody used and nobody had turned off. No exploit, no zero-day. A valid credential attached to standing access that should have been revoked months earlier. The account had no MFA because nobody remembered it existed.

That is not a story about VPNs. It’s a story about identity creep: access that accumulates and never gets removed, until an adversary finds the part of it you forgot about. It is the single most reliable way into an organization that exists today — identity weaknesses played a role in roughly 90% of Unit 42’s 2026 incident investigations [1], and compromised privileged credentials were central to 89% of major enterprise breaches analyzed in 2025.

Here’s the uncomfortable part: you are not going to fix this by getting better at least privilege. The numbers say you’re losing that race, and the structure of how organizations operate guarantees you’ll keep losing it. So the detection question isn’t “how do we eliminate the blast radius.” It’s “how do we instrument it, so we know the moment someone steps on the part we should have cleaned up.”

---

Why It Accumulates — and Why Governance Is Losing

Identity creep is not negligence. It’s the exhaust of normal operations. Someone gets onboarded with a role template that’s broader than their job. They change teams and keep the old access alongside the new. A break-glass permission gets granted during an incident at 2am and never revoked. A role gets copied wholesale because it “worked for the last person.” A vendor gets access for a project that ended a year ago. Every one of those is a reasonable business action in the moment. Together they produce a permanent, growing surplus of access.

The data on how much surplus is stark. Across one large cloud dataset, of more than 51,000 granted permissions, only 2% were ever used — the other 98% sat dormant. Over 90% of identities use less than 5% of the permissions they hold. Roughly 92% of identities are over-permissioned and 62% are dormant. Veza found 3.8 million dormant accounts across its dataset — 38% of all identity provider users — still authenticating with no activity for 90-plus days [2].

And the trend line is the wrong direction. Permissions classified as safe and compliant fell from 70% in 2024 to 55% in 2025, while ungoverned permissions rose from 5% to 28% of the total [2]. That is what losing looks like: the cleanup is not keeping pace with the accumulation, and the gap is widening year over year. Access reviews are quarterly; access grants are continuous. The math doesn’t close.

This is why “just enforce least privilege” is not a plan. Least privilege is asymptotic — you approach it, you never arrive, and the residual you never quite reach is exactly the standing access an attacker inherits when they compromise an identity. Governance shrinks the blast radius. It does not eliminate it, and right now it’s not even keeping it from growing.

---

Creep Is a Non-Event

Here is why this is a detection problem and not just a governance problem — and why most detection programs are blind to it.

Privilege accumulation produces no signal. Think about what a detection engineer keys on: events. A login, an API call, a process spawn, a grant. Creep is the absence of an event — the revocation that never happened. There is no log line for “this permission was granted eight months ago and has been sitting unused ever since.” Nothing fires. The blast radius grows silently, by definition, because growth here means a thing that should have happened didn’t.

That makes it invisible in exactly the way the detection funnel is invisible: your coverage report shows green because there’s nothing to alert on. A dormant over-privileged account is not a misconfiguration that trips a scanner once and gets fixed. It’s a steady-state condition that looks identical to a correctly-provisioned account right up until it’s used by the wrong person. Attackers understand this better than defenders do: dormant accounts don’t generate the activity that active accounts do, so a compromise of one produces no anomaly against its own baseline — there is no baseline. Compromise of a dormant admin account routinely goes undetected for weeks or months for precisely this reason.

So if accumulation itself is undetectable, what can you detect? Two things: the moments the blast radius grows in a way that bypasses your controls, and the moment someone uses the part of it that should have been gone.

---

“Isn’t This Just a Governance Problem?”

The strongest objection: this is an IAM hygiene issue, and the answer is CIEM, identity governance, and access reviews — not detection. If you right-sized permissions and deprovisioned on schedule, there’d be no blast radius to instrument. Detection here is treating the symptom while ignoring the disease.

In theory, yes. In practice, the 92%-over-permissioned number is the disease winning. Every organization quoting that statistic has a governance program. They have IGA tooling, they run access reviews, and they are still at 92% with the safe-permission share dropping. That’s not an argument that governance is useless — it’s necessary, and you should do all of it. It’s an argument that betting your security posture entirely on prevention, in a domain where prevention is empirically and structurally losing, leaves you blind on the day prevention fails. And it fails constantly: that’s what 27% of 2024 cloud breaches involving dormant credentials means.

Governance and detection are not alternatives here. Governance shrinks the surface; detection covers the surface governance can’t reach. The standing access you’ll never fully eliminate is not a reason to stop doing governance — it’s the precise thing detection exists to watch. Treating it as governance-only is how the residual becomes a breach.

---

Detectable Signal #1: The Out-of-Band Grant

Raw grant events are noise. A normal organization grants permissions constantly, and alerting on “a permission was added” will bury you — which is the right instinct behind the objection that “these could all be normal.” They can. The signal isn’t the grant. It’s the path the grant took and the scope it carried.

The high-fidelity version is the out-of-band grant: a sensitive permission added through a channel that bypasses your provisioning pipeline. If your access changes are supposed to flow through Terraform, an IGA workflow, or a ticketed pipeline — and in a Detection-as-Code shop they should — then a privileged grant that appears directly in your cloud audit log, issued by a human principal clicking in the console or hitting the API, is by definition out-of-band. It skipped the control. That’s not churn; that’s the one grant in ten thousand worth waking up for.

Three patterns carry real signal:

• Privileged scope via a direct path. AttachUserPolicy or PutUserPolicy attaching AdministratorAccess, made outside the IaC pipeline. AWS’s own guidance flags self-attachment of admin policy as a top escalation indicator.
• Grants to anomalous principals. An external user invited as project owner; a service account granted sensitive permissions it never had. GCP’s built-in IAM Anomalous Grant finding keys on exactly these — external-owner invitations and service-account sensitive grants.
• Self-granting and grant-to-create. An identity expanding its own permissions, or creating access keys for another user (CreateAccessKey for a different principal) — classic T1098 account manipulation.

# Detection rationale: in a Detection-as-Code / IaC-governed environment, all
# legitimate privileged grants flow through the provisioning pipeline (a known
# automation role/principal). A sensitive policy attached directly by a human
# principal is out-of-band — it bypassed the control path. High signal because
# the denominator is near zero once your pipeline owns provisioning.
title: Out-of-Band Privileged IAM Grant (Bypassed Provisioning Pipeline)
status: experimental
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName:
      - 'AttachUserPolicy'
      - 'PutUserPolicy'
      - 'AttachRolePolicy'
    requestParameters.policyArn|contains:
      - 'AdministratorAccess'
      - 'PowerUserAccess'
      - 'IAMFullAccess'
  pipeline_principals:
    # ARNs of the approved IaC/IGA automation that SHOULD make grants
    userIdentity.arn|contains:
      - ':role/terraform-provisioning'
      - ':role/iga-access-workflow'
  condition: selection and not pipeline_principals
falsepositives:
  - Break-glass admin actions during a declared incident (correlate to the
    incident window and the documented break-glass identity)
  - A new provisioning automation principal not yet added to the allowlist
level: high
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1098

The reason this works is the same reason DaC works: once provisioning is code, anything that isn’t code stands out. Your false-positive denominator collapses, because legitimate grants don’t show up here — they show up as pipeline runs.

---

Detectable Signal #2: The First Footstep on Dormant Privilege

The second signal is the one the Colonial Pipeline account would have tripped: a long-dormant identity or entitlement suddenly being used. A permission unused for eight months, exercised today. An account silent for 200 days, authenticating now. This is the footstep on the landmine — and unlike accumulation, use is an event you can catch.

It’s a real signal, and it’s also routinely oversold, so two honest limits up front:

Break-glass is legitimately dormant. In any large environment there are accounts and jobs that are supposed to sit idle and come alive only during a severity incident — emergency admin access, disaster-recovery automation, the quarterly compliance job. Their dormancy is by design. If you alert naively on “dormant thing became active,” you’ll fire on every SEV at the worst possible moment. The fix is inventory: maintain a registry of intentionally-dormant identities with their expected activation conditions, and exempt them — or better, route their activation to a different, higher-scrutiny queue. A break-glass account waking up outside a declared incident is a far better alert than the activation itself.

Dormant-first-use is necessary, not sufficient. Attackers don’t only take dormant accounts; the most heavily-used privileged accounts are also prime targets, and those generate no dormancy signal at all. Dormant-first-use catches the Colonial and Akira class of breach — the forgotten account, the orphaned vendor identity — but it is one instrument, not the whole panel. Pair it with behavioral baselining on your active privileged identities.

A technical note that matters for how you build it: this is not a clean stateless rule. “First use after long dormancy” requires state — a maintained last-used timestamp per identity and per entitlement, compared against the current event. That’s an enrichment layer (an ISPM/CIEM feed or a maintained lookup), not a Sigma one-liner. Build the dormancy baseline first; the detection is trivial once the state exists and impossible without it. Detect on first authentication after a threshold (Entra exposes signInActivity / lastSignInDateTime; AWS via Access Advisor and CloudTrail last-used), and weight it higher when the dormant identity carries privileged or unused-but-sensitive scope.

---

The Non-Human Multiplier

Everything above gets worse for non-human identities, and that’s where the largest share of the blast radius actually lives.

Service accounts, OAuth grants, and workload identities accumulate privilege faster than humans and shed it slower — they rarely get offboarded at all, because there’s no leaving-the-company event to trigger a review. As I argued in the NHI detection post, non-human identities outnumber humans roughly 45 to 1 and the number-one risk in the OWASP NHI Top 10 is improper offboarding. An orphaned service account with standing privilege and no human owner is the purest form of this problem: maximum blast radius, zero accountability, no dormancy alarm because nobody knows what its normal looks like.

This is not hypothetical. The 2025 Akira intrusion into a manufacturing org came through a ghost third-party vendor account that was never deactivated — an orphaned identity holding valid, privileged access that no one owned. The dormant-first-use signal applies to these even more sharply than to human accounts, if you can establish the baseline — which loops back to the NHI post’s core point: you can’t baseline a population you haven’t classified and don’t own.

---

What to Actually Instrument

Detection here rides on a substrate most programs haven’t built. The work, in order:

Make “granted but never used” a tracked state. This is the foundational telemetry. For every identity and entitlement, maintain usage data: when was this permission last exercised, when did this identity last authenticate. Cloud providers give you the raw material — AWS Access Advisor and last-accessed data, Entra sign-in activity, GCP IAM recommender. An ISPM or CIEM layer turns it into a queryable state. Without this, neither detectable signal above is buildable.

Anchor entitlement baselines to usage, not grants. The right baseline for an identity is what it actually does, not what it’s allowed to do. The 98%-unused gap is the difference, and it’s also your detection surface: an identity suddenly using permissions deep in its unused 98% is a stronger signal than one operating within its used 2%.

Wire grants to a pipeline so out-of-band means something. Signal #1 only has a low false-positive rate if there’s a defined legitimate path to be “out of” — that’s the Detection-as-Code discipline applied to provisioning.

Governance does the shrinking. This instrumentation does the watching. You need both, and the watching is the half detection engineers own.

---

Closing

Identity creep is the rare attack surface that grows while you do nothing — because doing nothing is exactly how it grows. You will not deprovision your way to zero, and the data is clear that nobody else has either. The residual standing access is permanent, and an adversary only needs to find the one credential you forgot to revoke.

So stop framing it purely as a cleanup backlog and start treating it as terrain you have to instrument. Two questions tell you whether you have: when a privileged permission gets granted outside your pipeline, do you see it? And when an identity that’s been silent for six months suddenly comes alive, does anything notice?

The blast radius is invisible until someone steps on it. Your job is to be the thing that hears the step.

Resources

1. 2026 Unit 42 Global Incident Response Report — Palo Alto Networks Unit 42 (identity weaknesses played a material role in nearly 90% of investigations).
2. The State of Identity & Access Report 2026 — Veza (3.8M dormant accounts = 38% of identity-provider users; safe-permission share falling, ungoverned permissions rising).