CliDeck
PlatformLog in
Workspace

FortiGate Factory Reset for IT Asset Recovery: Safe Wipe and Verification Checklist

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

Short answer

For an authorized FortiGate ITAD reset, confirm ownership, capture intake evidence, reset the device through a controlled console session, and verify that it boots without the former customer configuration. The asset is ready only when the transcript and clean-state checks support that result.

When this applies

Use this checklist when your team is processing owned FortiGate or FortiWiFi appliances for reuse, redeployment, lab stock, resale, or return-to-inventory.

This guide assumes:

  • The device is company-owned, customer-authorized, or otherwise legally cleared for sanitization.
  • You have physical access or authorized remote console access.
  • You are not trying to bypass security on a device you do not own.
  • Your organization has decided that a factory-default configuration reset is the correct disposition step for this model and customer contract.

If the device is under legal hold, incident investigation, managed service retention, or customer dispute, stop and follow that process first. A factory reset can destroy useful evidence.

Pre-reset intake checklist

Before touching the reset command, record enough information to prove what was processed and how.

  • Photograph the front, rear, serial label, service tag, and any visible asset tags.
  • Record model, serial number, asset ID, intake batch, customer or source account, and operator name.
  • Record observed power state, boot behavior, LEDs, fan status, and port damage.
  • Connect by console where practical and capture the session transcript.
  • Record firmware version if the device boots far enough to show it.
  • Record whether the device had an unknown admin password, known credentials, or no reachable management path.
  • Confirm whether the contract requires configuration backup, customer return, or secure destruction of backup files.
  • Confirm the reset method selected for this model: CLI, reset button, or another documented vendor process.

Do not save customer configuration backups unless your workflow explicitly requires them. If you must preserve a backup, store it in the approved evidence system and handle it as sensitive data.

CLI reset path

Use the CLI path when you can reach an authorized FortiOS prompt.

  1. Connect the appliance to a controlled network or isolated bench setup.
  2. Open a console session and confirm you are on the correct serial number or asset record.
  3. Capture the starting prompt and any useful intake facts.
  4. Run execute factoryreset from the CLI.
  5. Confirm the reset when FortiOS asks for confirmation.
  6. Keep the console connected until the reboot completes.
  7. Record the first boot result and any default-state indicators.

A reset can interrupt management access and reboot the device. That is expected. For a refurbish bench, console access is the reliable path because it does not depend on the old interface configuration, DHCP behavior, admin account, or management VLAN.

Reset-button path for supported models

Some lower-end FortiGate and FortiWiFi models support a physical reset button workflow. Fortinet publishes reset-button guidance for small-business models, but support varies by model family and hardware revision.

Use the reset button only when:

  • The exact model is in the supported reset-button scope for your procedure.
  • The device is physically present and labeled correctly.
  • The operator can watch LEDs and boot timing without guessing.
  • The resulting state will still be verified through console or management access afterward.

For high-throughput ITAD work, treat button resets as a model-specific exception, not the default. The CLI path is easier to script, easier to record, and easier to audit.

What not to use for resale wipe

Fortinet also documents execute factoryreset2, which resets to factory default configuration without losing management access. That can be useful for some operational maintenance cases, but it is usually the wrong default for resale sanitization.

If the goal is to clear prior-owner context, preserving management access is a sign that some management-related settings may intentionally survive. For an IT asset recovery workflow, prefer the clean reset path unless your written procedure says otherwise and your verification checklist accounts for what is retained.

Also avoid these shortcuts:

  • Deleting only policies, addresses, or users by hand.
  • Changing only the admin password and calling the device clean.
  • Relying on GUI access without recording console or reset evidence.
  • Mixing customer backup files into the refurbish bench environment.
  • Shipping a unit before verifying boot, management state, and visible configuration.

Post-reset verification checklist

After the reset and reboot, verify the outcome before the unit moves to grading, test, or resale.

  • Device boots without entering a recovery loop.
  • Console prompt is reachable after reset.
  • Previous hostname, banners, admin users, VPN objects, certificates, policies, address objects, routes, HA settings, and customer labels are not visible in the active configuration.
  • Firmware version is recorded and matches expectations for the batch.
  • Antivirus and IPS definition state is recorded if your grading process tracks it.
  • Default management access is tested only in an isolated bench network.
  • The unit is tagged with reset method, operator, timestamp, and verification result.
  • Any failed reset, boot issue, damaged port, or model mismatch is sent to exception handling.

The verification step matters because “command accepted” is not the same as “device is ready for resale.” The unit should not leave the bench until the reset result is visible and recorded.

A repeatable CliDeck workflow

A network-device wipe bench is easier to run when every operator follows the same script.

With CliDeck, the reset process can be organized as a repeatable console workflow:

  1. Scan or enter the asset ID.
  2. Open the correct console session.
  3. Capture model, serial, prompt, and boot state.
  4. Run the approved reset command for that device family.
  5. Wait for reboot and capture the first clean prompt.
  6. Run the verification checklist.
  7. Save transcript, result, operator, and exception notes with the asset record.

That is the difference between a one-off reset and a production refurbish process. The command is short. The evidence trail is the work.

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