By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: IllumioPublished July 22, 2025

TL;DR: Zero Trust has moved from a niche concept to a broad resilience strategy, with John Kindervag and Chase Cunningham arguing that security graphs now underpin better mapping, prioritisation, and containment, according to Illumio. The practical shift is away from compliance-driven alerting toward attacker-aware control of blast radius and transaction flow.


At a glance

What this is: This is an analyst-led Zero Trust discussion that argues the strategy has matured into a graph-driven containment model focused on visibility, prioritisation, and limiting attacker movement.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly need graph-informed access context to govern standing privilege, map critical paths, and contain compromise across human and non-human identities.

By the numbers:

👉 Read Illumio's discussion on how Zero Trust has matured into graph-driven containment


Context

Zero Trust works only when teams can see which identities, systems, and transactions matter most. The article argues that this has become clearer as security graphs make network and access relationships easier to map, which is directly relevant to how IAM and NHI programmes identify protected assets and limit lateral movement.

The key governance gap is not whether organisations can buy Zero Trust tools, but whether they can convert strategy into containment decisions that reflect real identity and access dependencies. For identity teams, that means treating human access, service accounts, and workload paths as a single risk surface rather than separate operational silos.


Key questions

Q: How should security teams implement Zero Trust when they cannot fully map all transactions yet?

A: Start with the protect surface, not the entire estate. Identify the critical applications, data, and identity paths first, then map the most important transaction flows around them. A partial but accurate map is more useful than a broad but shallow inventory, because containment decisions depend on knowing which paths attackers are most likely to use.

Q: Why do service accounts make zero trust harder to operationalise?

A: Service accounts often have broad, persistent access and are difficult to inventory across cloud and application layers. When their permissions are embedded in code or spread across many services, teams lose a clear view of what they can do. That makes blast radius larger and access reviews less reliable.

Q: What do security teams get wrong about measuring Zero Trust programmes?

A: They often measure noise instead of governance. Alert counts, login volume, and generic policy hits do not prove reduced risk. A useful dashboard shows whether exceptions are falling, standing privilege is shrinking, and risky access is being blocked before it turns into lateral movement or compliance exposure.

Q: What should organisations do before using AI to support incident response?

A: They should first reconcile who has access, who owns each account, and which permissions are still active. Without that baseline, AI may recommend the wrong containment step or miss the identities that matter most during a breach.


Technical breakdown

Why security graphs matter for Zero Trust mapping

Security graphs turn scattered telemetry into relationship maps that show who talks to what, through which path, and under what trust conditions. In Zero Trust terms, that makes step two, mapping transaction flows, operational rather than theoretical. Without that graph view, segmentation decisions are based on assumptions instead of observable dependencies. For identity programmes, the same logic applies to service accounts, workloads, and delegated access paths that often sit outside normal review cycles.

Practical implication: map access and transaction dependencies before writing segmentation or least-privilege policy.

Containment, blast radius, and attacker movement

Zero Trust is fundamentally a containment model, not a promise of prevention. Once an attacker or malicious insider gets a foothold, the real control question becomes how far they can move and how much they can touch. Blast radius is reduced through policy enforcement, segmentation, and tightly scoped identity permissions that break the path from entry to impact. This is where identity governance and network control meet, especially where NHIs can move laterally faster than human reviewers can intervene.

Practical implication: design controls around movement limitation rather than assuming initial access will be fully prevented.

How AI changes the speed of response

The article frames AI as useful when it accelerates detection, prioritisation, and containment. That only works if the underlying security architecture already supports machine-speed decisions, because AI cannot compensate for missing maps or unclear policy boundaries. This is an important lesson for agentic AI and NHI security as well: automated action needs clear identity scope, policy context, and trusted telemetry before it can be safely used in response workflows.

Practical implication: only automate response where identity scope and enforcement points are already explicit.


Threat narrative

Attacker objective: The attacker objective is to reach the protect surface quickly and expand access before defenders can contain movement or isolate the compromised path.

  1. Entry occurs when an attacker gains an initial foothold in the environment and tests which paths are exposed by poor visibility or weak segmentation.
  2. Escalation follows when the attacker identifies high-value transaction flows, privileged accounts, or unsegmented systems that allow movement toward the protect surface.
  3. Impact is reached when the attacker reaches critical data, applications, or services with insufficient containment to stop further spread.

NHI Mgmt Group analysis

Security graphs are becoming the missing control plane for Zero Trust. The article is right to treat mapping as a foundational task because policy fails when teams cannot see the relationships that matter. In identity terms, this is especially relevant to NHIs, where service accounts and workload paths often evade traditional review processes. Practitioners should treat graph visibility as a control requirement, not a reporting feature.

Zero Trust has matured from an architectural idea into a containment discipline. That matters because the security goal is no longer preventing every breach, but constraining what a breach can reach. This shift aligns with identity governance in both human and non-human programmes, where standing privilege and opaque dependencies are the real accelerants of lateral movement. Practitioners should reframe success around blast-radius reduction.

