Deperimeterization: SASE, SD-WAN and software-defined networking

Why this matters

Deperimeterization is the observation that the network boundary has stopped being where security is decided. Lesson twenty-one gave the three causes: the assets left for SaaS and cloud, the users left for home and mobile, and inside stopped being safe once any foothold means being inside.

What this objective adds is the architecture that replaces it. Three technologies appear in CompTIA's bullet and they are frequently confused because vendors sell them together. SD-WAN is a transport technology. SASE is a security service delivery model. SDN is a control plane concept underlying both. Knowing which does what is most of what the objective tests.

The claim to be careful about, and the one scenarios probe, is the marketing version: that deperimeterization means perimeters are obsolete. It does not. It means the perimeter is no longer sufficient and no longer the primary control — while segmentation, zones and data perimeters from the previous four lessons remain necessary.

The lesson

What deperimeterization actually claims, and what it does not

The accurate claim has three parts.

Network location is a weak signal of trust. Being on the corporate network says little about whether a request should be authorised, because devices arrive there by many routes and attackers arrive there too.

Controls must move to where the resource and the identity are, rather than sitting at a boundary the traffic may never cross. If a user on a home network reaches a SaaS application, no corporate network is involved anywhere in the transaction, and a control at the corporate egress point is not in the path.

Every access decision should be made on evidence available at the time of the request — identity, device state, resource sensitivity, behaviour — rather than inherited from a decision made when a tunnel was established.

What it does not claim:

• That network controls are worthless. Segmentation still bounds a compromise, egress restriction still prevents exfiltration, and private endpoints still remove exposure. Those are the previous lessons and they remain correct.
• That the perimeter can simply be removed. Legacy applications with no modern authentication, management interfaces, and operational technology all still depend on network adjacency, and an estate that dismantles its perimeter before those are addressed has removed a control without replacing it.
• That it is a product. It is an architectural direction implemented over years, and a scenario describing an organisation that "implemented deperimeterization" by buying something is describing the misunderstanding.

The professional framing: defence in depth with the network as one layer rather than the primary one. That sentence resolves most questions in this objective.

SD-WAN: policy-driven transport selection, and the security it does not provide alone

Software-defined wide area networking abstracts the transport. Instead of a site having one circuit with static routing, it has several paths — private circuit, broadband, mobile — and a controller decides per application which path to use based on policy, cost and measured link quality.

What it genuinely provides:

• Application-aware path selection, so latency-sensitive traffic takes the good path and bulk traffic takes the cheap one.
• Resilience, with failover between paths without a routing convergence event.
• Central policy, applied across many sites from one controller — the operational gain that drives adoption.
• Encrypted overlay tunnels between sites, which is real and is often mistaken for the whole security story.

What it does not provide, and this is the examinable part:

• Inspection. SD-WAN chooses a path; it does not examine what is on it.
• Access control for users. It is a site-to-site technology.
• Threat protection, data loss prevention or web filtering. These are separate functions.

The security consequence that scenarios are built on is the direct internet breakout. SD-WAN's efficiency case depends on sending SaaS and internet traffic straight out of each branch rather than backhauling it to a data centre. That removes the backhaul inefficiency and simultaneously removes every control that lived at the data centre egress. A deployment that enables local breakout without providing equivalent inspection at the branch has traded latency for exposure, usually without anyone recording the decision.

The two coherent answers are to provide security functions at the branch, which is expensive to distribute and maintain, or to deliver them from a cloud service the branch traffic passes through — which is SASE.

SASE as the convergence of network and security services at an edge

Secure access service edge converges wide-area networking and security functions into a cloud-delivered service. Traffic from users, branches and workloads goes to a nearby point of presence, where policy is applied, and on to its destination.

The security functions typically converged:

• Secure web gateway — filtering and inspection of web traffic.
• Cloud access security broker — the visibility and control of lesson thirteen.
• Zero trust network access — per-application access rather than network access, which is the next lesson's mechanism.
• Firewall as a service — network policy delivered from the cloud.
• Data loss prevention, inspecting content in the same pass.

Where the security half is emphasised over the networking half, the same idea is often called a security service edge. The distinction is not deeply examinable; the architecture is the same.

