Index › Foundations
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Foundations

← Back to full guide index

~2 min read
Prerequisites: None — this is the starting module.

What Makes It a "Next-Generation" Firewall 01

Learning objectives

  • Explain what a traditional Layer 3/4 firewall can and cannot see in traffic
  • Identify the three classification engines (App-ID, User-ID, Content-ID) that give an NGFW its visibility
  • Describe why policy built on app + user beats policy built on port + protocol

A traditional (Layer 3/4) firewall only sees IP addresses, ports, and protocols — so it can tell you traffic is going to port 443, but not what application, which user, or what content is inside that traffic. Palo Alto's NGFW was built to close that visibility gap by identifying traffic based on the actual application and user identity before deciding whether to allow it, rather than bolting inspection on top of a port-based allow/deny model.

Why

Port/protocol-based rules are trivially bypassed (apps hop ports, tunnel inside HTTPS, use encryption). Security teams needed policy that follows the application and the user, not the socket.

How

Three classification "engines" — App-ID, User-ID, Content-ID — run together in a single pass over every packet, so one policy rule can say "allow user Alice to use Salesforce and scan for threats/data-loss," instead of "allow TCP/443."
Traditional port-based inspection compared with NGFW application, user, and content visibility.
Traditional port-based inspection compared with NGFW application, user, and content visibility.

Pros

  • Policy maps to business intent (app + user), not just IP/port
  • Single vendor covers firewalling, IPS, AV, URL filtering, sandboxing
  • Consistent policy model across hardware, VM, container, and cloud form factors

Cons

  • More moving parts than a plain packet filter — steeper learning curve
  • Full feature set requires multiple paid subscriptions on top of the box
  • Deep inspection (App-ID, decryption, threat scanning) costs CPU/throughput

Exam Trap

Candidates often assume App-ID, User-ID, and Content-ID are separate licensed add-ons like Threat Prevention or WildFire. They are not — all three are core NGFW capabilities included with the platform; only the content that feeds Content-ID's deeper inspection (threat/URL/DNS signatures) requires a subscription.

Self-check: What Makes It a "Next-Generation" Firewall
Q1. A legacy port-based firewall allows TCP/443 outbound. An attacker tunnels a C2 channel inside HTTPS on port 443. Why does a traditional firewall miss this, and which NGFW capability specifically closes the gap?
A: A traditional firewall only evaluates IP/port/protocol, so any traffic that speaks valid TCP/443 is allowed regardless of payload. App-ID (backed by decryption, when enabled) identifies the actual application/behavior inside the session rather than trusting the port, so it can flag or block non-web traffic riding on 443.
Q2. True or false: enabling App-ID, User-ID, and Content-ID requires three separate subscriptions on top of the NGFW purchase.
A: False. All three are built into the NGFW at no extra license cost; subscriptions (Threat Prevention, WildFire, URL Filtering, DNS Security) unlock additional signature/content feeds that Content-ID acts on, not the engines themselves.

Source: ngfw/administration/getting-started/ngfw-overview

Single-Pass Architecture (SP3) 02

Learning objectives

  • Contrast single-pass parallel processing with legacy chained UTM scanning engines
  • Explain why SP3 keeps latency more predictable as more security services are enabled
  • Recognize dataplane CPU as the practical limiting factor of SP3, not the architecture itself

Legacy UTM appliances chain separate scanning engines (firewall → IPS → AV → URL filter), re-parsing the packet at every stage. Palo Alto's dataplane instead classifies the traffic once and applies every relevant security function to that single pass, using dedicated hardware (control plane, data plane, and often separate signature-matching processors on physical appliances).

Why

Chained "next-hop" scanning engines multiply latency and hardware cost as you add features. A single classification pass keeps throughput predictable as you turn more security services on.

How

Traffic is identified once (App-ID/User-ID/Content-ID run together), then policy, decryption, threat, URL, and file-inspection all act on that same classified stream instead of separate re-scans.
Legacy chained inspection compared with Palo Alto Networks single-pass parallel inspection.
Legacy chained inspection compared with Palo Alto Networks single-pass parallel inspection.

