FortiGate Factory Reset vs factoryreset2: Which Path Is Safe for Resale?

Short answer

For an authorized FortiGate resale reset, use execute factoryreset when the goal is a clean handoff. Do not use execute factoryreset2 as the default resale path because it can retain selected system and network-facing settings.

When each command fits

Use execute factoryreset when:

• The FortiGate is owned or customer-authorized for ITAD processing.
• The device is leaving the previous environment permanently.
• You need a clean-state evidence record for resale.
• The prior hostname, routes, interfaces, VDOMs, VPNs, policies, users, and logging targets must not remain.
• You can complete verification through console access after reboot.

Consider execute factoryreset2 only when:

• The unit is staying in the same managed environment.
• Keeping selected management/interface/routing state is intentional.
• The work is break-fix or remote maintenance, not resale preparation.
• The retained settings are documented and approved.

If the asset is going to resale inventory, the safer answer is simple: prefer full factory reset, then prove the result.

Pre-reset intake checklist

Before any reset, record:

• Model, serial, FortiOS version, boot state, and active prompt.
• Front and rear photos, ports, power supplies, storage, and visible damage.
• Whether the device is standalone, VDOM-enabled, or part of an HA pair.
• Current hostname, management access method, and whether console access is stable.
• Whether the log disk or storage warning needs attention.
• Operator, timestamp, asset ID, and reset method.

Useful intake commands are:

get system status
get hardware status
get system performance status
show system interface
get router info routing-table all

Do not publish raw command output from a customer device. Keep the raw transcript private, sanitize identifiers, and only expose the pass/fail evidence needed for the asset record.

Why factoryreset2 is risky for resale

The problem with factoryreset2 is not that it is broken. It does what it is designed to do: reset most of the configuration while retaining selected objects that help preserve access or platform structure. FortiOS release help shows this retained set can include VDOM mode or VDOM names, VDOMs, virtual-switch state, interfaces, system settings, and static IPv4 or IPv6 routes.

That retained set is exactly why it is a poor default for resale. Interfaces and routes can reveal prior network design. VDOM names can expose tenant or customer naming. Management settings can preserve old access assumptions. Even if the device looks cleaner than before, it is not the same evidentiary position as a full reset.

Recommended resale workflow

Use console access and make the reset explicit:

get system status
get hardware status
execute factoryreset

When prompted, confirm only after the asset record is ready:

This operation will reset the system to factory default!
Do you want to continue? (y/n)y

Then wait for the reboot and capture the first clean boot state. Do not interrupt the device during shutdown or storage checks. If the FortiGate reports a file-system check recommendation, record it and follow the bench policy for disk scan before the unit is marked ready.

Field note from FortiGate bench logs

Field note: In our FortiGate-300E bench transcript, execute factoryreset produced the warning This operation will reset the system to factory default!, then System is resetting to factory default..., then The system is going down NOW !! before reboot. The same log set exposed CLI help for both factoryreset and factoryreset2; factoryreset2 was listed as preserving selected VDOM, interface, system settings, and static route state. We also saw the same reset pattern on a FortiGate-1000D. Public asset notes should use sanitized serials such as FG3H0E5818900262 or FGT1KD3916800911, not the raw bench serials.

That is why our resale workflow treats factoryreset2 as a maintenance command, not a clean-handoff command.

Post-reset verification checklist

After the reboot, verify:

• The device boots to the expected FortiGate model and FortiOS train.
• The old hostname is gone or replaced by a default/sanitized state.
• No prior admin users, VPN names, address objects, policies, routes, VDOM names, or logging targets are visible.
• Interface settings do not retain customer IPs or descriptions.
• Static routes do not point to the old environment.
• HA configuration is not left behind if the device was formerly clustered.
• The reset method, operator, timestamp, firmware version, and sanitized serial are attached to the asset record.

A command accepted by the CLI is not enough. The evidence is the before/after transcript plus a clean verification pass.

When to stop and reimage instead

A factory reset is not a firmware reinstall. If the unit has an unknown firmware history, corrupted storage, repeated boot failures, or a security policy that requires fresh media, stop and move the asset into a reimage workflow. Resale teams should separate three states: configuration reset, storage cleanup, and firmware reimage. They are related, but they are not interchangeable.

CliDeck workflow angle

CliDeck can turn this into a repeatable operator path: capture intake, ask whether the job is resale or maintenance, block factoryreset2 for resale unless a supervisor explicitly approves an exception, record the reset transcript, and require a post-reset checklist before the asset can be closed.

That is the difference between "we ran a command" and "we can prove this FortiGate is clean enough 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.

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.

Quick decision table

Situation	Better fit	Why
One authorized engineer needs a quick low-risk task	Factory reset or simpler reset path	It keeps the workflow simple when no shared context, batch work, or durable evidence is required.
The work needs verification, handoff, or documentation	Zeroize, reimage, or documented processing workflow	It creates a clearer path for notes, logs, stop conditions, and final checks.
Multiple people or devices are involved	Zeroize, reimage, or documented processing workflow	Structured workflows reduce ambiguity and make it easier to prove what happened.

When option A is enough

The simpler option is usually enough when one authorized engineer is doing a low-risk task locally, the device state is known, and the work does not require shared context, batch processing, or durable evidence.

When option B is better

The more structured option is better when the work needs repeatability, collaboration, verification, logging, asset linkage, or a safer handoff between people or teams.

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

• FortiGate USB Auto-Install Before Resale: Prevent Old Configuration from Returning - Remove unreviewed USB media before resetting an owned FortiGate and inspect USB auto-install settings on supported models.
• FortiGate HA Pair Wipe Checklist: Resetting Both Units Without Leaving Cluster Data - A practical FortiGate HA pair reset and verification checklist for ITAD teams preparing both cluster members for refurbish and resale.
• FortiGate Factory Reset for IT Asset Recovery: Safe Wipe and Verification Checklist - A practical FortiGate factory reset and verification checklist for IT asset recovery, refurbish, and resale teams using console access and vendor-supported reset paths.
• A Technician Bench Workflow for Console Capture, Reset, and Exception Handling - Build the bench process around explicit checkpoints: identify the asset, confirm authorization, capture the permitted starting state, select the...
• pfSense and Netgate Reinstall for Resale: Console, config.xml, and Storage Scope - A pfSense configuration reset restores settings but does not remove arbitrary filesystem changes.