The collaboration gives Exclusive Networks' Hong Kong resellers a fast path to automated, identity-driven microsegmentation that verifies every connection and stops lateral movement, human or AI, within seconds. The goal is to help local enterprises strengthen resilience without launching complex, multi-year security projects, combining Zero Networks' automation and agentless-first architecture with Exclusive Networks' regional expertise and partner ecosystem.

Adam Hofeler, VP Sales & GTM at Zero Networks, commented:

As AI reshapes how organizations detect, manage, and respond to risk, Exclusive Networks partnered with Zero Networks to meet that reality head-on with preventative, identity-based control across different layers where AI introduces risk: governing which cloud AI services can be accessed, enforcing least-privilege boundaries on AI agents, segmenting model infrastructure so it can't be tampered with, cutting off the connectivity that enables lateral movement, and surfacing compliance gaps in real time.

A Zero Networks technical workshop hosted by Exclusive Networks last month, attended by their Hong Kong resellers, showed that the local community is ready to move beyond detection-focused security and toward prevention-focused models. Attendees focused on how far an attack,  human or AI, could spread inside their networks, and how to contain it without launching a tedious and lengthy project.

Empowering Reseller Partners

This partnership is designed with reseller partners in mind. By combining Zero Networks’ rapid deployment model and Exclusive Networks’ value-added services, partners will benefit from:

• Access to cutting-edge Zero Trust technology that meets the growing demand for scalable, identity-based security, helping organizations defend against AI-speed attacks, protect uptime, and contain breaches before they spread, so a breach never has to mean business disruption
• Accelerated deployment timelines, enabling faster customer onboarding and quicker ROI.
• Enhanced margin opportunities through deal registration, marketing support, and training incentives.
• Comprehensive technical enablement, including certifications, pre-sales support, and co-branded campaigns.
• Strategic alignment with a trusted distributor, helping partners build credibility and close deals more effectively.

About Exclusive Networks

Exclusive Networks (EXN) is a global cybersecurity specialist that provides partners and end-customers with a wide range of services and product portfolios via proven routes to market. With offices in over 45 countries and the ability to serve customers in over 170 countries, we combine a local perspective with the scale and delivery of a single global organisation.

Our best-in-class vendor portfolio is carefully curated with all leading industry players. Our services range from managed security to specialist technical accreditation and training and capitalize on rapidly evolving technologies and changing business models. For more information visit www.exclusive-networks.com.

Almost everyone has picked up a Rubik's Cube at some point. 

The first few moves feel productive. You line up a row of colours, complete part of a side, and convince yourself you're making progress. Then one more twist undoes everything you just achieved. 

The challenge isn't that the cube is impossible to solve. The challenge is that every move affects something else. 

Kubernetes environments often evolve in exactly the same way. 

A cluster starts simple. A few workloads. A handful of namespaces. A small platform team that understands every application running inside it. Developers know what their services communicate with. Security teams understand the environment. Documentation is current. Dependencies are well known. 

Then the business grows. 

New applications are deployed. Additional teams adopt the platform. New services are integrated. More namespaces appear. More clusters are introduced. Temporary projects become permanent services. Acquisitions bring in new workloads. Migrations create new dependencies. 

As the environment grows, responsibilities also begin to spread across application, platform and security teams. Each team makes decisions within its own part of the environment, but those decisions inevitably affect the others. 

Before long, what started as a neatly organised environment begins to resemble a Rubik's Cube that has been twisted thousands of times. 

Every team understands part of the environment. Few understand all of it. 

Kubernetes Was Never Designed to Stay Small 

One of Kubernetes' greatest strengths is its ability to scale rapidly. 

Development teams can deploy applications faster than ever. New environments can be created in minutes. Infrastructure becomes highly dynamic and workloads are constantly changing. 

But this flexibility introduces new challenges. 

Unlike traditional environments where servers may exist for years, Kubernetes workloads can appear and disappear in seconds. Pods are ephemeral. Services communicate across namespaces. Applications are distributed across dozens or even hundreds of microservices. Workloads often communicate not only within a cluster, but across clusters and with external systems. 

And it isn't just the technology that becomes distributed. Responsibility does too. 

Application teams design the application, deploy it and increasingly define aspects of its networking and security. Platform and IT teams operate the underlying Kubernetes environment. Security teams remain responsible for governance, risk and ensuring that appropriate controls are in place. 

The boundaries between these responsibilities are not always clear. 

If a privileged pod introduces unnecessary risk, who owns the problem? Is it an application issue, a platform configuration issue or a gap in security policy? If a new service introduces an unexpected communication path, who is responsible for identifying it and deciding whether that access should exist? 

As environments grow and development teams move faster, these questions become increasingly difficult to answer. Security teams may be accountable for protecting the environment without having complete visibility into how applications are changing or communicating. Platform teams understand the infrastructure, while application teams often have the deepest understanding of individual workload dependencies. 

Each team understands a different part of the cube. 

Questions that were once simple become surprisingly hard to answer: 

• Which services communicate with each other? 
• Which communications are business critical? 
• Which namespaces should never communicate? 
• Which connections were introduced for testing and never removed? 
• What would happen if access was restricted? 
• Who owns the risk when unnecessary access is discovered? 

In many organisations, nobody can confidently answer all of these questions. 

This isn't necessarily a failure of technology or process. It is the reality of operating a modern Kubernetes environment at scale, where the environment can change faster than teams can collectively understand it. 

Complexity accumulates faster than understanding. 

The Cost of Not Knowing 

Most platform and security teams understand the value of segmentation. 

Yet many Kubernetes segmentation initiatives never move beyond planning. Why? 

Because nobody wants to break production. 

Imagine being asked to implement restrictive Network Policies across a cluster containing hundreds of applications and thousands of workloads. 

Before creating a single policy, you need to understand what traffic is required, what traffic is optional, what traffic is legacy and what traffic represents unnecessary risk. 

That understanding is rarely owned by a single team. Application teams understand their services and dependencies. Platform teams understand the infrastructure. Security teams understand the risk and controls. 

Without that understanding, every policy becomes a gamble. 

Block the wrong communication path and a customer-facing application may fail. Restrict access incorrectly and a business-critical service may stop functioning. The operational consequences often feel more immediate than the security risks. 

As a result, organisations frequently choose the safest operational option. 

They leave access open. 

The business impact of this decision is significant. Excessive connectivity increases attack surface, expands blast radius during incidents, complicates compliance efforts, and makes investigations substantially more difficult. Security teams understand the risk, but reducing that risk often appears riskier than accepting it. 

The organisation becomes trapped between security and operational certainty. 

Why Native Kubernetes Controls Aren't Enough 

Kubernetes provides Network Policies that allow organisations to control communication between workloads. The concept is powerful. 

The implementation is often challenging. 

In smaller environments, manually managing Network Policies may be achievable. In larger environments, the reality becomes much more complicated. 

Different teams create policies. Applications evolve. New services are deployed. Existing services are modified. Documentation becomes outdated. New namespaces and workloads appear. Clusters grow. Additional clusters are added. 

The challenge is that Kubernetes environments never stay still. Development teams continuously ship changes, often at a pace that security teams cannot manually review. A cluster may initially align with CIS Benchmarks or an organisation's internal security baseline, but as new workloads, configurations and communication paths are introduced, the environment can gradually drift away from that intended state. 

This configuration drift is rarely the result of a single major change. It accumulates over time as applications evolve, teams move quickly and exceptions are introduced. At scale, maintaining consistent policy enforcement becomes just as challenging as defining the policies in the first place. 

Over time, organisations accumulate hundreds or even thousands of policy definitions spread across namespaces and environments. Policies that were appropriate when they were created may no longer reflect how applications operate today. 

The challenge isn't creating policies. 

The challenge is understanding whether those policies accurately reflect how applications should communicate and ensuring they continue to do so as the environment changes. 

Most teams can view individual policies. 

Few teams can easily understand the cumulative impact of all policies across the environment, identify where configuration drift has occurred, or determine whether new communication paths have introduced unnecessary exposure. 

Without visibility, organisations are effectively trying to solve a Rubik's Cube while only seeing one side. 

What Happens When a Workload Is Compromised? 

Security teams invest significant effort into preventing compromise. 

Clusters are protected by vulnerability scanners, image scanning solutions, admission controllers, runtime protection platforms, secrets management solutions and RBAC controls. These technologies are essential and form a critical part of a defence-in-depth strategy. 

However, no organisation can guarantee that a workload will never be compromised. 

The more important question is what happens next. 

Imagine a single workload becomes compromised. Not the entire cluster. Not a cluster administrator account. 

Just one pod. 

What can it reach? 

• Can it communicate with other workloads in the same namespace? 
• Can it access services in another namespace? 
• Can it discover internal APIs? 
• Can it reach backend databases? 
• Can it communicate with management services or infrastructure components? 

For many organisations, the answer is unclear. 

By default, Kubernetes environments can provide significantly more connectivity than teams realise. Over time, communication paths accumulate. Some are necessary. Others exist because of historical decisions, temporary exceptions, inherited configurations, or simply because nobody wanted to risk breaking an application. 

An attacker doesn't necessarily need cluster-admin privileges to cause damage. 

They need a path to something valuable. 

Once an attacker gains access to a workload, trusted east-west communication paths can allow them to discover internal services, communicate across namespaces, access backend APIs, interact with databases or explore management components within the environment. 

This is where a contained compromise can become a much broader incident. 

A workload that should have been isolated can become a launchpad for lateral movement. Sensitive services that were never intended to communicate may become accessible. Databases, internal APIs and critical business systems can all become part of the attack path. 

The challenge isn't simply that these communication paths exist. 

The challenge is knowing which ones should exist. 

Without visibility into workload-to-workload communication, it becomes extremely difficult to distinguish legitimate business traffic from unnecessary exposure. 

The risk isn't necessarily the compromised workload. 

The risk is everything connected to it. 

Before organisations can reduce lateral movement, they first need to understand it. 

Seeing the Whole Cube 

The turning point occurs when the environment becomes visible. 

Most Kubernetes tools provide visibility into individual components. Teams can inspect pods, deployments, services, logs and policies. While each of these views is valuable, they rarely provide a complete understanding of how the environment functions as a whole. 

