Palo Alto Factory Reset for Resale: Maintenance Mode and Verification Checklist

Short answer

For an authorized Palo Alto resale reset, use the Maintenance Recovery Tool path: connect by console, enter maintenance mode, select Factory Reset twice, reboot, and verify the clean state from the console. Record the model, software version, reset result, and post-reset login behavior before releasing the asset.

Maintenance Mode vs Private Data Reset

Path	Use it when	Important limitation
Maintenance Mode Factory Reset	Device is being prepared for resale or clean redeployment	Requires console or maintenance access and reboot time
request system private-data-reset	You have CLI access and need to remove logs/config quickly	It is not the same as Maintenance Mode factory reset and should not be treated as full disk zeroization
Reimage/RMA path	PAN-OS image is missing or the device will not boot cleanly	Separate workflow with image/source validation

For resale, the Maintenance Mode factory reset is the cleaner default decision when the device boots and your bench can use console safely.

Pre-Reset Intake Checklist

• Photograph labels and physical condition.
• Confirm ownership and wipe authorization.
• Connect serial console at the expected line settings for the platform.
• Capture the current boot state and login prompt.
• If CLI access is available, capture show system info and show interface all.
• Export diagnostics or a tech support file before reset if grading requires it.
• Isolate the management port from customer networks and Panorama-managed environments.

Factory Reset Workflow

1. Establish a console session and save the transcript.
2. Log in with an authorized administrator account if the CLI is available.
3. Enter debug system maintenance-mode and confirm the reboot.
4. When maintenance mode appears, continue to the menu.
5. Select Factory Reset.
6. Select Factory Reset again when prompted.
7. Wait for the reset status and reboot.
8. After boot, verify that the firewall no longer exposes the previous configuration.

Do not interrupt power while the reset is running. If the firewall loops back to maintenance mode or cannot boot, stop and mark it as a recovery exception instead of calling it ready for resale.

Commands To Capture Around The Reset

show system info
show interface all
debug system maintenance-mode

After reset and reboot, capture:

show system info
show interface all

If the device is processed from a maintenance menu rather than a normal CLI session, the transcript should still show the menu path, the reset status, and the post-reset boot/login state.

Bench Note: PA-820 And PA-850 Reset Results

In real bench transcripts, a PA-820 running PAN-OS 8.1.13 and a PA-850 running PAN-OS 9.0.0 both reached Maintenance Mode, showed Factory Reset Status: Success, rebooted, and later returned enough CLI access to capture post-reset system information. The sanitized proof record for the PA-820 used serial 012001014749, and the sanitized proof record for the PA-850 used serial 011901021349.

The same transcripts also show why request system private-data-reset should be treated as a different workflow. It is useful to know, but it is not the same resale proof as the Maintenance Mode factory reset path.

Post-Reset Verification Checklist

• Factory Reset Status is captured as success, or an exception is recorded.
• Firewall reboots without returning to an error loop.
• Model and PAN-OS version are captured after reset.
• Previous hostname, management IP, Panorama state, admins, policies, zones, logs, and certificates are not visible in normal management output.
• Interfaces are in a clean/default state or documented as not tested.
• Any remaining license or entitlement handling follows the resale policy.
• Transcript, photos, and final status are attached to the asset record.

Common Mistakes

• Running only a private data reset and calling it a full factory reset.
• Forgetting to collect a tech support file or grading evidence before reset.
• Leaving the firewall connected to a customer network or Panorama path during processing.
• Publishing raw post-reset output with real serial numbers.
• Marking a maintenance-mode loop as passed.

CliDeck Workflow Fit

The repeatable workflow is console-first: capture intake, collect diagnostics if required, enter maintenance mode, confirm reset, wait through reboot, collect post-reset identity, and write a pass/fail/exception result. A CliDeck runbook should make each of those states explicit instead of relying on a technician remembering menu timing.

Related CliDeck Field Guides

• Palo Alto Tech Support File Before Wipe
• Cisco ASA Factory Reset and Password Recovery

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.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

• Purpose
• When to use it
• When not to use it
• Target system or device
• Access path
• Read-only checks
• Change steps
• Expected output
• Stop conditions
• Rollback steps
• Verification steps
• Handoff notes
• Final summary format

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.

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

• Palo Alto ZTP After Factory Reset: Keep Refurbishment on a Controlled Bench - After resetting an owned Palo Alto firewall, inspect its Zero Touch Provisioning state before connecting it to an unrestricted uplink.
• MikroTik Not Detected by Netinstall: An Etherboot Troubleshooting Checklist - When Netinstall does not detect an owned MikroTik device, separate boot-mode entry from network discovery.
• Palo Alto Tech Support File Before Wipe: What an ITAD Bench Should Record - A practical Palo Alto tech support file checklist for ITAD teams collecting diagnostics before wipe, factory reset, refurbish grading, or resale.
• Cisco Catalyst 9136I AP Factory Reset for ITAD: Button Reset, CAPWAP Erase, and Verification - A practical Cisco Catalyst 9136I access point reset and verification checklist for ITAD teams using the reset button, CAPWAP erase, and console evidence capture.
• Juniper SRX Factory Reset vs request system zeroize: ITAD Decision Guide - A practical ITAD decision guide for Juniper SRX factory-default recovery versus request system zeroize, with verification steps for resale.