Many attacks do not become dangerous at the first login.

They become dangerous after the attacker starts moving.

A compromised account, stolen token, exposed API key, or hijacked session may only provide a limited foothold. The real risk emerges when that foothold is used to discover permissions, traverse access paths, assume roles, move across systems, and get closer to sensitive data or another high-value target.

Each step may be allowed. Each event may look ordinary in isolation.

The attack is in the progression.

Definition

Identity Progression Attacks (IPA) are post-compromise attacks where an adversary uses valid identities, permissions, and access paths to progress from an initial foothold toward a high-value target.

The defining feature is not that an identity was compromised.

The defining feature is that the attacker is using identity and access relationships to move closer to an objective.

That objective may be a production database, object storage bucket, source code repository, secrets store, privileged admin role, financial system, customer data environment, or any other asset that matters to the business.

Why the term matters

Security teams already have names for parts of this problem:

• Credential theft
• Identity compromise
• Suspicious login
• Privilege escalation
• Lateral movement
• Cloud misconfiguration
• Data exfiltration

These terms are useful, but they describe fragments.

They do not clearly describe the full phase between initial access and target access, where the attacker turns a foothold into impact by chaining legitimate identities, permissions, roles, groups, sessions, systems, and cloud resources.

That phase is where many enterprise attacks become material.

Identity Progression Attacks name that phase directly.

They describe the attacker's movement through the identity and permission fabric of the environment. The important question is not only, "Was this login suspicious?" or "Does this role have excessive access?"

The better question is:

Is this identity path moving an attacker closer to something valuable?

Anatomy of an Identity Progression Attack

A typical Identity Progression Attack may look like this:

1. Initial foothold
2. Valid identity use
3. Permission discovery
4. Lateral movement
5. Privilege expansion
6. Reachability increase
7. Target approach
8. Target access

At the initial foothold, the attacker gains access through a compromised user, exposed key, stolen session, vulnerable workload, or third-party integration.

With valid identity use, the attacker authenticates using credentials or tokens that the environment accepts.

During permission discovery, the attacker enumerates accessible resources, roles, groups, projects, accounts, repositories, secrets, or storage locations.

Through lateral movement, the attacker moves from one identity, system, workload, or cloud context to another.

With privilege expansion, the attacker assumes a role, joins a group, abuses inherited permissions, uses a service account, or finds a path with broader reach.

Reachability increases when the attacker's effective access moves closer to sensitive data or another high-value target.

During target approach, the attacker begins interacting with systems adjacent to the target, such as production services, data processing jobs, secrets stores, or administrative planes.

Target access occurs when the attacker reaches the asset that creates business, regulatory, or operational impact.

The attacker may never trigger one obvious malicious event.

The signal is the sequence.

Why these attacks are hard to detect

Identity Progression Attacks are difficult because they often use the same mechanisms legitimate users and systems rely on every day.

Attackers use valid credentials.
Cloud APIs accept the calls.
Role assumptions succeed.
Service accounts behave as designed.
Permissions may be excessive, but still authorised.
Activity may be unusual only when viewed across time and context.

This creates several detection gaps.

SIEM rules often see events, not progression. They may detect a failed login, a rare API call, or an unusual source IP, but they usually do not model whether a sequence of valid actions is shortening the path to sensitive data.

Posture tools see exposure, not live attack movement. They can identify excessive permissions or risky configurations, but static exposure is not the same as an attacker actively traversing a path.

DLP sees the problem late. By the time sensitive data is being copied, queried, staged, or exfiltrated, the attacker has already succeeded in reaching the target.

Cloud environments make this harder. Permissions are distributed across users, groups, roles, service accounts, machine identities, workloads, projects, accounts, policies, and inherited relationships. A path may be invisible if each system is assessed separately.

The attacker does not need to break every control. They need to find a valid path through them.

Examples

Compromised developer account moving toward production data

A developer account is compromised through a stolen session token.

At first, the account has no direct access to production databases. The attacker reviews repositories, identifies deployment workflows, discovers environment variables, and finds that the developer can trigger a CI job.

The CI job runs under a service identity with access to production configuration. From there, the attacker finds a role that can read database connection secrets.

No single action is obviously malicious. Repository access is normal. CI usage is normal. Secret access by the service identity is expected.

The risk is that the attacker has progressed from a human developer identity toward production data through valid access paths.

Service account token used to reach storage

A service account token is exposed from a workload.

The attacker uses it to enumerate permissions. The service account cannot directly read sensitive storage, but it can list projects, inspect IAM bindings, and invoke a data processing job.

That job has access to a storage bucket containing regulated data.

The attacker has not escalated privileges in the traditional sense. They have followed a machine identity path that already existed.

The meaningful signal is the change in reachability from a workload token to a sensitive storage environment.

Cloud user moving through groups, roles, and projects

A cloud user account is compromised after a successful phishing attack.

The user has limited direct access, but belongs to a group that can request temporary access to a shared analytics project. Inside that project, the attacker identifies a role binding that allows access to a data export service.

The export service can query datasets that the original user could not access directly.

From an event perspective, the attacker used accepted identity flows. From a risk perspective, the attacker moved from a low-privilege user identity toward sensitive datasets by chaining groups, roles, and project-level permissions.

How defenders should think about detection

Identity Progression Attacks require a different detection model.

The focus should be on progression, not isolated events.

Useful detection questions include:

• Did this action increase the identity's reachability to sensitive data?
• Did this sequence shorten the path from foothold to target?
• Did the identity move into a new cloud account, project, role, group, or resource tier?
• Did a permission change create a new path to a high-value target?
• Is activity converging on sensitive assets across multiple valid steps?
• Is a human or machine identity traversing an unusual access path?
• Is the risk delta increasing even if each individual event is allowed?

This means modelling identities, permissions, resources, activity, and sensitive assets together.

A login is not just a login.
A role assumption is not just a role assumption.
A permission change is not just a configuration update.

Each action should be evaluated by how it changes the attacker's possible paths and distance to target.

How vec0 fits

vec0 models Identity Progression Attacks by building a real-time attack graph across identities, permissions, activity, and high-value targets.

The goal is to detect risk increasing before the attacker reaches the target.

Instead of treating each event as a separate alert, vec0 evaluates whether actions create, shorten, or activate paths toward sensitive data. It focuses on the risk delta created by progression through valid identities and permissions.

That helps defenders see the phase between "someone got in" and "the target was reached".

Summary

Identity Progression Attacks describe the phase where attackers turn access into impact.

They are not just identity compromise, suspicious login detection, privilege escalation, lateral movement, posture risk, or data loss detection. They are the sequence of valid identity and permission use that moves an attacker closer to a high-value target.

That is the phase defenders need to see earlier.

If security teams can detect progression before target access, they have a better chance to interrupt the attack before sensitive data is reached.