Software Defined Perimeter (SDP): How It Hides Your Network
A software defined perimeter (SDP) hides applications and servers from the internet until each user and device is verified, then connects them to only the approved resource. That matters because remote access is a favorite way in: Verizon’s 2026 Data Breach Investigations Report (DBIR) found VPN access made up 44% of connection types sold by initial access brokers.
What Is a Software Defined Perimeter (SDP)?
An SDP is a zero trust access approach that keeps applications invisible to anyone who has not been authenticated and authorized. A controller checks the user’s identity and device first. Only then does a gateway open a narrow, encrypted connection to one specific application, so unauthorized users cannot see, scan or attack what sits behind it.
SDP Full Form and Meaning in Cybersecurity
SDP stands for software defined perimeter. In cybersecurity, it means the perimeter is drawn in software around each user and each application, not in hardware around a whole building or network. Outside security, SDP has other meanings (Session Description Protocol in voice and video calling is the most common), so check the context.
SDP in Plain Terms
Think of a traditional network as an office building with a lobby anyone can walk into. A VPN gives approved staff a key card to the whole building. An SDP removes the building’s front door from the street map: visitors cannot find it until a guard has checked their ID and walked them to one room.
How SDP Evolved: From Black Core to Zero Trust Network Access
SDP did not appear from nowhere. It is the practical result of two decades of work on removing trust based on network location. The timeline below uses the history set out in NIST Special Publication (SP) 800-207 (2020) and later government guidance.
Mid-2000s: DISA’s “Black Core” and the Jericho Forum
NIST SP 800-207 traces the idea back to the Defense Information Systems Agency (DISA) and the Department of Defense, whose “black core” strategy moved from perimeter security toward protecting individual transactions. In 2004, the Jericho Forum publicized “deperimeterization,” the idea of limiting trust based on network location instead of relying on one static boundary.
2010s: Zero Trust Gets a Name and SDP Gets a Specification
NIST credits John Kindervag, then at Forrester, with coining the term “zero trust.” The Cloud Security Alliance (CSA) also published an SDP specification; NIST’s reference list dates Specification 1.0 to 2015. NIST SP 800-207 later described its agent and gateway model and its multi-cloud server-to-server model as implementations of that specification.
2020 to 2022: NIST Defines the Architecture and the US Government Mandates It
NIST SP 800-207 (2020) named SDP as one of three ways to build a zero trust architecture, alongside enhanced identity governance and microsegmentation. In January 2022, the Office of Management and Budget memo M-22-09 required US federal agencies to meet specific zero trust goals by the end of fiscal year 2024.
2023 to Today: Maturity Models, Practice Guides and ZTNA Products
The Cybersecurity and Infrastructure Security Agency (CISA) released its Zero Trust Maturity Model Version 2.0 in April 2023. In June 2025, NIST’s National Cybersecurity Center of Excellence (NCCoE) published SP 1800-35, built with 24 collaborators and 19 example implementations, including SDP builds. Commercially, most vendors now sell SDP ideas under the label zero trust network access (ZTNA).
How a Software Defined Perimeter Hides Your Network
SDP flips the normal order of networking: authenticate first, connect second. A firewall or VPN concentrator has to listen on an open port for anyone to knock. An SDP gateway does not answer at all until the controller has approved the request.
The Three Building Blocks, Mapped to NIST
| SDP term | NIST SP 800-207 term | What it does |
|---|---|---|
| SDP controller | Policy engine and policy administrator | Checks identity, device and context, then decides and sets up the session |
| Initiating host (client) | Subject using a device agent | Requests access and proves who and what it is |
| Accepting host or gateway | Policy enforcement point (PEP) | Opens the connection to one approved resource, then closes it |
A Connection, Step by Step
- The user’s device agent contacts the controller, not the application.
- The controller checks identity through the identity provider, including multi-factor authentication (MFA), plus device health such as patch level and disk encryption.
- If policy allows, the controller tells the gateway to accept this one device for this one application.
- The client and gateway set up a mutually authenticated, encrypted tunnel, often using mutual TLS (mTLS), where both sides present certificates.
- The session ends when the work is done or when the controller revokes it.
Many SDP products also use a technique called single packet authorization (SPA). The gateway keeps its ports closed and silently drops traffic until it receives one cryptographically signed packet from an approved client. To a port scanner, the gateway looks like nothing is there.
SDP Deployment Models
SDP can connect different kinds of endpoints, and the model you choose depends on what you are protecting:
- Client-to-gateway: the most common model. A device agent connects to a gateway that sits in front of one or more applications. NIST SP 800-207 (2020) calls this the agent and gateway model and says it suits organizations with a strong device management program.
- Client-to-server: the agent connects straight to a server that runs the gateway function itself, with no separate gateway in front.
- Server-to-server: servers or services authenticate to each other before talking. NIST describes its multi-cloud use case as the server-to-server form of the CSA specification, with enforcement points placed at each application and data source.
- Client-to-server-to-client: two clients reach each other through a server that brokers the session, such as for peer-to-peer calling or remote support tools.
For most small and mid-sized businesses, client-to-gateway covers remote staff and contractors. Server-to-server matters once workloads span more than one cloud provider.
Why Attackers Cannot Scan What They Cannot See
NIST SP 800-207 (2020) explains the payoff: resources “may not even be discoverable without accessing a PEP,” which “prevents attackers from identifying targets via scanning and/or launching DoS attacks against resources located behind PEPs.” It also notes the limit: some components, such as DNS servers, must stay reachable. The practical takeaway is to list every application currently reachable from the internet and ask which ones only staff or partners need. Those are your first candidates to move behind an SDP gateway.
SDP vs VPN and SDP vs ZTNA
The SDP vs VPN difference is about what a user gets after logging in. A VPN usually places the device on the network. An SDP gives access to named applications only.
| Factor | Traditional VPN | SDP |
|---|---|---|
| Visibility | Gateway listens on an open port | Gateway hidden until authorized |
| Access granted | Network segment or whole network | Individual applications |
| Trust model | Trusted after login | Checked per session against identity, device and context |
| Lateral movement | Possible across reachable hosts | Limited to approved applications |
| Device health checks | Optional, often missing | Built into the access decision |
VPNs are not about to disappear, and they remain a common target. In the System Intrusion breaches Verizon analyzed for its 2026 DBIR, VPN was an action vector in around 16% of cases, about the same as the year before.
SDP vs ZTNA: Are They the Same?
Mostly, yes. SDP is the architecture; ZTNA is the market name for products that deliver it. Most ZTNA services follow the same pattern of controller, client and gateway, though some are agentless and broker browser access through a cloud proxy. When a vendor says ZTNA, ask how its gateway behaves before authentication. If it still listens openly, it is not hiding anything.
In secure access service edge (SASE) and security service edge (SSE) platforms, ZTNA is the component that handles private applications. That is where SDP-style access most often reaches small and mid-sized businesses today.
SDP Limitations and How to Roll It Out
SDP removes a large class of exposure, but it adds new dependencies you must plan for.
Limitations NIST Warns About
- The controller is a high-value target. NIST SP 800-207 (2020) warns that a compromised policy administrator “could allow access to resources that would otherwise not be approved,” so controller changes must be logged and audited.
- Availability depends on the control plane. If an attacker disrupts the policy enforcement points or the controller, users lose access. NIST recommends hosting policy enforcement in a well-secured cloud environment or replicating it across locations.
- Legacy applications. Older apps that hard-code IP addresses, rely on unusual protocols or expect wide network access can be hard to publish one by one.
Is SDP Worth It for a Small Business?
Here is an illustrative example. A 60-person engineering firm uses a VPN so staff can reach an on-premises accounts system and a project file server. A contractor’s laptop with a stolen password could join the VPN and see every internal host. With SDP, that contractor would be limited to the one project share they need, and only from a device that passes health checks. For a firm like this, a cloud-delivered ZTNA service with per-user pricing is usually more realistic than self-hosting a controller.
A Phased Rollout
- Inventory every application remote users and third parties reach, and who needs each one.
- Connect the SDP or ZTNA service to your identity provider and enforce MFA.
- Move contractors and third parties first, since they need the narrowest access.
- Migrate employee applications one at a time, keeping the VPN for anything not yet moved.
- Close the VPN’s internet-facing port once the last application is migrated.
Your SDP Readiness Checklist Before You Retire the VPN
A software defined perimeter is only as strong as the identity, device and application inventory behind it. Before you switch off the VPN, confirm four things: every remote-access application has an owner and an approved user group, MFA covers every user including contractors, device health rules exist for managed and unmanaged devices, and controller changes are logged with a backup access path documented. If any item is missing, fix it first, because SDP will enforce whatever gaps you bring into it. If you want help scoring that checklist against your current setup, Cyber Security Solutions Ltd offers a free, no-obligation cyber security assessment, which you can request through our contact page.
FAQs
SDP stands for software defined perimeter. It is a zero trust access model that hides applications until a user and device are verified, then connects them to only the approved resource. The "perimeter" is drawn in software around each user and application, instead of around a whole network as with firewalls and VPNs.
Yes. SDP is often used to replace or reduce reliance on remote-access VPNs. A VPN places a device on the network after login, while SDP grants access to specific applications only, after checking identity and device health for each session. Many organizations run both during migration and retire the VPN gradually.
SDP is the underlying architecture: a controller, client and gateway that hide resources until access is approved. Zero trust network access (ZTNA) is the commercial product category that delivers that model, often as a cloud service. In practice, most ZTNA products are SDP implementations with different packaging, pricing and management features.
It does not have to be. Self-hosting a controller and gateways takes skills most small firms lack, but many cloud-delivered ZTNA services price per user and need little hardware. Costs vary by vendor and features, so compare total cost against your current VPN, firewall licensing and the time spent managing remote access.
No. SDP controls who can reach specific applications, but you still need firewalls to filter other traffic, protect office networks and block unwanted inbound connections. SDP reduces how many services must be exposed through the firewall. Many organizations end up with fewer open firewall ports once applications move behind SDP gateways.
Yes, but the targets change. Applications behind the gateway become hard to find, so attackers focus on stolen credentials, unmanaged devices and the controller itself. NIST SP 800-207 warns that controller compromise or disruption are key risks, so protect administrator accounts, log configuration changes and plan for controller availability.
