Juniper SRX Factory Reset vs request system zeroize: ITAD Decision Guide

Short answer

For an authorized Juniper SRX resale wipe, use request system zeroize to remove configuration, logs, and key material. Use load factory-default only for staging or recovery; it is not the final clean-state step for an ITAD or resale workflow.

Decision Table

Use this decision path on the bench:

Situation	Preferred action	Why
CLI works and device is going to resale	request system zeroize	Clears configuration/log evidence and reboots to clean state
CLI recovery mode is needed to regain control	Recovery boot, then decide	Get into a safe operational state before wiping
You need a temporary default config to commit a recovery change	load factory-default	Helps rebuild configuration, but is not final sanitization proof
Device has customer VPN/security configuration	Zeroize and verify	SRX configs can contain sensitive policy, VPN, certificate, and user data
Device fails boot or storage checks	Quarantine or reimage path	Do not mark as clean resale stock without a stable boot and proof

Why Factory Default Alone Is Not Enough

load factory-default changes the candidate configuration. It does not automatically prove that old logs, key material, and storage artifacts were handled. On SRX firewalls, the prior configuration may include VPN settings, security policies, certificates, local users, license details, and customer-specific routing.

For resale, your pass condition should be stronger:

• the device was identified
• the wipe method was captured
• the device rebooted
• default state was verified
• old customer identifiers were absent from visible configuration
• exceptions such as ZTP, license state, or alarms were recorded

Recovery-to-zeroize Workflow

When password recovery or recovery-mode boot is required on an owned SRX, keep the process narrow:

1. Start console logging.
2. Boot into the supported recovery path for the platform.
3. Enter CLI/configuration mode only as needed.
4. Use factory-default only if it is needed to get the unit into a manageable state.
5. Exit or commit according to the recovery goal.
6. Run zeroize as the final sanitization action for resale.
7. Verify the post-reboot default state.

Example command sequence when CLI access is available:

request system zeroize

If you are in configuration mode for recovery staging, do not confuse the candidate configuration with final proof.

Bench Note

On an SRX320-POE running Junos 21.4R3-S3.4, our console transcript entered recovery mode, showed the recovery note for setting root authentication, then used load factory-default as a temporary recovery step. The operator exited with uncommitted changes and ran request system zeroize. The SRX warned that the system would reboot, reported that the IPsec key-management subsystem was not running, zeroized re0, synced disks, and rebooted. Afterward the unit came back to an Amnesiac login state, and show chassis hardware identified an SRX320-POE. The public serial was sanitized as CX4717AF0048.

SRX-Specific Verification Checks

After zeroize, capture:

• boot and login state
• Amnesiac or default prompt behavior
• show chassis hardware for model and serial match
• chassis alarms
• license state, sanitized for internal use only
• whether Auto Image Upgrade or phone-home ZTP messages appear
• management IP and interface state
• absence of old security policies, VPN objects, users, and hostnames

Do not publish raw license output. It can include customer names, entitlement identifiers, and device serials.

Handling Auto Image Upgrade Or ZTP Messages

Some SRX units may print Auto Image Upgrade, DHCP, or phone-home messages after a wipe. Do not treat those messages as customer data by themselves, but do record them because they affect bench behavior.

A good pass/fail note says:

• whether ZTP/auto-image messages appeared
• whether they stopped or repeated
• whether the unit remained reachable on console
• whether any management interface came up unexpectedly
• whether the final configuration view stayed clean

If the device repeatedly attempts network onboarding, isolate it and disable the behavior only if your refurbish procedure requires a staged config. For pure resale, the safer path is usually clean default state with no customer identifiers and an internal note about observed ZTP messages.

What Not To Do

Avoid these mistakes:

• calling load factory-default a complete data wipe
• publishing raw SRX transcripts with license or customer details
• skipping post-reboot verification
• assuming a recovery login means the device is clean
• ignoring security policy, VPN, certificate, or local-user remnants
• leaving a staged bench password on a resale unit

CliDeck Workflow Fit

CliDeck can make the SRX decision path explicit. The script can pause when it sees recovery mode, ask whether the goal is staging or resale wipe, capture load factory-default only as a recovery step, require operator confirmation before zeroize, and then demand post-reboot verification before the asset can move to resale.

That keeps the article's rule practical: factory-default can help you recover control, but zeroize and verification are what support the resale record.

Final Pass Criteria

Mark the SRX ready for resale only when:

• device identity and sanitized serial handling are complete
• zeroize command and confirmation are captured
• reboot completes
• default or Amnesiac state is visible
• no prior-owner configuration is visible
• license/customer details are kept internal and sanitized
• hardware alarms and ZTP behavior are recorded
• evidence is attached to the asset record

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 decision table

Situation	Better fit	Why
One authorized engineer needs a quick low-risk task	Factory reset or simpler reset path	It keeps the workflow simple when no shared context, batch work, or durable evidence is required.
The work needs verification, handoff, or documentation	Zeroize, reimage, or documented processing workflow	It creates a clearer path for notes, logs, stop conditions, and final checks.
Multiple people or devices are involved	Zeroize, reimage, or documented processing workflow	Structured workflows reduce ambiguity and make it easier to prove what happened.

When option A is enough

The simpler option is usually enough when one authorized engineer is doing a low-risk task locally, the device state is known, and the work does not require shared context, batch processing, or durable evidence.

When option B is better

The more structured option is better when the work needs repeatability, collaboration, verification, logging, asset linkage, or a safer handoff between people or teams.

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

• Juniper Virtual Chassis Wipe for ITAD: Zeroize Each Member Without Leaving VC Config Behind - A Juniper Virtual Chassis wipe and zeroize checklist for ITAD teams preparing owned EX and QFX members for resale without leaving member configuration behind.
• Juniper EX Switch zeroize for Resale: Clean Config, Logs, and Key Material - A Juniper EX zeroize and clean-state verification checklist for ITAD and resale teams clearing owned EX switches before shipment.
• FortiSwitch Factory Reset for ITAD: Console Capture and Verification Steps - A console-first FortiSwitch factory reset and verification checklist for ITAD, refurbish, and resale teams preparing owned switches for reuse.
• FortiGate HA Pair Wipe Checklist: Resetting Both Units Without Leaving Cluster Data - A practical FortiGate HA pair reset and verification checklist for ITAD teams preparing both cluster members for refurbish and resale.
• Cisco ASA Factory Reset and Password Recovery for Decommissioned Firewalls - A practical Cisco ASA factory reset, owner-authorized password recovery, storage cleanup, and resale verification checklist for decommissioned firewalls.