CliDeck
PlatformLog in
Workspace

Check Point Appliance Factory Reset and Gaia Clean-State Checklist for ITAD

ITAD & Refurbishment
#Check Point#Gaia#factory reset#ITAD#network device recovery#ITAD & Refurbishment#itad#network-device-processing
← Back to Blog

Short answer

Use this as an owner-authorized workflow for check point appliance factory reset and gaia clean-state checklist for itad. Capture the console session, use the approved device-specific procedure, verify the post-reset or post-recovery state, and attach evidence-style results to the asset record. This article does not describe certified data destruction.

Check Point Appliance Factory Reset and Gaia Clean-State Checklist for ITAD

A Check Point appliance is ready for an authorized ITAD handoff only when the selected recovery target is documented, the destructive confirmation matches the approved scope, and the appliance reaches a clean Gaia onboarding state. Recovery menus can show several release-specific factory targets. Never treat a familiar menu label as universal: capture the exact target displayed on the appliance before confirming it.

Direct answer and ownership boundary

Use this checklist for an authorized return, redeployment, or resale disposition. The asset owner approves the reset target and the evidence requirement. The technician identifies the appliance and Gaia recovery menu, performs the approved reset, verifies the clean state, and reports exceptions. A factory reset is not authority to access an appliance, alter a disputed tenancy, retain a license entitlement, or work around a customer’s management controls.

Your goal is narrow: remove the approved local configuration and prove that the unit reached the expected clean-state boot path. Do not expand the operation to unrelated storage or software recovery unless the work order explicitly calls for it.

Preflight: build the private evidence record

  1. Confirm the work order, asset ownership, and approved disposition. Keep serials, license references, account data, and network details in the private record only.
  2. Isolate the appliance from production networks and connect through the approved local console path. Do not attach it to a customer environment during recovery verification.
  3. Capture the observed platform family, currently installed Gaia release when available, recovery entry point, and the reset target offered by the menu.
  4. Record whether the work order calls for the appliance to be resold, redeployed, or held for software recovery. These outcomes have different proof requirements.
  5. Make sure a technician can observe the entire reboot. A power interruption during a destructive recovery operation can create a separate recovery incident.

Version and target gate

Gaia recovery menus can present more than one factory-default choice because the appliance may contain different release-era recovery targets. The menu item is an operational decision, not a generic instruction. Before confirmation, write down the exact text of the selected target and compare it with the work order. If the available choices do not clearly map to the approved release, stop and escalate to the owner or the approved recovery authority.

For a unit that reaches Gaia normally before the wipe, collect the version in the private record using the release-supported system display. For example, an authorized console session may use:

show version all

Use this only as a baseline and only when it is accepted by that appliance’s release and role. Do not include its output in a public handoff. The recovery menu is still the controlling source for the target that will actually be installed or restored.

Factory-reset workflow

  1. Boot into the approved recovery menu using the model’s documented local console method.
  2. Read every reset target presented by that menu. Select only the release-specific factory-default target approved in the work order.
  3. Capture the selection in the private evidence record before answering the destructive confirmation.
  4. Confirm only when the warning describes the intended configuration erase and factory-default action. If the warning mentions unexpected disks, images, licenses, or unrelated data, stop and escalate.
  5. Allow the recovery process and reboot to finish without a power cycle.
  6. Keep the appliance isolated until it reaches the expected clean state and the technician has completed the post-boot checks.

The recovery screen is not the place to guess. A menu choice associated with a different release can leave the appliance on an unexpected path or create avoidable software-recovery work. The correct technician action for an ambiguous menu is hold and escalate, not “try the closest option.”

Post-boot clean-state verification

After the reboot, verify the appliance from the console. A successful filesystem check during the boot path is useful evidence that the system completed a storage consistency stage; it is not proof that every required ITAD control passed. Combine that signal with the following checks:

  • The appliance completes boot without recovery-loop or filesystem-error messages.
  • It lands at the expected first-time Gaia setup or other documented clean-state prompt for the selected target.
  • Previously configured administrator identities, interfaces, routes, object data, policies, and customer-specific management settings are absent from the authorized local review.
  • The reported platform and available recovery target match the private evidence record.
  • The appliance has not rejoined a production management domain or restored a previous configuration.

A pass requires the expected clean-state prompt and a complete private evidence record. A fail includes an unexpected installed release, a recovery loop, a filesystem error, retained configuration, or a menu target that cannot be reconciled with the approved work order. Quarantine a failed unit and record the observed condition without attempting repeated resets.

Sanitized verification note

Verification note: On a Gaia recovery workflow, the local menu displayed multiple release-specific factory targets. The technician selected the approved target, confirmed the erase warning, and observed a storage-consistency check during the subsequent boot. The observation was sanitized; it contains no customer names, identifiers, addresses, credentials, license information, file paths, or raw console transcript.

This note demonstrates why the selected target must be recorded before confirmation. The filesystem-check signal supports the boot record, but it does not replace the clean-state and ownership checks.

Evidence artifacts for the private work record

  • Authorized work-order reference and disposition decision.
  • Appliance model family and baseline release, if safely observed.
  • Recovery-menu target text exactly as selected.
  • Confirmation result and action timestamp.
  • Boot completion and filesystem-check observation.
  • Clean-state pass/fail decision, exception owner, and technician identity.

Never publish console screenshots, raw transcripts, internal hostnames, addresses, asset identifiers, account details, policy names, certificate material, license references, or recovery files. A public resale description needs only the approved non-sensitive condition statement.

Make the procedure repeatable in CliDeck

Create a CliDeck runbook with a hard stop before destructive confirmation. Require the technician to enter the visible recovery target and the owner-approved target separately; the runbook should continue only when they match. Add required pass/fail steps for boot completion, clean-state prompt, and private evidence review. Attach a sanitized completion summary to the handoff and route every mismatch to the asset owner.

For related ITAD recovery patterns, see the Arista EOS recovery decision guide, the ExtremeXOS factory-default checklist, and the UniFi adoption cleanup checklist.

Final disposition gate

Approve the appliance for its next authorized owner only when the recovery target was approved and recorded, the destructive confirmation matched scope, the boot completed cleanly, and the clean-state review passed. Any uncertainty about the target, a retained configuration, or abnormal boot evidence means hold for recovery review.

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