This is similar to studying a Rubik's Cube one square at a time. You can understand individual pieces without understanding how they relate to each other. 

As Kubernetes environments grow, those relationships become increasingly important. 

Security teams need to understand which namespaces communicate with each other. Which communication paths are unrestricted. Which workloads are isolated. Which areas of the environment have no policy enforcement. Which connections are expected and which represent unnecessary exposure. 

But visibility also needs to be shared. 

Application teams understand how their applications are designed. Platform teams understand how the Kubernetes environment operates. Security teams understand the organisation's risk and governance requirements. Giving these teams a common view of communication, access and policy helps turn fragmented knowledge into coordinated decision-making. 

This is where the Zero Networks Kubernetes Access Matrix becomes valuable. 

Rather than analysing workloads and policies individually, the Access Matrix provides a visual representation of communication and policy enforcement across the cluster. Teams can identify unrestricted communication paths, isolated namespaces, partially restricted access and areas where no policies exist at all.

Combined with visibility into actual data flows and the existing rule baseline, teams can begin identifying where access is required, where it may be excessive and where ownership or policy decisions are needed.

What previously required teams to piece together information from multiple views becomes visible in a single place. More importantly, the conversation changes.

Teams stop asking: "What happens if we block this?" And start asking: "Why are we allowing this?"

Visibility transforms security from guesswork into decision-making.

And, just as importantly, it gives Application, Platform, and Security teams a common view from which to make those decisions together.

Solving the Cube Layer by Layer 

Nobody solves a Rubik's Cube by looking at it once and immediately making the perfect move. 

They start by understanding the current state of the puzzle. Only then can they begin making deliberate decisions that move them closer to the end goal. 

Kubernetes security follows a similar journey. 

The first challenge is understanding how workloads communicate. Which namespaces talk to each other? Which connections are required? Which exist purely because they were never removed? Which could become attack paths if a workload is compromised? 

Without those answers, implementing segmentation becomes difficult and potentially disruptive. 

This is where Zero Networks starts. 

Using eBPF-based monitoring, workload communication is automatically discovered and mapped across the cluster. The Kubernetes Access Matrix provides a clear view of namespace-to-namespace relationships, helping teams understand how applications actually communicate rather than relying on outdated documentation or assumptions. 

Once communication becomes visible, organisations can begin making informed security decisions. 

Instead of attempting to segment the entire environment at once, teams can progressively introduce least-privilege controls using Kubernetes-native Network Policies. Existing policies can be synchronised from Kubernetes into Zero Networks, giving Security and Platform teams a central view of the policies already defined across the environment. 

Policies can then be reviewed and approved within Zero Networks before enforcement, adding a governance layer around Kubernetes-native controls. This allows application teams to continue defining the policies their applications require, while giving Security and Platform teams the oversight needed to ensure those policies align with the organisation's security requirements. 

Where appropriate, policies can also be automatically enforced by Zero Networks, reducing the operational effort required to implement and maintain segmentation at scale. 

This becomes particularly important as Kubernetes environments continue to change. New workloads, namespaces and communication paths are constantly introduced, making it difficult for Security teams to manually keep policies aligned with the environment. 

With automated learning capabilities being introduced, Zero Networks can take this further by learning how workloads communicate and helping create policies based on observed behaviour. Combined with automated enforcement, this can help security controls keep pace as applications and Kubernetes environments evolve. 

The result is a Kubernetes environment that looks very different from where it started. 

What was once a flat environment with unclear communication paths becomes an environment where connectivity is understood, governed and intentionally controlled. 

Attack surface is reduced. Lateral movement opportunities are limited. 

And perhaps most importantly, application, platform and security teams gain a common framework for improving security without unnecessarily slowing development or risking disruption to production. 

Just like solving a Rubik's Cube, success doesn't come from making more moves. 

It comes from understanding the puzzle, making the right move and continuing to adapt as the puzzle changes. 

Final Thoughts 

The challenge with a Rubik's Cube isn't that it's impossible to solve. 

The challenge is understanding how every piece relates to every other piece. 

Kubernetes environments present a remarkably similar problem. As clusters grow, complexity accumulates faster than understanding. Communication paths multiply, applications continuously change and responsibility becomes distributed across Application, Platform and Security teams. 

Most organisations don't struggle because Kubernetes lacks security controls. Kubernetes already provides powerful capabilities such as Network Policies. The challenge is maintaining visibility and governance as the environment evolves — understanding what should be allowed, what can be restricted and how policies can be consistently enforced without disrupting business operations. 

Zero Networks provides the visibility and governance layer that helps bring those pieces together. By providing a shared understanding of workload communication and Kubernetes-native policies, teams can identify unnecessary exposure, coordinate policy decisions and progressively enforce least-privilege segmentation at scale. 

The goal isn't simply to solve the cube once. 

It's to keep it solved as the environment continues to change. 

The timing of this trend directly coincides with the rise of frontier AI models like Mythos and Daybreak, which represent a growing class of AI-driven vulnerability research tools capable of finding, analyzing, and generating exploits for vulnerabilities at a speed and scale no human team can match – a development that led Open AI to call on CISOs to implement network segmentation.

IBM’s 2026 Cost of a Data Breach report spells out the financial weight behind this rise in machine-speed vulnerability exploitation: AI-driven attacks add an average of $1 million to the cost of a breach as new velocity and scale reshape the economics of cyber incidents.  

When patches are released at an impossible volume, the window between vulnerability discovery and exploit shrinks to nothing, and security teams face mounting pressure to protect uptime. In response, enterprises need to fundamentally rethink vulnerability management, prioritizing proactive containment rather than faster patching.  

Key Answers 

• What are the latest trends in vulnerability management? Vulnerability management is shifting from patch-speed to containment-first strategies. Frontier AI models like Mythos and Daybreak have compressed discovery-to-exploit timelines beyond what patch management cycles can match, making proactive containment a key defense.  
• Are there any new tools or techniques for vulnerability mitigation? Security teams can build a standing protection layer that limits what an exploited asset can reach with identity-based microsegmentation, buying more time to test and validate patches before deploying them without leaving the business exposed to critical vulnerabilities in the interim. Tools like Zero Networks' Breach Map help identify exposure and uncover targeted opportunities for mitigating a vulnerability.  
• How can enterprises manage the rise in discovered vulnerabilities and patches driven by frontier AI models? Security teams can't realistically test and validate every patch fast enough to keep up with frontier AI-driven discovery volume. Rather than rushing unvalidated fixes into production, enterprises should close unnecessary access paths by default, rely on identity-based microsegmentation to buy the time needed to patch safely, and prioritize remediation based on reachability.  
• What are some best practices for proactively defending against vulnerabilities? Measure blast radius to prioritize business exposure over CVSS severity alone, close unnecessary access paths by default with microsegmentation, apply targeted access rules to buy time while a patch is tested, and ensure containment is enforced architecturally so protection doesn't depend on detecting an exploit first. 

What Is Vulnerability Management?  

Vulnerability management is the ongoing practice of identifying, assessing, resolving, and verifying fixes for security weaknesses across an environment.  

Continuous vulnerability management is one of 18 critical security controls included in the Center for Internet Security (CIS) Cybersecurity Framework – in theory, an always-on cycle of vulnerability scanning, assessment, and remediation enables organizations to remediate vulnerabilities before they can be exploited. However, AI-driven attacks have challenged the assumptions that underpin traditional vulnerability management cycles.  

The Vulnerability Management Lifecycle 

Some vulnerabilities pose a greater threat than others. The vulnerability management lifecycle is meant to help organizations catch and fix the most urgent problems – it typically revolves around four core stages:  

1. Identify: Continuous scanning and asset discovery keep a network map up to date, enabling security teams to effectively identify assets that could be impacted by known and newly disclosed vulnerabilities.  
2. Assess and prioritize: Security teams score vulnerabilities by severity (often using the Common Vulnerability Scoring System [CVSS]), exploitability, and business context to determine what needs attention first. 
3. Resolve: The most common approach to resolving a vulnerability is remediation, often achieved by applying a patch. But in some cases, a patch isn’t yet available or can’t be applied without risking disruption. When full remediation isn’t possible, organizations may resolve a vulnerability through mitigation – applying controls that make the vulnerability significantly harder to exploit or minimize the impact of exploitation, even if the vulnerability technically still exists.  
4. Verify: Whether the vulnerability is fully remediated or mitigated, teams confirm the fix closed the exposure to the greatest extent possible without introducing new risk or breaking dependent systems. 

How Patch Management Works  

Patching is a tried-and-true staple in vulnerability remediation. Until now, patch management has followed a predictable cycle: a vendor discloses a vulnerability and it’s assigned a CVE, the vendor issues a security patch, and organizations test the patch before deploying it into production. Testing is a critical step in the cycle – an unvalidated fix can break critical connections and disrupt operations. Once testing clears, the patches are typically deployed on a scheduled cadence, such as Microsoft's monthly Patch Tuesday; the team verifies the fix afterward.  

This cycle was built on the assumption that the time between a vulnerability's discovery and its mass exploitation would be measured in weeks or months, giving defenders room to test patches safely before deploying. But that timeline has collapsed in the wake of frontier AI models such as Mythos and Daybreak.  

“The announcement in April 2026 of a frontier model that managed to find thousands of high-severity vulnerabilities—including some in every major operating system and web browser—is a signal warning to security teams … In the hands of attackers, these tools will collapse the time between vulnerability discovery and exploitation. Attackers are abandoning human speed for machine speed.”  

IBM, 2026 Cost of a Data Breach Report  

Why Frontier AI Broke the Traditional Patch Management Model  

Even before AI-enabled discovery and exploitation upended the threat landscape, security teams were struggling to keep up with patching – and the data proves it. Now, as attackers increasingly weaponize AI, traditional patch management workflows are an untenable solution.  

So, the rapid acceleration in vulnerability discovery is forcing already strained patch management cycles to a breaking point. For example, Microsoft released its largest Patch Tuesday ever in July of 2026: 570 fixes, including three zero-day vulnerabilities – in total, a more than 3x increase since April.  

The practical impact for defenders that continue to rely on patching as their core vulnerability management strategy is a forced tradeoff: you can patch immediately and manage updates that contain thousands of fixes at a time, or wait and validate the highest priority patches while accepting risk exposure in the interim. In either case, operational continuity is at risk.   

