CliDeck
PlatformLog in
Workspace

MikroTik supout.rif Before Wipe: Diagnostic Evidence Without a False Clean-State Claim

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

Short answer

Create supout.rif before reset only when the owner authorizes diagnostic preservation. It is a binary RouterOS support artifact containing configuration and diagnostic context. Download it to restricted storage, associate it with the correct asset, and verify the file before erasing the device. A support file is neither a restoration plan nor evidence that the router is clean.

When the file helps

A support capture is useful when an intermittent fault, startup issue, or software behavior must be investigated after refurbishment begins. It preserves a snapshot tied to that capture moment. It cannot establish that every port passed a hardware test or that the fault has been resolved.

If the device arrives already reset, state that the original configuration is unavailable. If preserving customer information is prohibited, do not collect the file. Record a capture exception and use permitted non-sensitive grading observations instead.

Generate the artifact through authorized access

For a reachable RouterOS device, use the console command:

/system sup-output name=supout.rif

The file can also be generated through WinBox or WebFig. Download the completed file using your approved management method. On applicable flash layouts, a full path such as flash/supout.rif controls where the artifact is stored.

Before generation, note the RouterOS build, model, symptom, and time. After generation, inspect the file listing:

/file print

Do not overwrite a previous diagnostic snapshot unless retention policy permits it. Use separate private filenames when collecting before and after states, and make the distinction explicit in the job record.

Verify the downloaded copy

The report being visible on the router is not enough. Check that the workstation copy exists, has a plausible non-zero size, and belongs to the intended asset. Calculate a checksum if your evidence process needs an integrity record:

shasum -a 256 supout.rif

Keep the digest beside the capture metadata. If using a support viewer is authorized, ensure the artifact can be read there. Do not upload customer-derived diagnostics to an unrelated service or a public troubleshooting forum.

Verification note: password omission does not make the file public

The support output format omits router passwords, but configuration and diagnostic details can still identify the customer and network. Apply restricted handling to the entire artifact.

Before processing proceeds, answer four questions:

  1. Was collection authorized?
  2. Is the downloaded file complete enough for the stated purpose?
  3. Is the device and time association reliable?
  4. Is retention and later deletion assigned to someone?

A missing answer means capture is incomplete, even if the command returned successfully.

Separate diagnostics from wipe evidence

Keep pre-reset diagnostics in a private evidence location. After reset or reimage, produce a separate checklist showing the selected method, normal startup, configuration baseline, file disposition, and any external-storage exceptions.

Do not load a diagnostic file or old backup into the refurbished router to prove that it can restore the customer state. That is a different, owner-approved task and would undo clean-state preparation.

CliDeck Workspace can record the command and operator notes. Continue with the reset versus Netinstall decision guide, and keep the raw support file out of public transcripts and resale listings.

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