CliDeck
PlatformLog in
Workspace

FortiGate TAC Report Before Wipe: What to Capture for Refurbish Grading

ITAD & Refurbishment
#fortigate#tac-report#itad#network-device-wipe#diagnostics#ITAD & Refurbishment#network-device-processing
← Back to Blog

Short answer

Before an authorized FortiGate wipe, collect the console transcript, identity, hardware, storage, interfaces, log state, and a TAC report when the device is stable enough. The TAC report is pre-wipe grading evidence, not a reset method, so keep it privately before the reset removes useful context.

When This Applies

Use this checklist when a FortiGate or FortiWiFi unit arrives on an ITAD bench and you need a defensible record before clearing prior-owner configuration.

It is useful for:

  • resale intake
  • refurbish grading
  • exception review before wipe
  • evidence records for customer returns
  • determining whether the unit needs firmware recovery instead of a normal reset

Do not spend time collecting a large diagnostic report if the unit is unstable, repeatedly rebooting, or exposing sensitive customer data that your process says must be wiped immediately. In those cases, capture the minimum identity and failure proof, then move to reset, reimage, or quarantine.

Pre-Wipe Intake Checklist

Capture these fields before the wipe so the reset record can be tied back to the physical unit:

  • model family and front-panel photos
  • serial number from chassis label and console boot output
  • firmware train or boot version shown during startup
  • access method used: console, management interface, or boot menu
  • boot partition or backup firmware note if visible
  • disk or storage state if the device reports it
  • power supply and fan status where commands are available
  • whether local logs are present
  • whether configuration appears customer-specific
  • operator, timestamp, bench station, and asset ID

The important part is sequence. Capture first, wipe second, verify third. A clean device with no proof trail is weaker than a clean device with a transcript that shows what was checked.

Command Workflow

Start console logging before you run diagnostic commands. A TAC report can produce a large amount of output, so use a terminal profile that does not truncate scrollback.

execute tac report

For a resale bench, pair the TAC report with short, targeted commands. A practical pre-wipe capture can include:

get system status
diagnose hardware deviceinfo disk
diagnose hardware deviceinfo nic
diagnose hardware deviceinfo psu
diagnose hardware test info
execute log filter dump
execute log display

Not every FortiGate model supports every diagnostic command. If a command returns that an object is not available, keep that result in the transcript. For grading, a clean unsupported response is better than hiding the attempt.

What The TAC Report Is Good For

A TAC report is useful because it gathers a broad diagnostic snapshot before the device is changed. For ITAD, that means it can help answer questions such as:

  • Did the unit boot normally before reset?
  • Which firmware or boot image was active?
  • Were storage partitions visible?
  • Were interfaces detected?
  • Were local logs present before wipe?
  • Did the device show hardware errors before resale processing?

Do not publish the raw report in a customer-facing listing. It can contain configuration, names, addresses, VPN details, and other customer data. Store it in the internal asset record, restrict access, and attach a sanitized pass/fail summary to the resale workflow.

Bench Note

On a FortiGate-300E running boot version Ver:05000007, we captured a console transcript before the final reset. The unit reported a 14.9GiB boot SSD, listed 34 network interfaces through the NIC inventory command, and returned Log disk is not available when execute formatlogdisk was tested. That combination told us to record the storage exception instead of treating missing log-disk formatting as a failed wipe. The public serial in our resale record was sanitized as FG3H0E5818900262.

What To Avoid Before Resale

Do not rely on a TAC report as proof that data was removed. It is diagnostic evidence, not sanitization evidence.

Avoid these mistakes:

  • running diagnostics after reset and calling them pre-wipe evidence
  • storing raw reports where sales or listing staff can access customer data
  • keeping unredacted VPN, user, route, certificate, or license details in screenshots
  • skipping console output because the GUI is reachable
  • resetting first and trying to reconstruct hardware condition afterward

Wipe And Verification Sequence

After the diagnostic capture is complete, move to the approved reset path for the model and access state. For a normal CLI-accessible unit, the reset step is usually:

execute factoryreset

Then verify clean state after reboot:

  • device returns to default login/setup state
  • hostname and visible configuration do not show the prior owner
  • local logs are cleared or documented as unavailable
  • management interfaces are default or intentionally staged for bench access
  • firmware is recorded as unchanged unless a reimage was performed
  • serial in the asset record matches the physical label, with public listings using sanitized or internal-only serial handling as required

CliDeck Workflow Fit

CliDeck is useful here because the task is repetitive and evidence-heavy. A bench script can start the console transcript, run the diagnostic checklist, stop when a command is unsupported, prompt the operator for photos, and attach the proof bundle to the asset record before allowing the reset step.

For resale teams, that reduces the two common failure modes: wiping a unit with no diagnostic proof, and collecting a diagnostic bundle that nobody can tie back to the physical device.

Final Pass Criteria

Mark the FortiGate as ready for reset only when the asset record has:

  • model and sanitized serial handling complete
  • boot and firmware state captured
  • diagnostic output captured or exception documented
  • sensitive raw report stored internally, not publicly
  • reset method selected
  • post-reset verification checklist queued

A FortiGate is ready for resale only after the later clean-state check passes. Pre-wipe diagnostics are the start of the proof chain, not the end.

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.

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