Case file · NASA JPL 2018

How a Raspberry Pi let hackers into NASA's Jet Propulsion Laboratory

Published 2026-09-29 · 4 min read · Missing control: Complete inventory of connected devices

The attackers who spent nearly a year inside NASA's Jet Propulsion Laboratory got their start through a credit-card-sized computer that nobody had approved to be on the network.^[1]^[3] This case file covers what happened, why the lab's own records could not see the device, what the government watchdog found, and the one control that was missing.

What happened

The Jet Propulsion Laboratory in Pasadena, California, is a federally funded research center that NASA relies on to build and fly robotic spacecraft such as its Mars rovers. It also runs the Deep Space Network, the set of giant antennas used to talk to missions far from Earth.^[1]

In April 2018, the lab found that the account of an external user, someone outside JPL who had been given access to its systems, had been compromised. When investigators traced the intrusion, they found it had gone undetected for nearly a year, which puts the start around mid-2017.^[1]

The entry point was a Raspberry Pi, a small, inexpensive hobbyist computer, that had been attached to the JPL network without authorization.^[1]^[2]^[4] From there the attacker reached 2 of the lab's 3 primary networks, including the Deep Space Network, and took about 500 megabytes of data from 23 files.^[1] Two of those files held information controlled under the International Traffic in Arms Regulations, the U.S. export rules for military and space technology, and related to the Mars Science Laboratory mission, the one that carries the Curiosity rover.^[1]

How they got in

JPL kept a database meant to list every system and device on its network, along with who owned it and what it did. The watchdog found that list was incomplete and not always accurate. System administrators did not consistently add new devices, and the Raspberry Pi was one example of something connected but never recorded.^[1] A device that is not on the list does not get reviewed, patched or watched, so when it was used as a doorway, no one was looking at it.

The second problem was what lay behind that doorway. The lab's network was not divided into well-separated zones, so once inside, the attacker could move from one area to another instead of being stuck where they started.^[1] JPL also shared a network gateway with other parts of NASA, which is why the incident worried people far beyond Pasadena.^[1]

The report did not publicly say who was behind the intrusion.^[1]

What it cost

The biggest cost was trust between NASA sites. In May 2018, Johnson Space Center in Houston, which runs human spaceflight programs, temporarily cut its connection to the shared gateway out of concern that the attacker could move from JPL toward its systems.^[1] Johnson also stopped using Deep Space Network data over reliability concerns and did not fully restore those communications until March 2019.^[1]

NASA's Office of Inspector General published its audit on June 18, 2019.^[1] Beyond the inventory and segmentation gaps, it found that known security problems were sitting unfixed: in the sample it reviewed, 181 security log tickets had been open for more than 180 days.^[1] The lab also had no formal threat-hunting program, meaning no team was routinely searching the network for intruders who had slipped past the automatic alarms.^[1] The report made 10 recommendations, and NASA agreed with 9 of them.^[1] No one was publicly charged over the 2018 intrusion.

The missing control

The missing control: a complete inventory of every device connected to the network, with unknown devices flagged or blocked automatically.

You cannot protect what you do not know you have. If JPL's records had matched what was actually plugged in, the Raspberry Pi would have shown up as an unapproved device the day it appeared, and someone would have had to explain it or unplug it. Even if it had been approved, being on the list would have meant it got the same patching and monitoring as everything else. Stronger separation between network zones would have been the backup, keeping a single weak device from becoming a route into mission systems. Together, those two controls would likely have stopped this early or kept it small, instead of letting it run for nearly a year.^[1]

What to do in your business

Make a list of everything that connects. Walk the office and check your router's list of connected devices. Write down every computer, phone, printer, camera, smart TV and gadget, and who is responsible for it.
Chase down every unknown. Anything on the router list that you cannot name should be identified or disconnected. Repeat the check once a month.
Separate guests and gadgets from business systems. Put visitors, smart devices and personal phones on a guest network so they cannot reach the computers that hold customer data or run payments.
Set a rule for new devices. Tell staff and contractors that nothing gets plugged into the office network without a quick OK and an entry on the list.
Put a deadline on security fixes. When your IT person or provider flags a problem, give it a due date and review anything older than 30 days.

Watch the case

The tiny unauthorized computer that let hackers into NASADrops 2026-12-03

Close the same gap

Check your business for this control

The free Heist Control Checklist walks through the controls behind every case on this site in about ten minutes. For ready-made policies, the Policy Pack has five editable templates, and the Insider Threat Kit covers risks from inside your own team.

Free checklist Policy Pack ($19) Insider Threat Kit ($29)

More patching and monitoring cases

Facts are drawn from court records, government reports, company statements and reputable reporting, listed below. People are named only where they were convicted, pleaded guilty or spoke publicly in an official role.

Sources