Palo Alto Tech Support File Before Wipe: What an ITAD Bench Should Record
Short answer
Collect a Palo Alto tech support file before an authorized wipe when the firewall needs grading, diagnostics, RMA triage, or condition evidence. Run the collection while the device is stable, store the result as private evidence, and only then reset the device; a reset can remove the logs and configuration that make the file useful.
When This Applies
Collect a tech support file when a firewall is powered, reachable enough to run CLI jobs, and your work order requires proof beyond model and serial. It is useful before resale grading, before a factory reset, before RMA screening, and before deciding whether a unit should be reimaged or quarantined.
Skip it only when policy requires immediate wipe, the device cannot stay booted long enough, or the evidence would create a data-handling risk your team cannot accept.
Pre-Wipe Evidence Checklist
| Evidence | Command or source | Keep public? |
|---|---|---|
| System identity | show system info | Sanitized summary only |
| Interface state | show interface all | Usually internal only |
| Tech support file | request tech-support dump | Never raw public output |
| Job completion | show jobs all or show jobs id <job-id> | Internal proof |
| Photos | Labels, ports, boot/login state | Sanitized if shared |
| Reset result | Maintenance Mode status or CLI reset transcript | Sanitized summary |
CLI Workflow
show system info
show interface all
request tech-support dump
show jobs all
show jobs id <job-id>
When the job completes, download the tech support file through the approved management path. If the GUI is reachable, use the support file download path in the device interface. If the GUI is not reachable, record the exception and follow the approved internal escalation path for export.
What To Do With The File
- Store it in the internal asset or evidence system.
- Attach the asset ID, model, serial, collection time, and operator.
- Mark whether the file was collected before or after reset.
- Restrict access because the file can include configuration, logs, IP addresses, object names, certificates, or other sensitive data.
- Delete bench copies after upload if your retention policy requires that.
- Publish only sanitized summaries, never the raw archive.
Bench Note: What Is Lost After Factory Reset
In real PA-820, PA-850, and PA-3050 reset transcripts, Maintenance Mode factory reset produced a success status and post-reset CLI still allowed basic identity capture such as model and PAN-OS version. That was enough to prove the device came back, but it was not enough to reconstruct pre-reset policy, logs, interface history, or customer-specific operating state.
For that reason, a tech support file is a pre-wipe artifact. If you need it for grading, collect it before the reset window starts.
Sensitive Data Handling
Treat the tech support file like a private customer data artifact. It can contain operational details that should not leave the approved workflow. In public resale copy, use a summary such as model, PAN-OS version, reset method, and pass/fail result. Keep the raw file internal.
Before any excerpt is shared, remove or replace:
- real serial numbers and asset tags
- public IP addresses and customer network names
- admin usernames and authentication server details
- certificate, key, token, VPN, or license material
- object names that identify the previous owner
- logs containing users, URLs, threats, or customer traffic context
Pass/Fail Criteria
| Result | Meaning | Next action |
|---|---|---|
| Pass | File generated, job completed, evidence stored | Proceed to wipe/reset workflow |
| Warning | Basic identity captured but tech support file failed | Decide whether reset can proceed with exception |
| Fail | Device unstable or cannot run diagnostics | Quarantine or recovery workflow |
| Skip | Policy requires immediate wipe | Record reason and proceed to sanitization |
CliDeck Workflow Fit
A CliDeck workflow should make the tech support file a deliberate pre-wipe checkpoint. The operator should see the command, job monitor step, evidence upload field, sensitive-data warning, and reset handoff in one runbook. That turns a fragile manual task into a repeatable asset-processing record.
Related CliDeck Field Guides
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.
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.
- Juniper RSI Collection Before Reset: Asset Grading Diagnostic Checklist - A practical Juniper RSI and log collection checklist for ITAD teams capturing diagnostics before reset, zeroize, refurbish grading, or resale.
- NIST SP 800-88 Rev. 2: A Defensible Media Sanitization Process - Build an asset-level sanitization workflow with method selection, execution evidence, verification, validation and clear exception handling.
- Aruba Instant AP Factory Reset: Isolate the Device and Verify the Fresh Baseline - For an owned Aruba Instant AOS-8 access point, use the supported factory-reset procedure for the exact model and software.
- Cisco IOS XE Smart Licensing at Decommission: A Separate Checklist from Factory Reset - Before decommissioning an owned IOS XE device, identify its licensing model and coordinate license handling with the authorized Smart Account administrator.