System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

PDF

System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

Consent tokens

Updated: September 18, 2026

Want to summarize with AI?

Log in

Explains how Cisco-signed and customer-signed consent tokens authorize restricted router actions through time-limited, device-specific, single-use challenge-response workflows.

Consent tokens are security tokens that

  • are signed by Cisco and used to enable or disable restricted router actions

  • are associated with a particular device and must be used within a defined time window, and

  • can be used only once.

Cisco verifies that the user requesting a consent token is the legitimate device owner before issuing the token.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

Customer consent token configuration

Release 26.1.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q100, Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8600 [ASIC:Q200]) ; Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

This feature allows you to enable the customer consent token workflow so that the key name is linked to the key package.

The feature introduces these changes:

CLI: consent-token customer

Use this reference to select the consent-token workflow for a restricted router operation.

An owner token or customer consent token functions similarly to a consent token. A Cisco-signed token is signed by Cisco. An owner token or customer consent token is signed by a customer key rooted in the customer's OC.

Customer-signed tokens allow customers to control who is authorized to perform restricted actions and enforce stricter authentication requirements. They can be used only when the customer has installed an OV/OC.

Consent tokens are used when you disable secure ZTP or enable or disable lawful intercept. Customer consent tokens are also used to clear device ownership.

Consent tokens use a challenge-response process. The challenge string generated on the router is valid for a defined time interval.

Summary

The Cisco-signed workflow involves these actors:

  • The router generates a challenge containing the device ID, nonce, and requested action.

  • The Cisco TAC engineer verifies the requester and signs a response.

  • The router validates the signature and matching device ID and nonce.

If you use Cisco's consent-token workflow, contact Cisco TAC for every request to enable or disable certain privileged operations.

Workflow

These are the stages used to provision a Cisco-signed consent token:

  1. Generate the challenge string on the router.

  2. Submit the challenge to Cisco TAC. After verifying device ownership and authorization, a TAC engineer returns a signed response.

  3. The router validates the signature, device ID, and nonce, then enables or disables the requested feature.

Result

The requested restricted feature is enabled or disabled after the signed response is validated.

Enable or disable a restricted router feature by using the Cisco-signed consent-token workflow.

The challenge string generated on the router is valid for a defined time interval. The response must be provided within that interval.

Contact Cisco TAC for every request to enable or disable certain privileged operations.

Before you begin

  • Identify the supported security feature for which you need a consent token.

  • Have access to Cisco TAC to submit the challenge and receive the signed response.

Procedure

  1. Generate the challenge string on the router.

    Example:

    Router# request consent-token generate-challenge feature

    feature can be any supported security feature, such as secure-ztp, lawful-intercept, or factory-reset.

  2. Submit the challenge string to a Cisco TAC engineer.

    Example:

    Cisco verifies that the requester is the legitimate device owner and is authorized for the requested action. When the request is verified, the TAC engineer provides a signed response string.

  3. Accept the signed response on the router.

    Example:

    Paste the response string provided by the TAC engineer when prompted.

    Router# request consent-token accept-response

  4. Confirm that the requested feature is enabled or disabled.

    Example:

    The router validates the signature and confirms that the device ID and nonce match its records.

    The requested feature is enabled or disabled after the signed response is validated.

The requested restricted feature is enabled or disabled after the Cisco-signed consent-token response is accepted.

This process sets up a server on your premises to handle customer consent-token challenge responses.

Summary

The customer workflow uses customer keys, a key package, the consent-token configuration, and a signing server.

Workflow

Figure 1. Workflow for the consent token server

These are the stages involved in provisioning customer consent tokens:

  1. Generate customer consent-token keys by using the OpenSSL commands.

  2. Onboard the customer consent-token keys on the router by using key packages.

  3. Enable the customer consent token to link the key name with the key package.

    Enter these commands on the router:

    Router# configure

    Router(config)# consent-token customer cert-name CT_KEY key-name key1 product-name prod1

    Router(config)# commit

    cert-name indicates the consent-token certificate added through a key package. key-name indicates the consent-token key, and product-name indicates the product name for the consent token.

  4. Set up the consent-token server on your premises using the sample ct_sim.py script available at GitHub.

  5. Generate the challenge for a feature that supports the customer consent-token workflow.

  6. Sign the challenge string using the consent-token signing server. The server parses the challenge, verifies the checksum, and computes the signature using the key fetched from the Hardware Security Module (HSM).

  7. Accept the response generated by the consent-token signing server.

    The requested feature is enabled or disabled.