Why Rhombus
Stop shipping kits back to the depot.
The deployable cyber market has competed on hardware and setup speed. But missions don't fail on day zero. They fail on day 30, when the kit is out of date, drifting from its baseline and waiting on a vendor engineer. Rhombus is built for every day after deployment.
Across the mission
The questions that matter change after you deploy.
New to the term? Start with what a fly-away kit is and what to look for in one.
Day 0
Can we stand it up?
Factory-integrated, then frozen. Setup speed is the headline.
Mission packages deploy from one console, built from version-controlled code, so every kit is identical.
Day 1
Is it actually working?
Powered on is treated as done.
Validation checks every critical service and sensor, self-heals failures and exports an acceptance report.
Day 30
Is it current?
Updates need reach-back, a site visit or a trip back to the depot.
Signed offline bundles applied from USB or upload. Atomic, with a rollback point kept.
Day 90
Can we prove it to the assessor?
Compliance evidence is gathered by hand, if it exists.
On-demand STIG scans with ARF, HTML and STIG Viewer evidence. A full audit trail of every change.
Next mission
Can the next team start clean?
Re-image by hand, or ship it back.
Factory reset rebuilds mission services to the delivered baseline, with core infrastructure untouched.
What we mean
The words in our name, defined honestly.
Autonomous
Rhombus runs its whole lifecycle with no reach-back: no cloud, no license server, no vendor on site. Your operators stay in control of every defensive action.
Mission assurance
Not just "deployed", but validated, current and provably in its known-good state, on every kit and for every team.
Contested & disconnected
Designed to operate fully air-gapped, in austere and DDIL conditions, and at forward sites. Repositories sync only when a connection is approved.
For program offices
Fleet consistency is a software problem.
Buying the same part number twice gets you identical kits on the day they ship. It doesn't keep them identical in the field. Rhombus kits are built from the same version-controlled code, receive the same signed sustainment bundles and reset to the same baseline, so a fleet stays a fleet.
- Lower sustainment cost: patch and re-baseline in place instead of shipping kits back and forth
- Faster operator readiness: one console and one training path for every kit
- Accreditation support: repeatable builds and exportable evidence for your RMF package
Field guides
Field guides to every day after deployment.
- How to Reset a Fly-Away Kit to a Known-Good BaselineHow to return a fly-away kit to a known-good baseline between missions: rebuild mission machines from code, protect core services and check the result.
- Kit Acceptance Testing: Proving a Deployable Kit's Sensors WorkHow to validate a deployable cyber kit and produce an acceptance test report: check every service, prove the sensors see traffic and record sign-off.
- Offline Patching for Air-Gapped Fly-Away Kits, With RollbackHow to patch an air-gapped fly-away kit offline: signed update bundles, verification before anything changes, and a rollback point for every apply.
- STIG Evidence for a Deployable Kit's RMF PackageHow to produce DISA STIG scan evidence for a deployable kit: ARF results, STIG Viewer imports, documented deviations and a PDF your assessor can file.
See the full lifecycle in 90 minutes.
Our end-to-end briefing takes a Rhombus kit from power-on through detection, investigation, evidence export and reset to baseline. It runs on real hardware, fully offline.