Palo Alto Prisma SDWAN Deep Dive Part 5: Security — Prisma Access, Clean Pipe, and CloudBlades
Part 1 called Prisma SD-WAN’s destination “app-defined SASE” rather than just “app-defined SD-WAN,” and this is the post where that distinction earns its keep. Compare this against Fortinet’s model, where every FortiGate carries the full NGFW stack locally by design — Prisma SD-WAN draws the line between local and cloud-delivered security in a genuinely different place, and understanding exactly where that line sits is the point of this post.
What the ION does locally: Zone-Based Firewall
Every ION runs a stateful, application-aware Zone-Based Firewall (ZBFW) — segmentation and policy enforcement between zones (WAN, LAN, VPN, and any custom zones you define), using the same App-ID classification from Part 4 as the policy match criterion rather than raw port/protocol tuples. This is real, useful security: east-west segmentation within a branch, policy that says “guest Wi-Fi can reach the internet zone and nothing else” enforced locally, and outbound access control that doesn’t depend on anything upstream being reachable.
What ZBFW is not — and this is the honest comparison against Fortinet’s every-box-is-a-firewall model — is a full next-generation firewall stack. There’s no IPS engine, no antivirus/sandbox integration, no URL category database, no DLP inspection running natively on the ION itself. Palo Alto’s own guidance is explicit about where that heavier inspection belongs: at the data centre, a full NGFW is the recommended answer, leveraging Palo Alto’s advanced threat-prevention capabilities; at the branch and for anything internet-bound, that inspection is meant to happen in the cloud, via Prisma Access. The ION’s job is fast local segmentation and getting a flow to the right place — the right place for deep inspection is deliberately not the branch box.
Prisma Access and Clean Pipe
Prisma Access is Palo Alto’s cloud-delivered security service — the SASE half of the SASE story — and Prisma SD-WAN’s job with respect to it is to get branch traffic there reliably. The Clean Pipe framing describes exactly that use case: branch and retail traffic, VPC/cloud traffic, traffic from a Prisma-SD-WAN hub site, and even traffic from a third-party SD-WAN, all steered into Prisma Access so that URL filtering, threat prevention, and DLP apply to internet-bound flows regardless of what device originated them. When an ION steers a flow to Prisma Access, that’s an ordinary site-to-site IPsec Service Connection under the hood — the two documented topologies are Type 1 (branch talking to a headquarters site) and Type 2 (branch, headquarters, and a regional data centre all in the same design), and which one applies is purely a function of how many tiers of site the customer’s WAN actually has.
The mechanism that decides which traffic makes that trip is the same App-Defined Policy machinery from Part 3, extended to security rather than just path selection: service chaining in Prisma SD-WAN’s path policy can force traffic to a local next-hop (backhauled to a DC firewall, the traditional pattern) or route it directly to a SASE destination based on service groups referenced in the policy — no backhaul at all, no DC in the path, just branch-to-cloud-security-to-internet. That second pattern is the one that actually delivers on “app-defined SASE”: the same per-application policy engine that decided which fabric path a Teams call should ride in Part 3 is also deciding which flows get security-inspected locally versus sent to the cloud for it.
CloudBlades: chaining without touching the branch
CloudBlades is the integration platform that makes the “chain a cloud service in without redeploying the branch” pattern general-purpose rather than Prisma-Access-specific. Popular CloudBlades in current use include Zscaler Internet Access, Netskope, Akamai SIA, and — notably for Part 6 — AWS Transit Gateway. The Zscaler integration is representative of the pattern: the CloudBlade automatically creates, manages, and maintains IPsec and GRE tunnels from every relevant remote ION out to Zscaler Enforcement Nodes, entirely from configuration pushed centrally — no manual per-site tunnel building, no touching an individual ION’s config to add or change the integration. If a customer is already committed to a third-party SSE vendor rather than Prisma Access, CloudBlades is how Prisma SD-WAN participates in that architecture instead of insisting on its own stack — a genuinely more vendor-agnostic security posture than “buy our firewall too,” even though the natural, most-integrated pairing is obviously Prisma Access.
ZTNA and the branch
The convergence Fortinet’s SD-WAN series covered — collapsing ZTNA enforcement onto the same device already doing SD-WAN — shows up here too, but delivered from the cloud side rather than the branch box. Prisma Access carries Palo Alto’s ZTNA connector functionality as part of the same SASE stack that’s already inspecting internet-bound traffic; user-to-application access control is a Prisma Access policy, not something configured on the ION. This is consistent with everything else in this post: the ION’s job is getting the right traffic to the right place fast, and the identity- and application-aware enforcement — ZTNA included — lives in the cloud tier that has the compute budget and the update cadence to do it properly.
The honest trade-off
Line this up against Fortinet’s model and the trade-off is symmetrical, not a strict win for either side. Fortinet’s FortiGate-everywhere approach means full NGFW depth is available at every branch from day one, with no dependency on a cloud security tenant being reachable — genuinely useful for a site with unreliable internet where “send it to the cloud for inspection” is itself a fragile plan. Prisma SD-WAN’s approach means branch hardware stays comparatively simple (ZBFW plus App-ID, not a full threat-prevention stack) and the heavy inspection scales and updates centrally without touching branch devices at all — genuinely useful for an organisation already committed to Prisma Access or another SSE vendor, where duplicating that inspection at every branch would be pure waste. Which one is right depends entirely on how reliable a given site’s path to the cloud actually is, and how much the organisation has already invested in a centralized security stack — exactly the kind of question Part 8’s comparison capstone is built to help answer directly rather than in the abstract.
What’s next
Part 6 follows the CloudBlades AWS Transit Gateway integration mentioned above out to its logical conclusion: how Prisma SD-WAN actually reaches into public cloud, what “DC VPN” means for a VPC or VNet, and how that compares to Cisco’s native Cloud OnRamp automation and the Fortinet cloud on-ramp designs already on this site.