BIG-IP Tenant Cryptographic Module

Certificate

Approved Algorithms (52)

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

flowchart LR
  %% Deterministic review-risk graph for BIG-IP Tenant 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>status output<br/>Show status</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 BIG-IP Tenant 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>status output<br/>Show status</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. BIG-IP Tenant Cryptographic Module Module Version: 17.1.0.1 FIPS Security Level 2 Last update: January 2025 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com

© 2025 F5, Inc. / atsec information security.

3 of 51

F5®, BIG-IP®, and TMOS®, are registered trademarks of F5, Inc. Intel®, Atom® and Xeon® are registered trademarks of Intel Corporation. © 2025 F5, Inc. / atsec information security.

4 of 51

This document is the non-proprietary FIPS 140-3 Security Policy for the BIG-IP Tenant Cryptographic Module with firmware version 17.1.0.1. The document contains the security rules under which the 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 a This document provides all tables and diagrams (when applicable) required by NIST SP 800-140B.

Table 1 - Security Levels © 2025 F5, Inc. / atsec information security.

5 of 51

Purpose and Use: The BIG-IP Tenant Cryptographic Module (hereafter referred to as “the module”) is a smart evolution of F5’s market leading Application Delivery Controller (ADC) technology, and specifically designed for F5 hardware and the underlying platform layer. Traffic Management Operating System (TMOS) is the foundation and architecture for F5’s ADCs running on the BIG-IP platform. Together, BIG-IP hardware and the firmware components TMOS is a highly optimized system providing control over the acceleration, security, and management through purpose-built hardware and software systems. F5OS platform layer is tightly integrated with F5’s TMOS firmware. In the following documentation TMOS and BIG-IP are interchangeably used where system and feature modules are concerned. Module Type: Firmware Module Embodiment: Multi Chip Standalone

Table 2 - Tested Operating Environments

The module supports two modes of operation:

• in Approved mode of operation only approved or vendor affirmed security functions can be used.
• in non-Approved mode of operation only non-approved security functions can be used. The module enters operational mode after pre-operational and conditional algorithms self-tests succeed. The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of operation is equivalent to the indicator of the service that was requested. SSPs used or stored in the Approved mode are not used in the non-Approved mode, and vice versa. © 2025 F5, Inc. / atsec information security.

6 of 51

In the Approved Mode, the cryptographic module provides the cryptographic algorithms whose CAVP certificates are in Table 3 below. 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. Not all the ACVP tested capabilities are used by the module in approved mode of operation.

© 2025 F5, Inc. / atsec information security.

7 of 51

© 2025 F5, Inc. / atsec information security.

8 of 51

1 No parts of the TLS / SSH protocols except the KDF has been reviewed or tested by the CAVP and

CMVP © 2025 F5, Inc. / atsec information security.

9 of 51

2.4.2 Non-Approved, Allowed Algorithms and Non-Approved, Allowed Algorithms with No Security

Claimed There are no non-Approved algorithms allowed in the approved mode along with their usage with or without security claimed.

The following table lists the non-Approved algorithms along with their usage. © 2025 F5, Inc. / atsec information security.

10 of 51

Table 4 - Non-Approved Not Allowed Algorithms

Figures below show the platforms on which the module was tested. Figure 1 - r4800 © 2025 F5, Inc. / atsec information security.

11 of 51

Figure 2 - r5900 Figure 3 - r5920-DF Figure 4 –r10900, r10920-DF and r12900-DS (same chassis for the test platforms) © 2025 F5, Inc. / atsec information security.

12 of 51

Figure 5 – VELOS CX410 BX110 with 7 filler panels and one blade. The BX110 tested blade in slot #1 delineated with red rectangle.

The block diagram below shows the module cryptographic boundary, its interfaces with the host operational environment, the host platform, the flow of status output (SO), control input (CI), data input (DI) and data output (DO). The module cryptographic boundary is defined by the red dotted line in Figure

6. The TOEPP is defined by the tested platforms listed in Table 2 and delineated by the black rectangle in Figure
7. The description of the ports and interfaces can be found in Table
8. Figure 6 - Block Diagram © 2025 F5, Inc. / atsec information security.

13 of 51

The logical interfaces are the commands through which users of the module request services. There are no external input or output devices to the module can be used for data input, data For the purpose of the FIPS 140-3 validation, the physical ports are interpreted to be the physical ports of the hardware platform on which it runs. Table 5 - Ports and Interfaces