“We cannot patch Mythos or Daybreak away. Discovery is infinite now. We can find thousands or even millions of new vulnerabilities every day. And the patching time we have is finite – it's impossible to digest all those patches, validate that a new patch isn't generating a business impact, and move fast enough. Even with prioritization, it will always be late. Because the time AI needs to generate an exploit will always be faster than the time you need to prioritize, test, and apply the patch.” 

Albert Estevez, Field CTO, Zero Networks 

Enterprises understand the importance of taking action – 85% of organizations plan to increase security spending in response to frontier AI model threats. But simply throwing more budget at existing strategies won’t give defenders a reliable advantage. Instead, organizations need a containment-first architecture that stops attacks by design – regardless of their speed or initial access vector.  

How to Prevent Vulnerability Exploitation: 4 Best Practices for Preemptive Cyber Resilience  

Gartner noted after Mythos launched that "CIOs must tell their boards they will have to recalibrate their risk appetite for vulnerabilities because faster patch cycles won't be enough."  

The need for vulnerability management and patching hasn’t gone away, but the discipline must evolve – rather than chasing every vulnerability, organizations should prioritize cyber resilience and proactively limit the blast radius of vulnerability exploits by following these 4 best practices.  

1. Measure Blast Radius for Tailored Vulnerability Risk Insights 

While CVSS measures theoretical severity, it doesn’t clarify your business’ actual exposure. To assess the potential real-world impact of a vulnerability exploit, enterprises should map their internal network to discover reachable assets, how they connect, where attackers could move, and what they could reach. Free tools like Zero Networks’ Breach Map are the fastest way to uncover your blast radius and learn where an exploit could cause the most damage.  

2. Close Unnecessary Access Paths by Default with Microsegmentation  

Vulnerabilities give attackers an initial foothold but excessive lateral movement exposure is what turns minor cyber incidents into widespread breaches. Zero Networks' 2026 Lateral Movement Exposure Report found 80% of enterprise servers are reachable from anywhere on the network, and 85% of internal systems are directly accessible from a single compromised host. In other words, attackers typically inherit broad internal access regardless of how they initially breach the network – whether that’s via a vulnerability exploit or any other vector.  

Microsegmentation eliminates the internal pathways that exist for convenience rather than verified business need. Even if an attacker manages to gain initial access to a granularly segmented network, they’ll hit an immediate dead end because lateral movement is prevented by design.  

3. Buy Time to Patch Safely with Network- and Identity-Based Controls  

If a patch introduces outage risks of its own, it’s not a true fix. While patch availability is skyrocketing, security teams can’t realistically validate every patch quickly enough to remediate all newly discovered vulnerabilities. Even if bandwidth weren’t a barrier, OT and legacy systems can't always be patched on short notice without planning significant change windows that risk production impact. 

Organizations that have already implemented identity-based microsegmentation have built a foundational buffer against vulnerabilities; when a specific flaw poses a particularly urgent business risk, security teams have the tools in place to build a targeted rule that addresses the exposure until a patch can be deployed safely.  

For example, B. Riley Financial faced a Microsoft Outlook vulnerability involving outbound SMB traffic that left the firm exposed with no patch available from the vendor. Waiting for a fix meant leaving the exposure open, so they worked with Zero Networks to deploy a targeted rule blocking outbound SMB traffic from Outlook to the internet, closing the specific path the vulnerability relied on.   

“Having microsegmentation in place has really given us a precautionary protection layer so we can delay applying some of these patches. This gives us plenty of time to test, make sure everything’s working, and then apply it, but still have that protection layer in place.” 

- Aaron Goodwin, CISO, B. Riley Financial     

4. Automate Threat Containment Independent of Detection  

Last year, 29% of vulnerabilities in CISA’s KEV catalog were attacked before public disclosure, meaning exploitation was underway before defenders knew what to look for. Containment that depends on catching an exploit in progress inherits the same speed disadvantage as patching: a human SOC – or even an automated detection tool – still has to notice, verify, and respond before damage spreads. The probability that every step in the detect-and-respond chain works flawlessly and fast enough to stop machine-speed threats? Near zero.  

Built-in containment removes the dependency on detection and response workflows. If access paths are closed by default and enforcement doesn't require a trigger, a compromised asset can't move laterally regardless of whether the malicious activity is immediately detected. That's the difference between a reactive strategy and architecture that makes the attack's next move impossible from the start – and it becomes more consequential every month frontier AI compresses the window for containment.  

Build Proactive Vulnerability Protection in the AI Era with Zero Networks  

Zero Networks’ automated, identity-based microsegmentation agentlessly orchestrates native firewalls to isolate every asset, preventing lateral movement and building a containment layer against vulnerability exploits – no matter how quickly they’re executed.  

Unlike reactive tools that depend on known indicators, Zero builds a proactive security posture that prevents attacks from spreading at the architectural level, effectively mitigating the impact of vulnerabilities so security teams can protect business continuity while buying time to patch safely.  

Get a firsthand look at how you can build a closed-by-default architecture and stay resilient against machine-speed threats – request a demo.  

Manufacturing organizations can’t afford to rely on detection and response. Security teams know microsegmentation is the answer for building preemptive cyber resilience, but legacy approaches have a track record of failing manufacturing environments specifically: complex, agent-based deployments strain lean IT teams, manual policy management can't keep pace with production schedules, and the fear of breaking a live system stalls projects before they start. 

This roundup features three Zero Networks customers that successfully deployed identity-based microsegmentation to strengthen cyber resilience without adding operational complexity. We'll walk through how these manufacturers eliminated downtime risk during implementation, met cyber insurance requirements, and extended protection to legacy systems without disrupting the infrastructure their operations depend on. 

Non-Disruptive Network Segmentation: Eliminating Outage Risk 

Many manufacturers implementing microsegmentation fear that a new security tool might lead to operational disruption. Reconfiguring network architecture often risks the exact outcome security teams are trying to prevent: unplanned downtime. That’s why half of manufacturing security leaders point to implementation complexity as their top microsegmentation concern, followed closely by disruption to existing operations. 

Real-World Examples 

Vermeer manufactures the industrial and agricultural equipment that keeps global communities fed and fueled. The security team was on a mission to find a virtual airgap solution that could enhance overall security, but with a complex network and no appetite for downtime, Vermeer couldn’t rely on traditional tools or manual approaches.  

Atlantic Constructors – a commercial construction, prefabrication, and industrial services provider – faced a version of the same concern. Rising cyber insurance requirements pushed the team to look for a microsegmentation solution, but every other product they evaluated threatened a long, complex implementation that could disrupt the business before it delivered any protection. 

The Solution: Agentless Deployment and Deterministic Policy Automation 

Vermeer and Atlantic Constructors achieved granular protection without the outage risks and implementation complexity of legacy microsegmentation tools thanks to Zero’s automated, agentless approach:  

• With an agentless architecture, Zero Networks orchestrates native, host-based firewalls already present in the environment, avoiding the latency and integration risk that comes with agent-based tools. 
• A defined learning period allows Zero's automation engine to observe real traffic and build policies from actual network behavior, removing the upfront manual burden.  
• Policies generated and enforced via deterministic, human-on-the-loop automation reflect what the network actually needs to keep running securely, not a best guess that risks blocking legitimate traffic. 

“[Zero Networks] is an agentless solution, so it’s relying on the network firewall that’s native to Windows which allows us to control both allows and denies to the PC or the host that the connections are going between. And then on top of that, they have the automatic engine that is learning, and taking that data, and translating it into rules.”  

Justin Manifold, Senior IT Security Engineer, Vermeer  

By leveraging Zero’s non-disruptive, deterministic solution, Vermeer segmented their network in 30 days while maintaining 100% of legitimate traffic. Similarly, Atlantic Constructors deployed Zero in just 15 minutes, ultimately improving network performance and reliability by 100%. 

Legacy Systems and Vendor Lock-In: Extending JIT MFA Everywhere  

Manufacturing environments are built on decades of accumulated infrastructure that many security tools aren’t designed to address. Microsegmentation vendors that require complex configurations and proprietary MFA tools force manufacturers to accept coverage gaps or introduce additional complexity into an environment that can't afford failure.  

Real-World Examples 

Mikron is the leading partner for high performance production systems, building the complex components used to produce the things that matter – pharmaceutical devices, precision medtech, automotive parts, and more. With frequent changes to the environment, maintaining consistent policies via Group Policy Objects (GPOs) proved nearly impossible, but other segmentation vendors couldn’t easily integrate with Mikron’s existing environment and required proprietary MFA systems that threatened continuity.  

Similarly, Vermeer needed a way to protect privileged access without introducing the kind of friction that would disrupt the production and engineering workflows already running smoothly. 

The Solution: Just-in-Time Network-Layer MFA  

Mikron and Vermeer closed identity least privilege gaps without risking critical connections or leaving legacy systems vulnerable by enforcing Zero’s network-layer MFA for just-in-time access:  

• Network-layer MFA extends authentication to admin protocols and privileged activities without touching the underlying legacy systems or introducing new failure points. 
• Seamless integration with existing infrastructure means a consistent user experience rather than forcing a second, proprietary authentication system into the environment. 
• Added on top of identity-based microsegmentation, network-layer MFA effectively prevents compromised credentials from delivering access to production-critical systems.  

For Vermeer, the addition of network-layer MFA gave the security team confidence to strengthen privileged access protection while maintaining the stability its always-on manufacturing environment requires. Since Zero Networks integrated seamlessly with Mikron’s environment – no proprietary tooling or rip-and-replace approach required – Mikron achieved the comprehensive protection they needed without risking operational disruption, completing full network segmentation rollout within weeks and at a fraction of the effort GPOs demanded.  

Cyber Insurance and Compliance Requirements: Validating Protection 

In the industrial sector, cyber insurance has become table stakes, and carriers are asking for proof that cybersecurity strategies translate to real resilience. Over two-thirds of manufacturers say their cyber insurance carrier requires network segmentation specifically, and that mandate is only getting harder to satisfy with labor-intensive legacy approaches.  

Real-World Example 

Atlantic Constructors' search for a microsegmentation solution was driven directly by rising cyber insurance requirements. The team needed to strengthen its overall security posture in a way that would hold up to scrutiny – and once Zero Networks was deployed, the organization put it to the test.  