Graph-driven security exposes a new governance gap: organisations often know their tools better than their trust relationships. The article points to a recurring problem in modern security programmes, where teams deploy controls without a reliable model of how identities, systems, and services connect. That gap is where attackers operate, and it is also where NHI risk accumulates fastest. Practitioners should prioritise relationship visibility before expanding policy complexity.

AI will only improve Zero Trust if the environment is already identity-literate. Machine-speed response is useful only when policies, access paths, and telemetry are well-defined enough for automation to act safely. For agentic AI and NHI security, this is a direct warning: automation without identity scope creates faster mistakes, not better resilience. Practitioners should anchor AI use cases in explicit identity and containment boundaries.

Blast-radius thinking should replace control-count thinking. The article’s strongest message is that security maturity is not measured by how many tools exist, but by how quickly the organisation can isolate a compromised path. That is a useful corrective for IAM, PAM, and NHI programmes that still optimise for administration rather than containment. Practitioners should judge strategy by how much damage it prevents after entry.

What this signals

Blast-radius governance is becoming the more useful maturity test. Teams should expect stakeholders to ask less about how many Zero Trust controls exist and more about how quickly compromise can be contained once entry occurs. That shifts programme metrics toward identity scope, segmentation coverage, and the ability to isolate high-value paths before lateral movement expands.

The identity angle is especially important for NHIs, because high privilege and weak lifecycle controls turn graph visibility into a prerequisite for action rather than a nice-to-have. Programs that still treat service accounts as admin overhead will struggle to operationalise containment at machine speed.

For practitioners working across access governance and cloud resilience, the relevant standard remains NIST SP 800-207 Zero Trust Architecture, because the architecture is only as strong as the identity relationships it can continuously verify.


For practitioners

  • Map protect surfaces and transaction flows Identify the critical data, applications, services, and identity paths that attackers would target first. Use graph-based analysis to make those dependencies visible before designing segmentation or policy changes. Suggested anchor: protect surfaces and transaction flows
  • Align identity governance with containment goals Review whether human accounts, service accounts, and workload identities are governed as one risk surface. Tighten entitlement scope where standing privilege creates lateral movement routes into high-value systems. Suggested anchor: standing privilege
  • Prioritise blast-radius controls over alert volume Measure resilience by how far an attacker can move after the first foothold, not by the number of alerts generated. Pair segmentation, least privilege, and response playbooks so containment starts at the first suspicious movement. Suggested anchor: blast-radius controls
  • Only automate response where policy is explicit Use AI-assisted response only after access paths, policy boundaries, and escalation conditions are clearly defined. Automation should accelerate decisions that already exist, not invent them during an incident. Suggested anchor: policy boundaries

Key takeaways

  • Zero Trust now functions less as a slogan and more as a containment model that depends on accurate relationship mapping.
  • Identity sprawl, especially among NHIs, makes graph visibility and blast-radius reduction central to real-world resilience.
  • The practical test is whether your programme can limit movement after entry, not whether it can promise prevention everywhere.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01Graph-driven containment depends on knowing where NHI access exists and how it connects.
MITRE ATT&CKTA0008 , Lateral Movement; TA0040 , ImpactThe article focuses on containing attacker movement before it reaches high-value systems.
NIST CSF 2.0PR.AC-4Least-privilege access control is central to the containment model described here.
NIST SP 800-53 Rev 5AC-6Least privilege directly supports the article's containment and segmentation theme.
NIST Zero Trust (SP 800-207)Zero Trust Architecture is the primary architectural lens for the article.

Map likely movement paths and harden the controls that stop lateral movement toward the protect surface.


Key terms

  • Protect surface: The subset of data, applications, assets, and services that require the strongest security and governance controls in a Zero Trust model. It is the practical boundary for continuous verification, access review, and enforcement, and it should be defined by business criticality and exposure.
  • Security Graph: A security graph is a relationship model that connects identities, assets, permissions, and traffic flows so defenders can see how systems depend on each other. It turns scattered telemetry into a map that can support prioritisation, segmentation, and containment decisions.
  • Blast Radius: Blast radius is the amount of damage an attacker can cause after gaining initial access. In Zero Trust programmes, it becomes a practical measure of resilience because it reflects how far movement can spread, how much data can be touched, and how quickly containment can be applied.
  • Containment: The phase of incident response that stops an incident from spreading while preserving the evidence needed to investigate it. In cloud environments, containment often starts with identity revocation, isolation of workloads, and protection of logs before any system is terminated or cleaned up.

What's in the full article

Illumio's full article covers the operational detail this post intentionally leaves for the source:

  • The full conversation with John Kindervag and Chase Cunningham on how they apply Zero Trust in practice.
  • The security graph discussion that explains how map quality changes prioritisation and containment decisions.
  • The podcast context on how teams can think like an attacker when defining protect surfaces and response goals.
  • The article's discussion of AI-assisted response and why machine-speed action still depends on human-defined policy.

👉 Illumio's full article expands on security graphs, attacker thinking, and containment strategy.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to broader security and resilience programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org