CliDeck
PlatformLog in
Workspace

Aruba Instant AP Factory Reset: Isolate the Device and Verify the Fresh Baseline

ITAD & Refurbishment
#aruba-instant#ITAD#refurbishment#verification#ITAD & Refurbishment#itad#network-device-processing
← Back to Blog

Short answer

For an owned Aruba Instant AOS-8 access point, use the supported factory-reset procedure for the exact model and software. With authorized privileged CLI access on an isolated unit, write erase all reboot clears configuration and Instant AP database data, then restarts the device. Keep it away from the former cluster while verifying the new baseline, and handle external management release separately.

Confirm the operating mode first

This guide concerns Instant AOS-8. A campus AP, AOS-10 cloud-managed device, Instant On product, or controller appliance can have a different reset and provisioning workflow. Identify the actual software mode and hardware before selecting commands.

Record model, version, cluster role, management relationship, and power source. If the device belongs to a live cluster, obtain an approved removal window. Do not execute an erase command from a session whose cluster scope is unclear.

Prepare the isolated bench

Disconnect the previous customer network and other APs. Use a compatible PoE source or model-supported power adapter. Connect the model-appropriate console cable where supported; port shape alone does not establish the electrical interface or adapter compatibility.

Confirm permission to destroy configuration and database data. If a backup or evidence return is required, complete that task through authorized access before erasing the device.

Use the supported privileged command path

On the applicable Instant AOS-8 command path:

write erase all reboot

Read and respond to the displayed confirmation for the intended isolated asset. The all option includes Instant AP database data in the erase scope. Capture the response and allow normal reboot to finish.

If privileged access is unavailable, use the exact model's authorized hardware or bootloader recovery procedure. Do not substitute an old AP bootloader command for a different operating mode. Hardware reset-button timings and console parameters require model-specific checking.

Verification note: a cluster or provisioning system can restore configuration

Verify the appliance on the isolated segment before reintroducing a management network. A fresh local state can change after the device joins another system. Treat unexpected return of SSIDs or configuration as a provisioning investigation, not immediate proof that the erase command failed.

External management, cloud onboarding, account ownership, and subscription handling remain separate obligations. Do not represent a local reset as release from all management systems.

Check the resulting AP state

CheckRequired result
StartupNormal boot with stable power
SoftwareExpected Instant mode and version
ConfigurationPrevious SSIDs and customer settings absent
IsolationNo accidental join to the former cluster
HandoffManagement ownership and temporary credentials recorded

Default management and credential behavior vary across releases and hardware. Use the actual first-boot process instead of assuming every device uses an old default password or SSID. Test radios and Ethernet as separate hardware grading tasks after the configuration baseline is understood.

Record the final disposition

Save the reset command or hardware path, starting and final mode, boot observation, management disposition, and grading result. Hold the asset if mode conversion, firmware recovery, or account release remains unresolved.

CliDeck Workspace can retain the supported console session and operator checklist. Start the job with the network-device intake checklist so the exact AP family and processing scope remain clear throughout the task.

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