The Solution: Cyber Resilient Segmentation Architecture 

With Zero’s identity-based microsegmentation in place, Atlantic Constructors unlocked the compliance evidence they needed without creating a new manual burden for the security team:  

• Continuous, automated policy enforcement generates audit-ready evidence of segmentation as a byproduct of normal operation, rather than requiring a separate compliance exercise. 
• Because policies enforce least-privilege access by default, the pathways attackers and penetration testers rely on are closed structurally, before a test ever finds them. 
• Real-time network mapping demonstrates current resilience posture, unlocking up-to-date visibility into real risk exposure.  

“After we got Zero, I decided to run another pen test to see how things were working, and we literally could not get it to penetrate one of the machines we were testing … We did some speed tests and [network] performance probably doubled. Reliability went up 100%.” 

Jim Paolicelli, IT Director, Atlantic Constructors 

With the impact of microsegmentation validated through penetration testing, Atlantic Constructors ultimately traded multiple legacy platforms for Zero Networks’ unified solution.  

Built-in Cyber Resilience and Supply Chain Stability with Zero Networks  

From outage risks due to implementation complexity to legacy system constraints and beyond, manufacturers have long faced microsegmentation hurdles that cause initiatives to stall. Zero Networks removes those barriers and enables manufacturing organizations to secure complex environments, protect legacy systems, and boost operational resilience in days – not years.  

By delivering automated, identity-driven microsegmentation that seamlessly integrates with existing infrastructure combined with network-layer MFA for privileged access, Zero removes the manual effort and outage concerns that make legacy tools too risky to industrial orgs.  

See how Zero Networks makes cyber resilience practical for manufacturers – request a demo.  

We’ll break down why machine identities are uniquely risky, how attackers exploit overprivileged service accounts and AI agents, and what enterprises can do to expand least privilege enforcement to every network identity – from human users and admins to service accounts and AI agents.  

Key Answers 

• What are non-human identities (NHI)? An identity used by software rather than a human user to authenticate and access systems, such as service accounts, AI agents, cloud workloads, or APIs. 
• How can security teams protect service accounts and machine identities from abuse? By discovering every identity in the environment via an automated solution, scoping access to observed operational need identified during a learning period, and enforcing granular, identity-based access controls, backed by automated policy management that adapts as the network changes. 
• What are some best practices for AI agent access control? Treat every agent as its own governed identity: discover what's running, scope access to what each agent's function requires, and apply the same identity-based restrictions used for human users rather than granting AI agents ambient trust. 
• How can enterprises enforce least privilege across non-human identities? Continuously map what every identity – including service accounts and AI agents – can reach, restrict identities to pre-approved assets and logon types, and automate policy updates so access stays current as the network changes, rather than relying on static rules or manual review. 

What Is Non-Human Identity (NHI) Security?  

NHI security is the practice of applying the same governance to machine identities, service accounts, API keys, workload identities, and AI agents that enterprises enforce for human users.  

While “machine identity” originated as a narrower term for cryptographic credentials and “non-human identity” was introduced as a broader umbrella term, both are used to cover the same expanding category in practice: identities used by software (rather than human users) to authenticate and gain access to systems.  

This category encompasses a range of subtypes, with some of the most common including: 

Although every non-human identity carries a unique risk profile, two types in particular represent the greatest enterprise threat today: service accounts and AI agents.   

Machine Identity Security Risks and Challenges  

Like most non-human identities, service accounts and AI agents share an underlying set of risks: they run on standing access that’s rarely reviewed after being provisioned, and they’re built to operate in the background, so misuse goes unnoticed. What differs is how fast access accumulates and how well-established the governance gap already is – service account sprawl is an established vulnerability, while the full scope of the agentic attack surface is still unfolding. Some of the most pervasive NHI risks span: 

• Static credentials with no MFA checkpoint: AI agents operate across open-ended workflows without a human approving each step – they authenticate, hold tokens, and gain access autonomously through accumulated entitlements, yet less than half of organizations report securing NHI in AI workflows. Likewise, service accounts run on static credentials that are rotated quarterly at best, with some organizations even setting them to never expire at all, since rotating a credential tied to a live production process carries operational risk of its own.  
• Standing permissions and privilege creep: Many service accounts are over-provisioned with domain admin or enterprise-wide access that’s not operationally necessary. The same is true for agentic identities – the more tasks AI agents are assigned, the more entitlements they accumulate through policy drift, tool chaining, and expanding scope.  
• Shadow AI and the agentic governance gap: Nearly 80% of enterprises are already deploying AI agents internally, and roughly two-thirds have no governance policies in place to manage them. That gap starts as a visibility problem – security teams can’t discover, let alone control the shadow AI running in their environment. Sanctioned or not, agentic adoption is expanding AI attack surfaces faster than organizations can scale governance.  
• Activity evades detections tools: Service account and AI agent traffic blends in with normal activity because it relies on legitimate access. When attackers exploit those permissions to move laterally and access sensitive systems, the threat stays hidden from detection tools since it doesn’t look anomalous.  

How Attackers Exploit Overprivileged Service Accounts and AI Agents: Real-World Scenarios 

The risk of NHI exploitation isn’t theoretical – it’s a documented threat, backed up by real-world attacks.  

Stored Service Account Credentials Create Lateral Movement Pathways  

An incident response investigation carried out by Michael Matok, Incident Remediation & Recovery Lead at Sygnia, uncovered that after attackers breached a vulnerable NetScaler appliance via a widely exploited CVE, service account credentials stored in the compromised systems ultimately allowed attackers to move laterally via RDP.  

What should have been a low-privilege, read-only LDAP bind account had accumulated far more access than necessary, enabling hackers to pivot, change a domain admin account’s password, and take control. In other words, one misconfigured service account turned an initial foothold into a widespread breach.  

Agentic Threats Move Laterally at Machine Speed  

In July of 2026, Hugging Face disclosed an intrusion into its production infrastructure, later attributed by OpenAI to its own models operating autonomously during an internal security evaluation. The models found a zero-day in a package proxy, escalated privileges, and moved laterally through Hugging Face's internal infrastructure – autonomously – until they reached the target data in a production database.  

While the AI vector is distinct, the lesson is similar to takeaways from attacks involving overprivileged service accounts: when networks aren’t built to constrain lateral movement by design, a single vulnerability exploitation can quickly spiral into a business-impacting incident. 

How to Enforce Least Privilege for Non-Human Identities  

Closing machine identity security gaps isn’t a matter of layering on more monitoring to the same static access models. Instead, enterprises need dynamic access enforcement built around how non-human identities actually behave. 

Discover Every Service Account and AI agent in the Environment  

Because service accounts typically operate in the background, they’re notoriously hard to monitor. Similarly, widespread AI adoption – often beyond IT oversight – has created a massive AI agent blind spot in many enterprises. The first step in enforcing least privilege controls for NHI is implementing continuous network monitoring that maps every identity, tool, and connection in the environment, forcing shadow AI and long-hidden service accounts into the spotlight.

Scope NHI Access to Business Need  

Visibility establishes what agents and service accounts can reach; the next step is understanding what access they need to perform their intended functions. By observing real network behavior over time, security teams can identify which connections are genuinely necessary, where provisioned access exceeds true requirements, and where that gap creates the riskiest exposure. With this learned baseline, teams can down-scope access to reflect operational need without breaking key connections.  

“Among organizations that suffered AI-related breaches in this year’s study, 92% lacked proper access controls. This finding reveals a systemic failure to treat identity as mission-critical infrastructure. In the race to deploy AI agents to automate business processes—including security operations defending against frontier AI models—teams must fundamentally transform identity systems to secure not just humans, but NHIs, too.” 

IBM, 2026 Cost of a Data Breach Report 

Enforce Granular, Identity-Based Access Controls 

Granular access controls must apply to every identity – human, machine, or AI. Service accounts, AI agents, and all machine identities should be restricted to pre-approved assets and logon types, ensuring lateral movement and unauthorized access to sensitive systems are blocked even if machine identities are compromised.  

Automate Policy Lifecycle Management with a Deterministic Engine  

Modern enterprise environments are too dynamic for static, IP-centric policies that govern a location rather than an identity; that’s why Gartner says it’s time to pivot from IP-centric rules to unified identity fabric where enforcement adapts dynamically.  

“The shift from network-centric to identity-first segmentation is a response to the evolution of traditional perimeters to hybrid architectures, the rise of dynamic, cloud-native environments, and the adoption of NHI … Relying on static, IP-based microsegmentation guarantees catastrophic vulnerability to AI-driven attacks.” 

Gartner, Reimagining Network Microsegmentation: Beyond the IP – Identity, Context, and Agentless Innovation

A deterministic policy engine that leverages learned network baselines to create accurate rules can also be used to automatically adapt policies as the network changes, ensuring access is always tailored to identity.  

Close Identity Least Privilege Gaps with Zero Networks  

Most organizations struggle to answer a simple question: how many service accounts and AI agents are running in their environment right now, and what can each one actually reach? That blind spot, not attacker sophistication, turns a single overprivileged non-human identity into a business-disrupting breach.  

Zero Networks closes the least privilege gaps that have traditionally left machine identities over-permissioned and under-monitored with automated, identity-driven microsegmentation. Zero makes it easy to discover and control service accounts, AI agents, and every other identity:  

• After deploying in a click, Zero delivers comprehensive visibility into every network asset and identity on the network before tracking all logon activities, account behaviors, and asset access patterns during a learning period.  
• A deterministic automation engine maps observed network behavior, generates least-privilege policies based on learned baselines, and keeps teams in control through human-on-the-loop simulation and staged rollout before enforcement. 
• Identity-based policies govern access at the network layer, tied to user, machine, or AI identity, and automatically updated as environments change.  

Learn how you can secure service accounts and AI agents without slowing the pace of innovation in your organization – request a demo.  

While most businesses know what their critical assets are, far fewer have a clear understanding of their true cyber risk exposure – or what to do about it. This is especially true for cyber pros watching AI proliferate in the wild and within their networks; most organizations are still working to understand external and internal AI threat exposure, let alone forge a path to AI control. We’ll lay out a framework for analyzing attack paths as part of a business impact analysis, enabling security leaders to build a cyber resilience strategy that directly maps to business outcomes.  

