Short answer

Use this as an owner-authorized workflow for brocade fastiron factory reset for itad: config, keys, and boot-state verification. 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.

Brocade FastIron Factory Reset for ITAD: Config, Keys, and Boot-State Verification

On FastIron hardware, a boot-monitor factory-default operation and an in-service startup-configuration erase are different actions with different scope and verification needs. For authorized ITAD, select the path that the exact device, software release, and work order support, then prove the resulting clean boot state before resale.

Scope and ownership boundary

Use this workflow only for an owned or customer-authorized asset that has an approved ITAD, return, refurbish, or redeployment work order. Only the asset owner authorizes factory reset, stack-wide change, image handling, or any action that removes keys and configuration. The technician documents which context is active—boot monitor or normal runtime—and stops if the displayed warning exceeds the approved scope. The asset owner approves the disposition and recovery scope; the technician captures evidence, follows the exact-model decision gate, and stops when an observation does not match the work order. This is not a process for bypassing an active organization, recovering someone else’s service, or retaining customer configuration.

Preflight checklist

1. Match the physical asset to the approved work order and keep serial numbers, license records, management identifiers, and account information only in the private record.
2. Isolate the device from production networks. Use a known-safe bench network or local console that contains no customer credentials, provisioning service, or production automation.
3. Capture a private before-state: model family, software or boot version, current role, observed management state, planned action, operator, and timestamp.
4. Confirm that the approved action matches the device’s model, software family, and boot context. A command or menu option from a different release is a stop condition, not a substitute.
5. Prepare a private pass/fail form before changing state. The result must show what was observed, not just that a command was entered.

Model and version gate

The observed ICX7250 boot monitor ran the FastIron 08.0.30f family and offered factory set-default with a warning that user data such as configuration and keys would be removed. Normal runtime erase startup-config has a narrower configuration role and can affect stack behavior. Do not generalize the boot-monitor command to every FastIron release or use it while the stack scope is uncertain.

Safe execution checklist

1. Determine whether the work order requires a boot-monitor factory-default path or an approved normal-runtime configuration erase; record the reason before proceeding.
2. For a stack or multi-unit device, identify the active controller and member scope. Do not assume a local command affects only one unit.
3. Read the exact confirmation warning and stop if it includes unapproved images, storage, licensing, or members outside the approved disposition.
4. Allow the reset and reload to complete, then observe the initial boot sequence and clean configuration condition from the private console record.
5. Verify the expected clean-state prompt and confirm that no prior configuration, key material, provisioning state, or unexpected stack artifact remains in the approved review.

Commands and controlled observations

Run only the commands that are valid for the exact device and approved context. Do not paste production addresses, image locations, account data, or credentials into the public work record.

factory set-default
erase startup-config
reload

The first command is a boot-monitor factory-default path in the observed workflow; the latter two belong to normal runtime and must not be treated as identical. Use only the action selected by the approved model/version gate, and never include a running configuration or key material in public evidence.

Pass/fail signals

Pass: The approved action completes, the device reloads into the expected clean state, private boot messages corroborate the selected path, and the authorized review finds no retained configuration or keys.

Fail or hold: A warning outside scope, stack-member ambiguity, unexpected retained startup data, recovery error, unverified image state, or a boot prompt that does not match the expected factory-default condition. Quarantine the unit for owner review.

A successful command alone is not sufficient. The technician must observe the specified boot or management result, keep the device isolated until review is complete, and escalate any mismatch to the asset owner.

Sanitized verification note

Sanitized verification note: An ICX7250 boot-monitor capture on the FastIron 08.0.30f family showed factory set-default, an explicit confirmation that user data including configuration and keys would be removed, and a subsequent factory-default boot sequence with empty startup-configuration signals.

The note is a sanitized operational observation, not a replacement for the exact model and release check. It contains no customer names, hostnames, addresses, MAC addresses, credentials, license identifiers, file paths, or raw console transcript.

Evidence artifacts for the private record

• Authorized work-order reference and disposition decision.
• Model, software or boot version, and recovery context observed before the action.
• Exact reset, recovery, boot, or cleanup path selected, including any confirmation result.
• Boot completion result, clean-state or management-state evidence, and explicit pass/fail outcome.
• Exception owner and reason when the device is held rather than released.
• Technician identity, timestamp, and the sanitized handoff summary.

Never place raw console output, addresses, configuration exports, account names, customer topology, certificates, keys, passwords, licensing details, or recovery-file locations in a public resale listing.

Make the handoff repeatable in CliDeck

Create a CliDeck runbook with an ownership confirmation before the destructive or recovery step. Add a required model/version gate, a private evidence form, and a post-boot pass/fail checkpoint. Require the operator to choose “boot monitor” or “normal runtime” in the runbook before a reset command is shown. Add a stack-scope confirmation and a required after-boot clean-state observation. If the device reports an unexpected state, mark the runbook as held and route it to the asset owner instead of continuing toward resale.

For related owner-authorized workflows, see the Ruckus ICX reset checklist, the Arista ZTP cleanup guide, and the Dell ONIE decision guide.

Final disposition gate

Approve resale only when the reset context, scope, confirmation, and post-boot clean state are all documented and pass review. Any ambiguity 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

• Ruckus ICX / FastIron Factory Reset for ITAD: Version-Safe Wipe and Verification Checklist - Reset an owned Ruckus ICX or FastIron switch safely with a release-aware command gate, stack checks, reload evidence, and post-wipe verification.
• Palo Alto Panorama-Managed Firewall Reset: Detect and Clear Managed Remnants Before Resale - Use this authorized ITAD checklist to separate PAN-OS factory-reset proof from Panorama-release verification before firewall resale.
• Check Point Appliance Factory Reset and Gaia Clean-State Checklist for ITAD - Use this release-aware ITAD checklist to select a Gaia recovery target safely, verify factory reset completion, and document a clean-state handoff.
• TP-Link Omada Controller Removal and Factory Reset for Resale - Use this ITAD checklist to verify Omada controller release, factory-reset the device safely, and record a clean-state resale decision.
• ExtremeXOS Factory Defaults for ITAD: unconfigure switch vs unconfigure switch all - Choose the safe ExtremeXOS unconfigure switch path for resale. Covers NVRAM versus full erase, stack limits, reboot behavior, and clean-state verification.