CliDeck
PlatformLog in
Workspace

WatchGuard Firebox Factory Reset: Configuration, Feature Keys, and Resale Checks

ITAD & Refurbishment
#watchguard#ITAD#refurbishment#verification#ITAD & Refurbishment#itad#network-device-processing#network-operations
← Back to Blog

Short answer

Reset an owned Firebox with the procedure for its exact model when the goal is a fresh configuration. The reset removes saved backup images and the installed feature key, and returns management interfaces to their default roles. Keep account and entitlement handling separate, then verify the rebooted device before providing internet access or shipping it.

Separate factory reset from recovery mode

A factory reset is the configuration path when you do not intend to change the Fireware version. Recovery mode is a different path that can reinstall Fireware through the management tools. Choose the operation that matches the processing requirement rather than holding a reset button until something changes.

This guide is for owner-authorized refurbishment and decommissioning. Confirm that backups may be destroyed and that the asset is not subject to a preservation requirement. If a configuration must be returned, export it privately before resetting.

Capture the prerequisites

  • Exact T-series, M-series, or other model and revision.
  • Fireware version and starting fault, if management is available.
  • Local versus cloud-management mode.
  • Authorized account access and feature-key disposition.
  • Whether backup images exist and what must happen to them.
  • The selected model-specific reset procedure and LED checkpoints.

Disconnect cluster links and production interfaces. Keep the unit on stable power with a directly connected bench workstation. Label the ports physically so another operator does not accidentally reconnect the previous network.

Run the model-specific factory reset

Use the hardware procedure for the actual appliance. Timing and LED behavior differ across Firebox models. Record the observed sequence and wait for the reset to finish rather than forcing another power cycle.

After reset, interface 0 is normally the external DHCP client and interface 1 is the trusted side at 10.0.1.1. Larger appliances can have additional default trusted interfaces. Inspect the exact model before assuming every numbered port behaves like a small tabletop Firebox.

Connect through the intended trusted interface and verify the setup state. If the device does not boot normally, assess whether recovery-mode reinstallation is needed; do not describe that additional operation as another configuration reset.

Verification note: the feature key can be downloaded again

The previously installed feature key is removed by the reset. With an appropriate internet connection on interface 0, the Firebox can automatically attempt to download its feature key. Isolate the appliance until account handling is understood.

Removal of the local key does not settle product registration, ownership transfer, or subscription rights. Save those decisions in the asset record and make only the entitlement claims that the authorized account holder can substantiate.

Inspect the clean state

CheckAcceptable result
StartupNormal boot and reachable trusted management
ConfigurationOld policies, users, VPNs, and customer labels absent
BackupsReset result and private export disposition recorded
Feature keyLocal state and authorized re-download plan understood
NetworkNo accidental return to previous cluster or customer segment

Test management credentials on the isolated bench and record any temporary changes. A setup wizard alone is not enough if cloud or ownership status remains unresolved.

Close the job precisely

Distinguish configuration reset verified, firmware recovery required, entitlement hold, and hardware failure. Attach the method, version, operator, and supporting observations to the private job.

CliDeck Workspace can retain the console startup where supported and the operator checklist. Use the data-sanitization evidence guide to avoid turning a successful reset into an unsupported secure-erasure claim.

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.

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