Prisma Access becomes much easier to design when every connection type is assigned a clear job. Remote networks attach branches and sites. Mobile-user connectivity protects roaming endpoints and user traffic. Service connections connect the Prisma Access fabric to headquarters, data centers, and other private resources. These building blocks can coexist, but they do not create the same traffic paths, routing behavior, or operational responsibilities.

The current Security Service Edge Engineer scope emphasizes planning, deploying, operating, and troubleshooting Prisma Access. That makes connectivity-model selection an architecture decision rather than a naming exercise. The design should begin with who or what is sending traffic, where that traffic must go, and which party should own the tunnel, route, and policy lifecycle.

Start with the source of traffic

Branch users and devices have different connectivity needs from roaming laptops. A remote network typically represents a branch or other fixed site that sends traffic through an IPSec-based connection to Prisma Access. Mobile users are attached individually through GlobalProtect or, for web-oriented use cases, through an explicit proxy model. Service connections are not user-access methods at all; they provide connectivity between Prisma Access and internal resources or act as an interconnect for particular Prisma Access components.

This distinction matters because symptoms can look similar while the failure domain is completely different. A branch that loses a remote-network tunnel is a site-connectivity problem. A laptop that cannot establish GlobalProtect is an endpoint or mobile-user problem. A mobile user who reaches the internet but not an internal application may have a service-connection or private-app reachability problem even though user onboarding is healthy.

Remote networks are the branch connectivity model

Remote networks let branch sites send traffic to cloud-delivered security without placing a full enforcement stack at every location. The branch uses a compatible IPSec device, which can be a Palo Alto Networks firewall, an SD-WAN device, or another standards-based tunnel endpoint. Prisma Access then applies centrally managed security policy to traffic that enters through the remote-network connection.

Routing can be static or dynamic. In smaller sites, explicit static prefixes may be easy to understand. In larger environments, BGP usually scales better as branch networks change. Current Prisma Access deployments also distinguish newer site-based bandwidth models from older aggregate-bandwidth designs, so capacity planning should match the tenant’s actual deployment model rather than an old diagram or inherited runbook.

The conceptual SASE model explains why branch security and connectivity are moving toward cloud-delivered services. Prisma Access remote networks are the concrete operational mechanism: tunnels, locations, bandwidth, routing, policy, and monitoring still have to be engineered correctly.

Mobile users need an endpoint-aware access model

Mobile-user connectivity is designed around individual users and devices rather than a fixed branch subnet. GlobalProtect can establish an agent-based tunnel that protects internet, SaaS, and private-application traffic across ports and protocols. Explicit Proxy offers a different steering model for supported proxy-aware web traffic. These approaches can support different endpoint populations and migration strategies.

Do not treat “mobile user” as synonymous with “VPN.” The design also includes identity, device posture, DNS, location selection, authentication, and security policy. A user can have a healthy tunnel and still fail because the requested application is unreachable, the wrong identity is mapped, or policy does not allow the traffic. Conversely, an explicit-proxy user can reach approved web destinations while a non-proxy-aware application bypasses the intended path or fails entirely.

Service connections attach private infrastructure

A service connection links Prisma Access with headquarters, a data center, or another corporate network so protected users and sites can reach internal resources. It can also provide the interconnect that allows mobile users to reach remote-network locations. That second function is easy to miss: remote networks form their own connectivity fabric, but mobile-user infrastructure may rely on a service connection to reach those branch networks.

Service connections therefore belong in the architecture even when the business does not think of them as “user tunnels.” They are part of the transit and private-resource design. Location matters because poorly placed service connections can create unnecessary path length. Route advertisement, return routes, NAT, and internal firewall policy all need to agree with what Prisma Access is advertising and learning.

ZTNA Connector is an application-centric alternative

Private-app access does not always require traditional network-level service connections. ZTNA Connector can establish automated secure tunnels from connector virtual machines placed near private applications. That model is useful when the goal is to publish specific applications rather than extend broad network reachability. It can also simplify access to applications in overlapping private address spaces because application identities can be based on names rather than conventional routed reachability alone.

The underlying principle aligns with Zero Trust Network Access: users receive access to the applications they need, while policy, identity, device context, and inspection remain part of the decision. ZTNA Connector can coexist with service connections, so mature environments may use both models for different application populations.

