Picture a Monday morning flight to a remote compressor station. The operator wants a full OT security assessment. The corporate network can’t reach the site. The control system hasn’t been touched since 2014. There are three days on site, and whatever isn’t seen this week likely won’t be seen again for another year.
This is exactly the situation a flyaway kit is built for. Not the tabletop exercise version of OT, where everything lives on a slide deck, but the real-world version, where the control room runs hot, the site engineer is skeptical of anyone from IT, and the permanent monitoring infrastructure most assessments assume just doesn’t exist.
Flyaway kits emerged from years of on-site OT assessments, incident response engagements, and work in environments where permanent monitoring was never an option. Most teams used to assemble their own. Over the last few years, the category has matured into purpose-built tooling. For teams performing OT assessments, responding to incidents, or operating in environments with limited connectivity, this guide covers what flyaway kits actually are, when they make sense, how they get used in the field, what to look for when evaluating one, and how they fit into compliance programs like NERC CIP-015. Insane Cyber’s Cygnet flyaway kit is referenced as a working example throughout because the implementation details are where most of the real differences show up.
What is a flyaway kit?
A flyaway kit combines three capabilities into a single case: a portable computer powerful enough to run OT security analytics, a set of network capture interfaces that can tap into an industrial network without disrupting it, and enough local storage to retain every packet collected for the duration of an assessment.
That last point is where the category gets underestimated. An OT assessment is rarely a quick packet sniff. Captures often span 5 to 30 days because low-and-slow attacker behavior and the natural rhythms of industrial protocols only emerge over time. A standard laptop with a 500GB SSD can’t hold that volume of data, and it can’t run the protocol parsing, anomaly detection, and baseline analytics needed to make sense of it.
A mature flyaway kit typically includes:
- Ruggedized compute. Hardware rated for industrial temperatures where possible, capable of running continuously in dusty control rooms, and often powered through a UPS. Portability matters as much as ruggedness. A true flyaway kit fits in carry-on luggage and doesn’t require gate checks or freight shipping.
- Network interfaces for both SPAN and inline TAP. Both are necessary because many sites either lack available SPAN ports or are unwilling to reconfigure switches.
- Large, high-throughput local storage. Enough capacity and write performance to capture weeks of full packet data at line rate without packet loss.
- A preloaded analysis stack. Including protocol parsers for real-world ICS protocols such as Modbus, DNP3, OPC UA, IEC 104, and Ethernet/IP, along with detection and analytics workflows designed specifically for OT traffic.
- Host data collection capabilities. Mature kits don’t rely solely on network traffic. They also collect data from engineering workstations, historians, and jump servers.
- Wireless and cellular are disabled by default. In many OT environments, enabling these interfaces is either disallowed or heavily restricted.
Cygnet sits in this category as a purpose-built appliance. It runs the full Valkyrie analytics stack locally on the device, with no dependency on cloud services or internet connectivity. That architectural decision becomes critical in real-world OT environments.
When to use a Flyaway Kit vs. Permanent Monitoring
Permanent monitoring and flyaway kits are not interchangeable. They address adjacent but distinct problems, and mature OT security programs often use both.
Permanent monitoring is the right choice for environments with stable architectures, known asset ownership, predictable change cadence, sufficient budget for sensors at each collection point, and the organizational maturity to respond to continuous alerts.
Flyaway kits are most effective when:
- A site is being assessed for the first time. A short-term deployment can establish the asset inventory, protocol usage, and baseline behavior needed to design a permanent solution.
- The site won’t accept permanent hardware. Common in leased facilities, joint ventures, transitional assets, or environments resistant to long-term third-party devices.
- An incident response is underway. A flyaway kit provides passive visibility into potentially compromised environments without introducing additional risk.
- Small teams cover many remote sites. Rotating a limited number of kits across multiple facilities provides broader visibility at a fraction of the cost of permanent monitoring everywhere.
- A new platform or vendor is being evaluated. A flyaway deployment offers empirical evidence of how analytics perform on real OT traffic before a long-term commitment.
Mature programs use permanent monitoring for priority sites, flyaway kits for the rest, and flyaway kits first for environments that haven’t yet been assessed.
Read more about Strategic vs. Tactical Monitoring for OT environments.
Air-gapped and No-Cloud Environments
This is where true flyaway kits clearly separate themselves from laptops in padded cases.
Most modern security tools assume some form of internet connectivity for threat intelligence updates, cloud-based analytics, telemetry streaming, or management. Those assumptions break down immediately in air-gapped or tightly controlled OT environments.
And those environments are common. Refineries with physically separated networks. Nuclear facilities with restrictive egress policies. Classified and defense systems. Naval vessels. Offshore platforms with metered satellite links. Plants operating under strict safety or SIL boundaries.
In any of these settings, a cloud-dependent tool becomes a liability. A system attempting to beacon out can fail silently or trigger alarms that turn a security assessment into an incident.
A true flyaway kit processes everything locally:
– Protocol decoding is performed on-device.
– Baselines and anomaly detection are computed locally.
– Threat intelligence updates, when used, are applied manually via signed offline packages.
– No data leaves the device during collection.
– Exports are generated only after customer review and approval.
Cygnet was designed around this model from day one, running the full analytics pipeline locally with no external dependencies during operation. That approach also provides determinism. Operators can clearly explain data flows, answer change control questions, and attest that no site data left the network. Those are requirements that cloud-native architectures simply cannot meet.
Federal and tactical use cases
The fully offline requirement explains why flyaway kits have seen strong adoption in federal and tactical environments.
Defense, intelligence, and allied military OT programs require that any system entering sensitive environments operate without external connectivity. Consultant laptops running ad hoc open-source tools rarely provide the structured, auditable output these customers need.
Flyaway kits fill that gap by combining offline operation with standardized reporting and rugged, field-ready hardware.
Common use cases include:
– Forward-deployed OT assessments at military installations
– Baseline collection on classified industrial systems
– Tactical ICS deployments supporting weapons systems or expeditionary infrastructure
– Allied partner engagements where cloud-connected tools are legally restricted
Cygnet has been deployed in these exact scenarios, which is one reason purpose-built flyaway kits continue to gain traction across federal OT programs.
A typical assessment workflow with a flyaway kit
Flyaway kits are powerful, but they aren’t magic. Effective results depend on disciplined workflows.
- Pre-deployment. Scope the assessment, review available diagrams (or prepare to build them on site), confirm physical access and safety requirements, validate the kit’s state, and document its configuration for later attestation.
- Arrival and site walk. Walk through the facility with the site engineer to identify network boundaries, aggregation points, available SPAN ports, engineering workstations, and deviations from documented architectures. This phase is as much about building trust as it is technical discovery.
- Connection. Begin with passive collection. Validate SPAN configurations carefully and coordinate any TAP installations during approved maintenance windows.
- Collection. Deploy the kit for at least three days. Five to seven is typical, and ten to fourteen days provides visibility into weekly operational cycles. Daily health checks are essential.
- Active collection (if scoped). When permitted, controlled active queries can supplement passive data, provided they are logged, approved, and auditable.
- Host data collection. Engineering workstations, historians, jump servers, and HMIs often contain critical artifacts that never appear on the network. Comprehensive assessments include host data collection and correlation.
- Analysis. On-device analytics allow findings to be reviewed while still on site, enabling immediate validation with local engineers.
- Export and departure. Exports are reviewed and approved before removal. In sensitive environments, devices may be wiped on site, leaving only approved reports behind. Chain of custody is documented throughout.
The Flyaway Kit Buyer’s Checklist
When evaluating flyaway kits, the following questions quickly separate purpose-built solutions from repackaged laptops:
1. Is it truly portable? And how easy is it to transport?
2. Does it run fully offline?
3. Which ICS protocols are actually parsed?
4. Does it collect host data as well as network traffic?
5. How much storage capacity and write performance does it provide?
6. Are active queries supported with a full audit trail?
7. How do baselines and analytics actually work?
8. What do exports and reports look like?
9. How is licensing structured?
10. How is the kit itself secured?
Cygnet was designed to meet these requirements because they reflect real field constraints. The same checklist applies to any option in this category.
NERC CIP and Flyaway Kits
NERC CIP-015 mandates internal network security monitoring for high- and medium-impact BES Cyber Systems, with expanding scope under CIP-015-2. Permanent monitoring is driving widespread sensor deployment, but assessments still precede deployment.
Flyaway kits support CIP programs by establishing baselines, discovering assets, identifying protocol use, and informing INSM architecture. For low-impact sites that don’t require permanent monitoring, rotating flyaway assessments provide defensible visibility and evidence.
During audits, recent flyaway assessment outputs complement permanent monitoring data and demonstrate active security management across the fleet.
Flyaway Kits vs. a Laptop and Wireshark
DIY approaches have their place, but they don’t scale.
Laptops work for short, targeted captures. They fail at multi-day collections, host visibility, analytics, correlation, repeatability, auditability, and reporting. Over time, analyst labor costs dwarf the capital cost of a proper kit.## A category, not a stopgap
Flyaway kits address structural realities of OT environments: resistance to cloud connectivity, regulatory pressure, constrained budgets, and limited skilled staff. None of those pressures is easing.
For asset owners, flyaway kits complement permanent monitoring. For consulting teams, they enable repeatable, defensible assessments. For regulated industries, they bridge visibility gaps with audit-ready output.
Insane Cyber built Cygnet to meet these demands: fully offline operation, field-ready portability, and analytics that both customers and auditors can trust. For teams evaluating flyaway kits or integrating them into an OT security program, the category has matured into a core capability rather than a workaround.
