Device Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Device Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>status output</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"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    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"]
    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?"]
    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"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    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
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  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 C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Device Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>status output</i><br/>src: text:keyword"]
    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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

F5, Inc. Device Cryptographic Module Last update: August 2025 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com

F5®, BIG-IP®, TMOS® are Registered trademarks of F5, Inc. Intel® Xeon® and Intel® Atom® processors are Registered trademarks of Intel Corporation. © 2025 F5, Inc.

This document is the non-proprietary FIPS 140-3 Security Policy that contains the security rules under which the Device Cryptographic Module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an Overall Security Level 2 module.

Table 1: Security Levels © 2025 F5, Inc.

The Device Cryptographic Module (hereafter referred to as “the module”) is a smart evolution of F5’s market leading Application Delivery Controller (ADC) technology. Solutions built on this platform are load balancers. They are full proxies that give visibility into, and the power to control—inspect and encrypt or decrypt—all the traffic that passes through your network. Purpose and Use: Underlying BIG-IP/ VIPRION hardware and software are F5’s proprietary operating system, Traffic Management Operating System (TMOS), which provides unified intelligence, flexibility, and programmability. With its application control plane architecture, TMOS is a highly optimized system providing control over the acceleration, security, and availability services your applications require. TMOS establishes a virtual, unified pool of highly scalable, resilient, and reusable services that can dynamically adapt to the changing conditions in data centers and virtual and cloud infrastructures. In the following documentation TMOS and BIG-IP are interchangeably used where system and feature modules are concerned. The Control (or Management) Plane refers to the connection from an administrator to the BIG-IP for system management. The Data Plane refers to the traffic passed between external entities and internal servers. Module Type: Hardware Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the module is defined by the exterior surface of the appliance (red dotted line in Figure 1). The block diagram below shows the module, its interfaces with the operational environment and the delimitation of its cryptographic boundary. Figure 1 also depicts the flow of status output (SO), control input (CI), data input (DI) and data output (DO). Description of the ports and interfaces can be found in Table- Ports and Interfaces. Figure 1: Block Diagram © 2025 F5, Inc.

Tested Operational Environment’s Physical Perimeter (TOEPP): N/ A for hardware module. Diagram, Photograph: Figure 2 - BIG-IP i4600 and BIG-IP i4800 Figure 3 - BIG-IP i5600, BIG-IP i5800 and BIG-IP i5820-DF Figure 4

• BIG-IP i7600, BIG-IP i7800 and BIG-IP i7820-DF Figure 5 - BIG-IP i10600, BIG-IP i10800 and BIG-IP i11600-DS, BIG-IP i11800-DS Figure 6
• BIG-IP i15600, BIG-IP i15800, BIG-IP i15820-DF © 2025 F5, Inc.

Figure 7 - B2250 blade mounted in VIPRION chassis C2400 Figure 8 - B4450 blade mounted in VIPRION chassis C4480

Tested Module Identification – Hardware: © 2025 F5, Inc.

Table 2: Tested Module Identification – Hardware

Modes List and Description: Table 3: Modes List and Description The module enters the Approved Mode after the pre-operational self-tests and conditional algorithms self-tests (CASTs) have completed successfully. The module enters the approved mode after pre-operational self-tests succeed. The module automatically switches between the approved and non-approved modes depending on the

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: © 2025 F5, Inc.

Table 6: Non-Approved, Not Allowed Algorithms

Table 7: Security Function Implementations

AES-GCM: The IV for AES-GCM is constructed in compliance with IG C.H scenario 1a (TLS 1.2). For TLS 1.2, the module offers the AES-GCM implementation and uses the context of Scenario 1a of IG C.H. The module is compliant with SP 800-52r2 section 3.3.1 and the mechanism for IV generation is compliant with RFC5288. The module’s implementation of AES-GCM is compliant to IG C.H option i) where module implements TLS protocol. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. RSA module sizes (IG C.F): All the modulus sizes supported by the module have been ACVP tested for FIPS 186-4 RSA signature verification. SP 800-56Ar3 Assurances: To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the keys for KAS-FFC-SSC and KAS-ECC-SSC must be generated using the © 2025 F5, Inc.

approved key generation services specified in section 2.9. The module performs full public key validation on the generated public keys. Additionally, the module performs full public key validation on the received public keys. Legacy use (IG C.M): Per SP 800-131r2, the SHA-1 with FIPS 186-4 RSA Digital Signature Verification is used in approved mode (for legacy use). Algorithms designated as “Legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-

