Rajant In-Line Security Module (RiSM)

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Rajant In-Line Security Module (RiSM)
  %% 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/>Unauthenticated</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Rajant In-Line Security Module (RiSM)
  %% 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/>Unauthenticated</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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,C6 clueLow;

Security Policy, page by page

Rajant Corporation Rajant In-Line Security Module (RiSM) Version: 1.0 Date: September 23, 2025

20 0 C hes t er f i e ld Par k way

• Ma lv er n, PA 1 9 35 5
• t e l ( 4 84) 59 5- 02 33
• fax ( 4 8 4) 5 95 - 0 2 44

w w w . ra j ant . co m © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Table 1: Acronyms and Definitions © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

This document defines the Security Policy for the Rajant In-Line Security Module (RiSM), hereafter denoted the Module. The RiSM is an in-line network encryption device capable of very high bandwidth over gigabit Ethernet and utilizes very low POE power. The Module is used to secure layer 2 Ethernet communications over the Rajant’s Kinetic Mesh® wireless mesh networks. The Module is ruggedized and may be used in extreme environments to secure traffic between endpoints, subnets or a combination.

Purpose and Use: The Module is a Hardware cryptographic module. The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated in-line network encryption devices. The Module is intended to be used with Rajant’s Kinetic Mesh® wireless mesh networks to secure traffic between endpoints and/or subnets. The Module is an in-line network encryption device operating at layer 2 Ethernet. The module has two 10/100/1000 Ethernet interfaces and is powered using POE applied to either Ethernet ports. The plaintext (PT) interface of the Module, labeled POE IN, connects to a device or networking equipment that supports wired Ethernet (laptops, cameras, switches, servers, etc.) for sourcing or terminating unsecured traffic. The ciphertext (CT) interface, labeled POE OUT, connects to the mesh network. An example deployment is shown in Figure 1: RiSM Deployment Example. The Module receives Ethernet traffic from protected device or network on the PT interface, encrypts and authenticates the payload and then transmits it over the CT interface to the mesh network. The Module receives secure traffic on the CT interface, authenticates and decrypts the © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

payload and then transmits it over the PT interface to the protected device or network. The Rajant mesh network is capable of routing the traffic to its destination based solely on the Ethernet header. All RiSM modules on the network that possess the pre-shared master key (NK) are considered part of a secure enclave. When modules in a secure enclave exchange data with one another, the data is authenticated using an authenticated encryption cipher (AES-GCM) on every packet exchanged between the participating modules. The TEK, ultimately derived from the pre-shared NK, is used for the AES-GCM cipher. The module is managed using the management tool and procedures described in the latest version of the RiSM User Guide. Figure 1: RiSM Deployment Example Module Type: Hardware Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The physical form of the Module is depicted in Figure 2: RiSM-1SPF. The cryptographic boundary is the physical mechanical enclosure outlined in red. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Ethernet Ethernet Status LED Status LED POE                                                                                                       POE Unencrypted                                                                                               Encrypted Ethernet                                                                                                  Ethernet Zeroize         Power/Zeroize                       Module Button             Switch                          Status LED Figure 2: RiSM-1SPF Tested Operational Environment’s Physical Perimeter (TOEPP): © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Mo Nu Model: RISM-1SPF P/N: 23-100222-001

del and/or Part mber

Hardware Version 2.0

Firmware Version RISM_FIPS_02_03

Processors ARM Cortex-A53 with NEON

Features

RiSM Module Modul e Statu s                                                                                            SOC: Hard Processor System (HPS) LED Zeroize Logic, RTC, Key Storage                        ARM CPU 1                                              ARM CPU 2 (NEON Enabled, Stag e 1 FW, Stag e 2 FW HPS0)               (Stag e 1 FW, Stag e 2 FW HPS1) ATECC608B ON                      Zeroize        Entropy Source PWR       OFF ZEROIZE                                                                                           L2 Cache (HPS RAM) Flash ZERO                  Switches Power Enable                                                   On Chip RAM (OCRAM) (HPS RAM) Monitor Traffic Encrypt/ Decrypt/ Auth Core POE                          Red PHY Link Status LED Pass-thru Link Status                                                                                                      SOC: FPGA Fabric LED                                                                                                  (Stage 2 FW FPGA, HPS RAM) POE                          Black PHY Figure 3: Block Diagram

