What should teams do first when a compromise is confirmed?

Why This Matters for Security Teams

A confirmed compromise changes the objective from prevention to damage limitation. The first decision is usually not about eradication tools or password resets, but about stopping further attacker action while preserving enough evidence to understand what happened. That distinction matters because rushed cleanup can destroy the timeline needed for scoping, legal review, and post-incident hardening. Guidance in CISA incident response guidance and the NIST Cybersecurity Framework both emphasise containment, coordination, and evidence preservation as core response priorities.

Teams often get this wrong when the pressure to restore service overrides the need to understand attacker persistence. If privileged accounts, API keys, service tokens, or automation credentials remain active, an intruder can continue moving even after an endpoint is reimaged. The same problem appears in cloud and AI environments, where a compromised identity may have access to pipelines, secrets, or agent execution paths rather than just a single host. In practice, many security teams encounter the full blast radius only after hurried cleanup has already removed the clues needed to identify it.

How It Works in Practice

The first response should be a controlled containment sequence, not a broad reset of everything at once. That means identifying the blast radius, cutting off active attacker pathways, and preserving artefacts before making irreversible changes. SANS incident response guidance and the MITRE ATT&CK knowledge base are useful for mapping likely attacker actions to the right containment moves.

• Isolate affected hosts, cloud workloads, or identity providers from trusted paths without destroying volatile evidence.
• Revoke or rotate compromised credentials, including session tokens, API keys, certificates, and privileged service accounts.
• Disable suspicious automation, scheduled jobs, webhook integrations, and agent-to-tool permissions that could reintroduce access.
• Preserve logs, memory snapshots, authentication history, and change records before remediation changes the state of the environment.
• Notify incident leads, legal, and business owners early so containment decisions match operational and regulatory needs.

For identity-heavy incidents, containment should include session invalidation and privilege review, not just password resets. If a non-human identity or AI agent was involved, the team should also verify whether the compromise extends into secrets stores, CI/CD pipelines, or orchestration systems that can mint new access. The most important question is whether the attacker can still act, not whether one machine has been cleaned. The NIST incident response guidance is clear that containment decisions should be driven by scope and evidence, not urgency alone. These controls tend to break down when a live SaaS environment lacks central logging or where third-party integrations can silently reissue access after local credentials are revoked.

Common Variations and Edge Cases

Tighter containment often increases operational disruption, requiring organisations to balance service availability against the risk of ongoing attacker activity. That tradeoff becomes sharper in regulated or distributed environments, where a single compromised identity may touch production systems, customer data, and automation pipelines at once.

Best practice is evolving for AI-assisted and agentic environments. Current guidance suggests treating agent credentials, tool permissions, and retrieval connectors like any other privileged path, because an attacker who controls them may steer downstream actions without needing full system access. The Anthropic report on an AI-orchestrated cyber espionage campaign is a reminder that automation can amplify both speed and scope once compromise occurs.

There is no universal standard for whether containment should be host-first, identity-first, or network-first. The right sequence depends on where the attacker has durable access, whether logs are intact, and whether business continuity can tolerate short service interruptions. Edge cases include encrypted environments where evidence is limited, cloud tenants where revocation can cascade into outages, and shared administrative tooling where one reset can unintentionally preserve lateral access elsewhere.

Related resources from NHI Mgmt Group

• What should teams do first when a pre-authentication RCE is disclosed?
• How do security teams know whether Linux post-compromise controls are actually working?
• How do security teams know whether a web server compromise is likely to become a major incident?
• What should teams do when credential stuffing is confirmed?