CliDeck
PlatformLog in
Workspace

Cisco Catalyst 9200/9300 Factory Reset for ITAD: Secure Wipe and Proof Checklist

ITAD & Refurbishment
#cisco-catalyst#factory-reset#itad#network-device-wipe#serial-console#ITAD & Refurbishment#network-device-processing#network-operations
← Back to Blog

Short answer

For an authorized Cisco Catalyst 9200 or 9300 resale reset, choose the normal or secure wipe path at intake, keep the console transcript, and verify the switch after reload. A secure option can remove boot variables and images, so have the recovery path ready before starting.

When this applies

Use this checklist when all of these are true:

  • The switch is owned by your company or your customer has authorized the reset.
  • The unit is in an ITAD, refurbish, redeployment, RMA, or resale-prep workflow.
  • The operator has physical bench access or authorized console access.
  • The job goal is to remove customer-specific configuration and prove a clean state.
  • The team has a written exception path for units that do not boot, are locked, are stacked incorrectly, or need image recovery.

Do not use this process on a device you do not own or administer. If the switch is under legal hold, incident investigation, customer dispute, or managed-service retention, stop and follow that chain of custody instead.

Pre-reset intake checklist

Before any wipe command, collect enough detail to prove what was processed.

  • Photograph the front, rear, serial label, asset tag, and visible damage.
  • Record model, serial number, asset ID, customer batch, operator, date, and bench station.
  • Note whether the unit is standalone or part of a stack.
  • Record power-on behavior, LEDs, fan status, power supply status, and obvious port damage.
  • Capture console access from first boot prompt where possible.
  • Record the running software version and boot mode if the device reaches IOS XE.
  • Record license state only as needed for resale grading.
  • Confirm whether the job requires diagnostic capture before wipe.
  • Confirm whether the job requires a normal factory reset or a stronger secure wipe.
  • Confirm whether your bench has the expected IOS XE image available if the reset removes the boot image.

Useful intake commands when the switch is reachable:

show version
show inventory
show switch
show license summary
show environment all
dir flash:
show boot

Some teams also capture show tech-support, but that output can contain customer-specific names, addresses, logs, interface descriptions, and operational history. If your contract does not require keeping it, do not keep it. If you do keep it, store it as sensitive evidence and do not mix it into a general refurbish folder.

Pick the reset path

For resale, the default decision is usually between a normal factory reset and a secure wipe.

A normal reset is useful when the unit needs to be returned to a factory-like configuration state and the next step is internal redeployment, testing, or controlled resale. It is faster and fits high-throughput benches, but the technician still needs to verify what was removed.

A secure wipe is the better fit when the intake contract, customer policy, or resale standard requires stronger media sanitization. It can take longer and may require more recovery work afterward. Do not choose it five minutes before a shipping cutoff. Choose it at intake, document it, and make sure the image recovery path is ready.

For stacked devices, slow down. A stack can hide member identity mistakes. Record every member, serial, and switch number before reset. If the plan is to wipe the whole stack, verify that every member was included. If the plan is to wipe only one member, record why and keep that unit isolated afterward.

Standalone switch reset workflow

Use this shape for a standalone Catalyst 9200 or 9300 that is reachable from console and approved for wipe.

  1. Connect the console cable and start transcript capture.
  2. Confirm the asset label against the intake record.
  3. Run the intake commands needed for grading.
  4. Confirm the selected reset method with the work order.
  5. Run the approved reset command.
  6. Keep the console connected through reload or ROMMON.
  7. Record the first prompt after reset.
  8. If the switch lands in ROMMON, follow your bench image recovery procedure instead of improvising.
  9. After the device boots, run clean-state verification.
  10. Attach transcript and result to the asset record.

For a normal reset, the command commonly starts here:

Device# factory-reset all

For a stronger wipe, use the secure option only when your procedure calls for it and the switch supports it:

Device# factory-reset all secure
Device# factory-reset all secure 3-pass

The exact prompt and confirmation text can vary by software release. The operator should not paste reset commands blindly. Read the prompt, confirm the correct asset, and keep the transcript.

Stack wipe notes

Catalyst stack work needs an extra layer of control because the physical unit, stack member number, and resale asset record can drift apart.