Tested Module Identification

• Hardware: Number Version Table 3: Tested Module Identification
• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A for this module. Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Tested Operational Environments - Software, Firmware, Hybrid: N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module.

This section is not applicable. Modes List and Description: Table 4: Modes List and Description The Module only operates in Approved mode of operation and is shipped from the factory in this mode. The CO must follow the operational security procedures in this security policy to ensure the module is in Approved mode of operation prior to placing it in service. Approved mode of operation is indicated by a solid yellow, for Approved but un-keyed, or a solid green, for Approved and operational, module status LED after power-up. Data input and output interfaces are only enabled in the Approved and operational mode and no data is processed in any other modes. The Approved mode of operation is verified at reception of the Module by the CO role with the following steps.

1. Inspect the module and confirm it is a FIPS validated module by matching the model and hardware version is as specified under the tested and vendor affirmed module version and identification section.
2. Inspect the module and confirm the physical security mechanism are as specified in the physical security section.
3. Connect a POE power source to the module’s PT interface (see Figure 2: RiSM-1SPF). The module status LED will indicate a solid cyan during the boot and FIPS self-test.
4. The module status LED will indicate a solid yellow after boot and successful completion of FIPS self-tests. Note: If the module status LED is a solid green then the module was previously configured for operation and requires a zeroize operation to revert it back to the default state. Perform a zeroize and verify module status LED is solid yellow after boot and successful completion of FIPS self-tests.
5. Establish a connection between the module’s PT interface and a general purpose PC running management tool. Use the management tool to query the module and verify the firmware version is as specified under the tested module identification section. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Status Solid Gray Solid Cyan Solid Red Solid Magenta Solid Yellow Solid Green Solid Blue Blinking Yellow Blinking Blue Blinking Red Blinking Magenta

Color

Description Device is not powered or failed to boot The module is in the process of booting up. The module has encountered an error during its boot process. The module has encountered a security critical error during its boot process. The module is running in Approved mode and is not fully configured or keyed. The module is running in Approved mode and is fully configured and operational. The module is applying a previously downloaded application FW image. The module is in a sensitive security parameter (SSP) configuration mode allowing the CO to load keys. The module is actively downloading a FW image. The module has encountered an error while running. The module has encountered a security critical error while running.

The status LED will indicate red for general errors or magenta for self-test and other security failures if the module fails to boot and complete FIPS self-tests successfully. The module will reboot automatically up to three times to automatically recover from errors, after which it will remain in the error state. Contact the manufacturer if it fails to enter Approved mode of operation after multiple power cycle and zeroize attempts. Table 5: Module Status Led The module status may also be ascertained using the periodic module status message (UDP port 55580 multicast destination address IPv4 ‘224.0.0.224’ or IPv6 ‘fe90::’) sent every ten seconds over both PT and CT Ethernet interfaces. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Module Serial Number (4 bytes)

Message Origin Interface (1 byte)

PT Eth Link Status (3 bytes)

Module Up Time Seconds (4 bytes)

Module Status (2 bytes)

Status Solid Gray Solid Red Solid Yellow Solid Green Blinking Red Blinking Yellow Blinking Green

Color

Description Device has no Ethernet link 10 Link, no activity 100 Link, no activity 1000 Link, no activity 10 activity 100 activity 1000 activity

0x0000 Unkeyed 0x0001 SSP Config (Pending Set Time) 0x0002 SSP Config (Pending CO Pas sword) 0x0003 Reserved 0x0004 SSP Config (Pending Key Fill) 0x0005 SSP Config (Key Filled) 0x0006 FW Download 0x0007 Error (General or Security) 0x0008 – 0x000E Res erved 0x000F Operational The Ethernet link and activity status are indicated by the Ethernet Status Led for each Ethernet port as show below. Table 6: Ethernet Status LED

