NetSec Platform: Prisma Access (Distributed Enforcement Architecture)

In the previous post, I described Prisma Access as the distributed enforcement layer within the NetSec platform - steering user and branch traffic into regional enforcement points under a unified control plane.

If you are new to the discussion, it is worth reviewing that post before continuing. This article builds on those foundations and examines how the enforcement fabric itself is constructed.

Distributed Enforcement

Prisma Access is a a composition of enforcement nodes, routing domains, and service insertion points. Traffic enters the enforcement fabric through regional locations. Traffic inspection and enforcement is carried out at compute locations, by the appropriate Security-Processing Node (SPN).

Customer traffic is isolated within its own tenant and dedicated SPNs, preserving logical separation within the shared service infrastructure.

The distributed enforcement fabric comprises distinct attachment points and processing roles, each optimised for specific traffic domains:

Mobile-User Security-Processing Node (MU-SPN) - enforcement node optimised for identity-driven user traffic
Explicit-Proxy Security-Processing Node (EP-SPN) - enforcement node for explicit proxy-based web traffic
Remote-Network Security-Processing Node (RN-SPN) - enforcement node optimised for site-originated traffic
Service-Connection Corporate-Access Node (SC-CAN) - controlled ingress/egress boundary for private connectivity
ZTNA Tunnel Terminator (ZTT) - termination point for outbound-initiated application connectors
High level visual example of a multi-use case Prisma Access deployment

All cloud nodes are configured by the customer but provisioned automatically.

Internally, the enforcement fabric uses iBGP for node-to-node routing. A service infrastructure subnet is defined by the customer and used for cloud node IP addressing. A full mesh network is formed between all RN-SPNs and SC-CANs in the environment.

Where Customer Premises Equipment (CPE) peers with the service (Remote Networks or Service Connections), eBGP is used. IPSec tunnels can be built with any IPSec compliant CPE device.

Organisations may deploy one or multiple attachment types depending on the scale and complexity of their environment.

Control Plane

Strata Cloud Manager (SCM) is used for Prisma Access onboarding and initiating the automated workflows that deploy and configure the underlying network infrastructure.

All enforcement nodes operate under a unified control plane. Policy is:

  1. Defined centrally in SCM
  2. Distributed consistently to SPNs across regions
  3. Executed locally at each enforcement node
  4. Logged and correlated centrally for visibility and analytics
High level visual summary of the Prisma Access infrastructure components

Shared Responsibility

Because Prisma Access is delivered as a managed service, the distributed enforcement fabric is maintained and operated by Palo Alto rather than deployed as customer-owned appliances.

This includes the underlying service infrastructure that connects regional ingress and compute locations, as well as the orchestration systems that provision and scale enforcement components.

Customers do not deploy or manage individual appliances. They define policy in the control plane and onboard users, locations, and applications.

Provider Responsibilities:

  • Regional infrastructure lifecycle
  • Maintaining inspection engines and content
  • Capacity scaling and elasticity
  • High availability design
  • Platform upgrades and patching
  • Core service integrity
  • Securing the underlying cloud platform

Customer Responsibilities:

  • Defining and maintaining security policy
  • Onboarding users, branches, and private connectivity
  • Design of access patterns and application segmentation
  • Identity integration
  • Monitoring and responding to security events

Governance and policy authority remain with the customer, while operational responsibility for the infrastructure shifts to the service provider (Palo Alto).

Prisma Access is not a collection of independent nodes. It is a coordinated enforcement fabric operating across regions, governed centrally and executed locally.

Users, branches, and private applications all attach to the same distributed system. Policy is defined once and enforcement is applied consistently. This approach enables scale without fragmenting security.

Read more