Integrating SD-WAN with Prisma Access

Why Converge SD-WAN and Prisma Access

For years, branch networking and branch security were two separate projects with two separate teams. SD-WAN solved transport: it made cheap broadband behave like an expensive MPLS circuit. Secure access service edge (SASE) solves the other half by moving inspection, threat prevention, and access control into a cloud that sits close to the user.

Converging Prisma SD-WAN with Prisma Access lets a branch send internet- and SaaS-bound traffic to the nearest cloud gateway for full inspection, while still using application-aware path selection across its local circuits. The result is one operating model instead of two stacks bolted together.

Reference Architecture

At a high level the design has three moving parts:

• ION devices at each branch running Prisma SD-WAN, selecting paths per application based on live SLA telemetry.
• Prisma Access providing the cloud security layer, reached over standard IPsec tunnels.
• A controller plane (the Strata Cloud Manager / CloudGenix controller) that pushes policy and collects analytics.

Remote Networks vs. Automatic Onboarding

There are two ways to connect a branch ION to Prisma Access. The first is the classic remote network: you define the IPsec tunnel, peer addresses, and the branch subnets in the Prisma Access configuration. The second is automated onboarding, where the SD-WAN controller programs the tunnel for you and keeps the routing in sync.

Automated onboarding is the right default for greenfield deployments because it removes the most common source of outages — drift between what the branch advertises and what the cloud expects. Use manual remote networks only when you need an explicit design the automation cannot express.

Service Connections for Private Apps

Internet and SaaS traffic exits through the SD-WAN-to-Prisma-Access tunnel. Private application traffic — data centers, internal DNS, identity services — should reach Prisma Access through a service connection, not through the branch tunnels. Keeping private-app reachability on service connections gives you symmetric routing and a single, predictable path for east-west traffic between mobile users, branches, and private apps.

Designing the Integration

Traffic Steering Decisions

Decide, per application class, where inspection happens:

• Internet and SaaS: steer to Prisma Access for full security inspection.
• Branch-to-branch: keep on the SD-WAN fabric where latency matters and the traffic is already trusted.
• Branch-to-data-center: usually via service connection, so the same security policy applies as for mobile users.

Routing and BGP

Run BGP between the ION and Prisma Access rather than static routes wherever possible. Dynamic routing lets the branch withdraw a prefix the moment a circuit fails, so the cloud stops sending return traffic down a dead path. Watch for asymmetry: traffic that leaves through one tunnel and tries to return through another will be dropped by stateful inspection.

Security Policy Ownership

The single biggest operational win of convergence is deciding, deliberately, who owns which policy. App-path and QoS decisions belong to the SD-WAN policy. Threat prevention, URL filtering, decryption, and access control belong to Prisma Access. Do not try to recreate firewall policy on the branch — let the cloud be the enforcement point and keep the branch focused on transport quality.

Operational Considerations

• Capacity: size the branch tunnels for the inspected throughput, not just the raw circuit speed. Encryption and the cloud round trip both add overhead.
• Resilience: terminate to two Prisma Access compute locations where availability requirements justify it, and let BGP handle failover.
• Visibility: correlate SD-WAN path analytics with Prisma Access logs. A "slow application" complaint is usually either a path problem (SD-WAN) or an inspection/decryption problem (Prisma Access), and you want both views in one timeline.

Common Pitfalls

• Sending private-app traffic over the internet tunnels instead of a service connection, creating asymmetric routing.
• Leaving static routes in place after enabling BGP, which masks failover problems until a real outage.
• Duplicating security policy on the branch and in the cloud, which doubles the change workload and guarantees drift.

Summary

Converging Prisma SD-WAN and Prisma Access is less about a single feature and more about discipline: let the fabric own transport quality, let the cloud own security, connect them with dynamic routing, and keep private apps on service connections. Done that way, a branch turn-up becomes a templated, low-risk change instead of a bespoke project.