© 2025 F5, Inc. / atsec information security.

14 of 51

The module supports one CO role and one User role. Maintenance role is not supported. The FIPS 140-3 roles are defined below and corresponding service with input and output are described in Table 6.

• Crypto Officer (CO) role: The Crypto Officer is represented by the administrator of the module ("administrator" is the CO). This entity performs module installation and initialization. This role has full access to the system and has the ability to create, delete, and manage other User roles on the system. At initialisation of the module, the CO is the only available role and only the CO can create the user roles.
• The FIPS140-3 User role is mapped to multiple module roles: Auditor, Certificate Manager, Firewall Manager, iRule Manager, Operator, Resource Manager and User Manager. Each of the module roles are responsible for different components of the system (e.g. auditing, The list of services available to the CO and user roles are defined in Table 8 and Table 9. © 2025 F5, Inc. / atsec information security.

15 of 51

© 2025 F5, Inc. / atsec information security.

16 of 51

Table 6 - Roles, Service Commands, Input and Output

The module supports role-based authentication. The module supports concurrent operators belonging to 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:

• 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. © 2025 F5, Inc. / atsec information security.

17 of 51

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). role depending upon which interface is being used. Table 7 - Authentication Methods

Table 8 lists the Approved services, the service name, description, the Approved security function being used by the service, the keys and SSPs accessed by the service, the roles used by the service, access rights to keys and SSPs and the FIPS 140-3 service indicator returned by the service. The environment variable SECURITY_FIPS140_CIPHER_STRICT is exported with the cipher restriction status. If the cipher_restricted status is enabled, the status output from the service indicator is returned in the high speed login /var/log remote.log file as “'Service Indicator: Approved”. If the cipher_restricted status is disabled, there is no service indicator output. For SSH service the service indicator is implicit: when the SSH connection is established the service with the cipher selected is approved. The following variables are used in the Access rights to keys or SSPs column: • G = Generate: The module generates or derives the SSP. © 2025 F5, Inc. / atsec information security.

18 of 51

• 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. © 2025 F5, Inc. / atsec information security.

19 of 51

© 2025 F5, Inc. / atsec information security.

20 of 51

© 2025 F5, Inc. / atsec information security.

21 of 51

© 2025 F5, Inc. / atsec information security.

22 of 51

© 2025 F5, Inc. / atsec information security.

23 of 51

Table 9 - Non-Approved Services © 2025 F5, Inc. / atsec information security.

24 of 51

The integrity of the module using the approved integrity technique HMAC-SHA-384 is listed in the section 10.1.1. Integrity tests are performed as part of the Pre-Operational Self-Tests.

The on demand pre-operational self-tests, including the integrity test on demand, are performed by powering the module off and powering it on again.

The executable code is defined by the firmware version 17.1.0.1. All code belonging to this firmware version is the executable code of the module. © 2025 F5, Inc. / atsec information security.

25 of 51

The module operates in a non-modifiable operational environment provided by F5 with a firmware version 17.1.01. Once the module is operational, it does not allow the loading of any additional firmware. The module is a firmware validated at a Security Level 2 in Physical Security then there are no further requirements for this security area. © 2025 F5, Inc. / atsec information security.

26 of 51

The module tested in the platforms listed in Table 2 is enclosed in a hard-metallic production grade enclosure that provides opacity and prevents visual inspection of internal components. Each test platform is fitted with tamper evident labels to provide physical evidence of attempts to gain access inside the enclosure. The tamper evident labels shall be installed for the module to operate in approved mode of operation. Table 10 - Physical Security Inspection Guidelines The pictures below show the location of all tamper-evident labels for each hardware platform. Label application instructions are provided in Section 11.2.1 of the Crypto-Officer guidance below. The tamper labels are delineated with red circles in the pictures below. © 2025 F5, Inc. / atsec information security.

27 of 51

Figure 7 - Tamper labels on r4800 (5 of 5 tamper labels) © 2025 F5, Inc. / atsec information security.

28 of 51

Figure 8 – Tamper labels on r5900 (4 of 4 tamper labels) Figure 9 - Tamper labels on r5920-DF (5 of 5 tamper labels). Labels are located on the lateral sides of the platform -labels 1,2,3 and 4. The tamper label 5 on the chassis / enclosure lid is covering the ventilation fan tray that allows access to SSD. © 2025 F5, Inc. / atsec information security.

29 of 51

Figure 10

