Cisco Firepower Threat Defense Virtual Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Cisco Firepower Threat Defense Virtual 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>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</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/>linux<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 Cisco Firepower Threat Defense Virtual 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>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</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/>linux<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

Cisco Systems, Inc Cisco Firepower Threat Defense Virtual Cryptographic Module Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Defense Virtual Cryptographic Module (hereinafter referred to as FTDv or the Module), firmware version 7.4.2 The following details how this module meets the security requirements of FIPS 140-3, SP 800-140 and ISO/IEC 19790 for a Security Level 1 firmware hybrid cryptographic The security requirements cover areas related to the design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic indicates the actual security levels for each area of the cryptographic module.

Purpose and Use: This module is a multi-chip standalone firmware hybrid cryptographic module deployed as the virtualized version of the Cisco Firepower Threat Defense (FTD) which houses ASA and Firepower solutions with underlying operating system identified as Linux 4 (also referred to as Firepower eXtensible Operating System or FX-OS throughout this document). The Module’s FTD delivers enterprise-class firewall for businesses, improving security at the Internet edge, high performance and throughput for demanding enterprise data centers. This solution offers the combination of the industry's most deployed stateful firewall with a comprehensive range of © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

next-generation network security services, intrusion prevention system (IPS), content security and secure unified communications, SSHv2, HTTPS/TLSv1.2, IPsec/IKEv2, SNMPv3 and Cryptographic Cipher Suite B. Module Type: Firmware-hybrid Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The cryptographic module (red dash box) is a non-modifiable, multi-chip standalone firmware hybrid cryptographic module providing cryptographic support which takes data in and out from the host application via the API. The block diagram below shows the boundary of the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. The cryptographic boundary is the module (red dash box) and its interfaces with the operational environment. Processor API Host Platform Hypervisor API FTD FOM API Figure 1 Block Diagram The Block Diagram above comprises the following components

• Processor: Chip on the tested platforms handle all processes.
• API: Host API between hypervisor and processor
• Hypervisor: VMWare ESXi 7.0
• API: Host API between hypervisor and the FTD Module
• FTD: Firepower Threat Defense
• API: Guest API between the FTD Module and FOM Crypto library
• FOM: Cisco FIPS Object Module (FOM)

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: Table 3: Tested Module Identification
• Hybrid Disjoint Hardware Tested Operational Environments - Software, Firmware, Hybrid: Table 4: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: Table 5: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid

N/A for this module. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Modes List and Description: Table 6: Modes List and Description The module has one Approved mode of operation and does not implement a Non-Approved following the steps in section 11 of this document, the module will only operate in the Approved mode of operation. The module doesn’t claim the implementation of a degraded mode

Approved Algorithms: © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Table 7: Approved Algorithms Vendor-Affirmed Algorithms: Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Table 9: Security Function Implementations

• The module’s AES-GCM implementation conforms to Implementation Guidance C.H scenario #1 following RFC 5288 for TLS. The module is compatible with TLSv1.2 and provides support for the acceptable GCM cipher suites from SP 800-52 Rev1, Section 3.3.1. The keys for the client and server negotiated in the TLSv1.2 handshake process (client_write_key and server_write_key) are compared and the module aborts the session if the key values are identical. The operations of one of the two parties involved in the TLS key establishment scheme were performed entirely within the cryptographic boundary of the module being validated. The counter portion of the IV is set by the module within its cryptographic boundary. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established.
• The module uses RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the AES GCM encryption keys are derived. Two keys established by IKEv2 for one security association (one key for encryption in each direction between the parties) are not identical and abort the session if they are. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

• In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation as per section 5 in SP800-133rev2. The resulting generated seed used in the asymmetric key generation is the unmodified output from SP800-90Arev1 DRBG.
• The module was algorithm tested based on the FIPS 186-4 standard Digital Signatures. According to IG C.K, this module is 186-5 compliant as all 186-4 CAVP tests performed are mathematically identical to the 186-5 CAVP tests. The Module does not support 186-

