CliDeck
PlatformLog in
Workspace

Cisco IOS XE Smart Licensing at Decommission: A Separate Checklist from Factory Reset

ITAD & Refurbishment
#cisco-ios-xe#ITAD#refurbishment#verification#ITAD & Refurbishment#itad#network-device-processing#network-operations
← Back to Blog

Short answer

Before decommissioning an owned IOS XE device, identify its licensing model and coordinate license handling with the authorized Smart Account administrator. Capture read-only license state, satisfy any required usage reporting or authorization-return process, and only then apply the approved device-side cleanup. A configuration reset does not establish entitlement transfer, and a licensing reset is not a customer-data wipe.

Determine the licensing model before choosing a command

Classic Smart Licensing and Smart Licensing Using Policy have different workflows. The familiar license smart deregister command from older releases must not be treated as a universal cleanup command for every current Catalyst switch.

Scope this checklist to the exact platform, IOS XE version, and deployment. A standalone switch, stack, and high-availability pair can have different reporting and authorization scope. Do not copy licensing commands from IOS XR, a voice platform, or a different router family merely because the command names look familiar.

Capture inventory through authorized access

Use read-only commands supported by the running platform:

show version
show inventory
show license status
show license summary
show license all

Keep the output private. Inventory and license views can expose serials, account context, trust state, and entitlement details. Record the platform and software build beside the output so the licensing administrator can select the correct procedure.

If a command is unavailable, use the platform's command help and matching release guide. Do not make destructive changes to discover which licensing mode is active.

Assign the account-side work explicitly

The authorized administrator should determine whether usage must be synchronized, an authorization returned, a reservation handled, or the product instance retired from inventory. Air-gapped and reserved-license deployments require their corresponding offline workflows.

Record the decision, responsible person, completion evidence, and remaining obligations. A technician should not promise that a used switch includes transferable subscription rights simply because a license appeared in the original command output.

Understand the cleanup boundary

For applicable Catalyst Smart Licensing Using Policy deployments, the command family includes:

license smart factory reset

This is a destructive licensing operation intended for the approved decommission or return workflow. On the Catalyst 9300 IOS XE 17.9 path, it clears licensing information such as authorization codes and usage reports while retaining licenses in use. Required reporting and authorization handling must be resolved before removing those records. Use the exact release's instructions and any requested reload; do not run it as a routine troubleshooting shortcut.

Verification note: device cleanup and commercial rights are different outcomes

Verify the resulting device-side licensing state and separately confirm the authorized account-side disposition. Neither observation alone proves that another organization is entitled to use the same subscription.

For a stack, confirm the scope covers each member being shipped. If members are separated, preserve a reliable mapping from each physical unit to its licensing and sanitization record.

Finish configuration and data processing separately

Complete the Catalyst reset and wipe workflow appropriate to the platform. Inspect customer configuration, credentials, files, and boot behavior independently of licensing cleanup.

The final record should distinguish license handling complete, device configuration clean, hardware graded, and unresolved entitlement hold. CliDeck Workspace can preserve the console evidence and operator checklist while the authorized licensing system remains the source of account-side status.

Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.

Who this is for

This guide is for ITAD teams, refurbishment teams, network engineers, and operations teams who need to perform an owner-authorized reset, recovery, verification, or documented device-processing workflow on network devices that your team owns or is authorized to process.

When to use this

Use this guide when:

  • Your team owns or is authorized to process the device.
  • You need to reset, zeroize, recover, reimage, verify, or document a network device.
  • The result must be attached to an asset, resale, reuse, refurbishment, or recycling workflow.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • You need a certified data destruction procedure and your organization has not provided one.

Workflow

  • Confirm ownership, processing scope, device identity, and approved procedure.
  • Connect through the console or approved management path and capture the session context.
  • Run the reset, zeroize, recovery, reimage, or verification steps required by the article and vendor documentation.
  • Reboot or reconnect as needed and verify the expected clean, default, or recovered state.
  • Attach logs, verification output, exceptions, and final pass/fail/exception status to the asset record.

Verification checklist

  • Device identity matches the asset record.
  • Console or session log is attached to the asset.
  • The reset, zeroize, recovery, or reimage method is recorded.
  • The post-reboot state matches the expected clean or recovered state.
  • Verification commands and outputs are captured.
  • Exceptions or failures are quarantined instead of marked ready.

Resale and evidence checklist

Before marking the device ready for resale, capture:

  • Device model and serial number
  • Console transcript or session log
  • Reset, zeroize, reimage, or recovery method used
  • Any confirmation prompts and operator decisions
  • Post-reboot state
  • Visible default or clean-state prompt
  • Verification commands and outputs
  • Hardware alarms or boot errors
  • License, entitlement, or customer identifiers handled according to policy
  • Exceptions, failures, or quarantine decisions
  • Final pass/fail/exception status attached to the asset record

What not to publish

Do not publish raw transcripts that include customer names, public IP addresses, VPN settings, license keys, entitlement IDs, serial numbers that must remain private, passwords, tokens, certificates, or other sensitive identifiers. Keep sensitive evidence in the customer-approved internal system and publish only sanitized examples.

Common mistakes

  • Processing a device without owner authorization or the correct asset record.
  • Treating a factory reset as certified data destruction.
  • Failing to capture confirmation prompts, reboot state, verification output, or exceptions.
  • Publishing raw logs that contain customer identifiers, licenses, keys, passwords, or configuration remnants.

CliDeck workflow fit

CliDeck can help turn this procedure into a repeatable workflow. Console Server Go is useful for portable rack-side console access and shared remote support. Net Controller is better for ITAD, refurbishment, and batch processing where multiple devices need barcode tracking, approved scripts, logs, API updates, and evidence-style results.

Net Controller can help operators connect devices, scan assets, run approved workflows, capture console logs, require verification steps, and attach the result to the asset record.

FAQ

Is this a certified data destruction procedure?

No. This article describes a practical, owner-authorized workflow and verification approach. Certification depends on your organization’s process, evidence requirements, customer contract, and any formal certification program that applies.

Does CliDeck provide vendor OS images?

No. CliDeck does not distribute vendor operating system images. Recovery or reimage workflows can use images already present on the device or images provided by the customer where the customer has appropriate rights and licenses.

Should I publish the full console log?

Usually no. Keep complete evidence in the approved internal system and publish only sanitized examples. Console logs can contain serial numbers, license details, customer names, IP addresses, keys, passwords, or configuration remnants.

Can CliDeck help with this workflow?

Yes. Console Server Go helps with portable rack-side console access and shared remote support. Net Controller is better for batch ITAD, refurbishment, recovery, provisioning, barcode/API tracking, and evidence-style results.

Related guides