• Tamper labels on r10900, r10920-DF and r12900-DS (4 +1 of 5 tamper labels shown). Labels are located on the lateral sides of the platform -labels 1,2,3 and 4. The tamper label 5 on the chassis / enclosure lid is covering the ventilation fan tray that allows access to SSD. Label 1 Figure 11
• Tamper label on VELOS CX410 BX110 blade mounted on chassis. The tamper label (1 of 1 tamper label shown) marked as “Label 1” affixed between blade and chassis is positioned to provide evidence if the tested blade in slot #1 is removed from the chassis. © 2025 F5, Inc. / atsec information security.

30 of 51

This section is N/A until non-Invasive security is defined in NIST SP800-140F that replaces the ISO/IEC 19790 Annex F requirements. © 2025 F5, Inc. / atsec information security.

31 of 51

r © 2025 F5, Inc. / atsec information security.

32 of 51

r © 2025 F5, Inc. / atsec information security.

33 of 51

r / c ) © 2025 F5, Inc. / atsec information security.

34 of 51

r / c © 2025 F5, Inc. / atsec information security.

35 of 51

r © 2025 F5, Inc. / atsec information security.

36 of 51

r D.L) Table 12 - SSPs The module employs a Deterministic Random Bit Generator (DRBG) based on [SP800-90Ar1] for the generation of random value used in asymmetric keys. The Approved DRBG provided by the module is the CTR_DRBG with AES-256. The module uses the SP800-90B compliant Entropy source specified in Table 13 to seed the DRBG. The operator does not have the ability to modify the F5 entropy source (ES) configuration settings (see details in Public Use Document referenced in section 11.2). The F5 ES is tested in the OEs listed in Table 1. Table 13 - Non-Deterministic Random Number Generation Specification For generating RSA and ECDSA keys, the modules implements asymmetric key generation services compliant with [FIPS186-4]. A seed (i.e. the random value) used in asymmetric key generation is directly obtained from the SP800-90Ar1] DRBG. © 2025 F5, Inc. / atsec information security.

37 of 51

