AI
The Nanosatellite Explosion and Why It Creates Risk
Nearly 3,000 nanosatellites have launched as of 2025, roughly nine per day, and about 90% are CubeSats. Each one costs $50,000 to $150,000 to build, which is what makes them accessible to universities, startups, and hobbyists. That same price floor is also why security gets cut first. With tight budgets, tight deadlines, and hardware too small to run a security stack, builders optimize for a successful launch. Components bought off-the-shelf from manufacturers of uncertain provenance go straight onto the board. Nobody asks how secure they are.
Structural Weaknesses Baked Into the Hardware
Tight budgets and compressed launch schedules mean security gets cut first. Most cubesat OBCs use off-the-shelf components, many sourced from China, with no guarantee of secure defaults. When a developer opens the firmware and leaves a comment reading “I’m too lazy to check” next to disabled readout protection, that’s not an outlier — Open-source cubesat code with ‘too lazy to check’ comment (09:52) — it was repeated throughout the same repository. There’s also no OS standard: some teams run FreeRTOS, Nanyang Technological University’s group uses embedded Windows, and one Japanese team launched a modified Arduino.
25 Years of Satellite Attacks and What They Show
The incident list runs from 1999 to 2024. In 1999, a teenager breached NASA systems and triggered shutdowns, an embarrassment NASA never fully acknowledged. Search “NASA cyber attack” today and you find they were breached again. The 2024 Intelsat case is murkier: a satellite was lost mid-mission and whether a cyber incident caused it remains unresolved. Given what the hardware lacks by design, the question is not paranoid.
Choosing the Right Threat Modeling Frameworks
STRIDE is built for software. CubeSat OBCs are embedded hardware in orbit, so the team picked MITRE EMB3D, released September 2024, which maps device properties to threats to mitigations in machine-readable STIX 2.1 format. TARA scores those threats numerically. With a constrained budget you cannot mitigate everything, so you need a ranked list.
“if you don’t have memory management you don’t have any process isolation or any sort of user kernel separation.” — Donovan
Standard IT assumes on-demand patching. A satellite on the far side of Earth cannot receive an uplink. Every call has to be made before launch.
Applying EMB3D and TARA to a Real CubeSat OBC
The team fed CubeSat OBC properties — CPU, memory, debug ports, bootloader — into EMB3D’s property mapper, which returned matching threat IDs. TARA scored each threat on five weighted factors. T119 scored 3.0, the highest in the model. T119 highest-risk threat: latent debug port (32:30)
“Latent uh latent debug ports and hardware interfaces are extremely dangerous.” — Klara(ChaeYoung) Kim
JTAG and SWD ports give full memory access during manufacturing and student lab work before launch. Firmware backdoored at that stage is permanent — no physical recovery once in orbit. The fix: disable debug ports and enable hardware readout protection before launch. To automate the analysis, the CubeSat ATCK compliance kit ingests an OBC datasheet as JSON and outputs a ranked threat and mitigation list. CubeSat ATCK compliance kit demo (35:57)
What Comes Next: Hardware Testbed and Responsible Disclosure
Team SATCRACK has not hacked an orbiting satellite. The threat model came first. Now the team is building a physical hardware testbed to validate the attacks before any disclosure. That sequence, model then test then disclose, is the only responsible path when the target cannot be patched after launch.
“a single overlooked vulnerability on Earth can become permanent uncomfortable uh failure in orbit.” — Klara(ChaeYoung) Kim
“security by design isn’t about adding heavy security. It’s about making sure satellites can carry out their mission safely once they’re in orbit.” — Klara(ChaeYoung) Kim
Q&A
Once in orbit can a nanosatellite be hacked from the ground, or is it unreachable? Pre-launch is the higher-risk window because the satellite is physically accessible and, as the speaker noted, a cubesat often carries payloads from multiple groups simultaneously, making it a multi-tenant system with shared exposure before it ever reaches orbit. ▶ 39:58
What does the SATCHECK tool input file actually contain? The input file is the OBC datasheet organized into JSON, which the tool ingests to map properties against the EMB3D framework and output a prioritized threat list. ▶ 41:44
What is the probability that the patch uplink channel itself gets compromised? The speaker said the communication channel appears not to be the primary attack vector based on available public research, but flagged the bigger operational problem as the limited uplink window forcing teams to choose between sending patches and other mission-critical payloads. ▶ 42:45
Notable Quotes
a single overlooked vulnerability on Earth can become permanent uncomfortable uh failure in orbit. Klara(ChaeYoung) Kim · ▶ 37:52
security by design isn’t about adding heavy security. It’s about making sure satellites can carry out their mission safely once they’re in orbit. Klara(ChaeYoung) Kim · ▶ 38:56
Latent uh latent debug ports and hardware interfaces are extremely dangerous. Klara(ChaeYoung) Kim · ▶ 32:40
if you don’t have memory management you don’t have any process isolation or any sort of user kernel separation. Donovan · ▶ 17:48
Key Takeaways
- Disable all debug ports and enable hardware readout protection before launch — these are not optional.
- Score threats with TARA’s five-factor model first; nanosats cannot afford to mitigate everything.
- Pre-launch handling, not in-orbit RF attacks, is the primary attack window for cubesat firmware.
About the Speaker
Klara(ChaeYoung) Kim
Klara (Chaeyoung) Kim is a cybersecurity researcher and BoB (Best of the Best, Korea) program alumna with a Bachelor’s degree in Information Security. As a GCC (Global Cybersecurity Camp, Taiwan) student and NDSS(San Diego) workshop presenter, she specializes in threat modeling and consulting across emerging technologies including robotics and CubeSats. Her work bridges technological security frameworks and global compliance standards, focusing on proactive strategies for securing embedded systems in high-risk environments.