Written by Philip Griffiths, Head of Strategic Sales, NetFoundry.
The reason CSA started updating the SDP guidance more than a year ago is now playing out in real time. The internet is moving from human-speed exploitation to AI-speed exploitation, while most enterprise connectivity, patching, firewall, VPN, and approval workflows still operate on human-speed change cycles.
At the recent DoW Zero Trust Symposium, I opened my talk, Why Traditional Networking Fails Agentic AI: Identity-First Connectivity Matters for Zero Trust, with a simple point: exploit timelines are collapsing faster than traditional defensive processes can respond.
That was before the latest industry discussion around Anthropic’s Project Glasswing and Claude Mythos, which reinforced the same lesson: AI is compressing the window between vulnerability discovery, weaponization, and exploitation. Anthropic’s own Project Glasswing page says the window that once took months can now happen “in minutes with AI.”
This is why we started updating and now have released the CSA Software-Defined Perimeter (SDP) Architecture Guide v3.0. This is not only a refresh of a security architecture. It is a response to a structural reality: in an AI-speed exploitation environment, reachability itself becomes part of the attack surface. If a service is discoverable, routable, or probeable before identity and policy have authorized access, defenders are giving automation a target before trust has been established.
This update is a fundamental reimagining of how we establish trust. Zero Trust Architecture (ZTA), autonomous agentic AI, and converged IT/OT environments are now what define our world. By moving beyond traditional perimeter-based security, SDP offers a dynamic, identity-centric approach.
For decades, enterprise security relied on the assumption that anything inside the network was "safe." This flaw allowed attackers to move laterally once they bypassed a static firewall or VPN. The v3 update acknowledges that the perimeter has completely dissolved. The guide aligns directly with the ZTA principles defined by NIST and CISA. These frameworks mandate that we "never trust the network" and treat all environments as potentially compromised.
SDP serves as a foundational implementation strategy for ZTA by:
This is also why Zero Trust cannot be reduced to better identity, better MFA, or better detection after the fact. Those controls matter, but they do not remove the pre-authenticated reachability that attackers and automated tooling can discover, probe, and exploit.
SDP’s contribution to Zero Trust is more specific: it inverts the traditional sequence. Instead of “connect, then authenticate,” SDP moves toward “authenticate and authorize before connect.” That distinction becomes more important as AI reduces the cost and time required to discover, weaponize, and validate attacks against reachable services.
Put differently, discovery should inform policy; it should not be the prerequisite for protection. If enforcement depends on first finding every application, port, dependency, or flow through scans, then unknown services remain reachable until discovered. A stronger Zero Trust pattern is deny-by-default reachability, where access is created only when an identity, policy, posture, and service context say it should exist.
Earlier SDP guidance was naturally shaped by the dominant use case of the time: client-to-server access, often framed as a more secure alternative to VPN-based remote access. That remains important, but it is no longer sufficient. Modern environments require the same principles to apply to workload-to-workload, service-to-service, machine-to-machine, agent-to-tool, and edge-to-cloud connectivity.
In previous iterations, SDP was almost synonymous with SPA. SPA remains a valid technique for making infrastructure "dark" by validating identity before any component accepts a connection. However, v3 expands the toolkit to support the performance and scalability needs of modern enterprises.
A major shift in v3 is the inclusion of IFC, reflected in emerging open-source and commercial implementations such as OpenZiti and related SDP-derived architectures. Unlike traditional networking rooted in IP addresses, which are neither secure identities nor effective proxies, IFC centers connectivity on identities and services.
This is more than replacing IP addresses with identity labels. The deeper architectural shift is that the service, not the network location, becomes the object of policy. Access is no longer inherited from being on the right subnet, VPN, VLAN, cloud VPC, or route domain; it is explicitly created for a named identity to reach a named service under defined conditions.
Agentic AI makes the shift to IFC more urgent. Autonomous agents, tools, APIs, workloads, and data services are dynamic, distributed, and often short-lived. They do not map cleanly to static IP ranges, VPNs, firewall rules, routing tables, or topology-specific segmentation.
Trying to govern them through those controls creates a growing connectivity tax: every new workflow, agent, service, cloud, or boundary becomes another underlay change, exception, or approval cycle. SDP and IFC move the control point closer to identity, service intent, posture, and authorization context, making non-human identities first-class participants and allowing connectivity to be created by policy, not inherited from network topology.
Key principles include:
The guide introduces NHP as a session-layer protocol (OSI Layer 5) that offers a lightweight alternative to SPA.
A central pillar of the v3 update is its alignment with the Secure by Design principles promoted by CISA. This movement shifts the burden of security from the customer to the vendor. Traditionally, security was "bolted on" as an external add-on. V3 advocates for embedded SDP, where product teams treat the SDP controller and policy engine as native modules.
In 2026, we are no longer just securing human users. We are securing a web of autonomous agents that delegate tasks across domains. That means the Zero Trust question is no longer only “which user can access which app?” It becomes “which human, workload, agent, model, tool, API, or data service can initiate which action, through which delegated authority, and for how long?”
Without identity-bound connectivity and service-specific authorization, agentic systems risk recreating the same implicit-trust problem that VPNs and flat networks created for human users. AI workloads are highly ephemeral, with agents scaling, executing, and retiring in seconds. v3 addresses this with:
Since the SDP v3 work was largely completed, CSA has also moved further in this direction through the CSAI Foundation’s work on securing the agentic control plane. CSAI has identified the Agentic Trust Framework, created by Josh Woodruff, as one of the flagship specifications for applying Zero Trust governance principles to autonomous AI agents. SDP v3 and ATF are not the same workstream, but they point toward the same conclusion: agentic systems need identity-first controls, runtime authorization, privilege governance, and enforceable policy across humans, agents, tools, APIs, and data services.
The new guide provides specialized architectural adaptations for environments where uptime is safety-critical: Operational Technology (OT) and IoT fleets. This is no longer only a forward-looking architecture discussion. Large industrial organizations are already moving in this direction.
Siemens’ SINEC Secure Connect is a useful example: Siemens describes it as a Zero Trust security platform for OT networks that uses overlay networking, supports machine-to-machine, machine-to-cloud, machine-to-datacenter, and remote access use cases, and does so without traditional VPNs. Siemens also explicitly positions it as reducing the administrative complexity of IP-based machine management and supporting IEC 62443-aligned security outcomes.
That kind of adoption matters because OT exposes the practical reason SDP is maturing: the challenge is not only security. It is how to enable secure change across fragile, long-lived, uptime-sensitive environments without turning every new connection into a custom networking project.
In OT environments, stopping a manufacturing line can cost millions or threaten lives.
For IoT devices with severe resource limits (e.g., HVAC controllers or robots), v3 emphasizes Bandwidth-Sparing Heartbeats.
To move from theory to reality, v3 outlines a practical framework for Mapping the Transaction Flows. This process ensures that SDP policies are grounded in actual business requirements.
A practical SDP program should also measure the “connectivity tax” as a first-class outcome: the recurring effort spent on firewall changes, VPN exceptions, NAT rules, routing updates, security group changes, approval tickets, and environment-specific workarounds. One of SDP’s strongest outcomes is not simply that access becomes more secure; it is that secure access becomes repeatable, automatable, and portable across sites, clouds, partners, factories, workloads, and agents.
A significant clarification in v3 is the distinction between SDP and microsegmentation, as well as between connection-defined segmentation and topology-defined segmentation.
Traditional segmentation starts with the network: subnets, zones, VLANs, firewalls, routing domains, host agents, and enforcement points placed around topology. That model can be useful, but it inherits the complexity of the underlay. Every new application, partner, cloud, factory, agent, or service boundary risks becoming another networking and governance workflow.
SDP starts from a different premise: the connection itself should be defined by identity, policy, service intent, and authorization context. The question becomes not “which network can talk to which network?” but “which identity is allowed to establish which connection to which service, under which conditions?”
That distinction matters because topology-defined segmentation still tends to preserve ambient reachability inside approved zones, while connection-defined segmentation removes reachability unless a specific identity-to-service relationship has been authorized.
CSA’s upcoming work on Microsegmentation will go further into this distinction. The point is not that one model replaces all others. The point is that as systems become more distributed, automated, and cross-domain, topology-defined controls alone cannot keep up with the speed or granularity of modern trust decisions.
The SDP Architecture Guide reinforces that we don't just need more security products. We need a more Secure by Design way to connect. By making infrastructure invisible and enforcing identity-bound connectivity, SDP replaces brittle, rule-sprawl perimeters with a living, context-aware fabric.
The hard lesson is that reachability is no longer neutral. In a world of AI-assisted discovery and exploitation, every reachable service is a candidate target, and every manual network change process is a delay defenders may not have. SDP’s relevance is that it makes connectivity conditional: identity first, policy first, service first, and only then connection. That is the direction Zero Trust has always implied, but agentic AI is making it operationally unavoidable.
Looking forward, the rise of ZTA, identity-first connectivity, and SDP is also moving into the standards conversation. Within CSA, we are excited by the emerging IETF work around Zero Trust Control and Policy Protocols, which aims to explore interoperable mechanisms for authenticated-before-connect access, dynamic assurance, policy lifecycle management, and binding policy decisions to concrete sessions, flows, or channels.
SDP v3 does not attempt to solve all of that. But it does help frame the problem: Zero Trust cannot stop at policy language or architectural diagrams. It needs enforceable, interoperable control and policy mechanisms that can operate at the speed of cloud, OT, IoT, and agentic AI.
Make sure to check out the v3 guide to get a blueprint for a resilient, future-proof network architecture.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。