Field guide
How to Reset a Fly-Away Kit to a Known-Good Baseline
To reset a fly-away kit between missions, destroy the mission machines that held the last team's work and rebuild them from the same source used at delivery, leaving the kit's core services alone. Review exactly what is in scope first, refuse to start if anything cannot be rebuilt, and run validation afterwards to prove the baseline is back.
Why kits drift between missions
Every mission leaves something behind: configuration changes, accounts, collected data, half-finished tooling and machines left powered off. The next team inherits all of it unless someone puts the kit back the way it was delivered.
The usual answers are slow. Re-imaging by hand needs an engineer and a checklist, and sending the kit back to a depot takes it out of service. Both depend on people remembering every step.
What a good reset does
A good reset rebuilds rather than cleans. Mission machines are destroyed and recreated from a known-good definition, so nothing from the last deployment carries forward. The services that keep the kit usable, such as identity, name resolution and the management console, stay up throughout.
It is also predictable. The operator sees the scope before confirming, the reset refuses to start if any machine in scope cannot be rebuilt, and a run that stops partway says so plainly instead of reporting success.
How Rhombus resets a kit
Rhombus factory reset destroys the machines in scope and rebuilds them as one job, from version-controlled code, back to the delivered baseline. Core infrastructure is never touched, and custom machines created on the kit are left alone. An in-scope machine that has gone missing is rebuilt. Each rebuilt machine ends powered on and set to start with the kit.
The scope ships with sensible defaults and can be reviewed and edited in the console. The threat-intelligence platform is kept by default, so its data survives; including it is a deliberate choice. Before destroying anything, the reset checks that every machine in scope can be rebuilt on that kit, and it refuses rather than starting if the scope is empty. Integrations between rebuilt services are re-applied at the end, and every reset is written to the audit trail.
A reset does not update the kit. To take new software, apply an update bundle first, then reset for a clean baseline on top of it. Expect a full reset to take an hour or more.
What a reset is not
A reset rebuilds machines; it is not media sanitization. Destroying a machine deletes its disk image, but it does not cryptographically erase that image separately from the rest of the kit. On current-generation kits, a reset also leaves the kit's full-disk encryption key unchanged. Shared storage that mission services use for landed files is not reset either. Where an accreditation requires provable erasure, plan for the media sanitization procedure available on current-generation kits.