Pros

  • Lower latency than multi-engine "bolt-on" UTM designs
  • Enabling more subscriptions (Threat Prevention, WildFire, URL Filtering) doesn't multiply passes
  • Consistent logging: one session record carries app, user, threat, and URL context together

Cons

  • Still bounded by dataplane CPU — decryption + full content inspection can saturate smaller platforms
  • Sizing/hardware selection matters a lot; undersized boxes throttle badly once everything is enabled

Exam Trap

SP3 is often confused with simply "fast hardware." The point tested on the exam is architectural: traffic is classified once and every enabled security function (policy, decryption, threat, URL, file inspection) acts on that same pass — it isn't that the box is fast, it's that it avoids re-parsing the packet per engine the way chained UTM appliances do.

Self-check: Single-Pass Architecture (SP3)
Q1. A customer enables Threat Prevention, WildFire, and URL Filtering on top of base App-ID/User-ID/Content-ID classification. Does each additional subscription add a separate re-scan pass over the traffic under SP3?
A: No. Traffic is classified once, and each enabled service acts on that single classified stream in parallel rather than triggering a new pass — this is the core throughput advantage of single-pass architecture over chained "next-hop" UTM designs.
Q2. A branch firewall is undersized for the traffic volume once decryption and full content inspection are turned on. Is this a failure of the single-pass architecture concept?
A: No — SP3 reduces overhead versus chained scanning, but it's still bounded by the dataplane's actual CPU capacity. Undersized hardware will still throttle; correct platform sizing for the enabled feature set is a separate, necessary step.

Source: ngfw/administration/getting-started/single-pass-architecture

Module Quiz

1. A firewall administrator writes a Security policy rule allowing TCP/443 outbound to "any." An employee runs a non-web application that tunnels its C2 channel inside a session on port 443. Why does a traditional Layer 3/4 firewall permit this traffic?

Traditional firewalls make allow/deny decisions purely on L3/L4 attributes; App-ID is the engine that closes this gap by identifying the real application regardless of port.

2. Which two engines run alongside App-ID, together in a single pass, to give a Palo Alto Networks NGFW full traffic visibility? (Choose two.)

App-ID, User-ID, and Content-ID are the three core classification engines that run together in a single pass; QoS and Zone Protection are separate policy features, not classification engines.

3. Per the guide's foundational discussion, which of the following is a genuine trade-off of the NGFW model compared to a plain packet filter?

Added complexity, multiple paid subscriptions for full functionality, and CPU cost from deep inspection are the real trade-offs; the other options are false claims about NGFW capability.

4. An engineer explaining Single-Pass Architecture (SP3) to a colleague who is used to legacy chained UTM appliances should describe its main advantage as:

Chained UTM designs re-parse traffic at every stage (firewall → IPS → AV → URL filter); SP3 classifies once and applies every enabled function to that same classified stream.

5. A customer enables Threat Prevention and WildFire on top of an existing NGFW deployment that already runs App-ID/User-ID/Content-ID. Under SP3, what happens to the number of inspection passes performed over each packet?

Enabling more subscriptions doesn't multiply passes under single-pass architecture — that's precisely the throughput advantage over bolt-on, chained UTM designs.

6. A branch-office NGFW begins dropping legitimate sessions under load only after decryption and full content inspection are turned on. What is the most likely root cause?

SP3 reduces architectural overhead versus chained scanning, but it is still bounded by real dataplane CPU; decryption and deep content inspection are the most CPU-intensive functions and the most common cause of undersized-platform throttling.

7. Why can a single NGFW Security policy rule often replace what would take several rules to approximate on a traditional firewall?

Because App-ID/User-ID/Content-ID classify a session on attributes beyond IP/port, one rule can express "user + app + content action" instead of stacking multiple port-based rules.

8. A prospective customer asks whether App-ID, User-ID, and Content-ID each require a separate paid subscription like Threat Prevention or WildFire. Which statement is accurate?

App-ID, User-ID, and Content-ID are foundational NGFW capabilities included by default; it's the deeper content feeds (Threat Prevention, WildFire, URL Filtering, DNS Security) that require separate subscriptions.
Traffic Classification →