MACsec Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Release

Power-on Self-Test KAT for Common Criteria and FIPS

Updated: February 28, 2026

Want to summarize with AI?

On this page

Overview

How MACsec pre-shared keys with Type 6 password encryption work
Guidelines for MACsec FIPS-POST and KAT
Enable Power-on Self-Test KAT for MACsec FIPS cards

Overview

Describes the Power-on Self-Test (POST) Known Answer Test (KAT) mechanism, which verifies the cryptographic integrity of hardware components at startup to support compliance with security standards like FIPS.

A power-on self-test (POST) is a security mechanism that

verifies the cryptographic integrity of hardware components at system startup,
prevents network traffic flow if integrity checks fail, and
supports compliance with security standards such as Common Criteria and FIPS.

Power-on self-tests utilize Known Answer Tests (KATs) executed immediately after powering on the cipher module in MACsec-enabled Cisco 8000 series routers. These tests check cryptographic algorithms (e.g., SHA, DES) on each physical layer chip (PHY) with hardware crypto. If any PHY fails the test, the module enters an error state and does not allow traffic, ensuring only secure, verified hardware is operational.

The POST KAT feature is now available on Cisco 8800 48x100 GbE QSFP28 Line Card (8800-LC-48H), Cisco 8800 36x400GE QSFP56-DD Line Card with MACsec (8800-LC-36FH-M), and Cisco 8606 series routers.

On successful POST KAT execution, the system displays logs indicating KAT Test PASSED for each port, and the corresponding line card becomes operational.
If POST KAT fails on any PHY, the system logs a KAT Test FAILED message, the line card enters an ERROR state, and network traffic is blocked on that card.

How MACsec pre-shared keys with Type 6 password encryption work

Summary

MACsec pre-shared keys with Type 6 password encryption safeguard Layer 2 traffic by encrypting cryptographic secrets at rest using an AES-based method linked to a local primary password-encryption key. The router encrypts PSKs for storage and decrypts them in memory only when required for MACsec operations, ensuring secure handling and rotation of secrets.

The key components involved in the process are:

Primary password-encryption key: A locally defined secret serving as the root key for securing all Type 6–encrypted strings on the router.
Type 6 encryption engine: An AES-based service that encrypts and decrypts secret values for secure storage and controlled display.
MACsec PSK entries: The pre-shared keys used by MACsec; stored as encrypted strings when Type 6 is enabled.
Configuration datastore: The running and startup configuration repositories that persist encrypted secret strings.
Router: Hosts the primary key, runs the Type 6 engine, encrypts and decrypts PSKs, and manages configuration persistence.
User: Defines the primary key, enables Type 6 encryption, configures MACsec PSKs, and performs key rotation.

Workflow

These are the stages MACsec pre-shared keys with Type 6 password encryption:

Primary key setup: The administrator sets a primary password-encryption key that meets policy requirements. The router internally stores it and uses it as the root to protect all Type 6–encrypted strings.
Enable Type 6 encryption: The administrator activates the AES-based Type 6 mechanism. The router binds the encryption engine to the primary key, ensuring new or updated secret strings are encrypted at rest.
Enter PSKs and store securely: When MACsec PSKs are configured or modified, the router accepts plaintext input, encrypts it immediately using Type 6 with the primary key, and saves only the encrypted representation in the configuration.
Use PSKs for MACsec: When MACsec needs a PSK, the router decrypts the stored Type 6 value in memory using the primary key and provides the plaintext to MACsec to establish secure sessions.
Rotate the primary key (optional): When the primary key is rotated, the router re-encrypts all existing Type 6 strings, including MACsec PSKs, under the new key after the administrator authenticates and supplies the new key.

Result

The process ensures that MACsec PSKs remain encrypted at rest, prevents plaintext exposure in configurations, and supports controlled key rotation, thus enhancing the security posture of Layer 2 traffic protection.

Guidelines for MACsec FIPS-POST and KAT

Expect boot-up delays

Expect a boot-up delay of approximately 2 to 3 minutes for a line card when you enable Known Answer Test (KAT) compared to when it is not enabled.

Prevent configuration conflicts

Ensure that if Power-On Self-Test (POST) Known Answer Test (KAT) is already enabled on the PHY, you do not configure the hw-module macsec-fips-post location all command again. This prevents configuration conflicts, especially during a configuration restore. Use the show hw-module macsec-mode fips-post command to view the current running configurations in such scenarios.

Enable Power-on Self-Test KAT for MACsec FIPS cards

Ensure MACsec FIPS line cards on routers conduct Power-on Self-Test Known Answer Tests (KAT) to verify cryptographic integrity and support FIPS compliance.

This task is essential when deploying or maintaining routers with MACsec FIPS line cards to confirm hardware cryptographic integrity.