IG C.K: The module includes CAVP certificates using FIPS 186-4 tests done prior to the IG C.K transition date of Feb 5th, 2024, and are mathematically identical to FIPS 186-5 CAVP tests, hence the module claim FIPS 186-5 compliance for these tests.

The module employs a Deterministic Random Bit Generator (DRBG) based on [SP 80090Ar1] for the generation of random value used in asymmetric keys, and for providing a RNG service to calling applications. The approved DRBG provided by the module is the CTR_DRBG with AES-256. The output of entropy sources provides 256-bits of entropy to seed and reseed SP 800-90Ar1 DRBG during initialization (seed) and reseeding (reseed). In accordance with FIPS 140-3 IG D.L, the 'Entropy input string', 'seed', 'DRBG internal state (V and key values)' are considered CSPs by the module. No non-DRBG functions or instances are able to access the DRBG internal state.

The module implements RSA, ECDSA, EC Diffie-Hellman and Diffie-Hellman asymmetric key generation services compliant with [FIPS186-5], using a [SP 800-90Ar1] DRBG. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per [SP 800-133r2] section 4 example 1 (vendor affirmed). The RSA and ECDSA key pairs used for Digital Signature Schemes are generated in accordance with section 5.1 of [SP 800-133r2] and maps specifically to [FIPS 186-5] Appendix A.1.3 (ECDSA) and Appendix A.2.2 (RSA). The ECDH and DH key pairs used for Key Establishment are generated in accordance with section 5.2 of [SP 800-133r2] i.e. key generation method specified in [SP 800-56Ar3]. For this module the applicable method is from [SP 800-56Ar3] section 5.6.1.2 for ECC Key Pair © 2025 F5, Inc.

Generation which actually maps to [FIPS 186-5] Appendix A.3.1 and is from [SP 800-56Ar3] section 5.6.1.1 for FFC Key Pair Generation. The module does not implement symmetric key generation as an explicit service. The HMAC and AES symmetric keys are derived from shared secrets by applying [SP 800-135] as part of the TLS/ SSH protocols. The scenario maps to the [SP 800-133r2] section 6.2.1 Symmetric keys generated using Key Agreement Scheme.

The module provides the following key establishment services:

