In a recent Cybersecurity Insiders interview, Tufin’s Erez Tadmor, Global Field CTO, and Sagi Bar-Zvi, VP of Sales Engineering and Customer Success, discussed why network security has become harder to prove even as organizations add more controls. Their central point is simple: most enterprises have policies, tools, and segmentation plans, but far fewer can show whether those controls still produce the intended posture across the live network.
Behind that disconnect is a practical question CISOs increasingly have to answer under pressure: does the network actually enforce the security posture the organization believes it has?
Erez Tadmor, Field CTO at Tufin, put the architectural problem in one sentence. “Each individual control may look reasonable in isolation, but if you look at it from an overall posture perspective, you may still violate the intended policy,” he said.
The controls may exist. The policy may be approved. The segmentation diagram may look right. The missing answer is whether the live network still behaves that way.
“They want to know if the organization is exposed in ways that they don’t understand,” Tadmor said. “They may phrase it differently. They may ask, can any critical systems within the network be accessed? Does the segmentation plan that we all worked on together actually hold?”
The data behind those questions is unflattering. A 2026 Cybersecurity Insiders survey of more than 600 practitioners found that only 11% can confidently report east-west segmentation posture on demand, while 58% said they cannot. Confidence drops further across cloud networks (35% not confident) and remote access environments (46%).
Sagi Bar-Zvi, VP of Sales Engineering and Customer Success at Tufin, said the question of whether the network is actually doing what it should be doing comes up constantly. “They spend a lot of time hardening their environment, spending budgets on devices, firewalls, segmentation. But when they are asked to prove whether it all comes together and works together as they expected, in so many cases it just doesn’t.”
Boards are asking a version of the same question. Security leaders are no longer judged only by whether the organization has invested in controls. They are increasingly asked whether those controls can be proven to work right now.
The reason this question is so hard to answer sits in the architecture itself. Posture comes from how firewalls, cloud security groups, SASE, microsegmentation controls, routes, exceptions, and identity-aware access decisions interact across multiple vendors. No single console shows the full picture. Tadmor calls this the policy enforcement gap. Intent runs into enforcement scattered across dozens of consoles, and posture quietly falls apart.
A segmentation diagram is not segmentation. A policy document is not segmentation. An audit artifact is not segmentation. Segmentation exists only if the live network prevents unintended reachability across the boundaries it claims to enforce.
Policy Was Managed. Posture Was Assumed.
The confusion runs deeper than segmentation. Two disciplines often get treated as the same: policy management is about the rule; posture management is about the outcome.
“Policy management asks: is the rule documented, is it optimized, is it implemented on the right device, and can we remove an unused rule,” Tadmor said. “Those are very important capabilities, but they do not fully answer the CISO’s question. Posture management asks a broader question. Given all the rules, the controls, the routes, cloud policies, exceptions, and dependencies, what is actually the security state of the network?”
Cloud, identity, data, and application security have each developed posture disciplines. Cloud security has CSPM. Identity, data, and application security have followed with their own posture-management models. Each operates continuously, validating whether controls are configured correctly and exposure is understood. The network was the exception, even though every other posture discipline ultimately depends on it.
The same proof problem shows up in vulnerability management. Only 8% of organizations can automatically determine whether a critical vulnerability is reachable through the network. The other 92% patch by severity score alone, often burning cycles on findings that are technically critical but already contained, while genuinely exposed assets sit in the queue.
Reachability is what turns severity into risk. Severity without reachability is a guess with a score attached.
Regulators are starting to demand the same continuous proof. Updates to PCI-DSS, NYDFS, and EU DORA have pushed compliance from periodic audits toward continuous validation of controls. The frameworks are catching up to a question security leaders cannot answer with point-in-time tools.
Network Security Posture Management addresses that validation failure. It sits above individual enforcement points, normalizes policy across vendors into a common model, watches how those policies interact, and gives teams one consistent way to validate changes across the whole environment. Tadmor described the shift as moving from managing rule objects to proving the intended posture is actually enforced.
What an Audit Cannot Catch
NSPM adoption is rarely driven by a clean strategic roadmap. The trigger event is almost always operational, and it usually shows up in one of three ways.
“It’s never really one thing,” Bar-Zvi said. “If I have to pick three, the first is audit. Someone asks the team to prove something is in compliance or isolated from something else, and they end up spending a couple of weeks gathering logs from different tools, and even then they might not be too confident in their answers. The second is when there’s a breach in their industry and the CISO gets asked, can this happen to us. If the answer is not swift and clear, that’s an issue. The third is an internal incident, an outage from a change that wasn’t supposed to happen.”
Each trigger exposes the same problem. The snapshot produced today is stale by tomorrow, because networks never stop changing, and AI tools are beginning to push changes through faster than humans can review them.
AI makes that lag harder to tolerate. When agents recommend or initiate changes, the audit-cycle review cannot keep pace. A model that gets rebuilt only at audit time is not a posture discipline. It is a historical artifact.
Organizations divide along a clear maturity line. Fragmented teams hunt answers across separate consoles and trace paths by hand. Posture-driven teams answer from live data.
Bar-Zvi said most teams arrive at NSPM after that realization. “They’re managing hundreds of thousands of rules and dozens of vendors by hand. It just doesn’t scale.”
Years of Operational Residue
What organizations actually find when they move from manual review to continuous visibility is rarely a single dramatic problem. Tadmor said the accumulation is what surprises them.
“What consistently surprises organizations is how much connectivity actually exists without a current business reason,” he said. “Temporary access that became permanent. Application migrations that left old paths open. Overlapping rules from different teams. Exceptions that were valid at the time, but no longer make sense. The risk is often created by operational residue. It’s the byproduct of normal business change.”
The teams that built the environment do not always welcome having that residue surfaced. “It’s not because they don’t care about security,” Bar-Zvi said. “It’s because they built it.”
That resistance is understandable. Network operations teams are responsible for availability, continuity, and the fragile exceptions that keep critical systems running. They know why exceptions were created, which legacy systems are fragile, and which changes are risky. When a posture platform surfaces permissive rules, stale access, or configuration drift, it can feel like criticism of the people who kept the environment stable. Bar-Zvi said the adoption conversation works best when NSPM is positioned as relief from that burden rather than an audit of past decisions.
Once teams see the deployment numbers, the resistance fades. Bar-Zvi described a financial services customer with a hybrid mix of legacy firewalls, AWS and Azure workloads, SD-WAN technologies, and a microsegmentation initiative under evaluation. The average change request cycle ran about 20 days. After deployment, standard changes ran in about a day. The team’s first query across the full environment surfaced several access paths to a critical application the business had never intended to exist.
“It’s not a breach,” Bar-Zvi said. “It’s just years of incremental changes.”
A Tufin healthcare deployment shows the same effect with vulnerability data. Scanners flagged 347 critical findings, but reachability analysis showed only 89 were on assets actually reachable through live network paths. That cut the patch queue by 74% and dropped containment time from more than a week to under an hour.
Both stories matter more every quarter. AI is shrinking the time attackers need to find a way in, and operational residue is handing them more attack surface than defenders realize.
The Connectivity Model Everything Else Depends On
Resolving the exposure blind spot requires something most environments lack: a live, accurate model of how connectivity actually works across the enterprise. Tufin calls this the Dynamic Network Connectivity Graph, and Tadmor said the key word is graph.
“It is not just an inventory. It represents relationships,” he said. “It understands that connectivity is created through a combination of rules, but not just rules. It’s routes, it’s zones, it’s cloud controls, it’s NAT and many other enforcement points. When something changes, the graph helps us determine the impact of the change across those different relationships.”
Exposure is relational. A firewall rule on its own does not create or remove risk. Risk shows up when that rule combines with routing, NAT, inherited access, cloud controls, shared services, segmentation policies, and application dependencies to open a path that should not exist.
When a proposed change hits the model, the system sees it in context rather than as a one-off configuration item. It analyzes which assets become reachable, which policies apply, and whether the resulting state aligns with the intended posture. The questions security teams struggle to answer become operationally answerable: Is this access already allowed somewhere else? Is it compliant? Does it break segmentation? Does it expose a critical asset?
That model is what makes the difference between policy management and posture management practical. Without it, teams collect configurations. With it, teams validate outcomes. Organizations that build the model first find that every layer above it depends on the model being right.
When AI Agents Need a Map
The next layer is already arriving. Tufin recently introduced four AI agents that work off the connectivity graph, and the first pattern customers want is change-workflow automation. The architectural point matters more than the feature list.
“The agent is only good as the model underneath it,” Bar-Zvi said. “If your network model is fragmented and you’re automating based on wrong data, that’s not good. The agent is the natural next step. You’re not just automating the task, you’re automating the decision. And you need the full context of the underlying model to do that.”
Tadmor named the failure mode he watches for: AI sounding confident without operational context. “AI can recommend changes that are technically valid but operationally unsafe. It may suggest broad access because it does not understand the least-privileged path or the segmentation requirements. It can miss exposure because it does not understand effective connectivity. And it can create a governance problem if the organization cannot explain what data the AI used, what policy it applied, and why it recommended a certain change.”
That last failure is the one boards and auditors will care about most. If a team cannot explain why an AI workflow approved a change, rejected one, or allowed a risky exception, it cannot govern the workflow.
As attackers use AI to accelerate discovery and defenders introduce AI into change workflows, both sides depend on the same thing: whether the model reflects reality. The data an agent uses has to match the live environment. Policy context has to be encoded. Governance has to be in place before any decision goes live.
Tadmor compressed the dependency. “The more operational the AI becomes, the more important the foundation also becomes.”
Trusted Autonomy
Tadmor named three foundations enterprises need before introducing agents to network security workflows. The first is a trusted model of connectivity and control. “The agent needs to understand what exists, what’s reachable, which controls apply, how changes affect posture,” he said. The second is policy and business context. An agent cannot make decisions on technical reachability alone. It has to know the business intent behind a rule, the compliance requirements, the segmentation policy, ownership, and risk tolerance. The third is governance: identity, authorization, approval workflows, and the ability to validate outcomes.
All three serve a single goal. Tadmor framed it directly. “The goal is not autonomy for its own sake. The goal is trusted autonomy: AI that can operate within boundaries the enterprise can govern and prove.”
Network Security Posture Management is what makes that proof possible. It confirms that controls actually enforce the intended posture, that segmentation holds across every vendor and environment, and that exposure is measured against live network paths instead of assumptions.
The implication reaches further than network security. Every AI-assisted workflow will inherit the quality of the model beneath it. If that model is fragmented, the agent will automate uncertainty. If the model is trusted, current, and governed, the agent helps security teams keep up with environments that will not slow down.
Every other security domain answered the posture question years ago. The network is answering it now. The organizations that move first will be the ones that build the trusted model before they ask an agent to act on it.
Join our LinkedIn group Information Security Community!