KAT is not enabled by default. You can configure the `hw-module macsec-fips-post` command to enable POST KAT for the MACsec-enabled hardware. With this configuration, the KAT always runs as a self-test during power on. The cryptographic algorithm tests are performed on every physical layer chip (PHY) with hardware crypto once it is powered up.

Pass criteria for KAT: Any change in the FIPS mode configuration requires a line card reload. On reload, the FIPS POST is run as part of the line card boot sequence. The subsequent boot (based on the FIPS mode) state re-triggers the KAT. If there are multiple PHYs hardware in a module, the system performs the KAT on each PHY and returns the KAT results. If all PHYs pass the KAT, the system brings up the line card for regular usage.
Fail criteria for KAT: Traffic does not pass through a MACsec-enabled PID that failed KAT. If any PHY registers a KAT failure, the module enters an ERROR state and the system displays a critical ERROR SYSLOG output: KAT Test Failed. The system does not allow any traffic or data flow through the interfaces on that line card. Although the interfaces are present, they do not come up or allow traffic to flow through them on a line card that failed KAT. In a modular chassis, all other line cards, except the one that failed the KAT, will be up and running.

Before you begin

Install the k9sec package on the router.
Confirm that FIPS is supported and enabled on the line card.

Follow these steps to enable and verify Power-on Self-Test KAT for MACsec FIPS cards:

Procedure

Use the hw-module macsec-fips-post command to configure the Power-on Self-Test KAT on the desired line card.

Example:


Router#config
Router(config)#hw-module macsec-fips-post location 0/4/CPU0
Router(config)#commit

Use the show hw-module macsec-fips-post command to verify the Power-on Self-Test KAT on a line card.

Example:

Before configuring POST KAT:


Router#show hw-module macsec-fips-post 
Wed Jun 17 09:29:18.780 UTC
 
Location       Configured     Applied          Action         
-------------------------------------------------------------
0/0/CPU0       NO             NO               NONE          >>> LC36     
0/11/CPU0      NO             NO               NONE          >>> LC48

After configuring the command for POST KAT, and before the line card reload:


Router#show hw-module macsec-fips-post 
Wed Jun 17 09:36:31.932 UTC
 
Location       Configured     Applied          Action         
-------------------------------------------------------------
0/0/CPU0       NO             NO               NONE           
0/11/CPU0      YES            NO               RELOAD

After the line card reload:



Router#show hw-module macsec-fips-post 
Wed Jun 17 10:03:57.263 UTC
 
Location       Configured     Applied          Action         
-------------------------------------------------------------
0/0/CPU0       NO             NO               NONE           
0/11/CPU0      YES            YES              NONE

Review system logs to verify results for KAT execution on each port.

Example:

These are sample logs displayed after a successful KAT. The system performs KAT on each port, but the ports may not be in order in the display output.


Router#show logging | inc KAT
Wed Jun 10 12:07:29.849 UTC
LC/0/4/CPU0:Jun 9 10:37:37.521 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 0
LC/0/4/CPU0:Jun 9 10:37:37.522 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 28
LC/0/4/CPU0:Jun 9 10:37:37.522 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 27
LC/0/4/CPU0:Jun 9 10:37:37.522 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 1
LC/0/4/CPU0:Jun 9 10:39:10.393 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 2
LC/0/4/CPU0:Jun 9 10:39:10.393 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 6
LC/0/4/CPU0:Jun 9 10:39:10.393 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 7
LC/0/4/CPU0:Jun 9 10:39:10.393 UTC: optics_driver[159]: %L2-SECY_DRIVER-6-KAT_PASS : KAT Test PASSED for Port No: 8

These are sample logs displayed in KAT failure scenarios:


Router#show logging | inc SECY
Thu Jul 16 09:13:29.217 UTC
LC/0/7/CPU0:Jul 16 08:41:30.709 UTC: optics_driver[152]: %L2-SECY_DRIVER-0-KAT_FAIL_DETECTED : KAT Test FAILED for Port No: 0 
LC/0/7/CPU0:Jul 16 08:41:30.709 UTC: optics_driver[152]: %L2-SECY_DRIVER-0-KAT_FAIL_DETECTED : KAT Test FAILED for Port No: 47 
LC/0/7/CPU0:Jul 16 08:41:30.709 UTC: optics_driver[152]: %L2-SECY_DRIVER-0-KAT_FAIL_DETECTED : KAT Test FAILED for Port No: 7 
LC/0/7/CPU0:Jul 16 08:41:30.709 UTC: optics_driver[152]: %L2-SECY_DRIVER-0-KAT_FAIL_DETECTED : KAT Test FAILED for Port No: 6

MACsec FIPS line cards run Power-on Self-Test KAT upon reload. Successful PASS results are logged for each port; failures are flagged for further troubleshooting.

What to do next

If any port reports KAT FAIL, investigate and resolve hardware or configuration issues before continuing with production use.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.