NetSec Platform: Prisma Access (Distributed Enforcement Architecture)

In the previous post, I described Prisma Access as a cloud-delivered security edge and walked through the key use cases and access patterns.

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 distributed enforcement fabric is constructed and managed.

Distributed Enforcement

The Prisma Access enforcement fabric comprises distinct attachment points and processing roles, each optimised for specific traffic domains.

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).

The following components can be deployed for each organisation, depending on the access patterns in use and the scale and complexity of the environment:

Mobile-User Security-Processing Nodes (MU-SPN): enforcement nodes optimised for identity-driven user traffic, typically originating from an endpoint agent. In the back-end, the MU-SPN mapping and agent configuration is managed by Portal Nodes.

Explicit-Proxy Security-Processing Nodes (EP-SPN): enforcement nodes for explicit proxy-based web traffic, typically originating from a browser using a proxy configuration.

Remote-Network Security-Processing Nodes (RN-SPN): enforcement nodes optimised for site-driven traffic, typically originating from a branch office with an IPsec tunnel configured to the Customer Premises Equipment (CPE).

Service-Connection Corporate-Access Nodes (SC-CAN): attachment point for Service Connections and private interconnects, providing controlled ingress/egress boundaries for layer 3 private application connectivity.

ZTNA Tunnel Terminators (ZTT): outbound termination points for layer 7 application-initiated traffic. The ZTT automatically negotiates a secure connection from a ZTNA Connector (lightweight virtual appliance) that runs next to the private application.

Customer traffic is isolated in its own SCM-managed tenant, preserving logical separation within the shared service infrastructure, and providing:

• Dedicated Security Processing Nodes
• Dedicated egress IP addresses
• Resource insulation and control over IP address reputation

The infrastructure components within the enforcement fabric use iBGP for node-to-node routing with a customer-defined service infrastructure subnet. Where IPSec tunnels are built between Prisma Access and the Customer Premises Equipment, eBGP is used.

Note that although a mesh is formed between all Remote Network branch sites, Mobile User nodes are isolated from branch nodes by default. Connecting a remote user directly to a local branch requires either the Prisma Access Interconnect add-on, or routing through a Service Connection.

Shared Responsibility

Because Prisma Access is consumed as a service, the distributed enforcement fabric is maintained and operated by Palo Alto Networks 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.

With the exception of the optional ZTNA Connector, customers do not deploy or manage appliances. Instead, they define policy in the control plane and onboard users, sites, and applications.

Responsibilities of Palo Alto Networks (the provider) include:

• Infrastructure uptime and high availability
• Global architecture scaling
• Tenant upgrades and patch management
• Threat intelligence content delivery
• Securing the underlying cloud platform

Responsibilities of the customer include:

• Security policy and ruleset management
• Identity and Access Management (IAM)
• Customer Premises Equipment (CPE) and connector appliances
• Endpoint and agent management
• Monitoring and responding to security events

Control Plane

Prisma Access uses the advanced capabilities of Cloud-Delivered Security Services (CDSS) as the inspection layer for real time detection and prevention. As traffic transits Prisma Access, it undergoes single-pass inspection across modular services including threat prevention, malware analysis, URL filtering, and DNS security.

In a Prisma Access deployment, Strata Cloud Manager (SCM) forms the control plane for both the inspection and enforcement layers. This means security policy is:

1. Defined centrally in SCM
2. Distributed consistently to SPNs
3. Executed locally at the enforcement node
4. Logged and correlated centrally for visibility and analytics

Each SCM tenant has its own instance of Strata Logging Service (SLS), which retains logs and normalises telemetry into a common data model.

A common data model and management interface surface additional insights such as Autonomous Digital Experience Management (ADEM), which you can read more about in the SCM post.

The final key component to reference as part of the control plane is Cloud Identity Engine (CIE), which sits in the Tenant Services Group (TSG) common services.

CIE is an identity broker that connects to an organisation's Identity Provider (IdP). It enables directory sync and mapping for users and groups to be added directly to security rules in SCM, for identity-driven policy. CIE also uses SAML 2.0 integration to proxy authentication requests for mobile users, providing IdP handoff for Single Sign-On (SSO) and Multi-Factor Authentication (MFA).