The real breach starts before attackers exfiltrate data

Most breach narratives start too late.

They start when data loss is confirmed.

They start when a company says customer records were accessed, files were stolen, or a threat actor has published a sample.

That is when the story becomes legible from the outside. It is not when the security problem starts.

The real problem starts earlier. An attacker has access. The organisation must investigate, contain the intrusion, isolate systems, keep the business running, and work out what the attacker could reach.

That period is often messy. The scope is incomplete. The root cause is not yet clear. Data impact may still be unknown.

Operationally, the company is already managing a breach.

This is the phase Identity Progression Attacks describe: after access, before confirmed impact, as an attacker turns a foothold into a path toward something valuable.

Confirmed data loss is a late signal

Confirmed exfiltration is an important signal. It creates legal, regulatory, customer, and business consequences.

It is also late.

By the time a company can say with confidence that data was accessed or stolen, the attacker has already completed several meaningful steps.

They gained a foothold.

They operated inside the environment.

They reached systems or data that mattered.

They forced the organisation into investigation and response.

For defenders, the useful question is not only:

Was data exfiltrated?

The more useful earlier question is:

Is attacker access progressing toward data right now?

Those are different detection problems.

One asks for proof after impact.

The other asks whether the path to impact is forming while there is still time to interrupt it.

The uncertainty phase is where the work happens

Public breach reporting often treats uncertainty as if nothing has happened.

No confirmed record count.
No confirmed data categories.
No final root cause.
No complete timeline.

For security teams, that uncertainty is not empty space. It is the response window.

During that period, teams are trying to answer harder questions:

• Which identity, system, or integration was first accessed?
• What did that access make reachable?
• Did the attacker enumerate permissions, roles, projects, repositories, storage, or secrets?
• Did any action shorten the path to sensitive data?
• Which systems need to be isolated without breaking the business?
• What must be preserved for investigation?
• What can be ruled out with confidence?

This is not just incident administration.

It is the practical work of deciding whether access is becoming impact.

It is also why Identity Progression Attack detection has to start before the investigation reaches a final answer.

The useful signal is often the change in what an identity can reach, not the final proof that data was taken.

Access creates business cost before disclosure

Even when the public data-loss story is incomplete, attacker access can already create cost.

Systems may need to be taken offline.

Business continuity plans may need to stay active.

External investigators may need to be brought in.

Executives may need to brief boards, regulators, insurers, partners, and customers before the full scope is known.

Support teams may prepare for customer concern.

Security teams may spend weeks validating what happened and what did not happen.

That cost does not wait for a final breach notification.

Hasbro is a useful example of this pattern. Public reporting said the company took some systems offline and expected remediation to take weeks while business continuity plans remained active. The lesson is not about exactly what data was or was not taken. It is that unauthorised access can create operational pressure before the public story has a neat ending.

ICAO shows a related pattern. The organisation acknowledged a potential information security incident and implemented immediate security measures while the scope was still being investigated. Again, the point is not to overstate the final impact. It is that investigation and containment begin before certainty.

That is the period security tools should help with.

Why this is hard in cloud environments

Cloud environments make the early phase difficult because attacker movement can look legitimate.

An identity logs in.

A role is assumed.

A service account is used.

A repository is accessed.

A storage location is listed.

A cloud API call succeeds.

Each action may be allowed. Each event may make sense in isolation.

The question is whether the sequence changes the attacker's position.

Did the identity gain reachability?
Did it move into a more sensitive project, account, role, or system?
Did it discover a path to data?
Did it move from a low-value foothold toward a high-value target?

That is the difference between isolated activity and attacker progression.

Detection should move earlier

Many security workflows still centre on either the first suspicious event or the final data impact.

Both matter, but neither is enough.

The first event may be ambiguous.

The final impact is too late.

The important phase is the progression in between: the steps where the attacker turns access into leverage.

That middle phase is where Identity Progression Attacks matter. The attacker may not have reached the target yet, but the path to the target is getting shorter.

That means defenders need to evaluate activity by how it changes risk over time:

• Did this action create a new path to sensitive data?
• Did this role assumption reduce the distance to a high-value target?
• Did this service account make a protected system reachable?
• Did this sequence look normal event by event, but abnormal as a path?
• Is the attacker getting closer to the data that would turn access into a material breach?

This is the phase where earlier detection can still change the outcome.

How vec0 thinks about it

vec0 is built around the idea that breaches are paths through identities and permissions toward sensitive data.

The goal is not to wait until data is touched and then confirm that a breach happened.

The goal is to detect when activity is increasing risk before that point.

That means modelling Identity Progression Attack patterns across identities, permissions, actions, systems, and sensitive data.

It means asking whether each action creates, activates, or shortens a path toward something valuable.

Some actions are noise.

Some actions are ordinary.

Some actions are ordinary in isolation but meaningful in sequence.

That is where the signal lives.

The earlier question

Data exfiltration will always matter. But if the first confident answer comes after data is gone, the detection model is too late.

Security teams need help in the uncertain middle. Access has been detected. Impact is not confirmed. The attacker may still be progressing.

Defenders need to ask an earlier question:

Is someone moving toward sensitive data right now?

That is the moment where defenders still have leverage.