CliDeck
PlatformLog in
Workspace

Cisco Firepower FTD Reimage for Asset Recovery: Console, TFTP, and Evidence Checklist

ITAD & Refurbishment
#cisco-firepower#ftd#reimage#itad#network-device-wipe#serial-console#ITAD & Refurbishment#network-device-processing
← Back to Blog

Short answer

For an authorized Cisco Firepower appliance, reimage FTD when a normal configuration wipe does not provide a dependable clean starting point. Capture the current state, stage the correct local recovery image, complete the approved console workflow, and verify the device after installation before closing the asset record.

When this applies

Use this workflow for ITAD, refurbish, RMA prep, or resale benches when one of these is true:

  • The Firepower unit is locked, misconfigured, or stuck between ASA and FTD roles.
  • You need a clean FTD baseline instead of preserving a previous customer configuration.
  • The device has unclear boot variables, old logical-device state, or failed upgrade remnants.
  • A simple configuration erase does not provide enough confidence for resale.
  • The asset record needs transcript evidence showing what was installed and how the result was verified.

For Firepower 2100 and similar platforms, expect the exact workflow to vary by model, release, and whether the appliance is running in appliance mode or platform mode. The safe operator habit is to identify the current mode first, then choose the matching reimage path.

Intake checklist before you reimage

Capture these fields before you change the device:

  • Front and rear photos, including ports, labels, damage, and installed modules.
  • Model, PID, serial, software version, and current boot state.
  • Current role: ASA, FTD, FXOS platform mode, appliance mode, or failed boot.
  • Console speed and access method.
  • Whether the unit has a management IP configured, but do not preserve the previous customer network.
  • Which local transfer method will be used: TFTP, FTP, SCP, SFTP, SMB, HTTP(S), or USB, depending on model support.
  • Image filename, expected version, file size, and checksum when available.
  • Operator, timestamp, bench ID, and reason for reimage.

If the intake cannot establish legal ownership or processing authorization, stop. Do not continue into password recovery, image install, or configuration access.

Console and transfer-server preparation

Use a local isolated bench network. A simple pattern is a laptop or bench server at 192.168.10.10, the firewall management interface on the same isolated VLAN, and a serial console transcript recording from power-on through final verification.

A practical preflight looks like this:

1. Confirm console capture is running.
2. Confirm the exact appliance family and current software state.
3. Put the image on a local transfer server or approved USB media.
4. Verify filename and checksum before the install.
5. Confirm there is no production network path attached to the unit.
6. Record the planned target version in the asset record.

For a TFTP bench, keep filenames short and obvious. For larger images, SCP or another reliable transfer method is often cleaner when the platform supports it. The article title includes TFTP because technicians search for it, but the correct answer is to use the transfer method your exact Firepower release supports and your bench can verify.

Firepower 2100 style FXOS install pattern

On Firepower platforms that use FXOS for image handling, the operator workflow usually has three phases: download the image, confirm the package is available, then run the install. A typical checklist-shaped command pattern is:

connect fxos
scope firmware
download image tftp://192.168.10.10/<ftd-image>.SPA
show download-task
show download-task detail
show package
scope auto-install
install security-pack version <target-version>

Do not paste this blindly into every unit. Treat it as a pattern to validate against the active prompt and platform generation. Some devices use SCP, FTP, SFTP, SMB, HTTP(S), or USB instead of TFTP. Some releases expose different prompt paths. The pass signal is not that the command was accepted; the pass signal is that the package is present, the install finishes, the appliance reboots cleanly, and post-boot verification shows the expected clean FTD state.

Clean-state install and reset evidence

During the install, record the moments that prove the work happened:

  • Image download started and completed.
  • Package was visible before install.
  • Install command was accepted for the intended target version.
  • The console showed that configuration would be erased as part of the install path.
  • The appliance rebooted or restarted the logical device.
  • FTD startup completed without returning to the previous environment.
  • Final version and inventory commands match the asset record.

If the platform asks for confirmation that configuration will be erased, make that line part of the evidence transcript. It is one of the strongest resale proof points because it ties the reimage to configuration removal, not only software replacement.

Field note from Firepower bench logs

Field note: In our Firepower bench transcripts, we saw two useful proof patterns. On a Firepower 2100-family FTD run, the asset showed the image name cisco-ftd-fp2k.6.2.3-83.SPA, then the console reported Cisco FTD installation finished successfully and later Cisco FTD started successfully. In a separate Firepower 4110 recovery transcript, the FXOS path reached connect local-mgmt, accepted erase configuration, and show chassis detail verified a Firepower 4110 security appliance. The public evidence record should keep those success phrases, model family, and target version, but it should sanitize serials and omit private log paths.

That bench behavior is why we treat FTD reimage as an evidence workflow, not only an install task. The technician needs enough transcript detail to prove a clean state to a buyer, auditor, or internal QA reviewer.

What to verify after the reimage

After the first clean boot, run verification before the unit leaves the bench:

  • Confirm the expected FTD or platform prompt appears.
  • Confirm the software version matches the target image.
  • Confirm the prior hostname, customer objects, VPN names, routes, users, certificates, and management settings are not visible.
  • Confirm model, PID, and sanitized serial in the asset record.
  • Confirm interfaces are present and no unexpected module fault is hidden by the reset.
  • Confirm boot variables or package references do not point to the previous image by mistake.
  • Save the console transcript and attach the final pass/fail result.

A good resale record does not need the entire raw console dump. It needs enough structured proof to answer three questions: what arrived, what was done, and what clean state was verified.

Common mistakes to avoid

Do not publish or preserve the previous customer configuration. Do not leave a management IP from the old network in the final listing. Do not assume that a successful image copy equals a successful reimage. Do not ship a unit that boots but still has old logical-device metadata, old management access, or a hidden package mismatch.

Also avoid mixing role changes and resale claims without a transcript. If a unit was converted from ASA to FTD, or from FTD back to ASA, the asset record should say that plainly. Buyers care about the current clean boot state and the image installed, not only the chassis model.

CliDeck workflow angle

CliDeck fits this bench process by turning the console session into a repeatable operator runbook. A technician can run the same intake prompts, capture the install transcript, mark the local image used, collect model/version proof, and close the asset only when the verification checklist passes.

For resale teams, that matters because the work is repetitive and easy to under-document. The reset itself is only one part of the job. The durable value is a clean device plus evidence that the clean state was actually reached.

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