Key Answers 

• How does attack path analysis work? An attack path analysis traces the route an attacker could take from an initial point of compromise to a critical asset and measures the controls that stand in the way to uncover the true scope of exposure. This can be completed as a phased process (involving discovery, modeling, and pathfinding), or automated using free resources like Zero Networks’ Breach Map tool.  
• What is the role of an attack path analysis in a business impact analysis (BIA)? A BIA identifies which assets are critical and what downtime would cost; attack path analysis clarifies how exposed those critical assets are and identifies priority interventions for security leaders targeting cyber resilience objectives.   
• How should enterprises prioritize business resilience investments? By identifying the attack paths with the highest business impact relative to containment readiness, then implementing controls that increase path distance or eliminate entire attack scenarios (like microsegmentation), minimize privilege exposure (just-in-time authentication), and constrain potential damage to key resources (identity-based access controls). 

What is Attack Path Analysis?  

An attack path analysis identifies the route an attacker could take from an initial point of compromise to a critical asset, translating unstructured risk exposure insights into a view of real, exploitable paths.  

In the context of a business impact analysis (BIA), attack path analysis shouldn’t only identify exploitable attack paths to critical assets specifically but should also uncover the interventions that will most meaningfully improve cyber and operational resilience. 

How to Use Attack Path Analysis in a BIA 

A business impact analysis starts with identifying which systems and assets are critical to the strategic success and day-to-day operations of the company. Documenting critical assets – and establishing a baseline estimate of what downtime would cost – is the first step in tailoring cyber resilience strategies to business priorities. An attack path analysis answers the logical follow-up question: how exposed are critical assets?  

To uncover the scope of business exposure, attack path analysis maps open pathways and evaluates the level of effort it would take an attacker to move from a common ingress point to a critical asset, giving organizations a documented map of true exposure tied to likely attack tactics rather than a general sense of risk.  

A list of critical assets tells you what’s important, not where to act first. A cyber resilience focused attack path analysis turns that list into a prioritized map of where risk exposure and business impact intersect most sharply. 

Attack Path vs. Attack Vector vs. Attack Surface  

Security teams will deal with three related yet distinct terms when mapping and evaluating attack paths as part of a BIA:  

• Attack surface is the sum of all points in your environment where an attacker could potentially gain entry or exploit a vulnerability – every exposed port, every identity, every endpoint, every cloud workload, and every third-party integration. The larger and more complex your environment, the broader your attack surface.  
• An attack vector is the specific method an attacker uses to exploit a point in the attack surface and gain an initial foothold. For example, compromised credentials or vulnerability exploitation are common attack vectors.  
• An attack path is the route an attacker travels along through the environment after gaining initial access to reach critical assets – the amount of damage they could do along the way makes up an organization’s blast radius.  

In other words, attack surface describes what can be breached, an attack vector is how breaches can occur, and attack paths illustrate where adversaries can go after gaining initial access to eventually reach critical systems.  

4 Attack Vectors to Map for Every Critical Asset  

Starting with the most business-critical assets, security teams should analyze attack paths using scenarios that reflect today's threat landscape: 

• Compromised user: A standard user account compromised through phishing, credential theft, or malware.  
• Compromised cloud identity or AI agent: Stolen credentials or session tokens for a SaaS, IaaS, or agentic identity, often exploited to pivot into on-premises resources through federation, single sign-on trust relationships, or an AI agent’s standing access. 
• Technical perimeter entry: Exploitation of an internet-facing device or service, such as a VPN concentrator, edge firewall, or public-facing web application, to gain code execution and a foothold for further lateral movement. 
• Trusted vendor/third-party access: A compromised or malicious third party using pre-existing privileged access, like a vendor VPN connection or API integration, to reach internal systems. 

For each critical asset, trace the shortest plausible path per vector.  

How to Map Attack Paths: Discovery, Modeling, and Pathfinding  

With critical assets and relevant attack vectors identified, security teams can begin mapping the attack paths they’ll use to analyze exposure – when done manually, this typically happens in three stages:   

1. Discovery: Inventory Systems, Identities, and Connections 

Uncovering attack paths starts with an accurate view of all network assets, identities, connections – including service accounts, AI agents, and other traditionally under-monitored parts of the network – to effectively track how they might contribute to an exploitable pathway between a given entry point and a critical asset.  

2. Modeling: Uncover Communication Pathways  

Convert discovered inventory into a graphical view of what’s reachable across on-prem, cloud, IoT/OT, and Kubernetes: which systems and identities can access which assets, through what trust relationships, and whether or not that access shows up in routine traffic. 

3. Pathfinding: Chain Exploitable Steps Together  

Starting from a pre-defined entry point, trace the routes an attacker could exploit, including paths gated behind authentication or JIT approval, that lead to a critical asset. At enterprise scale, this usually requires graph traversal algorithms to enumerate every path reachable from an entry point to a given asset.  

Automated Attack Path Mapping  

For enterprises that need an accurate view of exposure without months of manual background work, free tools like Zero Networks’ Breach Map automate all three stages. Breach Map scans the internal network to discover reachable assets, then generates an interactive visual map showing how assets connect, where attackers would move, and what they could reach. 

The report surfaces total assets discovered, how many are reachable via lateral movement, average blast radius, attack surface, and direct and indirect crown jewel risk – without weeks of manual discovery and log analysis. It also acts as a personalized benchmark tool for cyber leaders and teams as they work to lock down key attack paths. 

Analyzing Attack Paths: How to Measure Cyber Risk Exposure  

After mapping attack paths from entry point to critical asset, security teams can analyze paths against three threat containment metrics that signal the true scope of exposure.  

Path Distance: How Attackers Move Laterally Through the Network 

Path distance is the most consequential dimension to measure, because interventions here can remove risk rather than just raising its cost. For example, microsegmentation can close lateral movement pathways and effectively eliminate entire compromise scenarios. For the purposes of measuring containment, focus on assessing four things:   

• Authentication boundaries crossed: Distinct credential challenges between entry point and asset, excluding any boundary satisfied by credentials the attacker already holds. 
• Network segments traversed: Segments governed by actively enforced, granular policy – not segmentation that exists on paper but permits broad access in practice due to accumulated exceptions and policy drift. 
• Enforced inspection points in path: Tools actively operating in prevention mode; detection-only controls don't count, since they depend on a human responding in time. 
• Cross-domain traversal: Genuine trust boundary crossings, like on-prem to cloud or IT to OT, that demand a distinct credential set rather than one satisfied by shared federation. 

Privilege Requirements: What Permissions Attackers Need to Access Critical Assets  

Reaching an asset isn't the same as accessing it. Privilege requirements measure how difficult it is for an attacker to obtain the privileges needed to actually impact a critical asset. As a measure of containment, this dimension carries less weight than path distance because privilege controls typically raise the cost of an attack (rather than removing the route entirely via structural controls), but the two are deeply interconnected. Privilege requirements should be captured through details like:  

• Escalation levels required: Each distinct privilege escalation is a separate point of potential failure for attackers, though shortcuts like cached credentials or over-provisioned service accounts can collapse multiple levels into one. 
• Persistent privileged access: Standing access without just-in-time reauthentication means a single compromised credential can be a ticket to critical assets on its own. 
• Service account density: Broadly scoped service accounts are frequent escalation targets and are often excluded from user activity monitoring. 

Additional authentication requirements: Hardware tokens or out-of-band approval that the entry vector can't reasonably satisfy caps the blast radius outright. 

Data-Layer Controls: Limiting Damage After a Breach 

The final containment dimension to assess along identified attack paths answers the only remaining question: if an attacker reaches the critical asset and manages to gain access, how much damage can they do? This can be measured through controls such as:  

• Encryption at rest: With separated key management, a successful compromise can corrupt or delete data but not read or exfiltrate it. 
• Identity-based access controls: Granular access controls limit what any single compromised identity can reach even after accessing a resource, enforcing a final layer of protection for the most sensitive data.  

How to Identify Top Business Resilience Priorities and Investments  

After analyzing attack paths to critical assets for current containment controls, security leaders should have three things:  

1. An inventory of business-critical assets and an understanding of downtime thresholds  
2. A view of all pathways from common ingress points to those critical resources  
3. A breakdown of how exposed the exploitable paths truly are, measured against containment controls  

With these insights, the final analysis can be completed – the goal is to find where business impact and containment readiness converge most sharply. For example, if a billing system has an extremely low downtime threshold due to its high revenue impact but is directly accessible within two lateral movement pivots via compromised user credentials, then it should rank as a high priority.  

With priorities defined, security leaders have a blueprint for tying cyber resilience directly to business impact. Resilience strategies should be implemented using same threat containment dimensions that help uncover risk exposure and define urgency:  

• Increase path distance or completely remove pathways to critical assets: Granular network segmentation, additional authentication boundaries, and inspection points can eliminate entire compromise scenarios. 
• Reduce privilege exposure: Eliminating persistent privileged access, reducing service account scope, and enforcing just-in-time reauthentication or additional authentication requirements for critical assets can rein in the privilege sprawl attackers rely on.  
• Enforce data layer controls: Implementing granular identity-based access controls and encryption at rest limits the damage an attacker can do if they manage to reach critical systems. 

As security leaders take a more active role in business continuity, this framework delivers a repeatable way to align cyber resilience strategies with board-level priorities.  

Cyber Resilient by Design: Protect Uptime with Zero Networks' Automated, Identity-Driven Microsegmentation  

Zero Networks proactively blocks threats to protect operational continuity with automated, identity-based microsegmentation, delivering the containment layer environments need to close attack paths without impacting legitimate traffic.  

Zero provides immediate visibility into every identity and asset on the network, then automatically enforces adaptive, identity-aligned policies based on observed network behavior. With always-current network visibility and a deterministic, human-on-the-loop automation engine, Zero Networks delivers preemptive cyber resilience with no manual effort or operational complexity. 

Learn how you can build a closed-by-default architecture that measurably improves business resilience – request a demo.  

Automated containment is the foundation of cyber resilience, translating to defensible uptime protection. When attackers move in seconds, AI-enabled workflows execute in parallel, and identity systems authenticate continuously, human response cycles can’t keep up, so defenders’ only durable advantage is limiting access by default. 