• EC Diffie-Hellman key agreement scheme compliant with SP 800-56r3 and FIPS 140-3 IG D.F scenario 2 (path 2) is used as part of the TLS and SSH Protocols. The full EC Diffie-Hellman KAS implements a shared secret computation with the key derivation implemented by [SP 800-135] TLS KDFs and [SP 800-135] SSH KDFs. EC Diffie-Hellman key agreement provides 128 or 192-bits of encryption strength.
• Diffie-Hellman key agreement scheme compliant with SP 800-56Ar3 and FIPS 140-3 IG D.F scenario 2 (path 2) is used as part of the TLS Protocols. The full Diffie-Hellman KAS implements a shared secret computation with the key derivation implemented by [SP 800-135] TLS KDFs. Diffie-Hellman key agreement provides between 112 and 150-bits of encryption strength.
• [SP 800-38F], IG D.G key wrapping in the context of TLS protocol where a key may be within a packet or message that is encrypted and authenticated using:
• An approved authenticated encryption mode (i.e. AES-GCM, AES-CCM) provides 128 or 256 bits of encryption strength (AES Certs. #A3697 and #A3698).
• A combination method which includes an approved AES encryption and an approved HMAC authentication method provides 128 or 256 bits of encryption strength (AES and HMAC Certs. #A3697 and #A3698).
• [SP 800-38F], IG D.G key wrapping in the context of SSH protocol where a key may be within a packet or message that is encrypted and authenticated using:
• A combination method which includes an approved AES-CBC or AES-CTR encryption mode and an approved HMAC authentication method provides

GCM with internal IV generation in the approved mode is compliant with version 1.2 of the TLS protocol (RFC 5288) and shall only be used in conjunction with the TLS protocol. Additionally, the module implements the TLS 1.2 and SSH key derivation functions for use in the TLS protocol and SSH protocol (RFC 4253 and RFC 6668). The TLS 1.2 and SSHv2 protocols have not been reviewed or tested by the CAVP or CMVP. © 2025 F5, Inc.

The physical ports mapping to the logical interfaces and the flow of data passing over them are described in the Table below. Table 10: Ports and Interfaces The logical interfaces are the commands through which the users of the module request services. There are no external input or output devices to the module can be used for data The module does not implement Control Output interface. © 2025 F5, Inc.

Method Name

Description less than 1/1,000,000. - - The maximum number of login attempts is limited to 3 after which the account switch to password authentication. Then the attacker probability of succeeding to establish the connection depends on the probability of guessing the password and it is, as above, 3/676,000,000 less than 1/100,000.

Security Mechanism

Strength Each Attempt

Strength per Minute

Table 11: Authentication Methods The module supports different roles (one CO role and one User role) which create different authenticated sessions, while achieving the separation between the concurrent operators. Two interfaces can be used to access the module:

• Command Line Interface (CLI): The module offers a CLI called traffic management shell (tmsh) which is accessed remotely using the SSHv2 secured session over the Ethernet connection.
• Web Interface (WebUI): The Web interface consists of HTTPS over TLS-enabled web browser which provides a graphical interface for system management tools. The User role can access the module through CLI or WebUI. However, the CO can restrict User role access to have the User accessing through WebUI only. The module does not maintain authenticated sessions upon power cycling. Power-cycling the system requires the authentication credentials to be re-entered. When entering password authentication data through the Web interface, any character entered will be obfuscated (i.e. replace the character entered with a dot on the entry box). When entering password authentication data through the CLI, the module does not display any character entered by the operator in stdin (e.g. keyboard).

Table 12: Roles At initialization of the module, the CO is the only available role. Only the CO can create the user roles.

The service indicator gets recorded in the /var/log remote.log file after the service is executed. For approved services, the indicator is identified with the log message 'Service Indicator: Approved' and for non-approved services the log message includes 'Service Indicator: Not Approved'. For SSH service the service indicator is implicit: when the SSH connection is established the service with the cipher selected is approved. :W :W © 2025 F5, Inc.

Table 13: Approved Services For the above table, the convention below applies when specifying the access permissions (types) that the service has for each SSP. 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 = Zeroize: The module zeroizes the SSP. © 2025 F5, Inc.

Table 14: Non-Approved Services © 2025 F5, Inc.

The integrity of the module is using the approved integrity technique HMAC-SHA-384. Integrity tests are performed as part of the Pre-Operational Self-Tests. The HMAC key used for integrity check is stored within the module.

The on demand integrity test is performed as part of the Pre-Operational Self-Tests by powering the module off and powering it on again. © 2025 F5, Inc.

The module operates in a non-modifiable operational environment provided by F5 called TMOS 17.1.0.1. The module is a hardware validated at a Security Level 2 in Physical Security. Once the module is operational, it does not allow the loading of any additional firmware. There are no further requirements for this security area. Type of Operational Environment: Non-Modifiable © 2025 F5, Inc.

Table 15: Mechanisms and Actions Required

Number: Placement: The pictures below show the location of all tamper evident labels for each hardware The tamper labels are delineated with red circles in the pictures below. © 2025 F5, Inc.

Figure 9 - Tamper labels on BIG-IP i4600 and BIG-IP i4800 (8 of 8 tamper labels and one opaque screen on second PSU slot) Figure 10 – Tamper labels on BIG-IP i5600, BIG-IP i5800 and BIG-IP i5820-DF (7 / 7 tamper labels and one opaque screen on second PSU slot) © 2025 F5, Inc.

Figure 11

• Tamper labels on BIG-IP i7600, BIG-IP i7800 and BIG-IP i7820-DF. Label position is as follows: on the front side of the platform -label 1-; on the opposite lateral sides of the platform -labels 2,3,7,8; on the ventilation fan tray that allows access to SSD -label 4. On the replaceable PSUs -labels 5,6. Figure 12
• Tamper labels on BIG-IP i10800, BIG-IP i10600, BIG-IP i11600-DS, BIG-IP i11800-DS. (7 / 7 tamper labels shown) © 2025 F5, Inc.

Figure 13 – Tamper labels on BIG-IP i15600, BIG-IP i15800, and BIG-IP i15820-DF.

1 label on the front, 4 labels on the sides, 2 tamper labels shown circled in orange to mark with

evidence the unauthorized removal of the fan tray and PSUs (replaceable items) that give access to replaceable storage drives. Figure 14 – Tamper labels on chassis with VIPRION B2250 blade (delineated by a red box) and three blanks (1 of 1 tamper label shown and 1/1 opaque screen) © 2025 F5, Inc.

Figure 15

• Tamper labels on chassis with VIPRION B4450 blade (delineated by a red box) and three banks (2 of 2 tamper labels shown and 1/1 opaque screen) Surface Preparation: Before the module is installed in the production environment, tamper-evident labels must be installed in the location identified for each test platforms below. The following steps should be taken when installing or replacing the tamper evident labels on the module. The instructions are also included in F5 Platforms: FIPS Kit Installation provided with each module.
• Use the provided alcohol wipes to clean the chassis cover and components of dirt, grease, or oil before you apply the tamper evidence seals.
• After applying the seal, run your finger over the seal multiple times using extra high pressure.
• The seals completely cure within 24 hours. Operator Responsible for Securing Unused Seals: The Crypto Officer shall be responsible for the storage of the label kits. Part Numbers: P/N: F5-ADD-BIG-FIPS140 © 2025 F5, Inc.

Per IG 12.A: Until requirements of SP 800-140F are defined, non-invasive mechanisms fall under ISO / IEC 19790:2012 Section 7.12 Mitigation of other attacks. © 2025 F5, Inc.

Table 17: SSP Input-Output Methods cryptographic boundary as part of protocol handshake process. Once TLS/SSH session is established any key or data transfer performed thereafter is protected by authenticated encryption provided by the respective protocol

Table 18: SSP Zeroization Methods

Table 19: SSP Table 1 © 2025 F5, Inc.

Table 20: SSP Table 2 © 2025 F5, Inc.

At power-up the module performed the pre-operational self-tests (the integrity test) and the conditional cryptographic algorithm tests (CASTs). Both the pre-operational tests and conditional tests are performed without operator intervention, without any external controls, externally provided test vectors, output results and the determination of pass of fail is done If the module fails any of the tests, the module transitions to the error state and a corresponding error indication is given. The module becomes inoperable, and no services are available. Data output and cryptographic operations are inhibited while the module is in the error State.

Table 21: Pre-Operational Self-Tests The pre-operational self-tests are performed automatically when the module is powered on. Services are not available during the pre-operational self-test and the data output interface is inhibited. On successful completion of the pre-operational self-tests, the module enters operational mode and cryptographic services are available. © 2025 F5, Inc.

Table 22: Conditional Self-Tests The non-physical entropy source performs the SP 800-90B health test (APT and RCT) classified as CAST:

• at start-up: performed on 1,024 consecutive samples.
• during runtime.

Table 23: Pre-Operational Periodic Information © 2025 F5, Inc.

Table 24: Conditional Periodic Information

Name

Description The data output is inhibited.

Conditions

Recovery Method

Indicator

Table 25: Error States The module must reboot to re-loaded with a fresh image to clear the error condition.

On demand and periodic self-tests are performed by powering off the module and powering it on again. This service performs the same cryptographic algorithm tests executed during pre-operational self-tests and CASTs. During the execution of the periodic and on-demand self-tests, crypto services are not available and no data output or input is possible. © 2025 F5, Inc.

Startup Procedures: The module is distributed as a part of a BIG-IP product which includes the hardware and an installed copy of firmware with version 17.1.0.1. The hardware devices are shipped directly from the hardware manufacturer/authorized subcontractor via trusted carrier and tracked by that carrier. The hardware is shipped in a sealed box that includes a packing slip with a list of components inside, and with labels outside printed with the product nomenclature, sales order number, and product serial number. Upon receipt of the hardware, the customer is required to perform the following verifications:

• Ensure that the shipping label exactly identifies the correct customer name and address as well as the hardware model.
• Inspect the packaging for tampering or other issues.
• Ensure that the external labels match the expected delivery and the shipped product.
• Ensure that the components in the box match those on the documentation shipped with the product.
• Verify the hardware model with the model number given on the shipping label and marked on the hardware device itself. Installation Process: Follow the instructions in the "BIG-IP System: Initial Configuration" guide for the initial setup and configuration of the module.
• Run the Setup wizard "appliance-setup-wizard" using the CLI with the CO account and default credentials. The system will prompt you to change the password.
• License the system from the WebUI. Installing the FIPS license for the host system is required for module activation and enabling the service indicator. Guidance on Licensing the BIG-IP system can be found in https://support.f5.com/csp/article/K7752 and summarized as follows: Before you can activate the license for the BIG-IP system, you must obtain a base registration key. The base registration key is pre-installed on new BIG-IP systems. When you power up the product and connect to the Configuration utility, the Licensing page opens and displays the registration key. After a license activation method is selected (activation method specifies how you want the system to communicate with the F5 License Server), the F5 product generates a dossier which is an encrypted list of key characteristics used to identify the platform. If the automated activation method is selected, the BIG-IP system automatically connects to the F5 License Server and activates the license. If the manual method is selected, the Crypto Officer shall go to the F5 Product Licensing page at secure.f5.com, paste the dossier in the “Enter Your Dossier” box which produces a license. The Crypto Officer will then copy and paste it into the “License” box in the Configuration Utility. The BIG-IP system then reloads the configuration and is ready for additional system configuration.
• Once the device is installed, licensed and configured, the Crypto Officer should confirm that the system is installed and licensed correctly as follows: Version Confirmation: The Crypto Officer should call the show version service (with command "tmsh show sys version" and "tmsh show sys hardware"), then confirm that the provided version matches the validated version shown in Table Tested Module Identification
• Hardware. Any firmware loaded into the module other than version 17.1.0.1 is out of the scope of this validation and will mean that the module is not operating as a FIPS validated module. © 2025 F5, Inc.

License Confirmation: The FIPS validated module activation requires installation of the license referred as ‘FIPS license’. The Crypto Officer should call the show license service (with command "tmsh show sys license"), then verify that the list of license flags includes "FIPS 140-3”. Additional Guidance: The Crypto Officer should verify that the following specific configuration rules are followed in order to operate the module in the FIPS validated configuration.

• All command shells other than tmsh are not allowed. For example, bash and other user-serviceable shells are excluded.
• Management of the module via the appliance's LCD display is not allowed.
• Usage of f5-rest-node and iAppLX and provisioning of iRulesLX is not allowed.
• Only the provisioning of AFM and LTM is included.
• Remote access to the Lights Out / Always On Management capabilities of the system are not allowed.
• Serial port console and USB port should be disabled after the initial power on and communications setup of the hardware.
• Use of command run util fips-util -f init is not allowed. Running this command followed by a System Reboot service or restart will mean that the module is not operating as a FIPS validated module.
• The Single Diffie-Hellman should be turned ON for the platform GUI.
• The server ssl profile shall be configured with "cert none" and "key none" option that disables client authentication.

The Crypto Officer should confirm that version and license are provided according to the documentation in section 11.1. The Crypto Officer should follow the additional guidance in section 11.1 to operate the module in the approved validated configuration. The ESV Public Use Document (PUD) reference for non-physical entropy source is as follows: https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropyvalidations/certificate/74

Secure sanitization of the module consists of using the secure erase service that will perform single pass zero write erasing the disk contents. The service can only be triggered by the administrator during reboot of the device. © 2025 F5, Inc.

The module does not implement security mechanisms to mitigate other attacks. © 2025 F5, Inc.

Appendix A.              Glossary and Abbreviations AES           Advanced Encryption Standard AES-NI        Advanced Encryption Standard New Instructions CAVP          Cryptographic Algorithm Validation Program CBC           Cipher Block Chaining CCM           Counter with Cipher Block Chaining-Message Authentication Code CFB           Cipher Feedback CMAC          Cipher-based Message Authentication Code CMVP          Cryptographic Module Validation Program CSP           Critical Security Parameter CTR           Counter Mode DES           Data Encryption Standard DF            Derivation Function DSA           Digital Signature Algorithm DRBG          Deterministic Random Bit Generator ECB           Electronic Code Book ECC           Elliptic Curve Cryptography ESV           Entropy Source Validation FFC           Finite Field Cryptography FIPS          Federal Information Processing Standards Publication GCM           Galois Counter Mode HMAC          Hash Message Authentication Code KAS           Key Agreement Schema KAT           Known Answer Test KW            AES Key Wrap MAC           Message Authentication Code NDF           No Derivation Function NIST          National Institute of Science and Technology OFB           Output Feedback PAA           Processor Algorithm Acceleration PCT           Pairwise Consistency Test PR            Prediction Resistance PSS           Probabilistic Signature Scheme RNG           Random Number Generator RSA           Rivest, Shamir, Adleman SHA           Secure Hash Algorithm SHS           Secure Hash Standard SSH           Secure Shell TDES          Triple-DES XTS           XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 F5, Inc.