What SASE genuinely changes:

• Policy follows the user, not the location. The same rules apply in an office, at home, or on a mobile network, which removes the class of gap where remote users are governed differently from office users.
• Local breakout becomes safe, because the inspection is at the edge rather than at headquarters. This is what makes SD-WAN's efficiency case compatible with control.
• Inspection scales without appliances, and its capacity is the provider's problem.

What to be careful about, and scenarios test all three:

• The provider becomes a dependency in the path of all traffic. Their availability is now your availability, and their breach is potentially your exposure — which makes this a third-party risk assessment of the kind lesson eight described, on a supplier with unusually deep access.
• Inspection requires decryption, which means the service terminates TLS. That has privacy implications, regulatory implications for some data, and breaks applications using certificate pinning. Exemption lists are necessary and are also holes in the inspection.
• It is not zero trust, though it is frequently sold as such. It is a delivery model that can deliver zero trust access as one of its functions.

Software-defined networking: the control plane as the new high-value target

SDN separates the control plane — which decides how traffic is forwarded — from the data plane, which forwards it. A controller holds the network's logic and programs the devices, which become comparatively simple executors.

The benefits that drive adoption are real: central policy, programmatic change, network as code, rapid reconfiguration, and the ability to implement microsegmentation at a scale that per-device configuration cannot reach.

The security consequence is the point of this section. The controller is the network. Whoever controls it can redirect any flow, create any path, mirror any traffic to a destination of their choosing, and bypass any policy — without touching a single device individually and frequently without generating traffic anyone inspects. In a conventional network an attacker must compromise devices one at a time; here the compromise is singular and total.

Controls that follow, and they are the same shape as the orchestration control plane from lesson fifteen — which is not a coincidence, since both are the same architectural pattern:

• The controller's management interface is the most restricted thing in the estate: isolated network, strong authentication, a small enumerated set of administrators, and administrative access brokered through a privileged path.
• Its API is an attack surface, needing authentication, authorisation and rate limiting like any other — and it is frequently deployed with weak defaults.
• Change auditing on the controller is a primary detection: an unexpected flow rule is a high-quality signal.
• Availability planning, since the controller is a single point of failure for network change and, depending on the design, for forwarding itself.
• Separation between the control plane network and the data plane network, so a compromise of a forwarded workload does not reach the controller.

The generalisation worth carrying out of domain 2: in software-defined infrastructure of every kind — networking, orchestration, cloud platforms — the control plane is a higher-value target than anything it controls, and estates consistently protect the workloads better than the thing that can reconfigure all of them.

Choosing between a SASE service and assembled components, with the trade-offs named

The decision that closes the objective, and both answers are defensible.

A converged SASE service from one provider gives a single policy model, one set of logs, one integration, and functions that are designed to work together. The costs: concentration of dependency on one supplier, a privileged position in your traffic, migration difficulty if you change your mind, and a policy model limited to what that provider supports.

Assembled components — a separate web gateway, broker, access service and firewall — give best-of-breed choice, independent replaceability, and no single supplier holding everything. The costs: several policy models to keep consistent, integration work that is yours to maintain, correlation across several log formats, and the gaps between products that nobody owns.

What actually decides it, and a scenario will hand you one of these:

• Existing estate. An organisation that already runs several of these functions well is being asked to discard working controls; one starting fresh is not.
• Scale and staffing. Assembled components need a team to integrate and maintain them. Converged services trade that operational cost for supplier dependency, which is the right trade for many organisations and is a decision rather than a default.
• Regulatory constraints on where traffic may be inspected and where decrypted content may exist, which can rule out points of presence in certain jurisdictions.
• The legacy tail. Whatever the choice, applications requiring network adjacency need a path, and the plan for them is usually the thing that determines the timeline.

Two closing observations that generalise beyond this objective. Migration is staged and reversible — run the new path alongside the old, move one application or one site at a time, keep the rollback — which is the same discipline lesson twenty applied to segmentation. And the security outcome depends on the policy, not the delivery model: a SASE deployment with permissive rules is worse than assembled components with strict ones, and a scenario comparing architectures without comparing policies is comparing the wrong thing.