Software Defined Perimeter

What is a Software Defined Perimeter (SDP)?

A Software Defined Perimeter (SDP) is a security architecture in which a system only becomes visible and reachable after the identity of the user and the state of their device have been verified, and in which every permitted connection gets its own encrypted tunnel to exactly that one resource. Instead of one static network boundary guarded by a Firewall, an SDP draws a small, dynamic perimeter per user and per session around the resources they actually need. The Cloud Security Alliance (CSA) published the first SDP specification in April 2014 and version 2.0 in March 2022.

In OT environments, an SDP prevents unauthorised users, devices or scanners from even seeing that systems such as SCADA, PLCs or a Historian exist.

🧠 Which principles underpin an SDP?

The idea comes from the “need-to-know” networks of the US Department of Defense, where infrastructure that does not need to be seen is simply not visible (“black” networks). The CSA turned that into an open specification for enterprises. Five principles recur:

1. Concealment by default - resources, and even the gateways, do not respond to traffic from unknown senders. A port scan sees nothing.
2. Authenticate first, connect second - user and device are verified before a network connection exists, not afterwards as with a classic login.
3. Dynamic policy - access depends on identity, role, device posture, location and time, and is decided per session in line with Least Privilege.
4. Mutual authentication and encryption - client and gateway prove their identities to each other with certificates, usually via mutual TLS (IKE/IPsec in some models).
5. Full visibility - every access is logged and traceable to a person and a device.

That makes SDP a concrete implementation of Zero Trust: trust nothing on the basis of network location, and verify every connection again.

🔧 How does an SDP work technically?

The CSA specification separates a control plane from a data plane. The control plane decides who may go where; only then does the data plane carry the actual traffic.

A connection is set up in a fixed order:

1. The controller comes online and connects to the identity and authorisation services.
2. The gateways (accepting hosts) register with the controller and from then on ignore all unregistered traffic.
3. A client contacts the controller and authenticates both user and device.
4. The controller determines which gateways and resources this client may reach.
5. The controller instructs those gateways to admit the client.
6. The client receives the list of permitted resources and builds a mutually authenticated tunnel to each one.

Concealment is achieved with Single Packet Authorization (SPA). Before a gateway or controller accepts any TCP connection at all, the client must send one cryptographically authenticated packet, in the specification over UDP. In version 1.0 that packet carries, among other fields, a one-time code based on HOTP (RFC 4226), an HMAC-based algorithm, so the gateway ignores packets without a valid code. Without a valid SPA packet the port does not respond, so scanners and botnets find no open service. Version 2.0 expanded the SPA message format and its alternatives, and added initial guidance for IoT devices.

🔄 What is the difference between an SDP and a VPN?

An SDP strongly limits lateral movement but does not eliminate it: an authorised laptop that is itself compromised can still reach the systems it has access to. That is why network segmentation inside the OT network remains necessary.

🧱 Which SDP deployment models exist?

Specification 2.0 describes six deployment models. They differ in topology, but all enforce the same principle.

For OT, the client-to-gateway model is by far the most important: a PLC or older SCADA server cannot run SDP software. Note that encryption then ends at the gateway. The last leg between gateway and PLC remains unencrypted traffic such as Modbus, so the gateway belongs as close to the asset as possible, in the same zone.

🏭 Why is an SDP useful in OT?

An SDP therefore supports several requirements in IEC 62443, such as restricted data flows between zones and conduits (Zones and Conduits Model) and controlled access via untrusted networks. It also fits well with the Purdue Model: the gateway sits in the DMZ or directly in the target zone, the controller in the DMZ or in a managed (cloud) environment outside the production zones.

🧭 How do you introduce an SDP in OT step by step?

1. Inventory access needs - start from an up-to-date asset inventory and record, per supplier and employee, which systems they need.
2. Choose the model - for PLCs and older systems the client-to-gateway model, for modern servers possibly client-to-server.
3. Connect identity - link the controller to your IAM environment and require MFA and device certificates.
4. Place gateways close - put gateways in the target zone or the DMZ, never centrally in the IT network.
5. Start with one use case - typically remote maintenance by a supplier (Remote Maintenance), with time windows and approval per session.
6. Log and monitor - send all session data to your SIEM and periodically review which access rights are still needed.
7. Expand - step by step replace broad VPN access and fixed firewall rules.

In the Netherlands this is relevant for organisations under the Cybersecurity Act (Cyberbeveiligingswet, in force since 15 August 2026), which must demonstrate appropriate measures for access control and supplier risk. An SDP is not a legal requirement, but it is a well-defensible measure for remote access.

❓ Frequently asked questions

Is a Software Defined Perimeter the same as ZTNA?

Software Defined Perimeter and Zero Trust Network Access (ZTNA) largely describe the same idea: per-application access after verifying identity and device. SDP is the open architecture specification of the Cloud Security Alliance, while ZTNA is the market term for products that deliver this principle; Gartner published its first market guide for it in 2019.

How does an SDP relate to NIST SP 800-207?

NIST SP 800-207, published in August 2020, explicitly names the software defined perimeter as one of three approaches to building a Zero Trust architecture, alongside enhanced identity governance and micro-segmentation. The publication refers to the CSA specification 1.0 in this context.

Can a PLC itself be an SDP client or SDP gateway?

A classic PLC cannot run SDP software, so it gets a gateway in front of it. The SDP gateway then protects the PLC as accepting host, while traffic between gateway and PLC stays unencrypted and therefore has to remain within the same zone.

What is Single Packet Authorization?

Single Packet Authorization (SPA) is the technique that keeps an SDP gateway invisible: the gateway only responds after the client has sent one cryptographically signed packet. Without that valid packet a scanner sees no open port, which makes attacks on the access service itself much harder.

Does an SDP replace the firewall in OT?

An SDP does not replace the firewall but complements it. The firewall keeps filtering traffic between zones, while the SDP decides which user may reach which system at which moment.

What are the drawbacks of an SDP in OT?

An SDP requires well-functioning identity management and an available controller; if the controller fails, nobody can set up new sessions. Commercial SDP and ZTNA products are also rarely interchangeable, which increases dependence on a single vendor, so plan redundant controllers and a documented emergency procedure.

📌 In summary

A Software Defined Perimeter makes OT systems invisible and gives only verified users and devices per-session access to exactly the systems they need.

An SDP separates deciding (controller) from admitting (gateway), hides services with Single Packet Authorization and encrypts every session, usually with mutual TLS. In OT it works mainly as a client-to-gateway solution for remote access and supplier maintenance, complementing segmentation and firewalls within a Zero Trust strategy.