Before reset:

  • Record show switch output.
  • Match every member to a serial number and asset label.
  • Decide whether the whole stack or one member is being processed.
  • Label units before disconnecting stack cables.
  • Confirm that the work order covers every member being wiped.

A stack workflow may use command forms that target the stack or a specific member. The important resale rule is not the syntax; it is the evidence. A clean record should show which member was targeted, how it was identified, what reset path was used, and what the post-reset result looked like.

If one member fails reset or boot recovery, do not ship the rest of the stack as a clean set until the exception is resolved. Split the batch, mark the failed unit, and keep the transcript.

Image and ROMMON handling

Factory reset can remove more than startup configuration. Depending on the option used, it can clear boot variables, remove local images, clear logs and user data, and leave the device needing a ROMMON reset or image recovery.

That is not a failure if it was planned. It is a failure if the unit reaches the shipping table with no boot proof.

Your bench should have a written recovery path that covers:

  • Expected console speed.
  • How to confirm ROMMON state.
  • Where approved IOS XE images are stored.
  • How image files are named in the asset record.
  • Who is allowed to load software onto resale units.
  • How to record the final booted version.

Do not use random images from old folders. A refurbish process needs controlled software inventory.

Post-reset verification checklist

After reset or recovery, verify the switch before it leaves the bench.

  • Device boots without a reload loop.
  • Console prompt is reachable.
  • Startup configuration is absent or factory-default.
  • Prior hostname is gone.
  • Prior local users are gone.
  • Prior banners, interface descriptions, VLAN names, routing configuration, SNMP strings, AAA servers, certificates, and keys are not visible in the active configuration.
  • Boot variables are in the expected state for the resale procedure.
  • Software version is recorded.
  • Stack member identity is recorded if the unit was part of a stack.
  • License or entitlement state is recorded only as required for grading.
  • Transcript is saved with the asset record.
  • Operator, timestamp, reset method, and pass/fail result are recorded.

A clean prompt is not enough. A clean resale record needs the reset method and verification proof.

Exception handling

Not every switch should move straight through the normal lane.

Send the unit to exception handling when:

  • The serial number does not match the intake record.
  • The switch does not boot far enough for identification.
  • Console is unreadable after speed checks.
  • The unit is stuck in ROMMON and the image process is not available.
  • A stack member cannot be matched to a physical label.
  • The reset command is rejected.
  • Previous customer identifiers remain visible after reset.
  • The unit has damaged ports, failed fans, failed power supplies, or thermal warnings.

Exception handling protects the resale team. It also protects the customer record. A failed reset should not be hidden inside a successful batch.

CliDeck bench workflow

A repeatable CliDeck workflow for Catalyst resale prep can be simple:

  1. Scan the asset ID.
  2. Open the serial console session.
  3. Capture intake commands and transcript.
  4. Select normal reset or secure wipe from the work order.
  5. Run the reset under operator confirmation.
  6. Capture reload, ROMMON, or first boot state.
  7. Run post-reset verification.
  8. Save transcript, method, operator, timestamp, and exception notes.

That turns a destructive command into a controlled production step. The value is not only that the switch was reset. The value is that the team can prove which unit was reset, how it was reset, and what was verified afterward.

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.

Quick checklist

  • Identify the device and console connector
  • Use the correct console cable or adapter
  • Find the correct serial port or COM port
  • Start with the expected baud rate and 8N1 settings
  • Press Enter to confirm the prompt
  • If output is unreadable, check baud rate and line settings
  • If the port will not open, check permissions, drivers, and whether another program is holding the port
  • Save useful session notes or logs when the work matters

Traditional cable vs CliDeck workflow

A traditional USB serial cable is still the simplest option for quick local work. CliDeck becomes useful when the console session needs browser access, notes, runbooks, sharing, logs, remote hands support, or a portable controller workflow.

Console Server Go can work like a wired USB serial adapter when connected by USB, but it also adds SSH Console on SSH-enabled firmware builds, browser Workspace, live sharing, 24h+ battery operation, OLED status, and magnetic rack mounting.

Net Controller is the larger 12-port option for teams that need to process many network devices with approved workflows, barcode/API tracking, provisioning files, and evidence-style logs.

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