Routing design determines whether the models actually connect

Connectivity components are only useful when the forward and return paths are coherent. A remote network may advertise branch prefixes with BGP. A service connection may learn data-center prefixes. Mobile-user address pools may need to be reachable from private infrastructure. Route controls can prevent advertisements in one direction, and static routes can take precedence over dynamically learned alternatives in specific configurations.

Document which component originates each route, which prefixes are expected on each side, and where NAT changes the visible source. Avoid overlapping infrastructure and application address pools. When a new site or application is added, update the routing model first rather than troubleshooting every downstream symptom independently.

Location and resilience choices shape user experience

Prisma Access uses cloud locations to terminate user and site connectivity. Selecting a location is therefore both a capacity decision and a path-quality decision. A branch should normally connect to an appropriate nearby location, while private-resource connectivity should avoid unnecessary geographic detours. Resilient designs also account for secondary site connections, redundant on-premises tunnel endpoints, multiple connectors, and internal path diversity where the service supports them.

Redundancy should be tested as a traffic path, not merely as a configuration checkbox. Verify that routes converge, return traffic remains valid, NAT expectations are preserved, and policy still matches after a primary connection disappears. A backup path that establishes a tunnel but cannot reach DNS, authentication, or the application tier is not an effective failover design.

Choose the model by control boundary, not by feature count

Use remote networks when the protected unit is a fixed site. Use GlobalProtect when the protected unit is a mobile endpoint and broad protocol coverage or endpoint context matters. Use Explicit Proxy when proxy-based web steering fits the application and endpoint population. Use service connections for routed reachability to internal resources and Prisma Access interconnect requirements. Use ZTNA Connector when private applications are better exposed as application destinations through automated connectors.

Role-based Palo Alto Networks certification objectives increasingly reflect these design decisions. The durable skill is explaining which connection owns the traffic, where the route comes from, which policy scope applies, and what happens when a component fails.

Build a connectivity map before troubleshooting

A useful production diagram should show users and sites, Prisma Access locations, remote-network tunnels, service connections, connector groups, mobile-user pools, important private prefixes, internet egress, and major policy boundaries. Add the expected route direction and NAT points. That diagram becomes the operational model for change review and troubleshooting.

When a ticket arrives, trace the packet against that map: source model, ingress component, tunnel state, route, policy, egress or private-resource connection, and return path. This approach prevents teams from changing security rules when the real issue is routing, changing BGP when the real issue is identity, or rebuilding user connectivity when only a private-app connector is unhealthy. A connectivity model is valuable only when it makes both design and fault isolation simpler.

Address planning deserves its own architecture review because Prisma Access introduces multiple logical address domains: mobile-user pools, remote-site prefixes, service infrastructure, private application networks, connector address blocks, and on-premises transit networks. Record them in one source of truth and flag overlap before deployment. Overlap is not only a routing problem; it can also complicate policy objects, logs, DNS responses, and escalation because the same RFC 1918 address can represent different systems depending on the path.

Also decide where internet and SaaS traffic should exit. A branch may send internet traffic directly into Prisma Access while internal destinations traverse a service connection. A mobile user may use a nearby Prisma Access location for internet access but reach a distant data center for a private application. Those choices affect latency, source addresses seen by downstream services, SaaS allow lists, and geolocation-sensitive applications. Include egress identity and public source ranges in the connectivity map.

Policy scope should follow the access model. A branch rule that assumes source zones and site context is not automatically equivalent to a mobile-user rule based on identity and device posture. Before consolidating policies, compare the attributes that are reliably available on each ingress type. Reuse common security intent where it is genuinely shared, but keep model-specific conditions where they prevent accidental broadening.

Finally, turn the architecture into a test matrix. For each user or site type, test internet access, representative SaaS, DNS, a private application, an identity-dependent rule, and failover. Repeat after significant routing, licensing, or onboarding changes. A diagram describes the design; a test matrix proves that every connectivity model still delivers the intended path.

For change control, label every planned modification by connectivity model and expected blast radius. A remote-network routing change should identify affected sites; a service-connection change should identify private prefixes and mobile-user dependencies; a mobile-user change should identify endpoint populations and steering behavior. This makes peer review much more precise than a generic “Prisma Access change” description.