The Diffie-Hellman generates keys using safe primes compliant with [SP800-56Arev3]. The public and private keys used in the EC Diffie-Hellman key agreement schemes are generated internally by the module using the ECDSA key generation method compliant with [FIPS186-4] and [SP800-56Arev3] In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 4 example 1 [SP800-133r2] (vendor affirmed). 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-135r1] 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 SP800-56Ar3 and FIPS 140-3 IG D.F scenario 2 (path 2) is used as part of the TLS and SSH Protocols. The full EC DiffieHellman KAS implements a shared secret computation with the key derivation implemented by [SP 800-135r1] TLS KDFs and [SP 800-135r1] SSH KDFs. EC Diffie-Hellman key agreement provides 128 or 192-bits of encryption strength.
• Diffie-Hellman key agreement scheme compliant with SP800-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 800135r1] 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 protocols where a key may be within a packet or message that is encrypted and authenticated using approved authenticated encryption mode or a combination method which includes approved symmetric encryption algorithm together with approved authentication method. [SP 800-38F] key wrapping using approved authenticated encryption mode (i.e. AESGCM, AES-CCM) provides 128 or 256 bits of encryption strength (AES Certs. #A3729 and # A3730). [SP 800-38F] key wrapping using a combination of approved AES encryption and HMAC authentication method provides 128 or 256 bits of encryption strength (AES and HMAC Certs. #A3729 and # A3730).
• [SP 800-38F], IG D.G key wrapping in the context of SSH protocols where a key may be within a packet or message that is encrypted and authenticated using a combination method which includes approved symmetric encryption algorithm together with approved authentication method. [SP 800-38F] key wrapping using a combination of approved AES-CBC or AES-CTR encryption mode and HMAC authentication method provides 128 or 256 bits of encryption strength (AES and HMAC Cert. # A3729).

For TLS with EC Diffie-Hellman / Diffie-Hellman key exchange, the TLS pre-primary secret is established during key agreement and is not output from the module. Once the TLS session is established, any key or data transfer performed thereafter is protected by authenticated encryption mode using AES-GCM/ AES-CCM or by AES encryption and HMAC authentication © 2025 F5, Inc. / atsec information security.

38 of 51

through a mutually agreed AES and HMAC session keys derived by applying SP 800-135r1 TLS KDF. For SSH with EC Diffie-Hellman key exchange, the SSH shared secret is established during key agreement and is not output from the module. SSH ECDSA public keys can be imported into the module by the CO and User role using the "Configure SSH user configuration" service. Once the SSH session is established, any key or data transfer performed thereafter is protected by AES encryption and HMAC authentication through a mutually agreed AES and HMAC session keys derived by applying SP 800-135r1 SSH KDF. There are no encrypted SSPs that are directly entered.

As shown in Table 12 the keys are stored in the volatile memory (RAM) in plaintext form. The static SSPs are persistently stored in plaintext in the SSD that is part of the OE. The static SSPs will remain on the system across power cycle. SSPs are only accessible to the authenticated operator, to which the SSPs are associated.

The zeroization methods listed in Table 12, overwrites the memory occupied by keys with “zeros” or pre-defined values. The zeroization of temporary values are performed when no longer needed. The zeroization can be enforced by the Crypto Officer and Resource Manager role with the following services: The zeroization can be enforced by the Crypto Officer with the following services:

• Calling Reboot System service will clear the SSPs present in volatile memory RAM memory.
• Using Secure Erase service (which can only be triggered by the crypto officer during reboot of the platform) will perform a single pass zeroization erasing the SSPs present in persistent memory. © 2025 F5, Inc. / atsec information security.

39 of 51

The pre-operational self-tests are performed automatically whenever the module is powered on. At initialization the module performed pre-operational self-test (integrity test) and the conditional cryptographic algorithm tests (CASTs). The data output interface is inhibited and services are not available during the pre-operational self-tests and CASTs. On successful completion of the preoperational and CASTs, the module enters operational mode and cryptographic services are available. If the module fails any of the tests, it will return an error code and enter into an error state.

The integrity of the module is verified by comparing the HMAC-SHA-384 checksum values of the installed binaries calculated at run time with the stored values computed at build time. If the values do not match the system enters the error state and the module will not be accessible. In order to recover from this state, the module needs to be reinstalled. The HMAC-SHA384 algorithm is self-tested prior to the integrity test being run.

The 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 by the module. If one of the conditional self-tests fails, 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.

The module performs cryptographic algorithm self-tests (CASTs) on all Approved cryptographic algorithms. © 2025 F5, Inc. / atsec information security.

40 of 51

© 2025 F5, Inc. / atsec information security.

41 of 51

Table 14 – Conditional Cryptographic Algorithm Self-Tests

A pairwise consistency test is run whenever asymmetric keys (RSA for Control Plane only, DiffieHellman, EC Diffie-Hellman, or ECDSA for both planes) are generated. PCT for ECDSA and RSA Key Pair Generation used for digital signatures is tested by the calculation and verification of a digital signature. PCT for Diffie-Hellman Key Pair Generation is performed following the SP 800-56Ar3 section 5.6.1 requirements. PCT for EC Diffie-Hellman Key Pair Generation in the Control Plane is covered by ECDSA PCT (IG 10.3.A). PCT for EC Diffie-Hellman Key Pair Generation used for key agreement in Data Plane is performed following the SP 800-56Ar3 section 5.6.2.1.4 requirements.

On demand self-tests are performed by powering off the module and powering it on again. This service performs pre-operational self-tests and CASTs. During the execution of the on demand self-tests, crypto services are not available and no output through data output or cryptographic operations are possible. Table 15 - Error States In any of the error states, any data output or cryptographic operations are prohibited. The module must reboot or re-load with a fresh image to clear the error condition. All data output and cryptographic operations are inhibited when the module is in an error state. © 2025 F5, Inc. / atsec information security.

42 of 51

The module is distributed as a part of a BIG-IP product which includes the hardware platform and an installed copy of firmware with a platform layer F5OS and the BIG-IP version 17.1.0.1. The hardware platforms 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's 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 platform itself.

The Crypto Officer should verify that the following specific configuration rules are followed to operate the module in the approved mode 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

Before the module is installed in the production environment, tamper-evident labels must be installed in the location identified for each test platforms in Section 7.2. The following steps should be taken when installing or replacing the tamper evident labels on the test platforms on which the module runs. The instructions are also included in F5 Platforms: FIPS Kit Installation provided with each hardware platforms.

• 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 48 hours.

Follow the instructions in the " 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. Guidance on Licensing the F5OS system can be found in https://techdocs.f5.com/en-us/hardware/f5-rseries-systems-getting-started/gs-systeminitial-config.html#run-setup-wizard) and summarized as followed: Before you can activate © 2025 F5, Inc. / atsec information security.

43 of 51

the license for the F5OS system, you must obtain a base registration key. The base registration key is pre-installed on new F5OS systems. When you power up the product and connect through the webUI, you can open the SYSTEM SETTINGS > Licensing page to display the registration key. Select "Automatic" for the license Activation Method 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 and activates the license.

The tenant inherits the license and VLANs of the rSeries VELOS host. The crypto officer must follow the following instructions to create a tenant from the Web-based management interface:

• Login with the CO account to the Tenant WebUI and select SYSTEM SETTINGS > Software Management to add image by uploading the qcow2 bundle file of the BIG-IP version 17.1.0.1.
• Under TENANT MANAGEMENT' > 'Tenant Deployments' and click 'Add'. Fill out the form and provide tenant Name, tenant Type (ie BIG-IP) and tenant Image (17.1.0.1.) and other information to fully deploy the tenant.
• Login to the new tenant via ssh or WebUI and configure as you would any BIG-IP system. Tenant creation from CLI is detailed in the publicly available f5,com page (https://techdocs.f5.com/en-us/f5os-a-1-0-0/f5-rseries-systems-installation-upgrade/title-installupgrade-software.html).
• Once the module is installed, licensed and configured, the Crypto Officer should confirm that the system is installed and licensed correctly.

The Crypto Officer should call the show version service (with commands "tmsh show sys version" and "tmsh show sys license"), then confirm that the provided version matches the validated version shown in Table 2. 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.

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”.

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 userserviceable shells are excluded.
• Management of the module via the platform'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 module. © 2025 F5, Inc. / atsec information security.

44 of 51

• 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 use option should be turned ON for the platform GUI.

The approved and non-approved algorithms available to users are listed in section 2, the physical ports, and logical interfaces available to users are specified in section 3. The Approved and nonApproved modes of operation are specified in section 2.3. The algorithm-specific information is listed in sub-section below.

AES-GCM IV is constructed in accordance with SP800-38D in compliance with IG C.H scenario 1. e module does not support AES-GCM with external IV. The implementation of the nonce_explicit management logic inside the module ensures that when the IV exhausts the maximum number of possible values for a given session key, the module triggers a new handshake request to establish a new key. In case the module’s power is lost and then restored, the key used for the AES GCM encryption or decryption shall be re-distributed. The AES GCM IV generation follows [RFC 5288] and shall only be used for the TLS protocol version 1.2 to be compliant with [FIPS140-3_IG] IG C.H scenario 1; thus, the module is compliant with [SP800-52r2] section 3.3.1.

All the modulus sizes supported by the module have been ACVP tested (per IG C.F).

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 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. © 2025 F5, Inc. / atsec information security.

45 of 51

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

46 of 51

Appendix A.              Glossary and Abbreviations ADC                 Application Delivery Controller AES                 Advanced Encryption Standard API                 Application Programming Interface ACVP                Automated Cryptographic Validation Protocol CAVP                Cryptographic Algorithm Validation Program CBC                 Cipher Block Chaining CCM                 Counter with Cipher Block Chaining-Message Authentication Code CFB                 Cipher Feedback CKG                 Cryptographic Key Generation CLI                 Command Line Interface CMAC                Cipher-based Message Authentication Code CMVP                Cryptographic Module Validation Program CSP                 Critical Security Parameter CTR                 Counter Mode DES                 Data Encryption Standard DSA                 Digital Signature Algorithm DRBG                Deterministic Random Bit Generator ECB                 Electronic Code Book ECC                 Elliptic Curve Cryptography ECDSA               Elliptic Curve Digital Signature Algorithm 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 KWP                 AES Key Wrap with Padding MAC                 Message Authentication Code NIST                National Institute of Science and Technology OFB                 Output Feedback PR                  Prediction Resistance PSS                 Probabilistic Signature Scheme RNG                 Random Number Generator © 2025 F5, Inc. / atsec information security.

47 of 51

RSA                 Rivest, Shamir, Adleman SHA                 Secure Hash Algorithm SHS                 Secure Hash Standard SSD                 Solid State Drive SSH                 Secure Shell SSLO                Secure Sockets Layer (SSL) Orchestrator TDES                Triple-DES TLS                 Transport Layer Security XTS                 XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 F5, Inc. / atsec information security.

48 of 51

SP800-140B NIST Special Publication 800-140B - CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf © 2025 F5, Inc. / atsec information security.

51 of 51