Table 10: Entropy Certificates Table 11: Entropy Sources The module employs a Deterministic Random Bit Generator (DRBG) implementation based on SP800-90Arev1. This DRBG is used internally by the module (e.g. to generate symmetric keys, seeds for asymmetric key pairs, and random numbers for security functions). The DRBG implemented is an AES-256 Counter DRBG, seeded by the entropy source described in the table above. The Counter DRBG utilizes the Derivation Function and employs prediction resistance. The DRBG is instantiated with a 384-bits long entropy input (corresponding to 384 bits of entropy). Additionally, the DRBG is reseeded with a 256-bits long entropy input (corresponding

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800- 133r2. When random values are required, they are obtained from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2. The following methods are implemented:

• Direct generation of symmetric keys: compliant with SP 800-133rev2, Section 6.1.
• Safe primes key pair generation: compliant with SP 800-133rev2, Section 5.2, which maps to SP 800-56Arev3. The method described in Section 5.6.1.1.4 of SP 800-56Ar3 (“Testing Candidates”) is used. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

• RSA key pair generation: compliant with SP 800-133rev2, Section 5.1, which maps to FIPS 186-4. The method described in Appendix B.3 of FIPS 186-4 (“Probable Primes”) is used.
• ECC (ECDH and ECDSA) key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-4. The method described in Appendix B.4 of FIPS 186-4 (“Testing Candidates”) is used. Note that this generation method is also used to generate ECDH key pairs. Additionally, the module implements the following key derivation methods:
• SNMPv3, SSHv2 KDF, TLS 1.2 KDF, IKEv2 KDF: compliant with SP 800-135r1. These implementations shall only be used to generate secret keys in the context of the SNMPv3, SSHv2, TLSv1.2 and IKEv2 KDF protocols, respectively. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service

The module provides the following key/SSP establishment services in the approved mode of operation: KAS-FFC Shared Secret Computation:

• The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-FFC shared secret computation. The shared secret computation provides between 112 and 152 bits of encryption strength.
• The module supports the use of the safe primes defined in RFC 4419 (SSH), RFC

7919 (TLS) and RFC 3526 (IKE). Note that the module only implements domain

parameter generation, key pair generation and verification, and shared secret computation.

• SSH (RFC 4419):  MODP-2048 (ID = 14)  MODP-3072 (ID = 15)  MODP-4096 (ID = 16)
• TLS (RFC 7919):  ffdhe2048 (ID = 256)  ffdhe3072 (ID = 257)  ffdhe4096 (ID = 258)
• IKE (RFC 3526):  MODP-2048 (ID = 14)  MODP-3072 (ID = 15)  MODP-4096 (ID = 16) KAS-ECC Shared Secret Computation:
• The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-ECC shared secret computation. The shared secret computation provides between 128 and 256 bits of encryption strength. The module also provides the following key transport mechanisms:
• Key wrapping using AES-GCM with a security strength of 128 or 256 bits. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

• Key wrapping using AES-CBC with a security strength of 128 or 256 bits with HMACSHA-1, HMAC-SHA2-256 or HMAC-SHA2-384.

The module supports SSHv2, TLSv1.2, IPsec/IKEv2 and SNMPv3 industrial protocols. No parts of SSHv2, TLSv1.2, IPsec/IKEv2 or SNMPv3 protocols, other than the KDFs, have been tested by the CAVP and CMVP. Please refer to SSPs Table for more information.

Table 12: Ports and Interfaces The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2. The module provides its logical interfaces via Application Programming Interface (API) calls. The logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces

Table 13: Roles The module supports Crypto Officer (CO) role. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

The following tables detail the types of approved services available to each role in approved mode of operation, the types of access for each role and the Keys or SSPs they affect.

• Generate G
• Read Access R
• Write Access W
• Execute Access E
• Zeroize Z © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Z Z Z Z Z Z Z Z Z © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Z Z Z Z Z Z Z Z Z © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Z Z Z Z © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Z Z :Z Z n. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

G,W,E G,W,E G,W,E © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

G,W,E G,W,E G,W,E G,W,E G,W,E © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

G,W,E © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

G,R,W G,W,E G,W,E G,W,E G,W,E © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

n G,R,W G,R,W G,W,E G,W,E © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

G,W,E G,W,E G,W,E n G,R,W © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

G,W,E G,W,E G,W,E : G,W,E G,W,E G,W,E © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

The module implements Self-initiated cryptographic output capability without external operator request. The Crypto Officer shall configure self-initiated cryptographic output capability. Prior to executing the self-initiated cryptographic output capability, the module conducts two independent internal actions to activate the capability to prevent the inadvertent output due to a single error. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

The module is provided in the form of binary executable code. To ensure firmware security, the library is protected by RSA 2048 SigVer with SHA-512 (RSA and SHA-512 Cert. #A4595) signature calculated at build time. At crypto module library initialization, the signature is recalculated and compared to the hardcoded build-time generated signature value. If at load time the signature does not match, the crypto module library exits with error. If failure occurs during self-test, all crypto functionality is disabled.

Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can power-cycle or reboot the tested platform to initiate the integrity test on-demand.

Type of Operational Environment: Non-Modifiable The module is a firmware hybrid module, which is operated in a non-modifiable operational environment per FIPS 140-3 level 1 specifications. The module’s firmware version running on each tested platform 7.4.2. The module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevent unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environments provide the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators.

The module is running on the multi-chip standalone production grade platform to meet physical security requirements from FIPS 140-3 level

1. The module’s Tested Operational Environment’s Physical Perimeter (TOEPP) is drawn at the casing of the tested platforms in Table
2. The module’s tested platforms consist of production-grade components.

N/A for this module. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Table 16: SSP Input-Output Methods

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Table 17: SSP Zeroization Methods h © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

h © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

h © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

h © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

h n © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

h © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

h © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

h Table 18: SSP Table 1 © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

n n © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

n n © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

n n n n © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

n n © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

n n © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

n n n © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

© 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

SHA-1 © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

The module includes an implementation of SHA-1 for hashing and digital signature verification. This implementation will be non-Approved for all uses starting January 1, 2031 FIPS 186-4/186-5 As of February 5, 2024, the CMVP does not accept module submissions that implement DSA or RSA X9.31 in the approved mode, other than for signature verification which is approved for legacy use. This module does not implement DSA or RSA X9.31 for signature generation and therefore is unaffected by the current transition from 186-4 to 186-5. As detailed in section 2.7, the CAVP testing performed on the 186-4 algorithms is mathematically similar to the testing performed on the 186-5 algorithms and therefore this module claims compliance with 186-5. This means that no timeline exists in which any of the implemented algorithms will transition from approved to non-approved.

Table 20: Pre-Operational Self-Tests The module performs the following self-tests, including Pre-operational and Conditional selftests. Prior to the module providing any data output via the data output interface, the module performs and passes the pre-operational self-tests. Following the successful pre-operational self-tests, the module executes the Conditional Cryptographic Algorithm Self-tests (CASTs). The self-test success or failure results are an output of the return value of the library load API call, which is functioning as the self-test status indicator. If anyone of the self-tests fails, the module transitions into an error state and outputs the error message via the module’s status output interface. While the module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The error state can only be cleared by reloading the module. All self-tests must be completed successfully before the module transitions to the operational state.

s d © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

s d © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

s d © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

s d © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Algorithm or Test

Test Propertie s

Test Metho d

Test Type

Indicat or

Details

Condition s first operational use.

s d Table 21: Conditional Self-Tests The module performs on-demand self-tests initiated by the operator, by powering off and powering the module back on. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests.

Table 22: Pre-Operational Periodic Information © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Table 23: Conditional Periodic Information The module performs on-demand self-tests initiated by the operator, by powering off and powering the module back on. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests.

Table 24: Error States © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

If any of the above-mentioned self-tests fail, the module reports the error and enters the Error state. In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to reboot the module and perform the selftests, including the pre-operational integrity test and the conditional CASTs. The module will only enter into the operational state after successfully passing the pre-operational integrity test and the conditional CASTs.

The module meets all the Level 1 requirements for FIPS 140-3. The Crypto Officer must configure and enforce the following initialization steps. Operating this module without maintaining the following settings will put the module into a non-compliant state. Step 1: Log in with the default username admin and the password Admin123. Step 2: The first time you log in to the Module, you are prompted to accept the End User License Agreement (EULA) and to change the admin password. You will be prompted with the CLI setup wizard. See the following guidelines:

• Do you want to configure IPv4? and/or Do you want to configure IPv6? Enter y for at least one of these types of addresses.
• Enter the IPv4 default gateway for the management interface and/or Enter the IPv6 gateway for the management interface Set a gateway IP address for Management 1/1 on the management network.
• Manage the device locally? Enter no to use the Firepower Management Center (FMC). Step 3: Register the module into Firepower Management Center (FMC) for the further configuration. > configure manager add {hostname | IPv4 address | IPv6 address} {registration key} Step 4: From the Firepower Management Center (FMC), navigate to Devices > Device Management and from the “Add” drop-down, choose Device. Set the following parameters:
• Host: Enter the IP address or hostname of the Firewall Threat Defense you want to add.
• Display Name: Enter the name for the Firewall Threat Defense as you want it to display in the Firewall Management Center.
• Registration Key: Enter the same registration key that you specified in the Firewall Threat Defense initial configuration in step 4 above. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

• Domain: Assign the device to a leaf domain if you have a multidomain environment.
• Group: Assign it to a device group if you are using groups.
• Access Control Policy: Choose an initial policy. Click Register, and confirm successful registration. If the registration succeeds, the device is added to the list. If it fails, you will see an error message. Step 5: From the Firepower Management Center (FMC), navigate to Device > Platform, select New Policy and choose Threat Defense Settings. Name the new Policy, and select the FTD from the “Available Devices” list and click Add to Policy. Then from the sidebar select UCAPL/CC Compliance in the dropdown choose CC option and save. This sets the mode of operation to the Approved Mode. Step 6: Reboot the module. > reboot Step 7: Check the Module’s name, version and approved service status by using the following commands: Output the modules name/version: > show version Output the modules approved mode of operation status: > show fips

No specific Administrator guidance.

No specific Non-Administrator guidance.

N/A for this module. © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.