Deep Dive into the Software-Defined Perimeter (SDP) Guide v3

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.

 

1. The End of Implicit Trust and the Rise of ZTA

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:

• Enforcing Authenticate-Before-Connect: No network resource is accessible or discoverable without verified identity and context.
• Promoting Continuous Verification: Check identity and security posture for users, devices, and workloads throughout the session.
• Ensuring Least Privilege Access: Grant access dynamically for each request, limited only to the specific application or service required.
• Assuming Breach: Act as if an attacker is already present, using identity-rich logs to detect and contain threats.

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.

 

2. Beyond Single-Packet Authorization (SPA)

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.

 

The Shift to Identity-First Connectivity (IFC)

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:

• Identity as a Primitive: Every participant, from a human user to an AI agent, is a first-class identity. This provides evidence of who connected to what service, under which policy, from what posture, and under what conditions.
• Outbound-Only Connections: Resources use outbound connections to policy enforcement points. This requires zero inbound firewall ports and protects against external scans.
• Topology Agnostic: Secure connectivity can span clouds and sovereign boundaries using identity alone, without requiring shared address space.

 

Introducing the Network-Infrastructure Hiding Protocol (NHP)

The guide introduces NHP as a session-layer protocol (OSI Layer 5) that offers a lightweight alternative to SPA.

• Decoupled Components: NHP separates authentication (NHP-Server) from access control (NHP-AC). This allows for massive horizontal scaling in clustered modes.
• Bi-Directional Feedback: Unlike the one-way nature of SPA, NHP provides confirmation messages. These let clients know exactly when they receive provisioned access.
• Identity-Based Cryptography (IBC): NHP utilizes IBC to simplify key management. This makes it easier to manage thousands of devices without a complex PKI.

 

3. Aligning with "Secure by Design"

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.

• Own Customer Outcomes: Services start in a deny-by-default state, exposing no open ports to the internet.
• Radical Transparency: Authenticate and log every micro-tunnel at the service layer. This provides identity-rich evidence of who connected to what service, under which policy, and under what conditions.
• In-Process SDKs: Projects like OpenZiti provide SDKs that developers can compile directly into their binaries. This eliminates the need for a separate VPN client.

 

4. SDP for the Era of Agentic AI

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:

• Semantic Context: Policies use metadata such as agent role, workload identity, tool capability, data sensitivity, user intent, and authorization scope rather than static IP rules.
• Federated Policy Planes: Authorization is executed locally via trust brokers to ensure low-latency decisions for bursty agent-to-agent interactions.
• Drift-Aware Revocation: Controllers detect when an agent changes posture and tear down stale sessions within seconds.

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.

 

5. Converging IT, OT, and IoT

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.

 

Securing the Industrial Floor (OT)

In OT environments, stopping a manufacturing line can cost millions or threaten lives.

• Zone-Resident Controllers: Lightweight controller instances reside within Level-3/DMZ zones. This allows local authorization to continue even if the WAN goes down.
• Protocol-Aware Policy Integration: SDP can be combined with OT-aware enforcement, inspection, or gateway controls so that access is constrained not only by identity, but also by permitted service, function, and operational context.
• Safety-Aware Degradation: Policy should define what happens when connectivity or controllers are degraded, such as read-only access, local-only operation, cached policy, or deny-by-default behavior, depending on the safety case.

 

Hardening the Edge (IoT)

For IoT devices with severe resource limits (e.g., HVAC controllers or robots), v3 emphasizes Bandwidth-Sparing Heartbeats.

• Hardware-Rooted Bootstrapping: Devices enroll using TPM attestation or hardware serial numbers, ensuring that only authenticated hardware can initiate an SPA handshake.
• Embedded Overlay SDKs: Ultra-light libraries (<50 kB) allow devices to maintain identity-bound tunnels. These are without the overhead of heavy agents.

 

6. Implementing SDP: The Five-Pass Framework

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.

1. Scope the Protect Surface: Enumerate the specific Data, Applications, Assets, and Services (DAAS) you need hidden.
2. Discover Live Flows: Use packet brokers or cloud flow logs to capture who, what, where, and how each transaction occurs.
3. Classify and Label: Tag each flow with business context so the policy engine can reason at the app level.
4. Model Access Paths: Diagram the intended micro-tunnels to serve as the authoritative source for least-privilege baselines.
5. Validate and Iterate: Feed drift or new dependencies back into the model. Ensure the loop is continuous and largely automated.

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.

 

7. Connection-Defined vs. Topology-Defined Segmentation

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.

 

Conclusion: A Context-Aware Security Fabric

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.