CliDeck
PlatformLog in
Workspace

FortiSwitch Factory Reset for ITAD: Console Capture and Verification Steps

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

Short answer

For an authorized FortiSwitch resale reset, capture the console session and asset state first, run the approved factory-reset path, then verify default login behavior and the absence of former management or FortiLink settings. The transcript and post-reset checks are the proof that the asset is ready for its next use.

When This Applies

Use this workflow when a FortiSwitch arrives at a bench as a standalone switch, a former FortiLink-managed switch, or a unit with unknown configuration that must be cleaned before resale.

It applies best when you have:

  • physical possession of the device
  • serial console access
  • authority to clear the configuration
  • a need to document the reset for a resale or return record

If the unit is still managed by a live FortiGate or customer network, isolate it before reset. A clean bench workflow should not send discovery, CAPWAP, or management traffic back into a customer environment.

Pre-Reset Capture Checklist

Before reset, capture:

  • model and physical condition photos
  • serial number from chassis and console boot output
  • FortiSwitchOS version shown during boot
  • management mode or FortiLink status
  • current interface configuration
  • hardware status and PoE firmware where available
  • visible log state
  • whether login forced a password change
  • reset method selected
  • operator, timestamp, and asset record ID

The goal is not to preserve customer configuration. The goal is to prove what you received and what you cleared.

Useful Intake Commands

On a console-accessible FortiSwitch, a compact intake script can use:

get hardware status
show system interface
execute switch-controller get-conn-status
execute log filter dump
execute log display

Some commands vary by FortiSwitchOS release and operating mode. If a command returns a parse error or an unsupported-object message, keep that response in the transcript and move to the next check.

Reset Command Path

For a standard configuration reset, use:

execute factoryreset

The expected workflow is a warning, an operator confirmation, a reset message, and a reboot. A full reset command may also exist on some FortiSwitchOS releases:

execute factoryresetfull

Treat the full reset path as a stronger option only after your internal process confirms it is appropriate for that model and software train. For ordinary resale prep, the key is not choosing the most destructive-looking command. The key is proving that the chosen reset path actually removed prior-owner configuration and that the device returned to an expected default state.

Bench Note

On a FortiSwitch-108E-FPOE running FortiSwitchOS v6.2.3, build0202, our console transcript showed both reset-button behavior and CLI reset behavior. Holding the mode button for more than 10 seconds triggered a factory-default reset message, and later execute factoryreset produced the confirmation prompt followed by System is resetting to factory default... and a reboot. The same transcript showed the switch had been in FortiLink mode, so the resale checklist required a separate post-reset management-state check. The public serial was sanitized as S108EF5920013306.

FortiLink-Specific Checks

FortiLink history matters because a switch may look physically fine while still behaving like a managed member.

Before resale, verify:

  • the switch is isolated from any former FortiGate
  • FortiLink connection status is captured if available
  • local mode or default management behavior is understood
  • no prior controller-specific settings remain visible
  • the post-reset login prompt behaves as expected

If the unit warns that it is under remote control, do not list it as clean until you reset and verify it away from the former controller.

Post-Reset Verification Checklist

After reboot, capture:

  • boot banner with model and software version
  • login prompt behavior
  • default or forced-password-change behavior
  • show system interface output
  • hardware status
  • FortiLink status or expected standalone state
  • local logs showing only reset/current boot activity or a documented unavailable state
  • final pass/fail operator note

Do not accept the reset command alone as proof. The pass condition is the combination of reset transcript plus clean-state verification after reboot.

Common Exceptions

Stop and escalate when:

  • the unit reboots repeatedly
  • the console becomes unreadable after reset
  • storage or flash errors appear during boot
  • FortiLink mode returns unexpectedly
  • old management IPs, SNMP, syslog, or admin objects remain visible
  • the device requires firmware recovery instead of a normal reset

For resale, an exception record is better than a silent pass. It protects the buyer, the seller, and the bench team.

CliDeck Workflow Fit

CliDeck can run the same FortiSwitch intake script every time: capture console output, prompt for physical photos, run hardware and management-state checks, request operator confirmation before reset, and attach the post-reset transcript to the asset record.

That makes the process repeatable for mixed FortiSwitch lots where some devices are standalone, some were FortiLink-managed, and some need exception handling.

Final Pass Criteria

A FortiSwitch is ready for resale when the record shows:

  • identity captured and serial handling sanitized for public use
  • reset path recorded
  • reboot completed
  • no prior-owner configuration visible
  • management state verified
  • hardware and PoE status captured where supported
  • final transcript attached to the asset record

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.

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