Architecture
What SDP v3.0 Changed: SPA Is No Longer the Definition
In May 2026 the Cloud Security Alliance updated its Software-Defined Perimeter Architecture Guide to SDP v3.0. If you are evaluating ZTNA right now, the reason to read it is not another restatement of zero trust principles. It is one sentence the new version settles: single packet authorisation is no longer what defines SDP.
That sounds like editorial housekeeping inside a specification. It is not. For several years, “does it do SPA?” has been the shorthand test for whether a product is really an SDP. After v3.0 that question misses an entire class of implementations, and it lets through some that do not actually deliver zero trust.
This article covers what changed, why, and what your evaluation and rollout should do differently as a result. The three roles and the step-by-step flow of SDP itself are in how a software-defined perimeter works and are not repeated here.
What SDP v3.0 actually changed
SDP v3.0 was released on 5 May 2026. Against the 2022 v2.0 specification, the changes sit at the level of “what SDP is” rather than at the level of fields and parameters. Seven of them matter, and each one lands on a different document of yours.
| What changed | In practice | Document it affects |
|---|---|---|
| Identity-centric scope | From user-to-application to everything-to-everything | Architecture blueprint |
| More than one mechanism | From SPA-only to identity-native overlays and other approaches | Technical evaluation sheet |
| Far wider use cases | AI/ML, agentic AI, IoT, OT, edge, hybrid and multi-cloud | Rollout scope and phasing |
| A structured framework | Repeatable passes for flow discovery, policy, continuous validation | Project plan and sign-off |
| Automation and AI support | Flow discovery, policy suggestion, drift detection, lifecycle | Operations staffing, audit |
| Real deployment patterns | Worked examples rather than principles alone | Architecture decision log |
| Clearer positioning | Where SDP starts and stops inside zero trust | Briefings for execs, audit |
The second row is the watershed, and the next two sections are about it.
Why static perimeters stopped working: the problem is lifecycle
Fixed network perimeters were not replaced by the cloud. They were outlived. Hybrid cloud, mobile workforces, IoT and operational technology, globally distributed applications, AI/ML workloads — what these have in common is not that they are spread out. It is that they are short-lived.
Containers scale out and die within seconds. Serverless functions exist for the duration of one request. Agentic AI systems call external APIs and internal services on their own initiative, spawning a dozen ephemeral identities inside a single workflow. Static controls meet that pace with two failure modes: hand-maintained firewall rules and access control lists accumulate into a thicket nobody can audit, and the gap between the rules and reality widens into policy drift — the path still open on the list leads to a workload that no longer exists.
The other half of the problem is implicit trust: clear the perimeter check, and the internal network is assumed safe. That assumption turns one stolen credential into a starting point for lateral movement. Zero trust architecture exists to remove the assumption, and both NIST and the CISA Zero Trust Maturity Model put it first among their principles. SDP removes it by inverting the order: authenticate, then connect. Fail the check and the resource is, as far as the network is concerned, not there.
SDP v3.0 leaves that premise untouched. What it changes is how many ways there are to meet it.
Single packet authorisation is now one mechanism, not the definition
Single packet authorisation (SPA) carries authentication and authorisation in one cryptographically protected message, and until that message verifies, the protected service answers nothing at all. Only once it verifies does mutual TLS (mTLS) carry the actual data connection. What it defeats is reconnaissance: service discovery, port scanning and automated exploitation of unpatched services all fail before a connection exists. None of that is retracted in v3.0. SPA is simply returned to what it always was — an implementation technique.
v3.0 sets out five limitations that show up in modern deployments:
- Client dependency. BYOD devices and constrained IoT hardware often cannot run the required client software.
- NAT and firewall traversal. UDP-borne SPA gets dropped on restricted networks, so a TCP or HTTPS fallback is needed.
- Key compromise blast radius. Shared-secret models require coordinated re-keying once a secret leaks.
- Cost per connection. The overhead is paid every time, which is heavy for short-lived, high-rate service interactions.
- Operational visibility. Services that are dark to attackers are also dark to your own troubleshooting, so monitoring needs a separate design.
Those limitations pushed implementations toward connection-defined, identity-native approaches, and v3.0 names two. The Network-Infrastructure Hiding Protocol (NHP) moves the handshake to the session layer and replaces shared secrets with the Noise Protocol Framework and identity-based cryptography, extending what is hidden from ports to domains and IP addresses. Identity-first connectivity (IFC) drops IP-centric thinking altogether, treats identities, services and policies as the primary abstractions, and ships SDKs that embed zero trust directly into an application.
- Authorisation repeated per connection
- Persistent identity-bound tunnel
- Cryptographic identity held by the endpoint
Text version of this diagram
One requirement — authenticate before connect — and two structurally different ways to meet it: SPA repeats itself per connection, while an identity-native overlay is joined once and then lets identity decide reachability.
Left — SPA (every connection knocks again)
- The client runs dedicated software and sends a single, cryptographically protected authorisation packet.
- The gateway drops everything by default and answers nothing until that packet verifies.
- Only then is an mTLS connection opened to the protected service.
- A loop arrow back to the client marks the point: the next connection repeats the whole sequence.
- Three limitations are listed: it needs a dedicated client, which BYOD and constrained IoT cannot run; UDP-based forms get blocked on restricted networks; per-connection overhead is heavy for short, high-rate workloads.
Right — identity-native (enrol once, identity decides)
- The endpoint holds a cryptographic identity and joins an identity overlay over an outbound connection.
- The overlay listens for nothing inbound; every connection is initiated outward from the endpoint.
- The two authorised services — ERP and an API service — each have a tunnel that persists.
- The third service, a finance system, is not authorised: the drawing shows no path at all rather than a refusal.
- Three characteristics are listed: services, workloads and AI agents are first-class identities; tunnels persist with no per-connection renegotiation; policy is re-evaluated for the life of the connection.
The practical consequence is blunt: stop asking vendors whether they do SPA. Ask whether an unauthorised party can detect the service at all, and where the cost of achieving that lands. The first question is the security outcome; the second decides whether BYOD, IoT and cloud functions can come along.
The line between SDP and microsegmentation runs through the first packet
Security teams struggle to explain how SDP, ZTNA and microsegmentation divide the work, and the cause is almost always the same: framing all three by traffic direction. v3.0 offers a more useful axis. The dividing line is not north-south versus east-west; it is the first packet of a connection.
- Connection-defined segmentation (SDP / identity-native ZTNA) governs who may establish a connection. It removes unauthorised parties before a connection forms, and the outcome is attack surface reduction.
- Topology-defined segmentation (classic microsegmentation) governs where traffic may flow once connectivity exists. It constrains spread after a foothold appears, and the outcome is blast radius containment.
- Connection-defined: before a connection forms
- Topology-defined: after a connection forms
- Where the attacker is stopped
Text version of this diagram
Both segmentation models placed on one connection timeline: the dividing line is not traffic direction but the first packet.
The timeline
- The left end is labelled “before the connection”, the right end “after the connection”.
- A gold dashed line down the middle marks the split: the first packet.
Left — connection-defined segmentation (SDP / ZTNA)
- It governs who may establish a connection.
- Outcome: a smaller attack surface and no pre-auth exposure.
- The unit of segmentation is the identity of a service or application.
- It holds across clouds, data centres and OT zones.
- An outside attacker’s probe is crossed out before the split, labelled “no connection forms”.
Right — topology-defined segmentation (microsegmentation)
- It governs where traffic may flow.
- Outcome: lateral movement contained and the blast radius reduced.
- The unit of segmentation is the workload, segment, port or protocol.
- It is bound to a single network or control domain.
- An attacker who already holds a foothold spreads rightwards and is crossed out, labelled “cannot leave this segment”.
Underneath
- When services are first-class identities, SDP already enforces microsegmentation — the two layers overlap rather than compete.
Laid out dimension by dimension, this is the table to hold a shortlist against:
| Dimension | Connection-defined | Topology-defined |
|---|---|---|
| Primary outcome | Attack surface reduction, least privilege | Lateral movement containment |
| Unit of segmentation | Identity of a service or application | Workload, segment, port, protocol |
| Trust model | Every connection explicitly authorised | Implicit trust inside a segment |
| Pre-auth exposure | None; services are dark | Visible within allowed segments |
| Boundary awareness | Spans clouds, data centres, OT zones | Bound to one network or domain |
| Policy expression | Who, which service, under what conditions | Source, destination, port, protocol |
| Change cadence | Event-driven (login, posture, risk) | Lifecycle-driven (deploys, topology) |
Where they overlap is stated plainly in v3.0: when services are first-class identities, SDP already enforces microsegmentation. That gives architects a clean mental model to work from — SDP is the guard on the first packet, microsegmentation is blast radius containment after the connection. A dimension-by-dimension comparison of three remote access architectures is in VPN, gateway ZTNA and SDP compared.
The first step is not writing rules; it is drawing the flows
v3.0 gives the implementation framework a chapter of its own, and it opens by insisting you define the protect surface before you write a single rule. The protect surface is the set of data, applications, assets and services (DAAS) in scope — settle what you are protecting before arguing about how.
Mapping the transaction flows follows, in five repeatable passes that fold back on themselves.
- Five passes, run in order
- Reviewable artefacts
Text version of this diagram
The five passes of transaction flow mapping, and the three reviewable artefacts they should produce.
Five passes, in order, with the last folding back to the first
- 1. Scope the protect surface: enumerate the DAAS elements.
- 2. Discover live flows: who, over what, along which path.
- 3. Classify and label: attach business meaning to each flow.
- 4. Model access paths: draw the current picture against the intended one.
- 5. Validate and iterate: run report-only before enforcing.
- An arrow runs from the fifth pass back to the first, labelled “drift and new dependencies feed back in: this is a loop, not a one-off project”.
Three reviewable artefacts
- Labelled flow inventory.
- Application-layer diagrams.
- Risk and maturity matrix.
Two details deserve calling out on their own.
First, run report-only before you enforce. Generate the suggested policy, confirm that no legitimate flow breaks, and only then switch enforcement on. What that buys you is the outage you would otherwise have on cutover day.
Second, AI-assisted discovery and policy generation are recommendations, not autonomous enforcement. v3.0 is deliberately conservative here: automation may cluster flows, label services and predict least privilege sets, but a human reviews before anything is applied. That line belongs in your own operations runbook.
OT and edge: decide now what happens the day the controller is unreachable
Industrial control systems order their priorities differently from IT. Safety and availability come before confidentiality, and many processes must keep running when the WAN does not. Bringing SDP onto a plant floor or out to the edge is not the same architecture scaled down; it is a different failure design.
The adaptations in v3.0 come down to four things:
- Put a controller inside the zone. A lightweight controller instance at Level 3 or in the DMZ keeps authorising locally through a WAN outage and syncs upstream when the link returns.
- Cache policy locally. Edge gateways keep a trimmed decision engine so authorised flows survive hours of controller absence.
- Write the failure logic down. Safety-side fail-open, read-only degradation or a human override — which one you pick is a business decision, not a technical one, and it has to line up with the safety clauses of IEC 62443. Both “wide open” and “total shutdown” are wrong answers.
- Wrap what cannot run an agent. An inline gateway terminates SDP on the outside and speaks the original industrial protocol on the inside, with no firmware change at all.
The point of this section is sequence rather than technique: in OT, failure modes get agreed during selection, not discovered the week before go-live.
Secure by Design: SDP is built in, not bolted on
Former CISA director Jen Easterly’s 2024 line — “we don’t need more security products, we need more secure products” — became the rallying call of Secure by Design. v3.0 spends a section mapping SDP onto that framework, and the fit is structural rather than rhetorical: services start deny-by-default, nothing is listening on the internet, and every micro-tunnel is authenticated, authorised and logged at identity level.
The same section names open-source routes for embedding zero trust into a product rather than wrapping it afterwards: identity-first connectivity SDKs at the overlay tier, and SPIFFE/SPIRE at the service-to-service tier, which issues cryptographic workload identities an application can request programmatically.
So beyond the feature checklist, three structural questions are worth putting to a vendor:
Are the control and data planes genuinely separate? A controller that only makes authorisation decisions and never sits in the data path determines both where your bandwidth ceiling is and who is technically capable of touching your traffic.
Is inbound exposure actually zero? If the protected side still has to open a port for someone to connect into, that port is your new attack surface.
Are non-human identities first-class? Whether services, workloads, scheduled jobs and AI agents can get an identity and be authorised the same way people are decides whether this architecture can follow your estate as it changes.
The inventory, parallel-running and phased verification path for replacing an existing VPN is in choosing and switching to a VPN replacement. Merak implements the SDP architecture described here; its specifications and deployment options are on the Merak product page.
Terms and further reading
| Term | In one sentence | Source |
|---|---|---|
| SDP v3.0 | CSA’s third-edition SDP architecture guide, 2026 | CSA SDP Architecture Guide v3 |
| Software-defined perimeter (SDP) | Resources become reachable only after authentication | How a software-defined perimeter works |
| Zero trust architecture | Trust is never granted on network position | What zero trust actually is |
| Implicit trust | Assuming the inside is safe once past the door | NIST SP 800-207 |
| Policy drift | Rules and reality diverging over time | CSA SDP Architecture Guide v3 |
| Lateral movement | Spreading from one internal host to the next | MITRE ATT&CK TA0008 |
| Single packet authorisation (SPA) | One signed packet carries the whole authorisation | CSA SDP Specification v2.0 |
| Network-Infrastructure Hiding Protocol (NHP) | Session-layer verification that hides domains and IPs | CSA Stealth Mode SDP |
| Noise Protocol Framework | A set of handshake patterns for encrypted channels | Noise Protocol Framework |
| Identity-based cryptography (IBC) | An identity string serves directly as the public key | Identity-based cryptography |
| Identity-first connectivity (IFC) | Connectivity abstracted over identity, not IP | CSA SDP Architecture Guide v3 |
| Mutual TLS (mTLS) | Both ends of a TLS connection present certificates | Mutual authentication |
| Topology-defined segmentation | Governs where traffic flows once connected | Network segmentation |
| Microsegmentation | Segmentation down to the workload or service | CSA SDP Architecture Guide v3 |
| Protect surface (DAAS) | The data, applications, assets and services in scope | CSA Map the Transaction Flows |
| Mapping the transaction flows | Inventory real traffic before writing policy | CSA Map the Transaction Flows |
| Principle of least privilege | Grant only what is needed, nothing more | Principle of least privilege |
| Safety-side fail-open | Keeping operations running when control is lost | NIST SP 800-82 Rev. 3 |
| IEC 62443 | Security standards for industrial control systems | ISA/IEC 62443 series |
| Secure by Design | Security built into the product, not added later | CISA Secure by Design |
| SPIFFE/SPIRE | Open framework issuing workload identities | SPIFFE |
| Control plane / data plane | Separating what decides from what carries traffic | Forwarding plane |
| Zero Trust Maturity Model | A staged way to assess zero trust adoption | CISA Zero Trust Maturity Model |
If firewalls and VPNs still have their uses, why move on SDP now? Because the cost of both has migrated from purchase to operations: firewall rule sets grow into thickets nobody can audit, and the broad network reachability a VPN hands out is the cheapest path ransomware has for moving laterally. SDP v3.0 does not ask you to replace your infrastructure over a weekend. It offers an order of operations — protect high-value assets and hybrid cloud workloads first, then pull implicit trust out of the rest of the architecture.
The diagrams here are simplified for explanation: controller high-availability topologies, the full field definitions of SPA and NHP, and the differences between implementations in policy caching and failure modes have been left out for clarity, and the specifications govern actual behaviour. If you want to discuss how this architecture would land in a specific environment, get in touch.