We’ll walk through a simple framework for benchmarking your current network resilience on the path to automated containment and share a roadmap for building a self-defending architecture.  

Key Answers  

• How does automated containment strengthen cyber resilience? Automated containment strengthens cyber resilience by constraining blast radius structurally, so a compromised asset is isolated automatically rather than depending on a team to detect and respond fast enough. This shifts resilience from a reactive workflow to a demonstrable outcome – uptime and continuity hold during an incident because containment is built into the architecture itself, not bolted on after the fact. 
• What are the pillars of network resilience? Containment architecture, identity and access governance, network visibility, and policy automation are the four central priorities for building network resilience. Together, they proactively minimize blast radius to contain the impact of any attack.  
• What does a self-defending network architecture look like? Automated, identity-aware microsegmentation keeps access paths closed by default, privileged access requires just-in-time authentication, and a real-time network map informs dynamic policy automation, so coverage adapts as the network changes.  

5 Stages of Network Resilience: Maturity Benchmarks  

Cyber resilience isn’t just about recovering from a breach – it’s about preventing the breach from spreading in the first place, so sensitive systems stay isolated and critical operations keep running. Rather than more automated detection or faster response, true resilience limits the impact of a breach automatically by proactively constraining blast radius.  

Because network resilience refers to an infrastructure’s capacity to provide continuous business operations, it’s the most direct measure of security success against business priorities – and it’s achieved when four interconnected capabilities work together:  

1. Containment architecture: How granularly assets and workloads are isolated from one another – and how much of the environment is accessible from any given foothold – defines the structural ceiling on how far a breach can travel, known as the blast radius.  
2. Identity and access governance: Network architecture defines the shape of the environment; identity determines who can move through it, where they can go, and under what conditions. 
3. Network visibility: Comprehensive, real-time visibility across every asset, workload, identity, and communication pathway ensures that resilience controls reflect the environment as it actually exists.  
4. Policy automation: A security posture held together by manual processes and periodic reviews will drift as the environment changes; automation ensures controls adapt continuously rather than degrade slowly. 

With these pillars in mind, organizations can map their network resilience against a simple five-stage framework:  

• Stage 1 – Flat and Blind: Everything trusts everything and there are no East-West controls.  
• Stage 2 – Alert-Heavy: Tools like EDR and SIEM provide visibility without containment.  
• Stage 3 – Early Containment: Some level of segmentation has been implemented but policies are manual and constantly multiplying. 
• Stage 4 – Automated Containment: Identity-aware segmentation automatically blocks unauthorized lateral movement. 
• Stage 5 – Self Defending: Adaptive controls create an audit-ready posture and breach containment is built into the network architecture. 

According to Chris Boehm, Field CTO at Zero Networks, most organizations sit between stages two and three today – they have tools in place, they complete red teaming exercises, and they meet basic compliance requirements, but they’re grappling with an unmanageable alert volume.   

“A developer says, 'I need access to everything or I won't get this done.' You open holes temporarily. A temporary hole here, a temporary hole there. You're paying someone $200,000 a year and you just need to get them going. That's how most organizations end up between stages two and three.”  

- Chris Boehm  

Benchmarking your current network resilience across core pillars delivers a clear starting point for building automated containment and, in turn, strengthening cyber resilience.

Automated Containment Roadmap: How to Build a Self-Defending Network Architecture 

As security leaders are increasingly tasked with proving a zero-tolerance policy for downtime, building automated containment – that dynamically adapts as the environment changes – into the network architecture is the most reliable path to true network resilience.  

Regardless of where your resilience posture sits today, you can reach a self-defending state in months by following a four-step roadmap:  

1. Map Every Network Asset, Identity, and Connection 

Manual discovery has historically taken months and gone stale almost immediately, since new assets and accounts appear faster than periodic audits can track them. By leveraging an automated solution, security teams can immediately pinpoint all assets and identities then learn logon activities, account behaviors, and asset access patterns to establish a baseline without the months of manual effort.  

This is the step that pulls flat, alert-heavy networks out of established blind spots, where East-West and inter-VLAN traffic often lacks visibility.  

2. Generate Deterministic, Identity-Aware Segmentation Policies  

Using the behavioral baselines learned through real network mapping and observation, a deterministic, human-on-the-loop automation engine generates and enforces granular, identity-based policies that precisely lock down unauthorized lateral movement without impacting legitimate operations.  

This step replaces implicit internal trust with explicit, least-privilege access, moving organizations out of early containment stages – where manually scoped exceptions keep multiplying to create gaps – and into automated enforcement. 

3. Enforce MFA on Privileged Internal Pathways  

Four admin protocols account for an outsized portion of lateral movement – 71% of enterprise threat activity flows through SMB, RDP, WinRM, and RPC. Business operations depend on privileged internal pathways like these, which is why they typically remain open, even in organizations that have made meaningful network segmentation progress. The fix is adding just-in-time network-layer MFA to make privileged access verified and time-bound, ensuring attackers hit a dead-end while legitimate operations keep moving.  

This is the identity governance evolution that closes least privilege security gaps, so attacks are automatically contained regardless of how they gain initial access.  

4. Automate Policy Updates Alongside Network Changes  

Modern enterprise environments never stop shifting; static policies can’t provide consistent coverage. The combination of real-time network visibility and deterministic automation closes this gap without manual overhead – new assets, identities, connections, and behaviors are automatically mapped and addressed with fine-grain policies, unlocking a self-defending architecture for true network resilience.

Fast-Track Cyber Resilience Success with Zero Networks  

Zero Networks delivers the proactive containment layer enterprises need to protect uptime with automated, identity-based microsegmentation, unlocking 91%+ segmentation coverage within 90 days.

Zero granularly segments every asset and identity with adaptive policies based on observed network behavior. This dynamic approach means containment remains an automatic architectural feature, even as environments change – removing the privilege creep and rule sprawl that create gaps in static architectures.   

By strengthening every pillar of network resilience, Zero enables security teams to build a mature, business-aligned posture without adding operational complexity or manual effort – request a demo to learn more.  

CertiGhost allows a basic Active Directory account to become a full domain takeover by tricking a trusted certificate system into treating the attacker like a domain controller. Installing Microsoft’s July 14 patch is important, but security teams should also confirm the protection is actually active across their environment. CISOs and their security teams should restrict certificate servers so they can communicate only with approved systems and block unauthorized attempts to copy sensitive identity data from domain controllers. The larger lesson: patches fix individual flaws, while segmentation and tight access controls can stop entire categories of attack.

Microsoft fixed CertiGhost on July 14, 2026. Researchers H0j3n and Aniq Fakhrul published a working proof-of-concept ten days later. If your CAs and domain controllers took the July updates, you are probably in reasonable shape — but you should be aware of the patch-versus-enabled loophole attackers are betting on and go verify that the fix is actually enforcing on your CAs and DCs, not just sitting around installed but inactive. 
I want to share a note on what “patched” means in AD CS specifically. When Microsoft shipped the SID security extension in May 2022 to counter Certifried (CVE-2022-26923), the fix arrived in a compatibility mode that still permitted weak certificate mapping. Full enforcement did not become the default until February 2025, three years later, which means the fix was installed almost everywhere but enforced almost nowhere unless an administrator knew enough to go investigate it. That’s a wide open door for attackers to sneak through. 
The CertiGhost fix leaves a similar attack vector open to attackers – but it hides in plain sight. The new validation sits behind a Windows velocity feature gate — Feature_3185813818 in the patched certpdef.dll, guarding the branch that calls _ValidateChaseTargetIsDC. Velocity gates are ordinary servicing machinery, not evidence of an incomplete fix: they let Microsoft stage, wave, or roll back a change without shipping a new binary, and MSRC security fixes are one of the things they gate. Most security features ship as always-enabled, in which case the gate is a rollback lever nobody will ever pull. What this means to real security teams is that enforcement is a runtime state rather than a property of the build, and a runtime state is something you have to confirm on your own CAs rather than infer from a patch level.
The rest of this post is about the more uncomfortable question. CertiGhost is a low-privileged domain user turning into krbtgt in a single automated script. The chain is short, the prerequisites are close to default, and nothing in it exploits memory corruption or breaks cryptography. It is a missing validation in a trust decision.
Since Will Schroeder and Lee Christensen published Certified Pre-Owned in 2021, the community has kept a running catalogue of AD CS escalation paths: ESC1 through ESC8 in the original research, extended by later work to ESC17. It's not a Microsoft scheme and not a CVE series — it’s an informal numbering that grows whenever someone finds another way to turn certificate issuance into domain privilege. Most of the seventeen are misconfigured templates or weak ACLs on PKI objects. Two of them, ESC8 and ESC11, are relay attacks that work for no reason more sophisticated than an enrollment endpoint being reachable by something that should never have reached it. CertiGhost belongs to the same family: the CA made a trust decision on data an attacker supplied. There will be an eighteenth.
So: if you had not patched on July 14, what in your network would have stopped this?
For most environments the honest answer is nothing, because the attack looks like ordinary Windows traffic at every step. But two of the four network legs in the chain are gateable with controls that don’t know or care that CertiGhost exists. That is the point worth making. 

Key answers in this article

