Security teams should confirm whether the firewall is running an affected PAN-OS version and whether GlobalProtect Gateway or Portal is enabled, then check whether device telemetry is turned on. Because the exploit can enable unauthenticated remote code execution, verification should be paired with exposure review and rapid patching. Active testing and continuous monitoring are the safest way to reduce blind spots.
What teams should verify first on externally exposed firewalls
The most important checks are product version, feature exposure, and telemetry state. If the firewall is on an affected PAN-OS release, has GlobalProtect Gateway or Portal enabled, and does not have device telemetry turned on, it deserves immediate attention. Those three facts determine whether the device is both vulnerable and reachable in a way that matches the published exploit path.
Version alone is not enough, because a firewall can be technically affected yet not exposed to the relevant attack surface. Likewise, exposure alone is not enough if the vulnerable code path is absent. Treat the verification step as a short, decisive triage exercise: confirm the software build, confirm whether the externally reachable GlobalProtect components are in use, and confirm whether telemetry gives you enough visibility to spot abuse.
One useful cross-check is to validate exposure against a trusted vulnerability record and the vendor advisory path. The NIST National Vulnerability Database and the CVE Program are the right starting points for mapping the affected product and understanding the official vulnerability record.
How to interpret exposure, telemetry, and patch urgency
Externally exposed firewalls are high-value targets because they sit on the boundary between trusted and untrusted networks. When the weakness can be reached without authentication, verification should not be treated as a passive inventory task. The practical question is whether the device is reachable in the vulnerable configuration long enough for exploitation to matter.
Telemetry changes the response posture because it determines how much evidence you can collect if the firewall has already been touched. If device telemetry is off, the team has less ability to distinguish normal administrative activity from exploitation attempts or post-compromise actions. That is why validation and response should be paired, not sequenced as separate projects.
For this kind of exposed-perimeter issue, the safest operational pattern is to combine verification with rapid remediation and continuous monitoring. NIST Zero Trust guidance reinforces the broader principle of verifying access assumptions rather than trusting network location alone, which is especially relevant when perimeter devices are externally reachable.
Teams that want a control-based way to frame the response can also map this work to NIST SP 800-207 Zero Trust Architecture, which emphasizes reducing implicit trust and validating access decisions continuously.
Risk and Threat Considerations
Externally exposed firewalls are attractive targets because they already occupy a trusted edge position and can provide direct access to internal networks. When a vulnerability can lead to unauthenticated remote code execution, the concern is not just initial compromise, but also configuration theft, lateral movement, and loss of visibility if logging or telemetry is incomplete.
Failure mechanism: An attacker scans for internet-facing firewalls running an affected PAN-OS version, then targets the enabled GlobalProtect Gateway or Portal path to trigger the flaw. If telemetry is disabled, the organisation may have little evidence of exploitation until secondary impacts appear.
Impact: The result can be full device compromise, policy manipulation, credential theft, traffic interception, or a foothold into higher-trust internal segments. Because the affected system is a control point, compromise can amplify downstream risk beyond the firewall itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 — Physical devices and systems inventory | Affected firewalls must be identified and inventoried before exposure can be verified. |
| PR.PT-1 — Audit/log records | Telemetry and logging determine whether exploitation can be detected on exposed firewalls. | |
| RS.MI-3 — Mitigation processes | A vulnerable exposed firewall requires rapid mitigation once confirmed. | |
| Recommendation — Inventory internet-facing firewalls and flag affected PAN-OS versions for immediate review. Enable and retain firewall telemetry so exposure checks are paired with detection evidence. Patch or isolate confirmed affected firewalls as soon as exposure is validated. | ||
| CIS Controls v8 | 01 — Inventory and Control of Enterprise Assets | You must know which firewalls exist and which are internet-facing to verify exposure. |
| 08 — Audit Log Management | Logs and telemetry are essential for confirming whether the firewall was targeted or compromised. | |
| 07 — Continuous Vulnerability Management | Version checking and rapid patching are core to validating and reducing this CVE exposure. | |
| Recommendation — Maintain an authoritative inventory of externally exposed firewalls and their versions. Centralize firewall telemetry and preserve logs for exposure verification and investigation. Scan perimeter firewalls for affected PAN-OS releases and accelerate remediation. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Identity assurance is indirectly relevant because compromised firewalls can expose access paths and credentials. |
| Recommendation — Use strong authentication for administrative access to exposed security appliances. | ||
| NIST Zero Trust (SP 800-207) | AC-1 — Policy and Procedures | Zero Trust supports the verify-before-trust posture needed for exposed boundary devices. |
| SC-7 — Boundary Protection | Exposed firewalls are boundary systems whose attack surface must be tightly constrained. | |
| Recommendation — Treat perimeter firewall exposure as a continuously verified trust decision. Restrict exposed management and portal paths to the minimum necessary boundary surface. | ||
Practitioner Guidance
What to prioritise: Triage internet-facing firewalls before internal-only assets, and prioritise any device that is both on an affected release and running GlobalProtect Gateway or Portal. If telemetry is off, treat the device as harder to trust even if no exploitation is yet visible.
What to verify: Confirm the exact PAN-OS version, the enabled exposure paths, and whether logs are sufficient to answer a simple incident question: “Can we tell if this box was touched?” If the answer is no, close that gap while you patch.
Practitioner takeaway: For exposed firewalls, verification is only useful if it leads directly to a containment decision, because the combination of remote reachability and weak observability is what turns a product flaw into a likely incident.
Related resources from NHI Mgmt Group
- What should security teams do first when a PAN-OS DNS Security firewall may be affected by CVE-2024-3393?
- How do security teams know whether an NGINX deployment is exposed to this issue?
- How do security teams know whether an inference stack is exposed to deserialization abuse?
- How can security teams tell whether an AI serving service is actually exposed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
