01
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.
Key Principle
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.
02
Zero Trust Concept
✗ Old Model — Trust But Verify
Inside network = trusted automatically
Perimeter firewall is the only control
Once inside LAN, move anywhere freely
VPN gives full network access
No device posture check
IP-based rules only — no user context
✓ Zero Trust — Never Trust, Always Verify
Every access request verified regardless of location
Microsegmentation — no lateral movement
Identity-aware policies (user + group)
Device posture checked before access
Least privilege — only what you need
Continuous re-verification — not one-time
03
6 Pillars of Zero Trust in Palo Alto
All 6 pillars must pass for a session to be allowed. Failure in any single pillar results in deny or quarantine.
PILLAR 01
User Identity
User-ID + SAML + MFA
Maps every IP to a real username via AD Security Event logs. Policies reference usernames/groups, not IP addresses. Step-up MFA enforced for sensitive resources.
PILLAR 02
Device Trust
HIP Check via GlobalProtect
GlobalProtect agent reports device posture — AV installed, disk encrypted, OS patched, domain joined. Valid credentials alone are not enough — device must also pass HIP.
PILLAR 03
Application Control
App-ID — Layer 7 inspection
Identifies actual application inside traffic regardless of port. Port 443 could be Office365, Dropbox, TeamViewer, or malware. Allow named apps only — deny everything else.
PILLAR 04
Network Segmentation
Zones + Microsegmentation
Every zone crossing is inspected. Finance servers cannot reach HR servers without explicit allow rules. Attacker who compromises one host cannot move laterally.
PILLAR 05
Data Security
SSL Decrypt + DLP
90% of traffic is encrypted — without SSL decryption you are blind. Decrypts, inspects for sensitive data (PII, credit cards, IP), re-encrypts. Blocks exfiltration even by trusted users.
PILLAR 06
Threat Prevention
IPS + WildFire + DNS Security
Even authenticated, compliant users on allowed apps — traffic itself is scanned. WildFire sandboxes unknown files. DNS Security blocks C2 domains. IPS catches exploit patterns.
04
Zero Trust Policy Decision Logic
This is what Prisma Access evaluates for every single session — in order. All checks must pass.
Check 2 — HIP / DeviceDisk encrypted + AV running + OS patched?PASS ✓
Check 3 — App-IDApplication = web-browsing to ERP? Not TeamViewer?PASS ✓
Check 4 — Zone PolicySource=Prisma-Zone → Dest=ERP-Zone policy exists?PASS ✓
Check 5 — DLPAny sensitive data (PII, credit card) being sent out?PASS ✓
Check 6 — ThreatAny exploit signatures, malware, C2 callbacks?PASS ✓
Result
All 6 checks passed → Session ALLOWED. If any single check fails → DENY or QUARANTINE. That is Zero Trust.
05
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 |
06
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.
STEP 01
User opens laptop
GP auto-connects
→
STEP 02
SSL tunnel
To Mumbai PoP
→
STEP 03
IdP Auth + HIP
SAML + posture
→
STEP 04
Policy check
SCM security rule
→
STEP 05
IPSec svc conn
Prisma → HQ PA
→
STEP 06
Private app
LAN delivery
Pro Tip
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.
07
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 |
08
HQ Firewall IPSec Config — Palo Alto
After completing SCM setup, configure the IPSec peer on your HQ PA firewall.
IKE CRYPTO PROFILE
# Network → Network Profiles → IKE Crypto → Add
Name : Prisma-IKE-Crypto
DH Group : group20
Authentication: sha256
Encryption : aes-256-gcm
Key Lifetime : 8 hours
Name : Prisma-IKE-Crypto
DH Group : group20
Authentication: sha256
Encryption : aes-256-gcm
Key Lifetime : 8 hours
IPSEC CRYPTO PROFILE
# 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
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
IKE GATEWAY
# 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
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
IPSEC TUNNEL + STATIC ROUTE
# 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
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
09
Verification Commands
PALO ALTO CLI
# 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
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 |
Summary
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.