• What is CertiGhost (CVE-2026-54121) and why does patching alone not close the risk? CertiGhost is an Active Directory Certificate Services (AD CS) exploit chain that turns a low-privileged domain user into a domain controller by tricking a certificate authority into signing a DC-identity certificate, which converts into krbtgt compromise via PKINIT and DCSync. Microsoft patched it July 14, 2026, but the fix ships behind a Windows velocity feature gate, meaning enforcement is a runtime state on each CA rather than a guaranteed property of the patch — the same pattern that left the 2022 Certifried fix in compatibility mode for nearly three years.
• How does the CertiGhost attack chain actually work? The exploit abuses AD CS's "chase" fallback, where a CA follows attacker-supplied cdc and rmd enrollment attributes to a secondary lookup host without validating it's a real domain controller; an attacker stands up rogue SMB/LDAP/LSA services, creates a machine account via the default ms-DS-MachineAccountQuota, relays Netlogon authentication to a real DC, and receives a certificate carrying that DC's identity.
• What single network control neutralizes the most dangerous leg of the attack? Default-deny egress on the certificate authority — permitting outbound SMB and LDAP only to known domain controllers — collapses the attack before identity confusion occurs, because this control requires no knowledge of CertiGhost, no signatures, and no patch-level awareness; it simply enforces that a CA's legitimate outbound peer set is small, stable, and enumerable.
• Why does per-asset microsegmentation matter more than per-subnet or VLAN-based rules? A CA sitting in a broad server VLAN with permissive east-west traffic has effectively no egress policy at all; the defensive value comes specifically from scoping rules to the individual asset (or even the process, like certsrv.exe), since CAs have a narrower legitimate communication footprint than the network segment they sit in.
• What is the single highest-ROI rule for blocking this entire class of AD CS attacks? Denying DCSync (MS-DRSR / DRSGetNCChanges) from all non-domain-controller sources is a narrow, low-breakage rule that neuters CertiGhost, every AD CS ESC escalation path, Zerologon, and any other attack whose final move is replicating secrets out of the directory.
• What's the broader architectural lesson beyond this one CVE? CertiGhost will be patched and forgotten within months, like the ESC series before it — but every one of these bugs shares the same weakness: a trust decision made on attacker-influenced data. The defense that ages well isn't one that recognizes cdc specifically; it's one that constrains what a compromised or confused asset can reach, since a CA that can't open SMB to an arbitrary host is indifferent to which validation was missing this time.

The chain, briefly

Certificate enrollment in AD CS has a fallback path the researchers call a chase. When the CA can’t resolve the requester’s directory object locally — a real scenario in multi-domain forests with replication lag — the enrollment request may carry two attributes that steer a secondary lookup: cdc, naming the host the CA should contact, and rmd, naming the principal to resolve.
Before the July patch, the CA followed the cdc value without confirming that the host was actually a domain controller. In certpdef.dll, CRequestInstance::_LoadPrincipalObject read the attribute straight out of the request and passed it into _GetDSObject with chase enabled. The July build wraps that call in _ValidateChaseTargetIsDC, which rejects IP literals, LDAP metacharacters, and oversized hostnames, then queries AD for exactly one computer object whose dNSHostName matches and whose userAccountControl carries SERVER_TRUST_ACCOUNT (8192).
The exploit stands up rogue SMB, LDAP, and LSA services on an attacker-controlled host, creates a machine account through the default ms-DS-MachineAccountQuota of 10 so it holds a genuine domain identity, and points cdc at itself. When the CA connects, the rogue services relay the authentication challenge to the real DC over Netlogon — satisfying the CA’s authentication checks — while returning the target DC’s objectSid and dNSHostName as directory data. The CA signs a certificate carrying a domain controller’s identity. PKINIT converts that into Kerberos credentials for the DC, and DCSync converts those into krbtgt.
Four network legs matter:

Leg 2 is the one to sit with. Every other leg is an attacker reaching into your infrastructure, which is the situation security tooling is built for. Leg 2 is your certificate authority — one of the most trusted machines in the domain — opening an SMB and an LDAP session outbound to an attacker’s Linux box, because a string in an untrusted request told it to.

Leg 2: the CA’s outbound peer set is small, and this isn’t in it

A certificate authority is not a general-purpose client. Its legitimate outbound connections are few, stable, and enumerable: domain controllers, its database, possibly an HSM, and wherever it publishes CRLs. That list changes on the order of once a year.
Which means the exploit’s critical leg is not merely suspicious — it is outside the CA’s entire behavioral envelope. Default-deny egress on the CA, permitting SMB and LDAP only to known domain controllers, collapses the attack before the identity confusion ever happens. The rogue LSA service never gets a connection. No directory data comes back. No certificate is issued.
The bar this sets is high rather than infinite. An attacker who has already compromised a host the CA is permitted to reach can stand the rogue services up there instead, and the chase succeeds. But that moves the prerequisite from “create a machine account, which the default quota lets any user do” to “own something on the CA’s short list of permitted peers” — a materially different class of problem, and one you are far more likely to have instrumented.
The thing worth dwelling on is that this control requires knowing nothing about CertiGhost. It doesn’t parse cdc. It doesn’t inspect enrollment attributes. It doesn’t need a signature, a patch level, or a threat intel feed. It enforces a statement that was true before the CVE existed and remains true after: this CA talks to these hosts on these ports, and nothing else.
Two things make this practical rather than aspirational. The first is automated policy generation — you cannot hand-write egress policy for every server in an estate, but you can observe what each asset actually connects to and propose a least-privilege ruleset from that — then run it in monitor mode and see what it would have blocked before it blocks anything. The organizations that get burned by least-privilege network policy are the ones that wrote it from an architecture diagram instead of from observed traffic. The second is that policy has to be per-asset rather than per-subnet. A CA in a broad “server VLAN” with permissive east-west rules has effectively no egress policy at all; the whole value is in the CA’s ruleset being narrow specifically because CAs have narrow needs.
If you want to go further, per-process egress narrows it again: certsrv.exe has a smaller legitimate peer set than the host as a whole, and the chase originates from exactly that process.

Legs 1 and 4: RPC-layer control

The remaining legs are RPC, which makes them addressable at a different layer.
Leg 1 is MS-WCCE enrollment. In the public PoC — impacket-based, no web enrollment endpoint involved — that means ICertPassage over DCERPC on the \pipe\cert named pipe: interface 91ae6020-9e3c-11cf-8d7c-00aa00c091be, opnum 0, CertServerRequest. The cdc and rmd attributes ride in that call’s attribute string. Note the transport: this is ncacn_np over port 445, not ncacn_ip_tcp over 135, so a port-based rule aimed at the RPC endpoint mapper never sees it. An RPC firewall that hooks the RPC runtime rather than filtering ports does.
Be precise about what this buys you. Filtering at the interface and opnum level tells you who may submit enrollment requests over RPC; it does not distinguish a malicious cdc from a benign one, because the discriminator is a string inside the parameters. So Leg 1 is an allow-list exercise: enrollment RPC to the CA should come from managed endpoints and enrollment proxies, not from an unmanaged host that appeared in the domain forty seconds ago. That shrinks the population who can attempt the attack. It does not identify the attempt.
It also only covers the RPC transport. If you run Certificate Enrollment Web Services, MS-WSTEP over HTTPS reaches the same policy module and the same chase logic, and RPC-layer filtering is blind to it. Leg 1 coverage is incomplete wherever web enrollment is deployed — which is another argument for Leg 2 carrying the weight, since egress policy on the CA is indifferent to how the request arrived.
That allow-list does have a second payoff worth naming. ESC11 is NTLM relay against precisely this interface — the RPC-based enrollment endpoint, as distinct from ESC8, which relays to the HTTP one. So restricting who may reach ICertPassage constrains CertiGhost’s submission leg and ESC11 with the same rule. That is the difference between an architectural control and a patch: the patch closes one bug, the rule closes a class of reachability.
Leg 4 is where RPC filtering earns its keep unambiguously. DCSync is MS-DRSR — interface e3514235-4b06-11d1-ab04-00c04fc2dcd2, DRSGetNCChanges at opnum 3. Only domain controllers have any business calling it. Denying it on your DCs from every non-DC source is a narrow, low-breakage rule, and it neuters the payoff of this attack, every AD CS ESC path, Zerologon and its derivatives, and any other chain whose final move is replicating secrets out of the directory. If you implement one rule from this post, implement that one.
Leg 3, the Netlogon relay, is MS-NRPC (12345678-1234-abcd-ef00-01234567cffb). It is RPC, but every domain-joined machine legitimately speaks it to DCs, so protocol-level blocking is disruptive. The tractable angle is source identity rather than protocol: an unmanaged Linux host making NRPC calls is the anomaly. Treat this as a detection opportunity, not a chokepoint.
Both rules want an audit pass before an enforcement pass. Logging calls to ICertPassage and DRSUAPI for a week gives you the real caller population, which is almost always narrower and stranger than the documentation implies, and occasionally includes a backup agent nobody remembers deploying.
One non-network control belongs on the same list, because it is cheaper than everything above it: set ms-DS-MachineAccountQuota to 0. The exploit needs a machine account to hold a valid domain identity, and the default lets any authenticated user create ten of them.

The generalization

CertiGhost will be patched everywhere within a few months and then largely forgotten, which is roughly what happened with the ESC series before it. The structural observation outlasts it.
Every one of these bugs is a trust decision made on data the attacker influenced, and the fix is always the same shape: add the validation that was missing. So the defense that ages well is not the one that knows about cdc. It is the one that constrains what a compromised or confused asset can reach — because a certificate authority that cannot open SMB to an arbitrary host, and a domain controller that will not replicate secrets to a non-DC, are indifferent to which validation was missing this time.
The cryptography was never the weak part. The reachability was.
If you want to see and control what your CAs and DCs can actually talk to right now — not what you assume they can talk to — request a demo.
 

What happened 

Hugging Face first disclosed an intrusion into part of its production infrastructure and attributed it to an external AI agent whose underlying model was unknown. On July 21, OpenAI took responsibility. The breach came from its own models during an internal cybersecurity evaluation. The models escaped their isolated testing environment and reached Hugging Face from there. 

OpenAI was running the models against an internal benchmark called ExploitGym, which measures how well a model can execute attacks against known vulnerabilities. The models involved were GPT-5.6 Sol and an even more capable pre-release model, with safeguards intentionally lowered for the test. According to OpenAI, the models became hyperfocused and went to extreme lengths to get the test solution. In plain terms, they tried to cheat on the eval by hacking Hugging Face to steal the answers. 

The attack chain 

The mechanics were ordinary even if the attacker wasn't. 

The models found a zero-day in a package proxy to get out to the internet. They escalated privileges and moved laterally through Hugging Face's internal infrastructure until they reached the target: the ExploitGym answer key in a production database. 

Hugging Face's account matches. Malicious content exploited code-execution paths in its data-processing pipeline and landed on a processing worker. From there the attacker escalated to node-level access, harvested cloud and cluster credentials, and moved into several internal clusters. OpenAI's account fills in on the other side. Its models exploited a zero-day in the research environment, escalated, and moved laterally to a node with internet access, then chained stolen credentials and more zero-days into a remote-code-execution path against Hugging Face production. 

