Some attackers can move from initial access to data theft in little more than an hour. That does not mean every breach follows the same clock — or that every response should be automated.
A security team receives an alert that a user signed in from an unusual location. An analyst opens the case, checks the account history and begins contacting the employee.
While that investigation is happening, the attacker uses the stolen session to enter a connected SaaS application, finds a cloud credential and starts collecting data. By the time the team confirms the first alert, information is already leaving the environment.
This is the operational problem behind a widely repeated 2026 statistic: in the fastest cases investigated by Palo Alto Networks Unit 42, attackers moved from initial access to data exfiltration in 72 minutes.
The number deserves attention. It also needs context. It was the fastest observed category in one incident-response dataset, not the average duration of every modern breach. It does not mean every attack is powered by an autonomous AI agent, or that every organization must contain every alert within exactly 72 minutes.
The useful lesson is simpler: some intrusions can now move faster than a response process built around queues, manual handoffs and disconnected evidence.
Security reports are measuring different clocks
Several 2026 threat reports appear to describe completely different realities.
| Reported measure | 2026 figure | What the clock measures |
|---|---|---|
| Fast initial access to data exfiltration | 72 minutes | Entry into the environment until data begins leaving it |
| Average eCrime breakout time | 29 minutes | Entry into one system until lateral movement begins |
| Fastest observed eCrime breakout | 27 seconds | An extreme instance of lateral movement, not a normal response target |
| Global median dwell time | 14 days | Entry into an environment until the intrusion is discovered |
Unit 42 based its findings on more than 750 major incidents across over 50 countries. CrowdStrike separately reported that average eCrime breakout time had fallen to 29 minutes, with one extreme case reaching breakout in 27 seconds. Mandiant reported a 14-day global median dwell time.
These numbers are not directly comparable. They come from different providers, customer populations and definitions. One measures movement after entry. Another measures progress toward data theft. Dwell time measures how long an attacker remains undiscovered.
Security leaders should resist turning any single number into a universal countdown.
Fast and slow attacks can exist at the same time
A financially motivated attacker may already have working credentials and a clear target. There is little reason to remain hidden for weeks. The attacker can enter, expand access, collect information and begin extortion while the victim is still deciding whether the first alert is serious.
An espionage actor has a different objective. It may establish quiet persistence, use legitimate administrative tools and access information gradually. Mandiant’s 2026 reporting found much longer dwell times in espionage and North Korean IT-worker cases. Other campaigns have remained hidden for many months.
The two patterns require different strengths:
- Fast attacks require early signals and pre-authorized containment.
- Slow attacks require durable logs, threat hunting and visibility into behaviour over time.
An organization can improve one and remain weak at the other. A fast automated response does not help if the initial activity is never visible. Long log retention does not help if nobody can act before a rapid intrusion reaches sensitive data.
AI is accelerating familiar work
The evidence so far points more strongly to acceleration than to completely new forms of attack.
Unit 42 says it has observed AI being used for reconnaissance, phishing, scripting and operational execution. Sophos documented a campaign in which approximately 12 AI agents were used to develop and test nearly 80 malicious modules and more than 70 evasion techniques. Work that could have taken a person weeks was completed in days.
These are significant developments, but the underlying activities remain familiar: obtain access, evade controls, move through systems and steal information. AI can help an attacker perform parts of that work faster and at greater scale. It does not remove the need for credentials, reachable systems or a path to the target.
That distinction matters because it keeps the defensive response practical. Teams do not need an entirely new security programme for “AI attacks.” They need to close the identity, visibility and response gaps that faster automation can exploit.
Identity and connected services change the response
Unit 42 reports that identity weaknesses played a material role in nearly 90% of its investigations. Almost 48% included browser activity, while 23% involved third-party SaaS applications.
An incident can therefore continue even after a laptop has been isolated. A stolen browser session may still be active. An OAuth grant may provide access to email or cloud storage. A compromised service account may operate without an interactive login. A third-party integration may remain trusted after the original user password changes.
A modern containment plan should be able to:
- revoke active sessions and refresh tokens;
- disable suspicious OAuth grants;
- rotate exposed API keys and service credentials;
- force phishing-resistant reauthentication;
- inspect inbox rules and delegated access;
- restrict cloud roles and temporary credentials;
- isolate affected endpoints; and
- identify connected SaaS applications that inherited access.
Endpoint, identity, browser, email, cloud and SaaS evidence must meet in the same investigation. If each team sees only its own product, the attacker benefits from the handoffs.
The First 72 Minutes
Attack speed is not one universal clock. Select a stage below to see a likely signal, where it would show up, what a system can safely automate, and where a person still has to decide. The example toggle compares an illustrative rapid intrusion with a slower, stealthier one — both are educational scenarios, not measured averages.
Likely signal: Sign-in from an unfamiliar device, location or network, or a successful phishing click.
Telemetry source: Identity provider and email-security logs.
Safe automated action: Enrich the alert with device, geo and identity risk context.
Conditional action: Force step-up reauthentication when confidence is high and the account is not shared.
Human decision: Whether to contact the user before or after containment.
Consequence of late detection: The attacker keeps standing access while the case sits in a queue.
Rapid example: a credential-stuffing hit lands on a valid password within the first minute.Stealth example: a phishing email is opened days earlier; the attacker waits before first using the credential.
Likely signal: A stolen session cookie or OAuth token used from a new device without a fresh login.
Telemetry source: Browser-isolation and SaaS session logs.
Safe automated action: Flag the session as high risk and add it to the investigation.
Conditional action: Revoke the specific session or token when confidence is high.
Human decision: Whether revoking would disrupt a legitimate, currently active business process.
Consequence of late detection: The attacker keeps a valid session even after the user’s password is reset.
Rapid example: the stolen session reaches a connected SaaS app within minutes of the initial phish.Stealth example: the token is used sparingly, days apart, to avoid an anomalous-volume alert.
Likely signal: An account requesting permissions or roles it has not used before.
Telemetry source: Cloud identity and access-management (IAM) audit logs.
Safe automated action: Add the unusual permission request to the case timeline.
Conditional action: Temporarily suspend a newly granted privileged role pending review.
Human decision: Whether the escalation matches a real administrative task in progress.
Consequence of late detection: The attacker reaches systems and data far beyond the original account’s normal scope.
Rapid example: a misconfigured role lets the attacker self-grant admin rights in under ten minutes.Stealth example: the attacker uses an already-privileged but low-profile service account instead of escalating at all.
Likely signal: One identity or host authenticating to several new systems in a short window.
Telemetry source: Endpoint detection and network authentication logs.
Safe automated action: Correlate the new connections against the identity’s normal access pattern.
Conditional action: Isolate a standard employee workstation showing the pattern, with rapid reversal available.
Human decision: Whether to isolate a shared, production or customer-facing system on the same evidence.
Consequence of late detection: The attacker gains a foothold on multiple systems, so removing one entry point no longer ends the intrusion.
Rapid example: CrowdStrike’s fastest observed eCrime breakout — 27 seconds from one host to the next.Stealth example: the attacker moves through two or three systems over several weeks, using legitimate admin tools each time.
Likely signal: Large or unusual data collection into a single location, archive or temporary store.
Telemetry source: Data-loss-prevention and cloud-storage activity logs.
Safe automated action: Flag the collection pattern and preserve a copy of the relevant logs as evidence.
Conditional action: Rate-limit or quarantine an anomalous bulk-download job.
Human decision: Whether the destination and volume match a legitimate backup, export or analytics job.
Consequence of late detection: Data is already packaged and ready to leave; the remaining window to intervene shrinks to minutes.
Rapid example: files are archived into one folder within an hour of initial access.Stealth example: small amounts are copied out over many sessions, each below a typical volume threshold.
Likely signal: An outbound transfer to an unfamiliar destination, or a volume spike on an otherwise routine connection.
Telemetry source: Network egress monitoring and cloud-application logs.
Safe automated action: Block a confirmed malicious destination with an expiry and rollback path.
Conditional action: Throttle or hold outbound traffic on the affected identity pending review.
Human decision: Whether to shut down a customer-facing service to stop the transfer, given the business impact.
Consequence of late detection: Data has already left the environment; the response shifts from containment to disclosure and recovery.
Rapid example: Unit 42’s fastest observed case — data leaving within 72 minutes of initial access.Stealth example: data leaves in small, encrypted batches over weeks, timed to blend into normal traffic.
Automation should depend on possible harm
“Automate or fall behind” sounds decisive, but it is incomplete advice. A false positive that enriches an alert wastes little. A false positive that disables a shared production identity can cause an outage.
The right level of automation depends on detection confidence, reversibility, blast radius and business criticality.
| Response action | Sensible treatment |
|---|---|
| Add identity, endpoint and threat context to an alert | Automate |
| Temporarily block a confirmed malicious indicator | Automate with expiry and rollback |
| Revoke one clearly suspicious browser or OAuth session | Automate when confidence is high |
| Isolate a normal employee workstation | Conditional automation with rapid reversal |
| Disable a privileged or shared account | Human approval except under a narrowly tested emergency rule |
| Isolate a production server | Incident commander or service-owner approval |
| Delete a cloud workload or data | Never use as the first containment action |
| Shut down a customer-facing service | Human approval with business-impact assessment |
This is not a universal policy table. Each organization must adjust it for its systems and regulatory duties. The principle is durable: automate actions that are well understood, limited and reversible. Put human approval before actions with a large or uncertain blast radius.
Automation should also preserve evidence. Removing malware may destroy information needed to understand how the attacker entered. Deleting a workload may eliminate logs or volatile state. Containment is meant to stop further harm while leaving a path to investigation and recovery.
Replace one MTTR number with a response chain
Mean time to respond, or MTTR, is often presented as a single measure of security performance. It can hide where the delay occurred.
A more useful response chain records:
- Time to first reliable signal: When did the organization first receive evidence that could support action?
- Time to ownership: How long before a person or automated workflow accepted responsibility?
- Time to understand scope: How long before the team identified affected identities, systems and services?
- Time to contain: When was the attacker’s ability to continue materially restricted?
- Time to verify containment: When did independent evidence show that malicious activity had stopped?
- Time to recover: When did services return to a trusted operating state?
Measure medians and slower percentiles, not only averages. A good average can hide a small group of incidents that remain unowned for hours. Track false-containment rate and rollback time as well; faster action is not an improvement if it repeatedly disrupts legitimate work.
Preparation creates speed before the incident
The first hour of an incident is a poor time to decide who can disable an account or isolate a server.
NIST’s current incident-response guidance places preparation, response and recovery inside the organization’s wider cybersecurity risk management. Canada’s Cyber Centre likewise recommends documented processes for detecting, responding to and recovering from incidents.
Before an alert arrives, teams should decide:
- who owns identity, endpoint, cloud and SaaS containment;
- which systems and identities are too critical for automatic isolation;
- which response actions are pre-authorized;
- how actions are reversed;
- where emergency access is kept;
- which evidence must be preserved;
- how long relevant logs remain available; and
- when legal, privacy, communications and business leaders must join.
Run exercises using realistic timelines. Begin with a suspicious login and introduce new evidence across email, browser, SaaS and cloud systems. Measure how long it takes to find the same identity in each place, revoke its sessions and confirm that data movement has stopped.
The exercise should test decision rights as much as detection tools. A technically correct alert is of limited value when nobody knows who may act on it.
What the 72-minute finding should change
The 72-minute case does not establish a universal deadline. It exposes a weakness in response models that assume investigators will always have several hours to collect evidence before making a decision.
Security teams should use it to ask four questions:
- Can we connect identity, endpoint, browser, cloud and SaaS activity quickly?
- Which high-confidence containment actions are already authorized?
- Can every automated action be explained and reversed?
- Can we verify that containment actually stopped the attacker?
The objective is not to remove people from incident response. It is to keep people focused on uncertain, high-impact decisions while machines collect evidence and carry out bounded actions at the speed the situation requires.
Some attackers may move in minutes. Others may remain hidden for months. A mature security operation must be prepared for both clocks.
Related reading: Why Frontier Cybersecurity AI Is Moving Behind Trusted-Access Gates, Why DNS Servers Remain a High-Value Attack Target, and What the 2026 Ransomware Numbers Really Tell Security Teams.
References and further reading
- 2026 Unit 42 Global Incident Response Report — Attacks Now 4x Faster — Palo Alto Networks Unit 42, 17 February 2026. Source for the 72-minute observation and findings covering identity, browser, SaaS and multi-surface incidents.
- 2026 Global Threat Report — CrowdStrike, 2026. Reports average and fastest observed eCrime breakout times and AI-enabled adversary activity.
- M-Trends 2026 — Google Cloud/Mandiant, 23 March 2026. Reports global median dwell time and longer-running intrusion patterns.
- AI Is Compressing Cyberattack Timelines — Sophos, July 2026. Describes the STAC6994 campaign and emerging risks around AI identities and connected services.
- NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations — National Institute of Standards and Technology, April 2025. Current incident-response guidance aligned with the NIST Cybersecurity Framework 2.0.
- Developing your incident response plan — Canadian Centre for Cyber Security, reviewed January 2026. Practical guidance for preparing detection, response and recovery procedures.
Sources reviewed: 25 September 2026.