CliDeck
PlatformLog in
Workspace

FortiGate HA Pair Wipe Checklist: Resetting Both Units Without Leaving Cluster Data

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

Short answer

For an authorized FortiGate HA resale wipe, reset and verify both physical units as separate assets. Capture their HA state, isolate them from production and from each other, reset each unit, and confirm that neither retains the prior cluster or customer configuration.

When this applies

Use this checklist when:

  • Two FortiGate units arrive as a known or suspected HA pair.
  • Hostnames, labels, or inventory records suggest primary/secondary roles.
  • The units have HA heartbeat cables or matching port use.
  • The buyer expects two standalone clean units, not the previous cluster.
  • You need proof that both serials were reset and verified.

If the pair is still in service or ownership is unclear, stop. This workflow is only for owned or customer-authorized decommissioned devices.

Intake checklist for both members

Label the units physically before reset. Use simple asset names such as Unit A and Unit B, then record:

  • Model, serial, FortiOS version, and hostname for each member.
  • Which unit is primary/secondary if the cluster is still running.
  • HA mode, group name, group ID, heartbeat interfaces, and monitored interfaces.
  • Whether override, session pickup, VDOM mode, or reserved management interfaces are enabled.
  • Photos of front, rear, labels, cabling, modules, and damage.
  • Console access status for each unit.

Useful commands before disconnecting the pair are:

get system status
get system ha status
show system ha
get hardware status

If you need to inspect the secondary from the primary while the cluster is still intact, use the platform-supported HA member access workflow and record which member you entered. For resale, do not rely on primary-side access as final proof. Each unit still needs its own post-reset console evidence.

Safe physical workflow

A practical bench sequence is:

1. Photograph and label both appliances.
2. Capture HA status and firmware/version evidence while the cluster is still intact, if safe.
3. Remove production data links.
4. Remove HA heartbeat links before resetting either unit for resale.
5. Connect serial console to Unit A and reset it fully.
6. Wait for Unit A to reboot and verify clean state.
7. Keep Unit A isolated.
8. Connect serial console to Unit B and repeat the same reset and verification.
9. Attach both transcripts to the same asset batch, but close each serial independently.

The key rule is isolation. A reset member should not rejoin a peer that still holds the old configuration. If the pair must stay physically cabled for a controlled test, document that as an exception and do not mark either unit resale-ready until both are clean and independently verified.

Reset command for each member

For resale, use full factory reset on each unit:

execute factoryreset

Confirm the prompt only after the transcript, photos, and asset notes are ready. The expected reset transcript includes a warning that the system will return to factory default, a confirmation prompt, a reset-in-progress line, and a reboot.

Do not substitute factoryreset2 for HA-pair resale cleanup. A partial reset path can retain interface, VDOM, system, or routing state, and those are exactly the areas where HA and customer network remnants often live.

Field note from a two-unit FortiGate bench set

Field note: In our FortiGate-240D bench logs, two matching units were processed separately. Unit A showed a hostname pattern ending in -01, FortiOS boot version Ver:04000006, and execute factoryreset followed by System is resetting to factory default... and reboot. Unit B showed a hostname pattern ending in -02, FortiOS boot version Ver:05000004, and the same reset confirmation and reboot pattern. Public examples should use sanitized serials such as FG240D4613800723 and FG240D4613801073, not the raw serials.

Both logs also showed file-system check warnings after unsafe reboot history. For resale, that warning is not cosmetic. Record it, run the appropriate disk scan when bench policy requires it, and do not mark the unit clean until boot and storage status are acceptable.

Post-reset verification for each unit

After each reboot, verify the unit independently:

  • The old hostname is gone.
  • The old HA group name and group ID are gone.
  • The old peer serial is not present in visible HA state.
  • Heartbeat and monitored interface configuration is not preserved.
  • Static routes, VDOM names, VPNs, address objects, admin users, and logging targets from the previous owner are absent.
  • The unit boots without joining the other member.
  • The model, FortiOS version, and sanitized serial match the asset record.
  • The transcript contains the reset confirmation and first clean boot evidence.

For a pair, the pass condition is both units passing. One clean member and one unverified member is a failed batch.

What to do with mismatched firmware

HA pairs can arrive with different firmware, failed upgrades, or one unit booting from a backup partition. Before reset, capture the mismatch. After reset, decide whether the resale SKU requires matching firmware. If it does, move the pair into a firmware normalization or reimage workflow. Do not hide mismatched versions in the listing.

When the FortiGate reports disk scan recommendations or boot inconsistencies, treat them as grading signals. The unit may still be reset, but it needs an exception note or repair workflow before resale.

CliDeck workflow angle

CliDeck can enforce this process as a two-member runbook: scan Unit A, scan Unit B, capture HA status, require cable isolation, block partial reset shortcuts, run the reset transcript for each serial, and close the batch only when both verification checklists pass.

That matters because HA mistakes are easy to make on a busy bench. The workflow must prevent an operator from cleaning one member, reconnecting it to an old peer, and shipping a pair that still carries cluster history.

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