Pick where you want to start
1. Introduction
This document covers how Palo Alto Networks implements Zero Trust — both on physical NGFW and via Prisma Access (cloud-delivered SASE). It explains the architecture, configuration, and policy logic for a company with HQ, branch offices, and remote users.
Zero Trust is not a product — it is a security framework. Palo Alto implements it through a combination of features: User-ID, App-ID, HIP, SSL Decryption, DLP, WildFire, and Prisma Access working together.
2. Zero Trust Concept — Old Model vs Zero Trust
In the old model a user who clears one perimeter firewall is trusted to move freely across a flat LAN. Under Zero Trust there is no trusted inside — every request re-proves identity, device posture (HIP) and per-app policy, so a compromised session reaches only the one app it is explicitly allowed and can't pivot to HR or Finance.
A laptop is already plugged into the corporate LAN at HQ. Under Zero Trust, what happens when it requests the ERP app?
🔑 Lock in the key terms — tap to flip
A security framework, not a product: "never trust, always verify". Every access request is authenticated, authorised and inspected regardless of location.
Palo Alto's cloud-delivered SASE — the NGFW stack as a service. Remote users and branches connect to the nearest PoP; the same inspection runs there, no box per site.
Host Information Profile. The GlobalProtect agent reports device posture (disk encryption, AV, patch level); policy only allows access when the device is compliant.
Strata Cloud Manager — Palo Alto's cloud-native, single-pane manager for Prisma Access (Service Connections, Mobile Users, policy, commit & push).
3. 6 Pillars of Zero Trust in Palo Alto
This is Techclick's 6-pillar framing. Palo Alto's official Zero Trust Enterprise whitepaper uses 5 pillars: User, Device, Application, Infrastructure, Data. We split 'Threat' out as a 6th for teaching clarity — when interviewing at Palo Alto, default to their 5.
All 6 pillars must pass for a session to be allowed. Failure in any single pillar results in deny or quarantine.
A user has valid AD credentials and is in the allowed group, but their laptop's disk encryption is turned off. What happens?
4. Zero Trust Policy Decision Logic
This is what Prisma Access evaluates for every single session — in order. All checks must pass.
All 6 checks passed → Session ALLOWED. If any single check fails → DENY or QUARANTINE. That is Zero Trust.
5. Why Prisma Access — Not Just Physical PA
Physical PA firewall protects your building. Prisma Access protects your users and data — wherever they are.
| Scenario | Physical PA Only | Prisma Access (SASE) |
|---|---|---|
| Branch protection | Need PA box at every branch | IPSec tunnel — no hardware needed |
| Remote / WFH user | VPN → backhauled to HQ | GP → nearest PoP (Mumbai for India) |
| SaaS inspection | Traffic hairpins through HQ | Inspected in cloud before reaching SaaS |
| Policy management | Per-device or Panorama | Strata Cloud Manager — single pane |
| Scaling | Buy more hardware | Elastic — auto-scales |
| New branch setup | Ship hardware, rack, configure | Configure tunnel in SCM — done |
| CapEx | High — PA-3200/5200 series | Zero — OpEx subscription |
| Zero Trust coverage | Where hardware exists | Everywhere — all users, all locations |
6. Mobile User → Private App Flow
This is how a remote user in Pune accesses an internal ERP application at HQ Delhi — without a traditional VPN.
The Service Connection is the bridge. One IPSec tunnel at HQ serves all remote users globally. You don't need VPN concentrators or per-user firewall rules at HQ. Prisma handles all user sessions in the cloud.
▶ Watch a remote user reach the HQ ERP through Prisma Access
A laptop in Pune opens the internal ERP at HQ Delhi. Press Play for the healthy path, then Break it to see the classic HIP / posture failure — and the fix.
In the flow above, what carries the remote user's session from the Prisma cloud into the HQ LAN to reach the private ERP?
Mobile User Flow — Direct Internet Access (DIA)
The most common Prisma Access traffic pattern: user → Prisma Service Edge → direct to SaaS / internet (DIA), NOT backhauled through HQ. Security stack (App-ID, Threat Prevention, URL Filtering, WildFire, DNS Security) runs on the Service Edge in line. The HQ-backhaul flow (Service Connection → on-prem firewall) is for private app access only — Office365, Salesforce, web browsing all go DIA.
Strata Cloud Manager (SCM) vs Panorama with Prisma Access plug-in
Panorama with Prisma Access plug-in remains the dominant management surface for tenants migrating from on-prem PAN. SCM is Palo Alto's strategic direction (cloud-native, multi-product), but if you already operate Panorama at scale, the plug-in path is the lower-risk migration.
Cortex Data Lake (CDL) — where the logs live
Cortex Data Lake (CDL) is where all Prisma Access logs land. Sized in storage tier (1 TB, 10 TB, etc.) — separate license from Prisma Access. Every Prisma operator deals with CDL daily for log queries, AutoFocus integration, and Cortex XSOAR/XSIAM ingest.
Licensing — sized in Gbps, not user count
Prisma Access licensing model: sized in Gbps (peak bandwidth), NOT user count. Sales conversations always start with 'how many Gbps?' — internalize this number for any Prisma role interview.
HIP enforcement mechanism
HIP enforcement: Z-App's HIP report is evaluated against HIP match objects, which can be referenced in security policy as a match condition. Posture violation → policy fires the configured action (block, isolate, restrict). HIP report distribution is per-session; mid-session HIP changes don't tear down existing sessions.
Cert path for Prisma Access roles
Cert path: PCNSE → PCCSE (Prisma Cloud) for cloud-native security roles; PCNSE → PCSAE (Prisma Access SASE Engineer) for SASE/Prisma Access roles. Pick PCSAE if your job is Prisma Access operations.
7. SCM Portal Setup — Step by Step
-
1
Service Connection — HQ IPSec Tunnel
Define the IPSec tunnel from Prisma cloud to your HQ firewall. After saving, SCM gives you Prisma's public IP — copy it for HQ firewall config.
Manage → Service Connections → Add -
2
Mobile User Configuration
Set the PoP region (India South — Mumbai), IP pool for GP users (100.64.0.0/10), internal DNS server, DNS suffix, and split-tunnel setting.
Manage → Mobile Users → Add -
3
IdP Integration (Azure AD / Okta)
Upload SAML Federation Metadata XML from Azure AD. Map attributes: username → userprincipalname, groupname → groups. Copy ACS URL back to Azure.
Identity Services → Identity Provider → Add -
4
HIP Profile — Device Posture
Define checks: AV running + definitions <7 days, disk encryption enabled, host firewall on, OS patched <30 days. Attach HIP profile to security policy.
Objects → HIP Profiles → Add -
5
Security Policy Rule
Source: mobile-user zone, 100.64.0.0/10, AD group. HIP: compliant-devices. Destination: service-conn zone, 10.10.0.0/16. Action: Allow + Threat Prevention profile.
Policies → Security → Add Rule -
6
Commit and Push
Select Mobile Users (India region) + Service Connections (HQ-Delhi-SC). Push takes 2–5 minutes to propagate to Prisma PoP.
Commit → Push to Devices
| Field | Service Connection Value |
|---|---|
| Name | HQ-Delhi-SC |
| Region | Asia Pacific — India South (Mumbai) |
| Subnets to advertise | 10.10.0.0/16 (your HQ LAN) |
| IKE Version | IKEv2 |
| Encryption | AES-256-GCM |
| DH Group | Group 20 |
| Pre-Shared Key | Generate strong PSK — save for HQ firewall |
8. HQ Firewall IPSec Config — Palo Alto
After completing SCM setup, configure the IPSec peer on your HQ PA firewall.
Certificate-based authentication for Service Connections (PAN-OS 11+) eliminates PSK rotation overhead. PKI: device cert issued by your internal CA, trusted on the Prisma Access side. PSK examples below are kept for legacy compatibility but new deployments should be cert-based.
# Network → Network Profiles → IKE Crypto → Add Name : Prisma-IKE-Crypto DH Group : group20 Authentication: sha256 Encryption : aes-256-gcm Key Lifetime : 8 hours
# Network → Network Profiles → IPSec Crypto → Add Name : Prisma-IPSec-Crypto Protocol : ESP Encryption : aes-256-gcm Authentication: none (GCM is AEAD — auth is built-in) DH Group : group20 Key Lifetime : 1 hour
# Network → Network Profiles → IKE Gateways → Add Name : Prisma-SC-GW Version : IKEv2 only Interface : ethernet1/1 (WAN interface) Local IP : 203.x.x.x (HQ WAN IP) Peer IP : 34.100.x.x (Prisma SC IP from SCM) Authentication : Pre-Shared Key PSK : YourStrongPSKHere IKE Crypto Profile: Prisma-IKE-Crypto
# Network → IPSec Tunnels → Add Name : Prisma-SC-Tunnel Tunnel Interface : tunnel.10 (zone = Prisma-Zone) IKE Gateway : Prisma-SC-GW IPSec Crypto : Prisma-IPSec-Crypto # Static Route — return path for mobile users Destination : 100.64.0.0/10 (GP IP pool) Next Hop : tunnel.10
9. Verification Commands
# IKE Phase 1 status show vpn ike-sa # IPSec Phase 2 status show vpn ipsec-sa # Traffic counter through tunnel show vpn flow tunnel-id <id> # User-ID mapping check show user ip-user-mapping all # HIP report for a specific IP show user hip-report ip <ip> # Active GlobalProtect sessions show global-protect-gateway current-user
| Test | Expected Result |
|---|---|
| GP agent connects | Status = Connected, IP = 100.64.x.x assigned |
| ping 10.10.1.50 from laptop | Reply from HQ server |
| tracert 10.10.1.50 | Hops: 100.64.x.x → Prisma PoP → HQ LAN |
| show vpn ike-sa | State = ESTABLISHED, Peer = 34.100.x.x |
| SCM → Monitoring → Traffic | User session visible with App-ID resolved |
| Non-compliant device (AV off) | HIP fails → access denied, remediation page |
10. Zero Trust Coverage: Physical PA vs Prisma Access
| PA Feature | Zero Trust Role | Physical PA | Prisma Access |
|---|---|---|---|
| User-ID | Verify WHO — username not IP | HQ only | All locations |
| GP + HIP | Verify WHAT device — posture check | VPN users | All users globally |
| App-ID | Verify WHAT application — not just port | HQ only | All locations |
| Zones + Policy | Least privilege — no lateral movement | Where hardware exists | Cloud-wide |
| SSL Decryption | See inside encrypted traffic | HQ only | All users, all apps |
| DLP | Protect what data is leaving | Limited | Full SaaS + web |
| WildFire + IPS | Verify traffic is not malicious | HQ only | All locations |
Zero Trust in Palo Alto is not one toggle — it is the combination of all these features working together, enforced on every session, continuously re-evaluated. Prisma Access extends this enforcement to every user, every location, without requiring hardware at each site.
Quick Lab (15 min): (1) Log into the Strata Cloud Manager demo or your Prisma Access tenant. Navigate to Service Connections — note auth method (PSK vs cert). (2) Open Cortex Data Lake; run a search for the past hour's threat events. (3) Build a HIP match object requiring disk encryption + AV updated within 7 days. Attach to a security rule. Verify by toggling the criteria on a test endpoint.
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. The exact framing an interviewer wants to hear.
Pre-curated from this lesson + Palo Alto interview Q&A. For a live tenant issue, paste your show vpn ike-sa output into chat.techclick.in.
📝 Check your understanding
10 scenario questions — same depth you'll see in PCNSE / PCSAE interviews. Pick one answer per question. You need 70% (7 of 10) to mark this lesson complete on your profile.
Frequently Asked Questions
The Zero Trust and Prisma Access questions that come up in interviews, design reviews, and the first week on a SASE project.
Is Zero Trust a product you can buy?
No. Zero Trust is a security framework, not a single product or a toggle. Its core idea is "never trust, always verify" — every access request is authenticated, authorised, and inspected regardless of where it comes from.
Palo Alto implements Zero Trust by combining features: User-ID (who), App-ID (what), zones + least-privilege policy, SSL decryption, HIP device posture, DLP, and WildFire/IPS — all enforced on every session, continuously re-evaluated.
What is the difference between Zero Trust and a traditional VPN?
A classic VPN drops the remote user onto the network — once connected, they can often reach anything that's routable, with no per-application control. That's implicit trust based on network location.
Zero Trust (and ZTNA specifically) grants access per application, not per network. The user is verified, the device posture is checked, and they only ever reach the specific apps policy allows — there is no "inside the LAN" to move around in.
What is Prisma Access?
Prisma Access is Palo Alto's cloud-delivered SASE — effectively their next-gen firewall stack running as a service in the cloud. Remote users and branch offices connect to the nearest Prisma Access location, and the same security inspection (App-ID, threat prevention, decryption, DLP, URL filtering) runs there instead of on a box at each site.
It extends one consistent Zero Trust policy to every user and location without shipping hardware to each one.
Prisma Access vs an on-prem NGFW — when do I use which?
- On-prem NGFW: best at HQ / data centres where you control the hardware and need line-rate inspection of local and north-south traffic.
- Prisma Access: best for remote users and branch offices, where standing up and maintaining a firewall per site is impractical.
In practice most enterprises run both and manage them with one policy model (often via Panorama / Strata Cloud Manager), so a user gets the same protection at the office, at a branch, or working from home.
What is HIP in Palo Alto?
HIP = Host Information Profile. The GlobalProtect agent reports the device's posture — is the disk encrypted, is antivirus running and up to date, is the OS patched, is a required process present — and the firewall matches that against a HIP object.
You then write policy that only allows access when the device is compliant. A laptop with disabled disk encryption can be blocked or quarantined before it ever reaches a sensitive app. This is the "verify the device" pillar of Zero Trust.
How does microsegmentation stop lateral movement?
In a flat network, once an attacker lands on one host they can pivot freely to others (east-west movement). Microsegmentation puts least-privilege policy between workloads — segment A can talk to the database it needs and nothing else.
On Palo Alto this is enforced with zones + App-ID/User-ID-aware rules, so even traffic inside the data centre is inspected and allowed only where it's explicitly needed. A compromised host has nowhere to spread.
What role does SSL decryption play in Zero Trust?
Most traffic is encrypted, and you cannot verify what you cannot see. SSL/TLS decryption lets the firewall (or Prisma Access) open the session, inspect it for threats, data exfiltration, and disallowed apps, then re-encrypt it.
Without decryption, "always verify" breaks down — App-ID, threat prevention, and DLP would all be blind to anything inside HTTPS. Sensitive categories (banking, health) are typically exempted for privacy and to avoid breaking certificate-pinned apps.
What are the pillars of Zero Trust in Palo Alto?
The commonly taught set, all working together on every session:
- User-ID — verify the user/group, not just an IP.
- App-ID — verify the application, not just the port.
- Zones + least-privilege policy — no lateral movement.
- SSL decryption — see inside encrypted traffic.
- DLP — control what data leaves.
- WildFire + IPS — verify traffic is not malicious.
Does Prisma Access need hardware at every site?
No — that's the point of it. Because inspection happens in the cloud, branches connect via Service Connections / IPSec tunnels and remote users connect via the GlobalProtect agent. There's no firewall appliance to buy, rack, patch, or refresh per location.
You still keep on-prem NGFWs where it makes sense (HQ, data centre), but new branches and a growing remote workforce don't each need their own box.
What's the difference between User-ID and App-ID?
User-ID answers who — it maps an IP/session to a real identity (and AD group) so policy can say "Finance group may use this app". App-ID answers what — it identifies the actual application in the traffic regardless of port or evasion, so policy can allow "Microsoft 365" while blocking "BitTorrent" on the same port 443.
Together they replace the old "IP + port" rule with an identity-aware, application-aware rule — the foundation of a Zero Trust policy.
What's next?
Go deeper on the model — how ZTNA actually replaces the VPN, broker by broker, policy by policy.