CliDeck
PlatformLog in
Workspace

Cisco Nexus Secure Erase for Resale: What to Verify Before Shipping

ITAD & Refurbishment
#cisco-nexus#secure-erase#factory-reset#itad#network-device-wipe#nx-os#ITAD & Refurbishment#network-device-processing
← Back to Blog

Short answer

For an authorized Cisco Nexus resale wipe, do more than write erase: use the secure erase or factory-reset workflow appropriate to the exact device, keep console power stable, and verify that former configuration, logs, boot variables, and customer identifiers are gone.

When This Applies

This checklist fits ITAD, refurbish, and resale benches that receive used Cisco Nexus switches and need a clean, documented state before shipment.

Use it when:

  • The device is owned by your company or covered by a customer work order.
  • You can access the serial console or the switch CLI.
  • You need proof that customer-specific data is removed before resale, return, parts harvesting, or reimage.
  • You must decide whether to preserve the installed NX-OS image or reinstall from known media.
  • You need an operator-friendly record: model, serial, software version, wipe method, transcript, and pass/fail result.

Do not use it when:

  • The device is not yours or the work order does not authorize reset or data removal.
  • The switch is still connected to a production fabric that can push configuration back.
  • You cannot keep power stable for a long erase or reimage operation.
  • You do not have the software image, license handling plan, or console access needed to recover from loader mode.

Pre-Erase Intake Checklist

Before starting any destructive command, capture enough information to identify the asset and rebuild the resale record later.

  • Photograph the front, rear, serial label, port damage, fan direction, PSU layout, and any asset tags.
  • Record model, PID, VID, serial, installed modules, power supplies, fans, and airflow direction.
  • Capture the current boot state: CLI, loader prompt, boot mode, boot image, or boot failure.
  • Capture software identity with show version when the CLI is available.
  • Capture hardware inventory with show inventory.
  • Capture basic health with show module, show environment, and show diagnostic result module all where supported.
  • Record whether the switch is standalone, a line card, a FEX-related unit, or part of an ACI fabric.
  • Confirm whether the resale workflow requires preserving the NX-OS image or fully wiping storage and reinstalling.

Suggested intake commands:

terminal session-timeout 0
show version
show inventory
show module
show environment
show diagnostic result module all
dir bootflash:
dir logflash:
show boot
show running-config
show startup-config

If credentials are not available but the work order authorizes reset, document that condition in the asset record and move to the approved console recovery or wipe path for that model. Do not present the work as password bypass; present it as authorized decommissioning.

Pick The Correct Wipe Path

Cisco Nexus platforms are not one uniform target. The safe path depends on the release, storage type, supervisor or module layout, and whether the device is running standalone NX-OS or ACI mode.

Use this decision path:

  1. If the switch supports the modern Secure Erase factory-reset command, use that path for resale wipe work.
  2. If the switch is ACI-attached, decommission or physically isolate it first so old fabric configuration is not pushed back after the wipe.
  3. If the platform supports preserve-image, decide whether your policy allows preserving the current NX-OS image. For many refurbish benches this is faster; for stricter sanitization policies, reinstall from known media instead.
  4. If the switch is an older Nexus release without the modern command, use the documented boot-mode init system style workflow only when you have console access, a known-good image, and a recovery plan.
  5. If only write erase is available, treat it as startup-configuration cleanup, not complete secure erase proof.

Modern Secure Erase Path

On supported Nexus 9000 releases, the secure erase path is built around factory-reset. Confirm the exact syntax and option order with command help on the device before execution because options vary by release, mode, FEX support, and module type.

Common release-dependent patterns include:

terminal session-timeout 0
configure terminal
factory-reset
factory-reset module 1
factory-reset all
factory-reset preserve-image

Use preserve-image only when the resale process accepts retaining the current boot image. Without image preservation, be prepared for loader recovery or image reinstall after the erase. On modular systems, erase order and module state matter, so treat line cards, supervisors, fabric modules, and FEX units as separate work items.

During the erase:

  • Do not power cycle the switch.
  • Keep the console transcript running.
  • Record each destructive confirmation prompt.
  • Record whether the device reboots, powers down, or returns to loader.
  • Record elapsed time and any failure message.

A clean result is not just command completion. The evidence must show the device returned to a clean boot path and no customer-specific configuration or logs remain visible.

Older NX-OS Boot-Mode Path

For older Nexus devices, especially units that do not expose the modern Secure Erase command, a boot-mode init system workflow may be the appropriate bench path. This is destructive and can remove the image from bootflash, so only run it when the operator has console access and a known-good NX-OS image available.

Typical recovery flow:

