PAN-OS 10.2 running on PA-220, PA-220R, PA-400 Series, PA-800 Series, PA-3200 Series, PA-3400 Series, PA-5200 Series, PA-5400 Series, PA-5450, and PA-7000 Series NGFWs

Certificate

Approved Algorithms (35)

Security Levels (Table 1)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for PAN-OS 10.2 running on PA-220, PA-220R, PA-400 Series, PA-800 Series, PA-3200 Series, PA-3400 Series, PA-5200 Series, PA-5400 Series, PA-5450, and PA-7000 Series NGFWs
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>10.2.8-h4 [1] and 10.2.17 [2]</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Firmware Update<br/>RSA SigVer (FIPS 186-4)</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status<br/>Zeroize<br/>Self-Tests</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>Micro USB Console (PA-220, PA-220R, PA-800 Series,…<br/>RJ45 Console<br/>RJ45 Ethernet</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C1,C2,C3,C4,C5,C6 clue;
  class I1,I2,I3,I4,I5,I6 infer;
  class R1,R2,R3,R4,R5,R6 risk;
  class E1,E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for PAN-OS 10.2 running on PA-220, PA-220R, PA-400 Series, PA-800 Series, PA-3200 Series, PA-3400 Series, PA-5200 Series, PA-5400 Series, PA-5450, and PA-7000 Series NGFWs
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>10.2.8-h4 [1] and 10.2.17 [2]</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Firmware Update<br/>RSA SigVer (FIPS 186-4)</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status<br/>Zeroize<br/>Self-Tests</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>Micro USB Console (PA-220, PA-220R, PA-800 Series,…<br/>RJ45 Console<br/>RJ45 Ethernet</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C1,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

PAN-OS 10.2 running on PA-220, PA-220R, PA-400 Series, PA-800 Series, PA-3200 Series, PA-3400 Series, PA-5200 Series, PA-5400 Series, PA-5450, and PA-7000 Series NGFWs Version: 1.3 Revision Date: May 1, 2025 Palo Alto Networks, Inc.​ www.paloaltonetworks.com​ © 2025 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be found at https://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their respective companies. This document may be freely

1. General​
2. Cryptographic Module Specification​
3. Cryptographic Module Interfaces​
4. Roles, Services, and Authentication​
5. Software/Firmware Security​
6. Operational Environment​
7. Physical Security​
8. Non-Invasive Security​
9. Sensitive Security Parameter Management​
10. Self-Tests​
11. Life-Cycle Assurance​
12. Mitigation of Other Attacks​
13. Definitions and Acronyms​
14. Reference Documents​ Appendix A - PA-220 - FIPS Accessories/Tamper Seal Installation (6 Seals)​ Appendix B - PA-220R- FIPS Accessories/Tamper Seal Installation (5 Seals)​ Appendix C - PA-800 series - FIPS Accessories/Tamper Seal Installation (11 Seals)​ Appendix D – PA-3200 Series – FIPS Accessories/Tamper Seal Installation (19 Seals)​ Appendix E - PA-5200- FIPS Accessories/Tamper Seal Installation (28 Seals)​ Appendix F - PA-7050 - FIPS Accessories/Tamper Seal Installation (24 Seals)​ Appendix G - PA-7080 - FIPS Accessories/Tamper Seal Installation (10 Seals)​ Appendix H - PA-5450 FIPS Accessories/Tamper Seal Installation (12 Seals)​ Appendix I - PA-410 FIPS Accessories/Tamper Seal Installation (4 Seals)​ Appendix J - PA-440/450/460 FIPS Accessories/Tamper Seal Installation (4 Seals)​ Appendix K - PA-3400 Series FIPS Accessories/Tamper Seal Installation (11 Seals)​ Appendix L - PA-5400 Series FIPS Accessories/Tamper Seal Installation (11 Seals)​ Page 1

Palo Alto Networks offers a full line of next-generation security appliances. Our platform architecture is based on our single-pass engine, PAN-OS, for networking, security, threat prevention, and management functionality that is consistent across all platforms. The devices differ only in capacities, performance, and physical configuration. The cryptographic modules meet the overall requirements applicable to Level 2 security of FIPS 140-3. Table 1

• Security Levels N/A N/A N/A Purpose Palo Alto Networks offers a full line of next-generation security appliances that range from the PA-220, designed for enterprise remote offices, to the PA-7080, which is a modular chassis designed for high-speed datacenters. Our platform architecture is based on our single-pass engine, PAN-OS, for networking, security, threat prevention, and management functionality that is consistent across all platforms. The devices differ only in capacities, performance, The Palo Alto Networks PA-220, PA-220R, PA-400 Series, PA-800 Series, PA-3200 Series, PA-3400 Series, PA-5200 Series, PA-5400 Series, PA-5450, and PA-7000 Series NGFWs (hereafter referred to as the modules) are multi-chip standalone modules that provide network security by enabling enterprises to see and control applications, users, and content
• not just ports, IP addresses, and packets
• using three unique identification technologies: App-ID, User-ID, and Content-ID. These identification technologies, found in Palo Alto Networks' enterprise firewalls, enable enterprises to create business-relevant security policies
• safely enabling organizations to adopt new applications, instead of the traditional “all-or-nothing” approach offered by traditional port-blocking firewalls used in many security infrastructures. Page 2

• ​ Application visibility and control: Accurate identification of the applications traversing the network enables policy-based control over application usage at the firewall, the strategic center of the security infrastructure.
• ​ Visualization tools: Graphical visibility tools, customizable reporting and logging enables administrators to make a more informed decision on how to treat the applications traversing the network.
• ​ Application browser: Helps administrators quickly research what the application is, its behavioral characteristics and underlying technology resulting in a more informed decision making process on how to treat the application.
• ​ User-based visibility and control: Seamless integration with enterprise directory services (Active Directory, LDAP, eDirectory) facilitates application visibility and policy creation based on user and group information, not just IP address. In Citrix and terminal services environments, the identity of users sitting behind Citrix or terminal services can be used to enable policy-based visibility and control over applications, users and content. An XML API enables integration with other, 3rd party user repositories.
• ​ Real-time threat prevention: Detects and blocks application vulnerabilities, viruses, spyware, and worms; controls web activity; all in real-time, dramatically improving performance and accuracy.
• ​ File and data filtering: Taking full advantage of the in-depth application inspection being performed by App-ID, administrators can implement several different types of policies that reduce the risk associated with unauthorized file and data transfer.
• ​ Legacy firewall support: Support for traditional inbound and outbound port-based firewall rules mixed with application-based rules smooth the transition to a Palo Alto Networks next generation firewall.
• ​ Networking architecture: Support for dynamic routing (OSPF, RIP, BGP), virtual wire mode and layer 2/layer 3 modes facilitates deployment in nearly any networking environment.
• ​ Policy-based Forwarding: Forward traffic based on policy defined by application, source zone/interface, source/destination address, source user/group, and service.
• ​ Virtual Systems: Create multiple virtual “firewalls” within a single device as a means of supporting specific departments or customers. Each virtual system can include dedicated administrative accounts, interfaces, networking configuration, security zones, and policies for the associated network traffic.
• ​ VPN connectivity: Secure site-to-site connectivity is enabled through standards-based IPSec VPN support while remote user access is delivered via SSL VPN connectivity.
• ​ Quality of Service (QoS): Deploy traffic shaping policies (guaranteed, maximum and priority) to enable positive policy controls over bandwidth intensive, non-work related applications such as streaming media while preserving the performance of business applications.
• ​ Real-time bandwidth monitor: View real-time bandwidth and session consumption for applications and users within a selected QoS class.
• ​ Purpose-built platform: combines single pass engine with parallel processing hardware to deliver the multi-Gbps performance necessary to protect today’s high-speed networks. Tested Configurations The configurations for this validation are highlighted in Table 2. Table 2 - Cryptographic Module Tested Configuration Page 3

The following procedure will put the modules into the Approved mode of operation:

• ​ Install physical kit opacity shields and tamper evidence seals according to the Physical Security Policy section. Physical kits must be correctly installed to operate in the Approved mode of operation. The tamper evidence seals
• ​ During initial boot up, break the boot sequence via the console port connection (by pressing the maint button when instructed to do so) to access the main menu.
• ​ Select “Continue.”
• ​ Select the “Set FIPS-CC Mode” option to enter the Approved mode.
• ​ Select “Enable FIPS-CC Mode”.
• ​ When prompted, select “Reboot” and the module will re-initialize and continue into “FIPS-CC” mode (Approved
• ​ The module will reboot.
• ​ In “FIPS-CC” mode, the console port is available as a status output port.
• ​ Once the module has finished booting, the Crypto Officer can authenticate using the default credentials that come o​ Once authenticated, the module will automatically require the operator to change their password; and the default credential is overwritten The module will automatically indicate the Approved mode of operation in the following manner:
• ​ Status output interface will indicate “**** FIPS-CC MODE ENABLED ****” via the CLI session.
• ​ Status output interface will indicate “FIPS-CC mode enabled successfully” via the console port.
• ​ The module will display “FIPS-CC” at all times in the status bar at the bottom of the web interface. Should one or more power-up self-tests fail, the Approved mode of operation will not be achieved. Feedback will consist of:
• ​ The module will output “FIPS-CC failure”
• ​ The module will reboot and enter a state in which the reason for the reboot can be determined.
• ​ To determine which self-test caused the system to reboot into the error state, connect the console cable and follow the on-screen instructions to view the self-test output. Note: Disabling FIPS-CC mode causes a complete factory reset, which is described in the Zeroization section below. Page 6

Non-Compliant State Failure to follow the directions in the Approved Mode of Operation above and Section 11 will result in the module operating in a non-compliant state. Zeroization The following procedure will zeroize the module:

• ​ Access the module’s CLI via SSH, and command the module to enter maintenance mode; the module will reboot o​ Note: Establish a serial connection to the console port
• ​ After reboot, select “Continue.”
• ​ Select “Factory Reset”
• ​ The module will perform a zeroization, and provide the following message once complete: o​ “Factory Reset Status: Success” Approved and Allowed Algorithms The following table details the cryptographic algorithms and their algorithm certificates. Only the algorithms, modes, and key sizes specified in this table are used by the module. The CAVP certificate may contain more tested options than listed in this table. Table 3 - Approved Algorithms Page 7

asymmetric seeds). Note: The symmetric keys and seeds used for asymmetric key pair generation are produced using the unmodified/direct output of the DRBG **The module is compliant to IG C.H: GCM is used in the context of TLS, IPsec/IKEv2, SSH:

• ​ For TLS, The GCM implementation meets Scenario 1 of IG C.H: it is used in a manner compliant with SP 800-52 and in accordance with Section 4 of RFC 5288 for TLS key establishment. During operational testing, the module was tested against an independent version of TLS and found to behave correctly. o​ From this RFC, the GCM cipher suites in use are TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
• ​ For IPsec/IKEv2, The GCM implementation meets Scenario 1 of IG C.H: it is used in a manner compliant with RFCs 4106 and 7296 (RFC 5282 is not applicable, as the module does not use GCM within IKEv2 itself). During operational testing, the module was tested against an independent version of IPsec with IKEv2 and found to behave correctly.
• ​ For SSH, the module meets Scenario 4 of IG C.H. The fixed field is 32 bits in length and is derived using the SSH KDF; this ensures the fixed field is unique for any given GCM session. The invocation field is 64 bits in length and is incremented for each invocation of GCM; this prevents the IV from repeating until the entire invocation field space of 264 is exhausted. (It would take hundreds of years for this to occur.) In all of the above cases, the nonce_explicit is always generated deterministically. AES GCM keys are zeroized when the module is power-cycled. For each new TLS or SSH session, a new AES GCM key is established. The module is compliant to IG C.F: The module utilizes approved modulus sizes 2048, 3072, and 4096 bits for RSA signatures. This functionality has been CAVP tested as noted above. The minimum number of Miller Rabin tests for each modulus size is implemented according to Table C.2 of FIPS 186-4. For modulus size 4096 the module implements the largest number of Miller-Rabin tests shown in Table C.2. RSA SigVer is CAVP tested for all three supported modulus sizes as noted above. The module does not perform FIPS 186-2 SigVer. All supported modulus sizes are CAVP testable and tested as noted above. The module does not implement RSA key transport in the approved mode. The module does not have any algorithms that fall under: -​ Non-Approved Algorithms Allowed in the Approved Mode of Operation -​ Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed -​ Non-Approved Algorithms Not Allowed in the Approved Mode of Operation The following table documents the module’s algorithms that are non-approved and not allowed for use in the approved mode of operation. Table 4 - Supported Protocols in Approved Mode TLSv1.2 SSHv2 IPSec and IKEv2 SNMPv3 Note: These protocols were not reviewed or tested by the CMVP or CAVP. Page 10

Module Diagrams Figure 1 depicts the logical block diagram for the modules. The cryptographic physical perimeter includes all of the logical components of the modules and the boundary is the physical enclosure of the firewall. Figure 1 - Logical Diagram Figures 2 - 29 depict the modules and their interfaces. Please refer to the appendices for depictions of the modules with the physical kits installed. Figure 2 - PA-220 Front Interfaces Figure 3 - PA-220 Rear Interfaces Page 11

Figure 4 - PA-220R Front Interfaces Figure 5 - PA-220R Rear Interfaces Figure 6 - PA-820 / PA-850 Front Interfaces Figure 7 - PA-820 Rear Interfaces Figure 8 - PA-850 Rear Interfaces Page 12

Figure 9 - PA-3200 Series Front Interfaces Figure 10 - PA-3200 Series Rear Interfaces Figure 9 - PA-3200 Series Front Interfaces Figure 10 - PA-3200 Series Rear Interfaces Page 13

Figure 11 - PA-3410/3420 Front Interfaces Figure 12 - PA-3430/3440 Front Interfaces Figure 13 - PA-3400 Rear Interfaces Figure 14 - PA-5200 Series Front Interfaces Figure 15 - PA-5200 Rear Interfaces Page 14

Figure 16 - PA-7050 Front Interfaces Figure 17 - PA-7050 Back Interfaces Page 15

Figure 18 - PA-7080 Front (on Left) and Back (on Right) Interfaces Figure 19 - PA-410 Front Interfaces Page 16

Figure 20 - PA-410 Rear Ports and Interfaces Figure 21 - PA-400 Front Interfaces (PA-440/450/460 front panels are identical) Figure 22 - PA-400 Rear Interfaces (PA-440/450/460 rear panels are identical) Figure 23 - PA-5410/5420/5430 Front Interfaces (Note: All modules are identical) Page 17

Figure 24 - PA-5410/5420/5430 Rear Interfaces (Note: All modules are identical) Figure 25 - PA-5450 Front Interfaces Figure 26 - PA-5450 Management Processor Card Page 18

Figure 27 - PA-5450 Networking Card Figure 28 - PA-5450 Data Processing Card Page 19

Figure 29 - PA-5450 Rear Interfaces 3.​Cryptographic Module Interfaces The modules are multi-chip standalone modules with ports and interfaces as shown below. The modules do not implement a Table 5 - Ports and Interfaces N/A Page 20

4.​Roles, Services, and Authentication Services While in the Approved mode of operation, all CO and User services are accessed via SSH or TLS sessions. Approved and allowed algorithms, relevant CSPs, and public keys related to these protocols are accessed to support the following services. CSP access by services is further described in the following tables. Table 6 - Roles, Service Commands, Input and Output N/A Page 22

Assumption of Roles VPN. The cryptographic modules enforce the separation of roles using unique authentication credentials associated with operator accounts. The modules support concurrent operators. The modules do not provide a maintenance role or bypass capability. The modules all support the use of a password (i.e. Memorized Secret as per SP 800-140E). Upon first boot, the module enforces a maximum of 10 failed attempts. Passwords stored in the module are hashed using SHA-256, and any passwords that are transported into/out of the module are protected via TLS 1.2. The passwords for the RA VPN and S-S VPN roles are created as part of the Security Configuration Management service Table 7 - Roles and Authentication In FIPS-CC Mode, the module checks and enforces the minimum password length of eight (8) as specified in SP 800-63B. Passwords are securely stored hashed with salt value, with very restricted access control, and rate limiting mechanism for Page 23

The minimum equivalent strength supported is 112 bits. The probability that a random attempt will succeed is 1/(2112) which is less than 1/1,000,000. The probability of successfully authenticating to the module within a one minute period is 3,600,000/(2112), which is less than 1/100,000. The firewall supports at most 60,000 new sessions per second to authenticate in a one-minute period. The table below defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. Table 8 - Approved Services N/A HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2256 HMAC-SHA2512 N/A N/A G/W/E G/W/E G/E/Z G/E/Z G/E/Z G/E/R/W/Z G/E/Z G/E/Z G/E/Z G/E/Z Page 24

HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 N/A HMAC-SHA2256 HMAC-SHA2384 G/E/Z G/E/Z G/E/Z G/E/R/W/Z W/E W/E W/E E E G/E/Z G/E/Z G/E/R/W/Z G/E/Z G/E/Z G/E/Z G/E/Z G/E/Z G/E Page 27

N/A N/A W/E W/E W/E E Z E N/A R Note: Configuration/System Logs for Approved services above will indicate FIPS-CC mode is enabled, configuration requirements from Section 11 are followed, and that the service succeeded. 5.​Software/Firmware Security ECDSA Cert. #A2906) during the Pre-Operational Self-Test. In addition, the module also conducts the firmware load test by using RSA 2048 with SHA-256 (Cert. #A2906) for the new validated firmware to be uploaded into the module. The pre-operational self-tests can be initiated by power cycling the module. When this is performed, the module automatically runs the cryptographic algorithm self-tests in addition to the pre-operational firmware integrity test. 6.​Operational Environment The FIPS 140-3 Operational Environment requirements are not applicable because the Firewalls do not contain modifiable operational environments. The operational environment is limited since the modules include a firmware load service to support necessary updates. New firmware versions within the scope of this validation must be validated through the FIPS 140-3 CMVP. Any other firmware loaded into these modules is out of the scope of this validation and requires a separate FIPS 140-3 validation. 7.​Physical Security The multi-chip standalone modules are production quality containing standard passivation. Chip components are protected by an opaque enclosure. There are tamper evident seals that are applied on the modules by the Crypto-Officer. All unused seals are to be controlled by the Crypto-Officer. The seals prevent removal of the opaque enclosure without evidence. The Crypto-Officer must ensure that the module surface is clean and dry. Tamper evident seals must be pressed firmly onto the adhering surfaces during installation and once applied the Crypto- Officer shall permit 24 hours of cure time for all tamper-evident seals. The Crypto-Officer should inspect the seals and shields for evidence of tamper every 30 days. If the seals show evidence of tamper, the Crypto-Officer should assume that the modules have been compromised and contact Customer Support. Note: For ordering information, see Table 2 for physical kit part numbers and versions. Opacity shields and Tamper Seals are included for the physical kits. Page 28

8.​Non-Invasive Security No approved non-invasive attack mitigation test metrics are defined at this time. 9.​Sensitive Security Parameter Management The following table details all the sensitive security parameters utilized by the module. Table 10 - SSPs n N/A Page 29

N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A HMAC-SHA2256 HMAC-SHA2384 N/A N/A N/A Page 30

N/A N/A N/A N/A N/A N/A HMAC-SHA2256 HMAC-SHA2512 N/A N/A N/A N/A N/A N/A HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 N/A N/A N/A N/A N/A Page 31

N/A N/A N/A N/A N/A N/A N/A N/A HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 N/A N/A N/A N/A Note: SSPs are implicitly zeroized when power cycling and explicitly zeroized when using the zeroize service. Table 11 - Non-Deterministic Random Number Generation Specification 10.​ Self-Tests The cryptographic module automatically performs the following tests below. The operator can command the module to perform the pre-operational and cryptographic algorithm self-tests by cycling power of the module; these tests do not require any additional operator action. Page 33

Pre-operational Self-Tests Pre-operational Firmware Integrity Test

• ​ Verified with HMAC-SHA-256 and ECDSA P-256 Note: the ECDSA and HMAC-SHA-256 KATs are performed prior to the Firmware integrity test Conditional self-tests Cryptographic algorithm self-tests
• ​ AES 128-bit ECB Encrypt Known Answer Test*
• ​ AES 128-bit ECB Decrypt Known Answer Test *
• ​ AES 128-bit CMAC Known Answer Test* *Note: Supported by the module cryptographic implementation, but only utilized for CAST
• ​ AES 256-bit GCM Encrypt Known Answer Test
• ​ AES 256-bit GCM Decrypt Known Answer Test
• ​ AES 192-bit CCM Encrypt Known Answer Test
• ​ AES 192-bit CCM Decrypt Known Answer Test
• ​ RSA 2048-bit PKCS#1 v1.5 with SHA-256 Sign Known Answer Test
• ​ RSA 2048-bit PKCS#1 v1.5 with SHA-256 Verify Known Answer Test
• ​ RSA 2048-bit Encrypt Known Answer Test
• ​ RSA 2048-bit Decrypt Known Answer Test Note: RSA Encrypt/Decrypt are only used for self-tests
• ​ ECDSA P-256 with SHA-512 Sign Known Answer Test
• ​ ECDSA P-256 with SHA-512 Verify Known Answer Test
• ​ HMAC-SHA-1 Known Answer Test
• ​ HMAC-SHA-256 Known Answer Test
• ​ HMAC-SHA-384 Known Answer Test
• ​ HMAC-SHA-512 Known Answer Test
• ​ SHA-1 Known Answer Test
• ​ SHA-256 Known Answer Test
• ​ SHA-384 Known Answer Test
• ​ SHA-512 Known Answer Test
• ​ DRBG SP 800-90Arev1 Instantiate/Generate/Reseed Known Answer Tests
• ​ SP 800-90Arev1 Instantiate/Generate/Reseed Section 11.3 Health Tests
• ​ SP 800-56Ar3 KAS-FFC-SSC 2048-bit Known Answer Test
• ​ SP 800-56Ar3 KAS-ECC-SSC P-256 Known Answer Test
• ​ SP 800-135rev1 TLS 1.2 with SHA-256 KDF Known Answer Test
• ​ SP 800-135rev1 SSH KDF with SHA-256 Known Answer Test
• ​ SP 800-135rev1 IKEv2 KDF with SHA-256 Known Answer Test
• ​ SP 800-90B RCT/APT Health Tests on Entropy Source Note: The SP 800-90B Health Tests are implemented by the entropy source. Conditional Pairwise Consistency Self-Tests
• ​ RSA Pairwise Consistency Test
• ​ ECDSA/KAS-ECC Pairwise Consistency Test
• ​ KAS-FFC Pairwise Consistency Test Conditional Firmware Load test
• ​ Firmware Load Test
• Verify RSA 2048 with SHA-256 signature on firmware at time of load Conditional Critical Functions Tests
• ​ SP 800-56A Rev. 3 Assurance Tests (Based on Sections 5.5.2, 5.6.2, and 5.6.3) Error Handling In the event of a conditional test failure, the module will output a description of the error. These are summarized below. Page 34

Table 12 - Errors and Indicators 11. Life-Cycle Assurance The module does not have any specific maintenance requirements. For details regarding the secure installation, initialization, startup, and operation of the module, see section “Modes of Operation”. Palo Alto Network provides an Administrator Guide for additional information noted in the “Reference Documents” section of this Security Policy. The module design corresponds to the module security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-3 Level 2 module. 1.​ The cryptographic module provides four distinct operator roles. These are the User role, Remote Access VPN role, Site-to-site VPN role, and the Cryptographic Officer role. 2.​ The cryptographic module provides identity-based authentication. 3.​ The cryptographic module clears previous authentications on each power cycle. 4.​ When the module has not been placed in a valid role, the operator does not have access to any cryptographic services. 5.​ Data output is inhibited during power-up self-tests, zeroization and error states. 6.​ Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 7.​ There are no restrictions on which keys or CSPs are zeroized by the zeroization service. 8.​ The module maintains separation between concurrent operators. 9.​ The module does not support a maintenance interface or role. 10.​ The module does not have any external input/output devices used for entry/output of data. 11.​ The module does not enter or output plaintext CSPs. 12.​ The module does not output intermediate key generation values. Vendor imposed security rules In FIPS-CC mode, the following rules shall apply: 1.​ The operator shall not enable TLSv1.0 or use RSA for key wrapping; it is disabled by default a.​ Checked via CLI using “show shared” command 2.​ The operator should not enable TLSv1.3, it is disabled by default. a.​ Checked via CLI using “show profiles” command 3.​ If using RADIUS, it must be configured using TLS. a.​ Checked via CLI using “show shared” command 4.​ If using TACACS+, configure the service route via an IPSec tunnel, and ensure the TACACS+ server is configured for a minimum password length of eight (8) characters or greater. a.​ Checked via CLI using “show deviceconfig” command Failure to follow these Security Rules will cause the module to operate in a non-compliant state. Page 35

12. Mitigation of Other Attacks The module is not designed to mitigate any specific attacks outside the scope of FIPS 140-3. These requirements are not applicable.
13. Definitions and Acronyms API – Application Programming Interface App-ID – Application Identification - Palo Alto Networks’ ability to identify applications and apply security policy based on the ID rather than the typical port and protocol-based classification. BGP – Border Gateway protocol – Dynamic routing protocol CA – Certificate authority Content-ID – Content Identification – Palo Alto Networks’ threat prevention features including Antivirus, Antispyware, and Intrusion Prevention. CO – Cryptographic Officer DLP – Data loss prevention Gbps – Gigabits per second HA – High Availability HSCI - High Speed Chassis Interconnect IKE – Internet Key Exchange IP – Internet Protocol IPSec – Internet Protocol Security LDAP – Lightweight Directory Access Protocol LED – Light Emitting DiodeOCSP – Online Certificate Status Protocol OSPF – Open Shortest Path First – Dynamic routing protocol PAN-OS – Palo Alto Networks’ Operating System QoS – Quality of Service QSFP - Quad Small Form-factor Pluggable RA VPN – Remote Access Virtual Private Network RIP – Routing Information Protocol – Dynamic routing protocol RJ45 – Networking Connector RNG –Random number generator S-S VPN – Site to site Virtual Private Network SFP – Small Form-factor Pluggable Transceiver SSL – Secure Sockets Layer TLS – Transport Layer Security USB – Universal Serial Bus User-ID – User Identification – Palo Alto Networks’ ability to apply security policy based on who initiates the traffic rather than the typical IP-based approach. VPN – Virtual Private Network XML – Extensible Markup Language
14. Reference Documents FIPS 140-3 - FIPS Publication 140-3 Security Requirements for Cryptographic Modules Palo Alto Networks Administrator’s Guide : https://docs.paloaltonetworks.com/content/dam/techdocs/en_US/pdf/pan-os/10-2/pan-os-admin/pan-os-admin.pdf Page 36

Appendix A - PA-220 - FIPS Accessories/Tamper Seal Installation (6 Seals) 1.​ Place the firewall upside down on a flat Electrostatic Discharge (ESD) protected surface and ground yourself by touching a metal surface on the firewall. 2.​ Slide the firewall into the physical chassis cover and attach it to the cover using a Phillips-head screwdriver to tighten four (4) captive screws (two (2) screws on each side of the cover). 3.​ Install the front (network, management, and console) cables (you cannot access the front ports after you complete the front-cover install described in the following steps). 4.​ Place the physical front cover onto the physical chassis cover and attach it using four (4) #4-40 x .25” screws (two (2) screws on each side of the cover). 5.​ Route the front-port cables through the front-cover cable-guide openings. Page 37

6.​ Attach the physical front-cover panel to the FIPS front cover by sliding the two (2) panel tabs under the physical chassis cover and then attach the panel using two (2) #4-40 x .25” screws. 7.​ Apply a tamper-evident seal to each location shown in the following illustration (six (6) seals total). After all seals are applied, place the firewall right-side up. Page 38

Appendix B - PA-220R- FIPS Accessories/Tamper Seal Installation (5 Seals) 1.​ Place three tamper-evident seals on the top of the module. 2.​ Place two tamper-evident seals on the bottom of the module. Appendix C - PA-800 series - FIPS Accessories/Tamper Seal Installation (11 Seals) 1.​ Place the firewall on a flat Electrostatic Discharge (ESD) protected surface and ground yourself by touching a metal surface on the firewall. Page 39

2.​ Place the physical back cover onto the back of the firewall and attach it using four #4-40 x 5/16 screws (two screws on each side of the back cover). ​ 3.​ Insert the front (network, management, and console) cables in to the front ports. 4.​ Place the physical front cover onto the front of the firewall and place the rack-mount brackets over the holes on the front cover. Attach the front cover and rack-mount brackets to the firewall using eight (8) #6-32 x 5/16” rack-mount bracket screws (shipped with the firewall)—use four (4) screws on each side. Route the front cables through the front-cover cable-guide opening. ​ ​ Page 40

​ 5.​ Apply a tamper-evident seal to each location shown in the following illustrations (eleven (11) seals total). The seal placement over the power supply of the PA-820 firewall and PA-850 firewall is slightly different as shown. ​ Page 41

Appendix D

• PA-3200 Series
• FIPS Accessories/Tamper Seal Installation (19 Seals) 1.​ Install the back cover to the back of the firewall 2.​ Attach the bracket to the firewall that will be used. Note: The firewall can use a mid-mount, front-mount or four-post mount. All seal placement is the same for the various use cases. Page 42

3.​ Place 19 tamper seals on the module. Note: Tamper seal placement is the same for all mount types. Seal #16 is required only for the front-mount of four-post rack installations. It is not required for the mid-mount installation Page 43

Appendix E - PA-5200- FIPS Accessories/Tamper Seal Installation (28 Seals) 1.​ Place the firewall upside down on a flat Electrostatic Discharge (ESD) protected surface and ground yourself by touching a metal surface on the firewall. 2.​ Install power cables: plug the power cords into the power inlets located on the back of the firewall and connect the ground lug and ground cable to the ground lug bolts (you cannot access these back ports after you attach the FIPS back cover). 3.​ Place the physical back cover onto the back of the firewall and attach it to the firewall using four (4) #8-32 x 1/4” screws (two (2) screws on each side of the cover). Route the power cables through the back-cover cable-guide openings. ​ ​ 4.​ Attach the physical back-cover panel to the physical back cover using four (4) #4-40 x 1/4” screws (one (1) screw on each side of the cover and two (2) screws on the back of the cover). ​ 5.​ Place the physical front cover onto the front of the firewall and place the rack-mount brackets over the holes on the front cover. Attach the front cover and rack-mount brackets to the firewall using eighteen (18) #8-32 x 5/16” screws (shipped with the firewall)—use nine (9) screws on each side. Page 44

​ 6.​ Apply a tamper-evident seal to each location shown in the illustrations (28 seals). Page 45

Appendix F - PA-7050 - FIPS Accessories/Tamper Seal Installation (24 Seals) 1.​ Attach front right rack mount brackets in 4-post rack position. Do not attach rear rack mount brackets. Note that brackets are rotated 180 degrees, so the screw holes line up and the rack mount holes are now on the front of the chassis. 2.​ Align the right plenum bracket with five (5) open screw holes. Attach air plenum brackets using five (5) of the remaining bracket screws as shown. Repeat for the left side. 3.​ Attach bottom plenum to the front right rack mount bracket. Place only the middle two (2) screws. Page 47

4.​ Attach the bottom plenum to the rearward right plenum bracket. 5.​ Rotate PA-7050 chassis clockwise 90 degrees onto the bottom plenum. Page 48

6.​ Assemble top plenum and cable guide hardware. 7.​ Attach top plenum to the front left rack mount bracket Page 49

8.​ Attach front opacity shield using the four (4) captive screws 9.​ Attach top plenum to the rearward left plenum bracket along with plenum’s rear opacity shield as shown Page 50

10.​ Loosen four (4) screws on the panel containing the power supply vent. Insert the power supply vent opacity shield and tighten screws. 11.​ Facing the front of the module, affix two (2) seals to top of the front opacity shield, one (1) near left edge and one (1) near the right edge. Ensure the seals, when placed, overlap onto the top of the plenum, as shown. (2 total) Page 51

12.​ Facing the front of the module affix one (1) seal centered to the bottom of the front opacity shield to the bottom air plenum, as shown. (1 total) 13.​ Facing the rear of the module, affix two (2) seals to top of the rear opacity shield, one (1) near left edge and one (1) near the right edge. Ensure the seals, when placed, overlap onto the top of the plenum, as shown. (2 total) Page 52

14.​ Facing the rear of the module; A.​ Affix one (1) seal to the top plenum/opacity shield, covering the left and right outermost screws, as shown. B.​ Affix one (1) seal to the left and right edge of the top plenum bracket folding over the outer edge of the module, as shown. C.​ Affix one (1) seal to the top of each rear panel (three (3). Ensure that the seals lap onto the top rear plenum brackets, as shown. (7 total) 15.​ Facing the rear of the module, Page 53

A.​ Affix one (1) seal to the bottom of each rear panel (three (3). Ensure that the seals laps onto the bottom rear plenum brackets, as shown. B.​ Affix one (1) seal to the left and right edge of the bottom plenum bracket folding over the outer edge of the module, as shown. C.​ Affix one (1) seal to the bottom plenum’s rear side and the bottom plenum rear bracket. (6 total) 16.​ Facing the rear of the module;

• ​ Affix one (1) seal to cover one (1) screw for each power switch, as shown.
• ​ Affix one (1) seal to the top and bottom of the vent opacity shield, as shown. Please ensure that the captive screw is covered. (6 total) Page 54

Appendix G - PA-7080 - FIPS Accessories/Tamper Seal Installation (10 Seals) 1.​ Using the supplied screws attach the Cable Manager Kit with upper opacity lip to the front of the PA-7080, as shown. 2.​ Using the supplied screws, attach the Left and Right Front Cover brackets to the sides of the PA-7080, as shown. Page 56

3.​ Using the supplied screws attach front opacity shield to the PA-7080 as shown. 4.​ The final assembly for the PA-7080 with the physical kit is as shown. Page 57

5.​ Facing the front of the PA-7080: A.​ Affix one (1) seal to the front and center of the exhaust fan tray. Ensure the seal overlaps the seam with the front PA-7080 branding panel as shown. (1 total) B.​ Affix one (1) seal to the left and right outer edge of mounting flanges for the front opacity shield. Seals should fold over the edge of the cover flange and mounting bracket onto the side of the PA-7080. (2 total) C.​ Affix one (1) seal to the front and center of the air intake fan tray. Ensure the seal overlaps the seam with the PA-7080 electrostatic discharge port panel as shown. (1 total) Page 58

6.​ Facing the rear of the PA-7080; D.​ Affix one (1) seal to the left and right outer edge of the upper back panel. Seals should be placed just below the rear exhaust vent as shown. Seals should wrap around onto the sides of the PA-7080 (2 total). E.​ Affix one (1) seal to the left and right outer edges of each power entry module as shown. Seals should wrap around onto the sides of the PA-7080 (4 total). Page 59

Appendix H - PA-5450 FIPS Accessories/Tamper Seal Installation (12 Seals) The PA-5450 requires twelve tamper seals. Follow the directions below to install the physical kit. Affix 7 seals at the locations on the rear of the device: On the top cover of the module, place one seal at the following location: Affix the front opacity shield to the front of the device and screw into the locations as below: Page 61

Finalize the process by adding four seals at the following locations to secure the screws: Appendix I - PA-410 FIPS Accessories/Tamper Seal Installation (4 Seals) The PA-410 requires four tamper labels. The placement of these seals are needed in the following areas. Affix one seal to the front of the module that connects to the top/bottom. Page 62

The left and right side of the module requires one seal each in the same location, as noted in the following area. This wraps to the top and bottom of the module. The last seal is placed on the rear side of the module, and wraps to the top and bottom of the module. Appendix J - PA-440/450/460 FIPS Accessories/Tamper Seal Installation (4 Seals) The PA-440/450/460 require four tamper labels that are placed at the same location as the modules have the same enclosure. Affix four seals on the rear of the module as shown below: Page 63

Appendix K - PA-3400 Series FIPS Accessories/Tamper Seal Installation (11 Seals) The PA-3400 series require 12 tamper labels that are placed at the same location on all devices in the series. Affix 12 seals on the module as shown below in the diagrams: Page 64

Appendix L - PA-5400 Series FIPS Accessories/Tamper Seal Installation (11 Seals) The PA-5400 series requires 11 tamper labels. The location of the tamper labels placement is the same for all models in the series. Affix 11 seals on the module as shown below in the diagrams: Page 65

Referenced URLs

• www.paloaltonetworks.com​
• https://www.paloaltonetworks.com/company/trademarks.html
• https://docs.paloaltonetworks.com/content/dam/techdocs/en_US/pdf/pan-os/10-2/pan-os-admin/pan-os-admin.pdf