Zero Trust in a crisis: targeted containment

Zero Trust is usually introduced as an access project: replacing the VPN, securing sign-ins, cleaning up permissions. What the model means for incident response often gets lost in such projects. Yet the difference shows precisely when an account has been compromised or a server starts behaving oddly. If every access is checked individually, every access can also be withdrawn individually.

From pulling the plug to precise levers

In traditionally built networks, the means of containment are blunt. The team shuts down the VPN, cuts off an entire segment or takes a server off the network. That may slow the attacker down, but it also hits everything that has nothing to do with the incident. Accordingly, teams hesitate for a long time before pulling that lever.

In a Zero Trust architecture as described in NIST SP 800-207, every access passes through a decision point that evaluates identity, device posture and policy. An enforcement point puts the result into effect, not only at sign-in but throughout the session (more on this in our post on identity as the engine of Zero Trust). For incident response, one thing above all changes: there are levers of different strengths. A team can force a fresh sign-in, cut permissions back to the bare minimum, revoke sessions, lock out a device or close a single connection path between two workloads. Everything else keeps running.

A lever only works if it has been prepared

NIST fundamentally revised its incident response recommendations in April 2025. Revision 3 of SP 800-61 maps them to the six functions of the Cybersecurity Framework 2.0 and treats incident response as an integral part of risk management. Preparation is therefore not a warm-up but part of day-to-day operations. Whether a team can contain an incident in a targeted way is decided beforehand.

Every lever first needs an owner. Who may revoke a session at night, and who may isolate a production system? Without that decision made in advance, people debate while the attacker keeps working. OpenAI's report on the Hugging Face incident shows where this can lead: the monitoring raised an alert at the end of June, and the evaluation continued anyway.

Just as important is knowing what an intervention will hit. Anyone who closes a connection path needs to know which applications depend on it. In its microsegmentation guidance from July 2025, the US agency CISA treats mapping these dependencies as a step of its own, before the first policy is written. In a crisis, this map answers the most important question before any intervention: what will still work afterwards?

Finally, every lever has to be rehearsed. How long does it take to isolate a workload? Does a revoked access really take effect everywhere? Questions like these belong in an exercise, not in the first hour of a real incident.

Revoked is not the same as locked out

One detail shows why such exercises pay off. In Cloudflare Access, a user's sessions can be revoked across all applications in a few clicks. If the account at the identity provider is still active, however, the same user can sign in again shortly afterwards, and with stolen credentials, so can the attacker. The revocation only becomes permanent once the account is disabled at the identity provider. Anyone unaware of this sequence believes an incident is contained when it is not.

The same applies to telemetry. Zero Trust logs every access decision with identity, device, resource and time. For analysis, however, this data is only useful if it is retained long enough and remains reachable even when parts of the environment are compromised. Germany's Federal Office for Information Security (BSI) explicitly counts log data and its retention as part of preparing for security incidents.

What this means for NIS-2 reporting

Germany's NIS-2 implementation act has been in force since December 6, 2025. Particularly important and important entities must report significant security incidents to the BSI: with an early initial notification within 24 hours of becoming aware, a follow-up notification within 72 hours and a final report no later than one month after the follow-up. Even in the early notification, the BSI asks about the measures taken and whether the incident is under control.

After 24 hours, these questions can only be answered if it is clear which identities, devices and applications are affected and which levers have already been pulled. Logged access decisions and prepared containment levels provide exactly these answers. How we support companies with these obligations is shown on our NIS-2 compliance page.

Questions for your next exercise

These questions help to check how well your own preparation holds up:

1. Which containment levels are defined, from a fresh sign-in to isolation, and who may trigger which level, including at night and on weekends?
2. When a session is revoked, is the account at the identity provider disabled as well, and who takes care of that?
3. Is there an up-to-date map of which applications and workloads depend on each other?
4. Are access decisions logged for long enough, and can the logs be reached even if the environment is compromised?
5. How long does it demonstrably take to isolate a workload or a device, and when was this last rehearsed?
6. In what order is access restored after the incident, and who confirms that a system is clean?

How KAEMI helps

We deliver both sides of Zero Trust as a managed service. With Cloudflare One, every access is bound to identity and device posture and can be withdrawn in a targeted way when it counts. With microsegmentation based on Illumio, the dependency map emerges, and compromised workloads can be isolated without stopping the rest of the operation. Where your environment stands today, from identity to log and flow data, is clarified in a Zero Trust readiness workshop.

Sources: NIST SP 800-61 Rev. 3, “Incident Response Recommendations and Considerations for Cybersecurity Risk Management” (April 2025); NIST SP 800-207, “Zero Trust Architecture” (August 2020); CISA, “Microsegmentation in Zero Trust, Part One: Introduction and Planning” (July 29, 2025); BSI information on the NIS-2 reporting obligation under Section 32 BSIG; Cloudflare documentation on session management in Access.