Approved Algorithms: © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

5) Table 7: Approved Algorithms The Module implements the approved cryptographic algorithms listed in the table above. Vendor-Affirmed Algorithms: Table 8: Vendor-Affirmed Algorithms The Module implements the vendor affirmed cryptographic algorithms listed in the table above. Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: Table 9: Non-Approved, Allowed Algorithms with No Security Claimed The Module implements the non-approved but allowed cryptographic algorithms with no security claimed listed in the table above. Non-Approved, Not Allowed Algorithms: N/A for this module. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Table 10: Security Function Implementations The Module implements the security functions listed in the table above.

Data Traffic Service deterministic IV generation and restoration: The data traffic IV consists of a 32-bit fixed field, unique to the module, and a 64-bit invocation field, incremented by 1 after each use. The invocation field wraps after 2^64 increments. However, the module is not capable of reaching this limit as the key duration is 24 hours. The module can at most process 103,846,147,200 Ethernet frames at 1 gigabit link rate in a 24-hour period. The service does not error on wrap around as the 64-bit invocation field space is sufficiently large to ensure an IV cannot wrap around. The upper 32-bit value of the invocation field is incremented and stored in flash every time the lower 32-bit value wraps. The stored value in flash is used to initialize the upper 32-bits of the invocation field on reset, eliminating the possibility of replicating a previously used invocation field upon restoration. Secure Session Service deterministic IV generation and restoration: © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The secure session IV consists of a 72-bit fixed field, generated randomly each time a new key session key is established and a 24-bit invocation field, incremented by 1 after each use. The invocation field wraps after 2^24 increments after which the secure session is terminated. A new secure session is established in the case of power loss or reset.

Table 11: Entropy Certificates Table 12: Entropy Sources

The module generates symmetric keys in compliance with NIST SP 800-133r2, sections 4, 6.2.1 and 6.2.2, using a NIST SP 800-90A Hash DRBG for random number generation and NIST SP 800-90B entropy source (see section 2.8 RBG and Entropy). Asymmetric keys are generated in compliance with NIST SP 800-133r2, sections 5.1 and 5.2 and FIPS 140-3 IG D.H.

Key establishment is performed in compliance with NIST SP 800-56Arev3 section 6.1.2.2 and NIST SP 800-56CRev2 section 5. No key confirmation is supported. Key transport is performed in compliance with FIPS 140-3 IG D.G using AES GCM algorithm. See AES-GCM in section 2.7.

The section is not applicable.

The module implements a proprietary protocol for configuration and management secured with approved cryptographic algorithms. The Rajant In-Line Security Module Management Protocol (RiSM-MP) establishes a logical UDP based authenticated and encrypted control channel over the PT or CT network interface. It utilizes 56Ar3 Ephemeral Unified ECC CDH key agreement scheme to establish a session key to encrypt all sensitive data with AES GCM 256 encryption. The CO role is also authenticated as part of establishing the secure channel. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Table 13: Ports and Interfaces The Module’s ports and associated FIPS defined logical interface categories are listed in the above table.

