A software-defined perimeter (SDP) is a security architecture that controls access to applications by verifying users and their devices first and only then building a connection to the specific applications they are allowed to use. Instead of placing people “inside” a trusted network, as a traditional VPN does, SDP draws a small, individual perimeter around each permitted connection. The approach was formalized by the Cloud Security Alliance and is one of the foundations of what is now usually sold as Zero Trust Network Access (ZTNA).
At a glance
- SDP verifies identity and device first, then connects the user to specific applications, not to the whole network.
- Protected applications typically accept connections only through the SDP gateway, which hides them from ordinary internet scanning.
- It limits how far an attacker can move with one compromised account, though it doesn’t stop misuse of the access that account legitimately has.
- It is a common replacement for remote-access VPNs and a building block of zero trust designs.
- Today most products built on the idea are sold as ZTNA, often inside a SASE or SSE platform.
What problem it solves
Traditional network security assumed that anything inside the corporate network could be trusted. A firewall guarded the edge and a VPN let remote users in. Once connected, a VPN user often had network-level access to far more systems than their job needed. If an attacker stole those credentials, they inherited the same reach and could use lateral movement to find valuable targets.
Cloud applications, remote work and contractor access have stretched that model further. SDP removes the idea of a trusted inside. Every connection is checked against who the user is, the state of their device and the policy for that application, and the user is connected only to what they are allowed to reach.
How it works
SDP designs usually have three parts:
- A client or agent on the user’s device, which identifies the user and reports on device health. Some products offer browser-based access without an agent for web applications.
- A controller, which checks the user’s identity, typically through an identity provider with multi-factor authentication, evaluates device posture, and decides which applications the user may reach.
- Gateways in front of the protected applications, in a data center or cloud, which accept connections only when the controller has approved them.
The sequence is authenticate, authorize, then connect. Once approved, the user gets an encrypted connection to the specific application, not a route into the network. Many implementations keep checking during the session and can cut access if the device or risk level changes. Some use techniques such as single packet authorization, where the gateway ignores any connection attempt that doesn’t start with a valid cryptographic token, so the protected services don’t answer ordinary scans.
Policies are usually written per application and per group: finance staff on managed laptops can reach the accounting system, contractors can reach one project tool, and so on. That gives a similar effect to microsegmentation for user access.
When it matters for buyers
- When replacing or reducing VPN use. SDP or ZTNA can give remote staff access to the applications they need without broad network access.
- When giving third parties access. Contractors and partners can be limited to specific systems, with access that is easy to revoke.
- When cyber insurers or auditors ask about remote access. Many questionnaires ask how access is restricted and whether MFA is enforced.
- When moving toward a secure access platform. SDP-style access is usually one component of a SASE or SSE service, alongside web filtering and cloud app controls.
Our Security Service Edge guide covers how per-application access is packaged with other cloud-delivered security controls.
Questions to ask vendors
- Which applications and protocols are supported, including non-web and legacy applications?
- Is an agent required, and what can unmanaged or contractor devices do without one?
- Which identity providers and device-management tools does it integrate with for posture checks?
- Does it re-check users and devices during a session, and how quickly can access be revoked?
- Where are your gateways or points of presence, and how will that affect performance for our users?
- How are the controller and gateways themselves protected and patched, and who is responsible for that?
- What logs are produced, and can they be sent to our SIEM?
How it differs from ZTNA
SDP and Zero Trust Network Access (ZTNA) describe largely the same idea and are often used interchangeably. SDP is the older architectural term for identity-first, per-application access with a controller and gateways. ZTNA is the market category most vendors use today, and it covers a wider range of designs, including cloud-delivered services where the provider runs the gateways. In practice, compare products on what they do, such as application coverage, device checks and session controls, rather than on which name they use.