Operational technology is the equipment that does the work: the systems that steer a ship, trip a breaker at a substation, or sit in the path to command a satellite.
The attack that matters against OT does not look like an attack.
It looks like expected traffic. A valid command, right protocol, right port, from an authenticated account. There is no malformed packet, no malware signature, no exploit to point at. The only thing wrong is that the command came from a system that had no business sending it, or at a moment when nobody should have sent anything.
Your sensor sees that traffic and reports a healthy network. It is not wrong. It just has no idea what the operation was supposed to be doing that day.
A ground station and a ship share the same three problems
A ground station, a ship at sea, and a water treatment plant have almost nothing in common. Ask any of them how they would spot an attacker already inside, using their own systems against them, and the same three problems come back.
First, these sites are isolated. Connectivity is bad or absent, shipping everything to a cloud or a SOC for analysis is normally off the table, and the only people on site are the operators already busy running it.
Second, malicious activity looks exactly like legitimate activity. Open the packet and nothing in it says anything is wrong.
Third, what tells you a command is wrong is not in the packet at all. It is in the plans the site already keeps, the ones that say what is supposed to happen and when.
A ground station keeps a contact schedule, the times it is actually talking to a spacecraft, plus a list of which systems may send commands at all. A command that shows up when no pass is open, or from a system not on that list, is wrong even though the command itself is valid.
On a ship, the voyage plan says what it should be doing at each point in the passage, and control of systems like ballast and propulsion is handed between stations, so only one holds it at a time. A ballast change from a station that does not hold control, or one that makes no sense for where the ship is in its voyage, is wrong.
A plant has an approved operating range and a maintenance schedule. A value pushed past that range, or a change made outside a maintenance window, is wrong.
Hold the live traffic up against those plans, and a command that looked like expected traffic stops looking normal.
You will not learn any of that by baselining traffic for a week. The operators know it, and your detection needs to too.
Governments have reached the same conclusion. In August 2025, CISA, the NSA, the FBI and partners across six countries published joint guidance on OT asset inventory, telling operators to keep an authoritative list of their own equipment, down to protocols, ports, and how critical each asset is. That is the exact context a hunt has to read.
A SOC would never see this
Most people hear "sensor on the network" and picture a security operations center. Hunting and a SOC do different jobs.
A SOC waits to be told. Something trips a rule, it drops into a queue, an analyst decides whether it is real. EDR on the hosts and a managed MDR service run the same loop, just with the queue in a different place. That works for most networks, but it assumes a vendor shipping signatures, a link back to a SIEM or a cloud, and people to keep a queue moving around the clock. Run it against a ground station and nothing trips: the command was valid, the account authenticated, the protocol was correct. A quiet queue looks exactly like a quiet night.
Hunting starts somewhere else. You assume they are already inside and go looking, asking what an intruder would look like on this network and whether you could see them from where you stand. MITRE published this process for US Cyber Command as TTP-Based Hunting: model how an adversary behaves, turn it into testable hypotheses, work out what data each needs, and only then check whether you can collect it at all. That last step, identify and mitigate collection gaps, is the one everybody skips, and the one that decided whether our range exercise worked. Splunk's PEAK framework says the same thing with different labels.
This works alongside a SOC, not instead of one. A hunt turns up detections the SOC can keep running on its own, covering ground their tooling was never placed to reach.
OUTPOST, our deployable hunt kit
We built it small and portable, to carry to those sites and run with no internet connection. On the operational network it stays passive, reading a copy of the traffic and never transmitting onto it; on the hosts it can do more, pulling logs and checking state when an operator clears it. Either way it collects what an investigation needs: packets, host logs, and protocol activity.
It does not touch mission or operational systems on its own; anything that could affect them is an operator decision. When you are done it builds a signed evidence package you can carry out, every file hashed into a manifest, so if a byte changes later the verification fails and names the file. It exports those findings to common formats, so the results slot into the standards an enterprise already runs on.
The base platform does not care whether you are in space, at sea, or in a plant. The domain knowledge loads separately, as packs: what counts as normal for a site is data you hand it, not logic we hardcoded. Findings map to whatever framework fits the work, for example SPARTA in space and MITRE ATT&CK for ICS in industrial settings.
How you would know a space system is compromised
Space is the environment we have built out and tested so far, most of it against IRON GALAXY, our own space cyber range. Every signal below comes off the ground network.
A telecommand on the wire when no contact window was scheduled. There is no legitimate reason to command a spacecraft outside a scheduled pass. SPARTA tracks this as malicious commanding via a valid ground station, IA-0007.02, and command packet replay, EX-0001.01.
A telecommand from a source that is not a mission control host. Commands should only come from mission control, so a valid-looking command from any other source is unauthorized.
A command identifier that is not in the mission's approved set. The mission uses a fixed set of commands, and an identifier outside that set does not belong.
A Space Link Extension session from a peer that is not in the baseline, or a known peer asking for a service it was never provisioned for. SPARTA tracks this as the rogue ground station pattern, IA-0008.01.
Telemetry sequence counts that stop being contiguous. A gap means either real packet loss or traffic the sensor cannot see from where it sits.
An onboard alert that lines up in time with something on the ground network. Either one alone is ambiguous; correlated in time, they point to the same event.
Not one of those needs a malformed packet. Every one of them needs the contact schedule, the authorized hosts, and the approved command set.
Proving the detections work
We tested OUTPOST against real spacecraft flight software. NASA's core Flight System is open source, so we deployed version 7.0.1 on a test range, commanded it, and checked our decoder against an independent reference decoder. The two agreed on all 115 packets, by type, identifier, and sequence, across 20 telemetry identifiers with contiguous counts and no false gaps. Of the 115, 112 were telemetry and three commands; the detections fired on all three and stayed quiet on the 112.
The same capture found two problems. Our first version suppressed repeat alerts by sender, target, and command identifier, so two commands sharing an identifier but different function codes collapsed into one alert. The key now includes the function code. We had also carried the telemetry port over from an older configuration; current cFS sends it elsewhere.
Each finding went back into the build. That is how we have developed OUTPOST, one real test at a time.
We also ran OUTPOST against live IRON GALAXY traffic while the range team ran attacks. That run taught us that placement decides what a sensor sees: to catch a command, the sensor has to sit where that command travels, so we walk the network before we write rules.
Where the AI model helps the analyst
The network, hosts, and telemetry produce more than a small crew can read in a night, so a local AI model reads it with them. It is fastest at the first pass, drafting an investigation in about a minute for the analyst to check and refine, and most useful at pulling host events, network records, telemetry, and artifacts into one account of what happened. That correlation is the slow part to do by hand, and it is what the model takes on. Ask it to summarize the top APIDs, the SLE peers, and any out-of-pass telecommands, and the result shows each claim tied to the record that backs it, with anything unsupported flagged.
Find what your sensors miss
When a cloud platform cannot reach your network, the usual detection tooling cannot run there, and an attacker sending valid commands from the wrong place sets off no alerts. OUTPOST closes that gap.
If you want to know what it would catch on your network, let's talk. You can also see IRON GALAXY and our platforms or read about Terrain Trace.