Table 14: Authentication Methods The password authentication method is used for role based authentication for operators accessing the module over RiSM-MP secure session. The minimum passphrase length is eight bytes. The passphrase character set consists of the 95 printable characters of A-Z, a-z, 0-9, space, and the 32 special characters (! @ # $ % ^ & * ( ) _ + - = [ ] { } ; ' : “ , . / < > ? \ | ` ~) . The Module will reject all operator authentication attempts after 30 consecutive failed attempts for a period of one-minute beginning with the time of first failed attempt. Thus no more than 30 © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

failed authentication attempts are allowed per minute. The probability of a successful passphrase guess in a single attempt using the character set described above is 1/95^8, which is lower than the required 1/1,000,000. The probability of a successful guess using multiple attempts in a one-minute period using the rate limit described above is 30/95^8, which is lower than the required 1/100,000.

Table 15: Roles The module supports a single distinct authenticated operator role, Cryptographic Officer (CO). The cryptographic module enforces separation of roles by utilizing role based access control for authenticated services. The above table lists all roles supported by the module. The Module does not support a maintenance role. The Module does not support bypass capability. The Module does not support concurrent operators. The CO role is authenticated using a password. The module has a default CO password which must be changed during initialization of the module. The CO password is transmitted to the module encrypted using approved algorithms. The CO role authentication is cleared upon reset as well as after 120 seconds of inactivity and it must be re-established by the operator. Prior authentications are cleared any time a role is authenticated.

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

G,Z E C: E G,E,Z G,E,Z G,R,Z W,E,Z © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

A module running in Approved mode of operation is capable of receiving a firmware update. The firmware update is a partial image replacement, either stage 1 or the stage 2 FW. The firmware update is performed by the CO as follows. See section 6.2 for additional FW loading requirements.

1. Ensure the FW update file is received directly from Rajant. A FW update file from Rajant is signed and encrypted by Rajant. Any other file will fail integrity validation and the FW will not be updated.
2. Perform the FW update using the management tool. Note that the module will be in SSP config state and not encrypt or decrypt data traffic during FW update.
3. The module will perform a ECDSA signature verification FW load test on the downloaded FW.
4. The module will reset automatically after downloading the FW and passing the FW load test to apply the new FW and perform self-tests.
5. Read the module FW version using the management tool and ensure it is matches the new FW version. initiation process is described in the section 11.1, under Module Initialization. The module will © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

automatically enter the operational state after boot and show status output of OPERATIONAL, indicating SICOC is active, enabling the Data Traffic service.

The Module is composed of the following firmware component(s):

• Stage 1 firmware: executable binary stored encrypted in flash
• Stage 2 firmware: executable binary and FPGA image stored encrypted in flash Stage 1 firmware authenticates its stored flash image using ECDSA P-384. Stage 2 firmware stored flash image integrity is verified using 128-bit EDC.

The operator can initiate the integrity test on demand by performing a module reset or power cycle.

Type of Operational Environment: Limited

The Module has a limited operational environment under the FIPS 140-3 definitions. The Module includes a firmware update service to support necessary updates. Firmware versions validated by CMVP for FIPS 140-3 will be explicitly identified on a validation certificate. Any firmware not identified in this Security Policy does not constitute the Module defined by this Security Policy or covered by this validation.

Table 17: Mechanisms and Actions Required The Module is a monolithic mechanical enclosure secured with four screws on the bottom. There are no openings to give visual or physical access to the internal components. The Module must be located in a controlled access area. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The tamper evidence is provided by the use of a cyanoacrylate material (Loctite® 425, mfg. Part no. 42540, available from Rajant) covering selected chassis access screws. Screws requiring application are indicated in figure below. It is recommended that the CO perform regular inspections of the Module while in operation. The recommended tamper inspection period for the Module is once every 90 days. Any attempt to open the Module will be visible as cracks in the Cyanoacrylate material or crumbling of the material. Zeroize and remove module from service upon tamper detection and contact manufacturer. Table 18: Physical Security Inspection Guidelines The Module will be shipped from the manufacturer with tamper-evident coatings pre-applied, as shown below. Mounting Holes Figure 5: Module Seal Application Locations (Bottom) Table 19: Tamper-Evident Seal Locations Guidance © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The Module does not implement any mitigation method against non-invasive attacks.

Table 21: SSP Input-Output Methods Table 22: SSP Zeroization Methods

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Table 23: SSP Table 1 © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Table 25: Pre-Operational Self-Tests

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Table 26: Conditional Self-Tests © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Table 27: Pre-Operational Periodic Information Table 28: Conditional Periodic Information

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The Module allows the operator to initiate power-up self-tests by manually power cycling the power or remotely resetting the Module using the self-test service.

The CO must perform the following steps to securely deploy modules in Approved mode of operation. Deployment:

1. Verify module is ready for Approved mode of operation by following steps in section 2.4.
2. Establish a connection between the module and a general purpose PC running management tool. The module may be installed in the network prior to initialization. However, a direct network connection is recommended for module initialization and then subsequently deploy the initialized module to the network. Module Initialization: A module running in Approved mode of operation is ready to be initialized by the CO to provide the data encryption and decryption service between modules in the enclave. It supports selfinitiated cryptographic output capability after being initialized by the crypto officer. Use the management tool to initialize the module.
3. Generate an enclave configuration file, if one is not available. CO is responsible for protecting the enclave configuration file. ‘rismtool addkey <enclave file name>’
4. Initialize module using the enclave configuration file and default CO password. ‘rismtool init <default IP address> <enclave file name> This step will configure the current date and time, update the default CO password and load network key for the enclave.
5. Verify module status led is green indicating module is operational. An initialized module will automatically enter operational state on subsequent boot based on a valid network key being present and non-default CO password.

This section is not applicable.

This section is not applicable. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Overall security design:

1. The Module provides role-based authentication with a single distinct operator role: Cryptographic Officer.
2. The Module also has self-initiated cryptographic output capability in order to participate in a secure network enclave with other Modules. Enclave packets are authenticated using AES GCM encryption with pre-shared key on a per packet basis.
3. The Module clears previous role authentications on power cycle, upon a new authentication and after a two-minute timeout.
4. The Module does not support concurrent authenticated operators.
5. An operator does not have access to any cryptographic services prior to assuming an authorized role.
6. The Module allows the operator to initiate power-up self-tests by power cycling power or resetting the Module. Power up self-tests do not require any operator action.
7. Data output are inhibited during key establishment, boot up and self-tests, FW update, zeroization, and error states.
8. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.
9. All SSPs, except as noted in the security policy, are zeroized and the module is restored to factory default state after zeroization. The CO will need to re-initialize the module per section 11.1 and 2.4.
10. The Module does not support a maintenance interface or role.
11. The Module does not support manual SSP establishment methods.
12. The Module does support entering plaintext CSPs. These CSPs and SSPs are initially entered by the CO over an AES-GCM encrypted network link using management tool running on a general purpose computer. This is covered under the “CO Authentication” method in table 21.
13. The Module does not store any plaintext CSPs outside of RAM.
14. The Module does not output intermediate key values.
15. The Module does not provide bypass services or ports/interfaces. Rules of operation: The module must be operated in accordance with the following rules.
16. The Module must be initialized and operated in accordance with Verification of Approved Mode of operation and Life-Cycle Assurance sections.
17. Regularly inspect Module for damage and tampering (see Physical Security section).
18. Regularly verify the installed firmware version is approved using the management tool.
19. Only update module firmware with approved versions.
20. Regularly verify the operational status of the module using the management tool and promptly address any error status. Remove module from service if error status is not resolved by a reboot.
21. The module enforces an 8-byte minimum length for CO password. It is recommended to establish a strong CO passphrase policy and change passphrases on a regular basis.
22. The module supports configuration two network keys at a time for seamless key rollover for the data service. It enforces a maximum network key period of one year and will © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

inhibit data service when no network keys are configured. It is recommended to check and configure a new network key as the active key expires.

8. Use a trusted general purpose PC to run the management tool.
9. Ensure the protection of network key is only entrusted to COs.
10. Zeroize modules when not in operation or returning to manufacturer.

Operation:

1. The network key period must not exceed one year. CO must update network key prior to expiration for seamless operation.
2. CO must periodically verify and update module time to compensate for clock drift so that data encryption keys remain synchronized across the secure network enclave. Firmware Update: A module running in Approved mode of operation is capable of receiving a firmware update. The CO performs a firmware update when Rajant releases new firmware using the process described in external software/firmware loaded section. See section 6.2 for additional FW loading requirements.

Decommission: The module must be zeroized prior to decommissioning or re-deployment.

Anti-Replay: The Module is designed to reject replayed encrypted packets received on the ciphertext interface. Any encrypted packet received on the ciphertext interface that is determined to be replayed is dropped and not forwarded to the plaintext interface. The anti-replay mechanism only applies to encrypted packets on the ciphertext interface. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.