loader > boot usb1:nxos.<version>.bin
switch(boot)# init system
switch(boot)# format logflash:
switch(boot)# reload

After the switch boots, rebuild only the minimum boot setting needed for resale verification:

show version
show inventory
dir bootflash:
configure terminal
boot nxos bootflash:nxos.<version>.bin
end
copy running-config startup-config

If copy running-config startup-config fails because the system is not ready, do not force the shipment. Wait for the boot process to settle, check storage, and rerun verification. A switch that has booted once is not automatically ready for resale.

Field Note From A Nexus 9000 Bench Run

On a Nexus9000 C9372TX running NX-OS 7.0(3)I7(4), our console transcript showed the older boot-mode pattern clearly. From switch(boot)#, init system warned that it would erase startup configuration, licenses, and bootflash. The run then formatted cfg0:, cfg1:, pss:, plog:, bootflash:, and logflash:, reset CMOS defaults, reinitialized NVRAM, and completed initialization. We then ran format logflash: explicitly and reloaded.

Post-boot verification on the same unit showed BIOS 07.59, NX-OS 7.0(3)I7(4), image bootflash:///nxos.7.0.3.I7.4.bin, chassis N9K-C9372TX, and sanitized processor board ID FDO20231SFN. The transcript also showed why write erase is not enough for resale proof: later in the run, write erase only warned that it would erase the startup configuration.

For grading, we kept the diagnostic result in the evidence record. show diagnostic result module all showed USB and OBFL passing, while several tests were still marked U immediately after boot. That is a retest queue, not proof of a failed wipe and not proof of a completed resale check.

What To Verify Before Shipping

After the wipe or factory reset, verify four things: clean state, usable boot, hardware identity, and evidence quality.

Clean state checks:

  • show running-config does not contain customer hostnames, usernames, SNMP communities, AAA servers, RADIUS or TACACS entries, NTP servers, logging targets, banners, crypto material, management VRFs, old VLAN names, or fabric-specific remnants.
  • show startup-config is empty, default, or contains only the minimal clean boot configuration your process intentionally wrote.
  • dir bootflash: contains only expected images and files.
  • dir logflash: does not retain old operational logs when logflash was in scope for wipe.
  • No old POAP, guestshell, scripts, crash files, tech-support archives, or copied configs remain unless intentionally retained for internal quarantine review.

Boot checks:

  • show version reports the expected NX-OS image and uptime after reset.
  • show boot or the equivalent boot variable check points to the intended image.
  • The device can reload once and return to the expected prompt without manual intervention.
  • If the unit lands in loader, that outcome is documented and the unit is not shipped as ready until reimaged.

Hardware checks:

  • show inventory matches the physical chassis label and resale listing.
  • show module shows expected modules and status.
  • show environment shows fans, PSUs, and temperature sensors in acceptable state.
  • show diagnostic result module all has no unresolved fail result that affects resale grading.

Evidence checks:

  • Save the full console transcript.
  • Save the method used: factory-reset, factory-reset preserve-image, init system, format logflash:, reimage, or exception path.
  • Save model, sanitized serial in public materials, real serial in private asset record, NX-OS version, operator, timestamp, and pass/fail result.
  • Save photos before and after processing.
  • Save any exception notes separately from the clean-sale record.

Common Mistakes

The most common mistake is treating write erase as a full secure erase. It is useful for clearing startup configuration, but it does not prove that logs, bootflash contents, operational history, guest shell artifacts, copied configs, or storage partitions were sanitized.

Another mistake is using preserve-image without a policy decision. Preserving the image may be correct when you need a fast resale-ready unit, but it is not the same as removing every file from bootflash and reinstalling from controlled media.

A third mistake is skipping post-reset diagnostic capture. A switch can be clean and still not saleable. Fan direction, PSU health, module status, and boot diagnostics matter to buyers and to your internal grading.

CliDeck Workflow Angle

This is the kind of process CliDeck is built to make repeatable. A technician should not have to remember which Nexus family needs which reset path while also managing a serial console, confirmation prompts, screenshots, and evidence files.

A CliDeck-ready Nexus workflow should:

  • Start a console transcript before the first destructive command.
  • Prompt the operator to capture model, serial, NX-OS version, boot image, and photos.
  • Select the correct reset path based on model, release, and available command help.
  • Pause before destructive prompts so the operator can confirm ownership and work-order scope.
  • Capture post-reset show version, show inventory, show environment, and storage checks.
  • Produce a pass/fail resale record with exceptions, not just a terminal log.

That evidence record is what makes the difference between a switch that merely rebooted and a switch that is ready to ship.

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.

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