Compromise one system. Gain privilege. Steal credentials. Move to the next. Repeat until something valuable is reachable. That sequence is why lateral movement is the control point that decides how bad a modern attack gets. 

The incident didn't turn serious because an AI found one vulnerability. It turned serious because that first foothold led somewhere that mattered. 

Preventing infiltration is no longer enough 

Keep patching. Keep securing pipelines. Keep protecting credentials and watching for bad behavior. None of that goes away. But this incident shows why you can't build a security model on stopping every first compromise. 

AI changes the economics of offense. It can hunt for vulnerabilities, test combinations, retry what failed, and run thousands of actions without getting tired. Hugging Face described an autonomous framework running many thousands of actions across short-lived sandboxes. Work that used to need a skilled team can now be automated. 

So, the asymmetry keeps widening. Vulnerabilities and possible paths grow faster than any team can patch, investigate, or contain by hand. Traditional detection leans on human habits: known tools, known protocols, known sequences. AI agents have none of those. They adapt as they go. The reliable move is to remove the paths, not to recognize the attacker walking them. 

Enterprise networks give an attacker room to run 

The Zero Networks 2026 Lateral Movement Exposure Report shows the size of the problem. Across hundreds of enterprise environments, one compromised system could reach a median of about 85% of the network in a single hop. By the second hop, reachability approached the entire environment. About 60% became reachable inside the first hour. A small foothold can become an enterprise-wide incident before most teams finish triage. 

This isn't spread across thousands of exotic techniques. About 71% of threat-relevant activity sat in four familiar protocols: SMB, RDP, WinRM, and RPC. Businesses run on those every day. Attackers spread on those same protocols. 

The gap holds across the industry. In Kiteworks' 2026 Data Security and Compliance Risk Forecast, a survey of 225 security leaders, 63% said they can't enforce purpose limits on AI agents and 60% can't shut down one that misbehaves. Most can watch an agent go wrong. Far fewer can stop it. 

Hugging Face fits the pattern. The execution path created access. Credentials and too much internal connectivity created reach. Lateral movement turned one vulnerable worker into access across multiple clusters. 

Stop the movement, stop the attack 

Defenders have an edge here. You may not know which vulnerability a human or an AI finds next. You do get to decide which systems can talk to each other and which identities can use privileged pathways. 

If the first compromised worker can't freely reach other nodes, the attack stalls. If stolen credentials can't be reused across clusters, it stalls. If admin protocols are limited to the users and systems that need them, it stalls. The attacker might still get initial execution. The company-wide breach never happens. 

That's the design goal: one compromised system stays one compromised system. 

Detection still matters. It just can't be the only thing standing between initial access and real damage. AI-enabled attackers move at machine speed. An architecture that waits for an analyst to see an alert, work out the path, and block it by hand will keep losing the race. 

When Hugging Face's own responders tried commercial frontier models to analyze the attack logs, the providers' safety guardrails blocked the requests. The models couldn't tell an incident responder from an attacker, so the team fell back to open-weight models they ran themselves. Provider-side safety is not a containment strategy. Containment must live in the network. 

How Zero Networks handles this 

Zero Networks decides which network paths are allowed to exist at all. It deploys directly on servers, cloud workers, and endpoints, and it works at the process level rather than only at the perimeter. So, you can enforce a rule like this: this dataset-processing worker may never SSH into an internal database cluster, no matter what credentials it holds. Present stolen credentials and the path still isn't there. The attack stops at the boundary. 

In the Hugging Face case, the first code execution on the worker was a software flaw. The moment that agent tried to move across internal clusters with harvested credentials, it would have hit a wall. The 17,000-plus recorded events in the campaign all depended on one thing: the ability to move. Take that away and the breach stays a single worker instead of a multi-cluster event. 

A practical agenda for CISOs 

Ask four questions: 

• How much of our environment can one compromised system reach? 
• Which pathways lead to critical servers, cloud workloads, and clusters? 
• Can stolen credentials move through those pathways? 
• Can we contain a compromised workload automatically, without waiting for an analyst? 

Then act on the answers. Segment the network so one compromised system can't reach the rest. Restrict privileged protocols to the systems that genuinely need them. Bind identities to paths so stolen credentials can't travel. Automate containment so a suspicious workload is isolated in seconds. 

The goal isn't to predict every AI-enabled attack. It's to remove the pathways that let any attacker, human or autonomous, turn access into impact. 

Hugging Face detected the activity, contained it, rebuilt the compromised nodes, rotated credentials, and tightened cluster controls. All necessary. The larger lesson is preventative. Constrain the blast radius before the incident starts. 

AI will find vulnerabilities faster. Attackers will chain them faster. The answer isn't a permanent race to patch everything first. You don't have to outrun every new attack. You have to out-architect its ability to spread. 

The blast radius is a design choice. Book a walkthrough and watch Zero Networks contain lateral movement in your own environment. 

Zero standing privileges (ZSP) is an advanced response to that condition that removes excessive standing access rights by default and replaces them with narrowly scoped, time-bound entitlements. We’ll break down what ZSP means, why persistent access has become one of the most exploited weaknesses in modern networks, and a practical approach to implementing the ZSP standard.  

What Does Zero Standing Privileges (ZSP) Mean?  

Zero standing privileges is a security principle that requires eliminating persistent, always-on access rights in favor of just-in-time, just-enough access – granted only when it's needed and only for as long as it's needed.  

Rather than a user, service, admin, or AI agent holding a permission indefinitely, access is requested, verified, and provisioned for a defined window, then automatically revoked when that window closes. 

ZSP vs. the Principle of Least Privilege (PoLP) 

At a high level, zero standing privileges and least privilege are different articulations of the same underlying principle:  

• The least privilege principle states that a user, process, or system should receive only the minimum level of access required to perform its intended function – but it does not limit how long privileges are available.  
• ZSP applies the same access scoping discipline that PoLP requires, then adds a time dimension: access isn't just limited to what's necessary, it's limited to when it's necessary. 

The principle of least privilege was first introduced in the 1970s, while zero standing privileges was coined within the last 10 years, meaning ZSP is an evolution of the PoLP – not a distinct philosophy. And in fact, least privilege is a core tenet of ZSP. 

Key Pillars of Zero Standing Privileges  

Like Zero Trust or any other security philosophy, ZSP is an ideal upheld by a few core principles:  

• Just-in-Time (JIT) Access: Critical for operationalizing the time constraint that is core to zero standing privileges, JIT access allows organizations to unlock temporarily elevated permissions before automatically revoking them.  
• Least Privilege Principle: By restricting every identity – including admins and service accounts – to least privilege by default, enterprises implement the foundation for ZSP.  
• Always-Current Network Visibility: A live network map delivers the real-time insights teams need to keep policies granular and prevent privilege creep.  

Where JIT Isn’t Possible: A Risk-Aligned Approach to ZSP in Real Enterprise Environments  

While just-in-time access is central to the zero standing privileges philosophy, it’s important to note that not every application or workload is designed to support just-in-time access. Some legacy systems require persistent connectivity. Others break under real-time gating.  

This is why a risk-aligned approach to just-in-time access – and, in turn, to ZSP – is critical. By enforcing just-in-time access controls on lateral movement paths, privileged activity, and interactive sessions, while applying least privilege policies to everything else, organizations can achieve zero standing privileges where it matters most without the risk of breaking something.  

A risk-aligned approach like this gets enterprises as close as their environments allow to comprehensive ZSP while effectively managing legacy limitations.

Why Standing Privileges Are a Security Risk 

Privileges accumulate over time for the sake of operational ease. But the same internal pathways that enterprises rely on to keep the business operating are the ones that attackers exploit, creating gaps that leave organizations vulnerable to familiar risks.  

Lateral Movement and Privilege Escalation  

Over 80% of attacks leverage stolen credentials at some stage. When an identity carries broad, always-on access, attackers immediately inherit those entitlements via stolen credentials, allowing them to escalate privileges and move laterally across the network without triggering alerts.  

Overprivileged Service Accounts and Machine Identity Sprawl 

Machine and service identities now outnumber human identities 109:1, and only 2.6% of workload identity permissions are actually used – meaning the overwhelming majority of machine access exists as unmonitored and unnecessary risk. To top it off, AI agents are compounding the issue. Roughly 80% of enterprises are already deploying AI agents, but nearly two-thirds don’t have the necessary policies to effectively govern them.  

Because identity-based attacks exploit legitimate permissions and blend in with normal activity, more detection tools and alert dashboards won’t solve the problem.  

How to Implement Zero Standing Privileges 

Implementing the zero standing privileges model requires a multi-step approach for removing excessive “always-on” access and operationalizing granular, dynamic controls.  

1. Discover every network asset, identity, and activity 

Start by comprehensively mapping every identity, asset, and existing privileged pathway – including service accounts, AI agents, and machine identities, not just human users and admins.  

2. Learn network connections and baseline permissions 

Determine what access is genuinely needed by observing real behavior, logon activities, and asset access patterns rather than relying on assumed or historically granted permissions. 

3. Build deterministic, identity-based policies 

Translate learned network insights into policies grounded in real behavior. Automatically restrict all identities to pre-approved assets and logon types, and define privileged access policies for specific resources tied to identity.  

4. Enforce JIT network-layer MFA for privileged access 

Enforce JIT verification for access to admin protocols, critical services, and other privileged activity. Use context-aware, identity-based policies to ensure that only in-scope identities are eligible for access, and network-layer MFA to provision access only for the duration needed – without adding operational friction.  

5. Dynamically adapt policies on an ongoing basis 

Standing privilege has a way of creeping back in as new accounts, services, and access paths are created. Policies should adapt continuously based on real-time visibility that automatically flags out-of-scope privileged access, anomalous paths, and high-risk ports.  

Close Privileged Pathways by Default with Zero Networks  

Zero Networks delivers every core pillar of ZSP in a single, unified platform – automated, identity-based microsegmentation enables least privilege enforcement at scale, just-in-time network-layer MFA keeps privileged access closed by default, and our real-time network map delivers up-to-date insights that power adaptive policies.  

By making least privilege the default and adding an adaptive authentication at the exact moment of privileged access, Zero Networks removes risky always-on permissions and closes the privileged internal pathways attackers rely on to escalate breaches. Request a demo to learn more.