How Satellites Are Built: Bus, Payload, Testing and Flight Software

A satellite is built as two parts: a payload that does the mission (a camera, a radio, a science instrument) and a bus that keeps the payload alive (power, attitude control, propulsion, thermal control, structure, a flight computer and radios). Teams assemble both from qualified parts, prove the whole vehicle on the ground with vibration, thermal vacuum and electromagnetic tests, license its radio and debris plans, and run it with flight software and a ground segment that sends commands and collects telemetry.

This guide goes one level deeper than our overview of how a spacecraft gets to space. It walks through each bus subsystem, the CubeSat form factor and what fits inside it, component grades and radiation, the test campaign with real numbers from NASA's Goddard standard, the ground segment, the US and international licensing path, the two best known open source flight software frameworks, and the cybersecurity guidance that now applies to builders. Every figure below comes from a primary source we fetched and checked in October 2026, listed at the end.

Key takeaways

• Bus plus payload. The bus is the common platform (power, attitude determination and control, propulsion, thermal, structure, command and data handling, communications). The payload is what the customer pays for. Many small satellite buses are bought off the shelf and the payload is integrated onto them.
• CubeSats are a mechanical standard, not a mission type. The Cal Poly CubeSat Design Specification (Rev. 14.1, February 2022) defines a 1U as a 10 cm cube with a typical maximum mass of 2.00 kg, scaling to 6.00 kg for a 3U, 12.00 kg for a 6U and 24.00 kg for a 12U.
• Parts grade is a risk decision. NASA's 2026 small spacecraft report notes that space qualified parts are often rated from minus 55 to plus 125 degrees Celsius with radiation testing, while commercial parts are usually rated from minus 40 to plus 85 degrees Celsius with less screening. Most CubeSats fly commercial parts, or a mix.
• You launch it on the ground first. NASA Goddard's GEVS standard sets generalized random vibration levels of 14.1 grms for qualification and 10.0 grms for acceptance on components of 22.7 kg or less, thermal vacuum margins of 10 degrees Celsius beyond the allowable flight temperatures, and a workmanship goal of at least 12 thermal cycles before flight.
• Licensing runs in parallel with engineering. In the US, the FCC licenses the radio and reviews debris plans (with a streamlined path for small satellites under 47 CFR 25.122), the Commerce Department licenses private remote sensing, and the ITU records frequency assignments internationally. Low Earth orbit satellites launched after 29 September 2024 must be disposed of within five years of mission end under the FCC's rule.
• Flight software is open source software with a supply chain. NASA's cFS (Apache 2.0, C) and JPL's F Prime (Apache 2.0, C++) are widely used frameworks. cFS states that fixes are not backported to older releases, and F Prime's Python tooling pins 81 packages in its requirements file. Those dependencies need the same inventory and patching discipline as any other software.
• Cybersecurity guidance now names builders. Space Policy Directive 5 (September 2020), NIST IR 8270 (July 2023) and NIST IR 8441 (September 2023) ask for authenticated or encrypted command links, secure development practices, supply chain risk management and a recovery plan if the command link is attacked.

From raw material to a satellite in orbit: the step table

The table below follows one small satellite from raw stock to operations. Durations vary widely. NASA's CubeSat 101 guide (revision dated October 2017) says a CubeSat "can be designed, built, tested, and delivered in as little as 9 months" but typically takes 18 to 24 months, and that launch providers usually want the finished spacecraft between 4 weeks and 6 months before launch.

Timeline: the dates that shaped how small satellites are built

What are the subsystems of a satellite bus?

NASA's 2026 State of the Art of Small Spacecraft Technology report is organised by subsystem, and its chapter list is a good map of a bus: complete spacecraft platforms, power, in space propulsion, guidance navigation and control, structures materials and mechanisms, thermal control, small satellite avionics, communications, launch and deployment, and ground data systems and mission operations. Here is what each one does and the design questions it raises.

Electrical power system (EPS)

The EPS generates, stores, regulates and distributes power. Solar cells are the source, lithium based batteries carry the satellite through eclipse, and a power management and distribution (PMAD) board switches and protects each load. NASA's report draws a clear contrast: a 10 kg CubeSat with limited surface area typically uses fixed body mounted solar cells, small batteries and a single low voltage bus, while a 150 kg microsatellite can carry deployable arrays, larger batteries with redundancy and multiple regulated buses. The report also notes that commercial 18650 cylindrical cells have flown on several CubeSat and nanosatellite missions, and that commercial PMAD units can reduce integration work but vary in which protection features they include.

The design questions are an orbit average power budget (how much the payload draws, how long the eclipse lasts), battery depth of discharge over thousands of cycles, and fault protection so one shorted load cannot take down the bus. The CubeSat Design Specification adds launch safety rules on top: the power system must be off from delivery to the launch vehicle until deployment, a deployment switch must cut power to every powered function while the satellite sits in the dispenser, and a remove before flight (RBF) pin must cut all power when inserted.

Attitude determination and control (ADCS) and GNC

ADCS knows which way the satellite points and turns it. Sensors include sun sensors, magnetometers, gyroscopes, star trackers and GNSS receivers; actuators include reaction wheels, magnetorquers and, on larger craft, thrusters. Pointing accuracy is set by the payload: a broad beam radio needs little, an Earth imaging camera or an optical terminal needs a great deal. NASA's report lists radiation tolerance (in krad) as a column in its tables for wheels, magnetorquers, star trackers and GNSS receivers, which tells you how seriously builders treat radiation for these parts. The CubeSat specification also limits passive magnets to 0.5 Gauss above Earth's magnetic field, so a magnet based stabilisation scheme has to respect that.

Propulsion

Not every small satellite has propulsion. Those that do use it for orbit raising, station keeping, formation flying, collision avoidance and deorbit. Options range from cold gas to electric propulsion. Propulsion changes the licensing picture: the FCC's streamlined small satellite rule accepts either deployment at or below 600 km or a propulsion system able to make collision avoidance and deorbit manoeuvres. It also brings hazards (pressure vessels, stored energy) that launch providers review closely.

Thermal control

Space has no air to carry heat away, so heat moves only by conduction and radiation. A satellite in low Earth orbit swings between full sun and eclipse every orbit. Thermal control uses coatings and tapes with chosen absorptivity and emissivity, multilayer insulation, radiators, heat straps and heaters, all checked against a thermal model. The thermal vacuum test, covered below, exists largely to correlate that model with reality.

Structures and mechanisms

The structure carries launch loads and holds everything in alignment. On a CubeSat, the rails slide along the dispenser's rails, so their dimensions, finish and contact area are tightly specified. Mechanisms include deployable solar panels, antennas, booms and the hinges and burn wires that release them. The CubeSat specification requires at least three independent inhibits against inadvertent release of deployables, and that deployables be constrained by the CubeSat itself, not by the dispenser wall.

Command and data handling (C&DH) and avionics

C&DH is the flight computer and its storage: it runs the flight software, executes commands, schedules activities, stores payload data and produces telemetry. NASA's report treats C&DH within its avionics chapter and notes that many groups build custom C&DH platforms, while others buy heritage designs to spread engineering cost across missions. This is where radiation effects matter most for software, because a bit flip in memory can corrupt a variable, a table or the program itself.

Communications

Every satellite needs a telemetry, tracking and command (TT&C) link, and most need a separate high rate payload downlink. Low rate links often use UHF or S band; higher rate downlinks use X band, Ka band or optical terminals. NASA's 2026 report updated its free space optical communications section, a sign of how quickly optical links are moving into small satellites. The CubeSat specification requires at least three independent RF inhibits against inadvertent transmission (a timer does not count as an inhibit) and bans any transmission earlier than 45 minutes after deployment.

Bus versus payload: where the line sits

The payload is the reason the satellite exists: an imager, a synthetic aperture radar, an internet relay, an Internet of Things receiver, a science instrument or a technology demonstration. The bus is everything that supports it. In practice the boundary is defined by an interface control document that fixes the mechanical mounting, the power the bus will deliver, the data interfaces, the pointing the bus can achieve and the thermal environment the payload will see.

That boundary matters for two reasons. First, it lets a bus vendor sell the same platform to many customers, which is why NASA's report has a whole chapter on complete spacecraft platforms. Second, it shapes the software split. The bus flight software owns safety: fault protection, power load shedding, safe mode. The payload software owns the mission. When those two pieces of software come from different organisations, the interface between them becomes a security and reliability boundary, which is exactly what NIST IR 8441 means by a hybrid satellite network: independently owned and operated components with varying levels of assurance working together.

CubeSat standard sizes and what fits in a 3U or 6U

The CubeSat Design Specification (CDS) Rev. 14.1, released by Cal Poly in February 2022, defines CubeSats from 1U to 12U. Its stated goal is to provide the design specifications plus information on the dispensers those CubeSats ride in. A 1U is a 10 cm cube; larger sizes stack or tile those units.

The CDS is explicit that these are typical maximums. Masses above Table 1 "may be evaluated on a mission-to-mission basis" with the dispenser or launch provider, and some dispensers accept more. The revision notes in the CDS show the 3U length specification in the acceptance checklist is 340.5 mm, plus or minus 0.3 mm, which gives a sense of how tight the mechanical tolerances are.

What fits in a 3U

A useful way to think about a 3U is as three 10 cm slots along its length. The split below is an illustrative budget we built to show the trade, not a requirement from any standard:

• About 1U of bus avionics: flight computer, EPS board, battery pack, UHF or S band radio and a compact ADCS unit with magnetorquers and small reaction wheels.
• About 2U of payload: a small telescope and detector, a software defined radio, or a technology demonstration.
• On the outside: body mounted solar cells on the long faces, sometimes deployable panels, plus deployable antennas.

The hard limits are power (a 3U with body mounted cells has little surface area), volume for optics and the 6.00 kg mass guideline. Propulsion is possible but competes for the same volume.

What fits in a 6U

A 6U doubles the cross section, not just the length, which changes what is possible. The extra width allows a larger aperture for optics, a star tracker with a clear view, a propulsion module, bigger batteries and deployable arrays that can multiply the power available. It is the smallest size where many commercial Earth observation and communications payloads become practical. The trade is cost, launch price and a heavier qualification burden.

CDS rules that shape the design

Several CDS requirements reach deep into the design, so they belong on the first page of any CubeSat requirements document:

• Materials: structure "should be made from aluminum alloy", typically 7075, 6061, 6082, 5005 or 5052; surfaces in contact with dispenser rails "shall be hard anodized" to prevent cold welding.
• Outgassing: materials must have total mass loss of 1.0 percent or less and collected volatile condensable material of 0.1 percent or less, using NASA's outgassing database.
• Power off at launch: at least one deployment switch that disconnects the power system from all powered functions while integrated, plus an RBF pin that cuts all power.
• Inhibits: at least three independent RF inhibits and three independent inhibits against releasing deployables.
• Timers: deployables wait at least 30 minutes after the deployment switches actuate; no transmission earlier than 45 minutes after deployment.
• Debris: design per NASA NPR 8715.6, with every component re-entering with energy below 15 joules, which in practice drives material choices for dense parts.
• Licences: operators must provide documentation of proper frequency licences, and amateur frequency use needs proof of coordination through the IARU.

Those timers and inhibits are implemented partly in hardware and partly in flight software, which is a good early example of software carrying a safety requirement that a launch provider will audit.

Materials, radiation hardening and component grades

Materials

Aluminium alloys dominate small satellite structures because they are light, machinable and well characterised. Larger spacecraft add carbon fibre composites, titanium fittings and honeycomb panels. GEVS notes that beryllium and composite materials "cannot be qualified by analysis alone", so they need test evidence. Everything inside the vacuum also has to pass outgassing limits, because vapour from adhesives, plastics and lubricants can condense on optics and sensors.

Radiation effects

NASA's 2026 report separates radiation effects into two families. Long term cumulative effects are measured as total ionizing dose (TID, in krad), which slowly shifts a device's parameters until it fails, and displacement damage dose (DDD), the non ionizing damage from particles hitting the crystal structure. Single event effects (SEEs) happen when one particle deposits enough charge to cause a problem. Single event upsets (SEUs) are non destructive and flip the logic state of a memory cell. Single event latch ups (SELs) are destructive and can drive a CMOS device into a high current state.

What that means for design:

• Memory: use error detection and correction (EDAC) and periodic scrubbing so single bit upsets are corrected before they accumulate.
• Processors and logic: use watchdog timers that reset a hung processor, and consider redundancy for critical functions.
• Latch up: use current limiting and power cycling on susceptible parts, so a latch up is cleared before it destroys the device.
• Software: store critical tables with checksums, keep a known good software image, and design safe mode to work from minimal resources.

These are general engineering practices; the exact mix depends on orbit, mission length and how much risk the mission accepts. NASA's report says CubeSats are often built from only commercial parts, or a hybrid of commercial, radiation tolerant and radiation hardened components, and that spaceflight heritage and demonstrated radiation performance become the main differentiators for harsher environments.

Component grades

The NASA report adds an important caveat: space qualified parts generally offer higher reliability but are "often limited in availability and subject to slow revision cycles", while commercial parts bring better performance, quicker availability and lower cost. That trade is why so many small satellites fly commercial processors and then rely on software and system design to tolerate upsets.

Assembly, integration and test: vibration, thermal vacuum, EMC and deployment

Assembly, integration and test (AIT) is where a pile of qualified units becomes a spacecraft. The CubeSat specification says launch provider requirements always take precedence, and that when the launch environment is unknown, GEVS (GSFC-STD-7000) and the Space and Missile Systems Center standard SMC-S-016 can be used to define the environments. GEVS itself, approved in revision B on 28 April 2021, is the reference most US small satellite teams reach for.

Qualification, protoflight and acceptance

The CDS describes three test philosophies:

• Qualification: test an engineering unit identical to the flight unit at qualification levels, then test the flight unit at lower acceptance levels.
• Protoflight: test the flight unit itself at protoflight levels. The CDS says the flight CubeSat shall not be disassembled or modified after protoflight testing without a waiver, and notes that some launch providers treat any mechanical change, including actuating a deployable for a deployment test, as invalidating earlier vibration tests.
• Acceptance: a final test of the CubeSat integrated in its dispenser, as the launch provider requires.

Random vibration

Launch shakes a satellite across a broad band of frequencies. GEVS Table 2.4-3 gives generalized random vibration levels for components of 22.7 kg (50 lb) or less on expendable launch vehicles:

Heavier components can be tested at lower spectral density. GEVS gives the reduction as 10 log(W/22.7) dB, where W is the component weight in kilograms. For a 45.4 kg unit (twice the reference mass), that is 10 log(2), about 3 dB, so the protoflight plateau drops from 0.16 to 0.08 g squared per Hz. Teams run a low level sine sweep before and after each axis to check that the natural frequencies have not shifted, which would signal a loose fastener or cracked part.

Thermal vacuum

Thermal vacuum (TVAC) testing puts the spacecraft in a chamber at vacuum and cycles it between hot and cold plateaus while it runs. GEVS Table 2.6-1 summarises the parameters for non cryogenic hardware:

The notes to the table set a workmanship goal of "a minimum of 12 cycles before flight". GEVS also says spare components need at least eight thermal cycles before integration, and that repaired units repeat at least four unit level cycles. For a CubeSat, the CDS requires at minimum a thermal vacuum bakeout to drive off volatiles, with the profile set by the launch provider.

Here is a worked example of the margin rule. Suppose the thermal model predicts a radio will see minus 15 to plus 45 degrees Celsius in orbit, and the project adds a 5 degree design and uncertainty margin, giving an allowable flight range of minus 20 to plus 50. The protoflight test then drives the radio to minus 30 and plus 60 degrees Celsius. If the radio's datasheet stops at plus 55, the team now has a parts problem to solve before test, not after launch.

EMC

Electromagnetic compatibility (EMC) testing proves that the satellite's own electronics do not interfere with each other or with the launch vehicle, and that they tolerate the fields around them. GEVS section 2.5 uses MIL-STD-461 as its point of departure, with tailored conducted and radiated emission and susceptibility tests. For small satellites the most common practical concern is a radio receiver being desensitised by noise from a switching power converter or a processor clock on the same bus.

Deployment and functional tests

Deployment tests prove that solar panels, antennas and booms release and latch, often with gravity offload rigs. Because the CDS warns that actuating a deployable can invalidate earlier vibration tests, teams plan deployment tests carefully around the vibration campaign. Functional tests run at each stage: a comprehensive performance test before and after every environment, and a short aliveness test between steps.

End to end tests and the day in the life

GEVS section 2.9 covers end to end compatibility tests and simulations. In plain terms: send real commands from the real ground software, through a real or simulated radio link, to the flight vehicle, and check the telemetry that comes back. A "day in the life" test runs the spacecraft through a full operational timeline. This is the test that finds mismatched command dictionaries, wrong byte orders and time conversion errors between flight and ground software.

Ground segment: ground stations, TT&C and mission control software

The ground segment is half the system. It has three layers.

Ground stations. Antennas, radios and modems at sites around the world. A low Earth orbit satellite is in view of any one station for only minutes per pass, so operators combine stations, buy time on commercial networks or use ground station as a service (GSaaS). NASA's 2026 report describes GSaaS as a managed service in which customers schedule contacts on a provider's antennas and receive the data through the provider's cloud.

TT&C. Telemetry, tracking and command is the low rate link that keeps the satellite healthy: commands go up, housekeeping telemetry comes down, and ranging or GNSS data establish the orbit. Section 25.122 of the FCC's rules requires that a small satellite can be commanded from the ground to cease transmissions immediately, so the TT&C link is also a regulatory control.

Mission control software. Operators use software that holds the command and telemetry dictionary, displays telemetry, checks limits, schedules passes, stores data and runs automated procedures. The cFS open source distribution includes a "cFS Ground System" component. F Prime ships its own ground data system, fprime-gds, and its pinned Python requirements also include packages for Yamcs integration and XTCE export, which shows how flight frameworks plug into broader mission control tooling.

The interfaces between those layers follow CCSDS standards. NASA's 2026 report points out that CCSDS support matters when picking a flight software framework because consistent interfaces for data exchange and commanding let parts from different sources work together. For security, CCSDS 355.0-B-2, the Space Data Link Security Protocol published in July 2022, defines how to add authentication and confidentiality to the contents of transfer frames at the data link layer. That is the standards based way to meet SPD-5's call for authenticated or encrypted command links.

Ground systems are ordinary IT: Linux servers, containers, databases, web front ends, Python and Java. SPD-5 and NIST IR 8270 both say so directly and ask for the usual practices there, from patching and segregation to logging and incident response. Our post on satellite terminals and the KA-SAT incident shows what happens when the ground side of a space system is the weak point.

Licensing: FCC Part 25, small satellite rules, ITU coordination, remote sensing and the five year rule

Licensing is not a final step. It touches orbit choice, radio design, propulsion and disposal, so it runs alongside engineering from the start. NASA's CubeSat 101 guide (2017) budgets four to six months for regulatory licensing. The summary below covers US rules and the international layer; other countries have their own national processes that feed the same ITU system.

FCC Part 25 and the streamlined small satellite path

The FCC licenses commercial satellite radio operations under 47 CFR Part 25. Section 25.122 sets out a streamlined process for small space stations. An application can cover ten or fewer satellites, and the applicant must certify, among other things, that each satellite:

• operates only in non geostationary orbit, with a total in orbit lifetime of six years or less;
• is deployed at or below 600 km, or carries propulsion able to perform collision avoidance and deorbit manoeuvres;
• carries a unique signal based telemetry marker so it can be identified;
• releases no operational debris and has assessed the risk of accidental explosions;
• has a collision probability with large objects (10 cm or larger) of 0.001 or less over its orbital lifetime, using NASA software or a higher fidelity model;
• will re-enter with a zero probability of human casualty as calculated by NASA software or better;
• can be commanded from the ground to cease transmissions immediately;
• is 10 cm or larger in its smallest dimension and has a mass of 180 kg or less including propellant;
• has a probability of 0.01 or less of being disabled by small debris or meteoroids in a way that prevents disposal;
• will respond to conjunction warnings by assessing and mitigating collision risk.

The narrative part of the application asks how the satellite will be identified and tracked, whether it will register with the 18th Space Control Squadron (or successor), how ephemeris will be shared, and, for satellites in long lived orbits, a demonstration that disposal succeeds with probability 0.9 or greater. Several of those answers depend directly on flight software: the cease transmission command, the telemetry marker and the manoeuvre logic.

Other routes exist. Universities and some demonstrations use experimental or amateur radio authorizations, and the CDS notes that amateur frequency use requires coordination through the IARU. Choose the route early, because it constrains frequencies, data content and who can operate the satellite.

The FCC five year deorbit rule

On 29 September 2022 the FCC adopted a Second Report and Order (FCC 22-74) that shortens the long standing 25 year benchmark for post mission disposal in low Earth orbit to five years. The rule is now codified at 47 CFR 25.283(e): spacecraft ending their mission in or passing through LEO below 2,000 km and planning disposal by uncontrolled re-entry must complete disposal "as soon as practicable" and no later than five years after the end of the mission. End of mission is defined as the point the spacecraft can no longer perform collision avoidance manoeuvres, or, for spacecraft without that capability, when it completes its primary mission. The order gave a two year grandfathering period from 29 September 2022, so satellites launched after 29 September 2024 must comply.

A worked example of what this means for design: a 3U CubeSat without propulsion that finishes its mission after two years must be low enough that drag brings it down within five years after that. That is an orbit selection problem solved with orbital lifetime analysis, typically with NASA's Debris Assessment Software, which the CDS points to. A satellite with propulsion can choose a higher orbit if it reserves propellant and has a reliable deorbit sequence in its flight software.

ITU coordination

Radio spectrum is coordinated internationally through the International Telecommunication Union. The ITU's Space Services Department processes and publishes frequency assignment notices submitted by national administrations, establishes coordination requirements and records assignments in the Master International Frequency Register (MIFR). Operators do not file with the ITU directly; the national administration (the FCC in the US) files on their behalf. Start early: coordination can take longer than building the satellite.

Remote sensing licences

In the US, private operators of remote sensing space systems may need a licence from the Department of Commerce. Commercial Remote Sensing Regulatory Affairs (CRSRA), now a division of the Office of Space Commerce, issues those licences under the National and Commercial Space Programs Act (51 U.S.C. 60101 and following) and the rules at 15 CFR Part 960. The rules sort applications into three tiers based on whether the system can collect unenhanced data that is already available from foreign or unlicensed sources (Tier 1), available only from licensed US sources (Tier 2), or not available from anyone else (Tier 3), with conditions that increase by tier. The CDS still points to an older NOAA web address for this licence, so use the Office of Space Commerce page instead.

ESA's Zero Debris approach

Outside the US, the European Space Agency has set a Zero Debris approach, its goal to "significantly limit the production of debris in Earth and Lunar orbits by 2030" for all future missions and programmes. ESA's guidance also asks for health monitoring and passivation to prevent break ups from leftover fuel or stored energy, which again lands partly in flight software: passivation sequences have to run reliably at end of life.

Flight software frameworks: NASA cFS and F Prime, and their open source supply chain

Flight software is where the satellite's behaviour lives: commanding, telemetry, scheduling, fault protection, attitude control loops, payload control and the safety timers the CDS requires. NASA's 2026 report notes that frameworks supply "infrastructure services such as command handling, telemetry routing, time synchronization" that are too expensive or error prone to build from scratch, while mission specific algorithms still have to be written. It also warns that flight software problems "are frequently discovered during integration with late-schedule implementations" and recommends early prototyping, version control, continuous testing and mature frameworks.

NASA core Flight System (cFS)

cFS is described in its own repository as "a generic flight software architecture framework used on flagship spacecraft, human spacecraft, cubesats, and Raspberry Pi". The open source version is released under the Apache 2.0 licence and is built from layers:

• cFE (core Flight Executive): the core services: executive, software bus, events, tables and time.
• OSAL (Operating System Abstraction Layer): a portable API over the real operating system.
• PSP (Platform Support Package): board and platform specific code.
• Applications: the open source distribution lists Data Storage, File Manager, Housekeeping, Health and Safety, Memory Dwell, CFDP file transfer, Checksum, Limit Checker, Stored Command, demo labs for command ingest, telemetry output and scheduling, plus tools such as elf2cfetbl and tblCRCTool.

Three statements in the cFS README matter for anyone treating it as a dependency. First, the GitHub repository is a demo bundle: the lab apps "are demos intended as examples only" and the bundle "should not be flown as is"; verification and validation are the mission's responsibility. Second, cFS uses semantic versioning and "Bug/vulnerability fixes are addressed in the next sequential release"; they are not backported. Third, a separate Government use version, cFS Gov, is available under a software user agreement with additional features and security measures. The README also notes that Memory Manager is being deprecated from the open source version in the 7.0.2 release candidate and will continue in cFS Gov with additional security measures.

When we checked on 23 October 2026, GitHub's latest release redirect for nasa/cFS pointed to v7.0.1, while the README described v7.0.2rc1 as a release candidate. The README's build configurations show the range of targets: native Linux builds for development, cross compiles for RTEMS 5 on pc686 (runnable in QEMU) and on a GR712 board, VxWorks 7 and Linux on a Raspberry Pi, and a Yocto based Linux image in QEMU.

JPL F Prime (F´)

F Prime is "a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications", developed at JPL and released under Apache 2.0. Its website says JPL created it to cope with the proliferation of small flight systems like CubeSats, with tighter budgets and shorter schedules. F Prime provides:

• an architecture of components with typed ports and well defined interfaces;
• a C++ framework with message queues, threading and an OS abstraction, which can run with or without an operating system;
• modeling tools (the FPP language) that generate code from component and topology definitions;
• a component library and unit and integration testing tools;
• a ground data system, fprime-gds.

F Prime's projects page lists flight uses at JPL including ISS-RapidScat (an instrument on the International Space Station, September 2014 to November 2018) and the ASTERIA CubeSat technology demonstration. GitHub's latest release redirect for nasa/fprime pointed to v4.4.1 when we checked.

Comparison

NASA's report also lists the NanoSat MO Framework (Java) and Space ROS as alternatives, and says GERICOS offers more architectural freedom with less flight heritage. It adds a fair warning about release dates: older software "can be stable and battle-tested or outdated and unmaintained", and readers should verify the latest versions themselves.

The open source supply chain inside flight software

A flight software image is the end of a long chain of open source and third party inputs:

• The framework itself, pulled in as git submodules (cFS) or as a Python installed toolchain plus source (F Prime).
• The operating system: an RTOS such as RTEMS or VxWorks, or embedded Linux built with Yocto, each with its own components and patches.
• Compilers and build tools: GCC or Clang cross toolchains, CMake, Make, code generators.
• Python tooling and ground software: F Prime's pinned requirements file lists 81 lines, including Flask, Flask-RESTful, Jinja2, certifi, idna, cookiecutter and CMake, alongside the fprime-gds, fprime-tools and fprime-fpp packages.
• Vendor board support code and drivers for radios, star trackers and power boards, often delivered as source or binaries with their own dependencies.

Each of those can carry vulnerabilities or licence obligations, and a satellite's software lives for years. NIST IR 8270 makes the point directly: once vehicles launch, hardware changes are "limited, if not impossible", but software "can often be patched or modified from the ground". That makes a current inventory of every software component, and a tested path to patch it, part of the mission design rather than an afterthought. The CycloneDX bill of materials format already has component types for firmware, devices, device drivers and operating systems, so the same inventory format can describe a flight computer's software stack and the ground systems around it. Our post on hardware and firmware supply chain inventory covers the hardware side.

Step by step: build cFS and F Prime and inventory their dependencies

The walkthrough below uses the commands from each project's own README. It builds the frameworks on a Linux development host, records exact versions and produces an inventory you can track. Nothing here touches flight hardware.

1. Build cFS and pin exact versions

You need Make, CMake, GCC and Git.

git clone https://github.com/nasa/cFS.git
cd cFS
git submodule init
git submodule update

# Record the exact commit of cFE, OSAL, PSP and every app you build
git submodule status > ../cfs-submodules.txt
git describe --tags --always >> ../cfs-submodules.txt

Build, install and run the unit tests for the native development configuration:

make native_std.prep      # set up the build tree
make native_std.install   # compile and stage to the exe directory
make native_std.runtest   # run unit tests (add -j to parallelise)
make native_std.lcov      # collect coverage metrics

Boot the executive from the staged directory and look for the cFE reaching the OPERATIONAL state:

cd build-native_std/exe/cpu1/
./core-cpu1

Remember the README's warning: this bundle and its lab apps are a starting point, not a flight distribution. Treat cfs-submodules.txt as the source of truth for which cFS code your mission carries, and update it every time you move a submodule.

2. Create an F Prime project in an isolated environment

F Prime needs Linux, macOS or Windows with WSL, Git, Python 3.10 or newer and a C and C++ compiler.

python3 -m venv fprime-venv
source fprime-venv/bin/activate
pip install fprime-bootstrap
fprime-bootstrap project

Inside the generated project, the tutorial workflow is to generate the build, build, and run the ground data system:

fprime-util generate
fprime-util build
fprime-gds

3. Record the Python tooling as a bill of materials

The F Prime toolchain and ground data system are Python packages, so capture them exactly:

pip freeze > fprime-tools.lock.txt
pip install cyclonedx-bom
cyclonedx-py environment -o fprime-tools.cdx.json

Commit both files next to your flight software. The CycloneDX file can be loaded into any tool that reads the standard.

4. Scan the repositories and the ground system images

With the Safeguard CLI installed, scan the source tree, any container images you use for ground software, and the SBOM you just produced. Results are written as JSON under ./output.

safeguard scan --dir .
safeguard scan --image your-registry/mission-control:2026.10
safeguard scan --sbom fprime-tools.cdx.json

Use the scan results to decide what to patch before your next software freeze, and keep the reports with your test records.

5. Gate changes in CI

Add the scans to the pipeline that builds your flight and ground software, so a vulnerable version cannot slip back in. A minimal GitHub Actions job looks like this:

name: fsw-dependency-check
on: [push, pull_request]
jobs:
  inventory:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - name: Record submodule versions
        run: git submodule status
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install F Prime tooling
        run: |
          pip install fprime-bootstrap cyclonedx-bom
          cyclonedx-py environment -o fprime-tools.cdx.json
      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: fsw-sbom
          path: fprime-tools.cdx.json

Pair it with the Gold scan Action described further down if you want the build to fail on known exploited vulnerabilities.

6. Carry the inventory into operations

Before launch, freeze a software baseline and archive the source, the build environment, the submodule list and the SBOMs. After launch, when a fix lands upstream, you can answer quickly whether your flight image, your ground system or both carry the affected version, then plan an uplink or a ground patch with the same test discipline you used before launch.

Satellite cybersecurity guidance: NIST IR 8270, IR 8441 and SPD-5

Space Policy Directive 5

SPD-5, "Cybersecurity Principles for Space Systems", was signed on 4 September 2020 and published in the Federal Register on 10 September 2020. Its starting point is that "Cybersecurity principles and practices that apply to terrestrial systems also apply to space systems". Section 4 sets out the principles. Space systems "including software" should be developed with risk based, cybersecurity informed engineering. Owners and operators should have cybersecurity plans that let them "retain or recover positive control" of space vehicles. At a minimum, based on risk, those plans should consider:

1. protection against unauthorized access to critical vehicle functions, including authentication or encryption of command, control and telemetry links that stay secure for the whole mission lifetime;
2. physical protection of command, control and telemetry receivers;
3. protection against jamming and spoofing;
4. protection of ground systems using practices aligned with the NIST Cybersecurity Framework, including segregation, regular patching, physical security, limits on portable media and staff training;
5. cybersecurity hygiene and intrusion detection for antennas, terminals, receivers, routers, networks and power supplies;
6. management of supply chain risks, "through tracking manufactured products; requiring sourcing from trusted suppliers; identifying counterfeit, fraudulent, and malicious equipment".

SPD-5 also says measures should let operators manage risk tolerances according to vehicle size, mission duration, manoeuvrability and orbit, which matters for small satellite teams with tight budgets.

NIST IR 8270: Cybersecurity for Commercial Satellite Operations

NIST IR 8270, published in July 2023, applies the NIST Cybersecurity Framework to commercial satellite operations. NIST calls it a general introduction, not a comprehensive treatment. It walks through the lifecycle (design, assembly, pre launch, operations) and gives example action plans. For the assembly phase it says components "are procured from across the world" and that "The hardware, firmware, and software supply chain are, therefore, a critical component of cybersecurity". Its example action plan for the satellite includes:

• identify and document asset vulnerabilities, including by understanding suppliers' cybersecurity programmes;
• authenticate every device that tries to communicate, drop unauthorized communication attempts and check message integrity;
• encrypt communications and authenticate recipients;
• keep a secondary or alternate channel and fail over automatically;
• protect the vehicle if communications are compromised, for example with an autonomous safe mode;
• use secure development practices for hardware, firmware, operating system and applications, with process isolation and validation of every command and input, citing the Secure Software Development Framework;
• log security events, investigate them, fail safe and recover by restoring data and software.

NIST also notes that cryptographic modules may need to allow upgrades for post quantum cryptography over a long mission.

NIST IR 8441: Hybrid Satellite Networks profile

NIST IR 8441, published in September 2023, is a Cybersecurity Framework profile for hybrid satellite networks: systems built from independently owned and operated terminals, antennas, satellites, payloads and other components with varying levels of assurance. It was developed with satellite builders, operators, acquisition authorities and academia. Its supply chain risk management category applies five subcategories (ID.SC-1 to ID.SC-5) to HSNs, covering supply chain processes, identifying and assessing suppliers, contracts, supplier assessments and joint response and recovery planning. NIST's page adds a planning note that the profile references CSF version 1.1.

What the guidance asks of builders

For the operations side of resilience, including space weather, see our solar storms and satellite software checklist and the 2026 space weather update.

Where Safeguard fits, honestly

Safeguard does not design spacecraft, analyse structures, model radiation or orbits, test hardware, scan firmware binaries or produce hardware bills of materials, and its models are single purpose security models, not engineering or physics tools. The fit is narrower and practical: the software that runs a satellite programme. Flight software frameworks, their submodules, the Python tooling around them, and the Linux servers and container images of the ground segment are ordinary open source dependencies. Safeguard scans repositories, container images and SBOM files, matches components against vulnerability databases, uses reachability analysis to show which findings sit on code paths your application calls, shows which projects contain a given component and version, and evaluates policies and gates. Autonomous remediation can open fix pull requests for dependency upgrades, and it ships switched off. What Safeguard cannot do is patch a satellite in orbit: uplinking a new image remains your team's flight operations decision, with your own test and approval process.

Common mistakes

• Treating the CubeSat mass table as a guarantee. The CDS calls Table 1 typical maximums; your dispenser and launch provider set the real limit. Confirm it before the design freezes.
• Running a deployment test after vibration without asking. The CDS warns that some launch providers treat actuating a deployable as a configuration change that invalidates earlier vibration tests.
• Picking parts on datasheet temperature alone. A part rated to plus 85 degrees Celsius may be fine in orbit and still fail a protoflight thermal vacuum test that drives it 10 degrees beyond the allowable range.
• Assuming commercial means radiation tolerant. NASA's report notes commercial parts receive less screening. Without radiation data, plan for upsets and latch ups in system and software design.
• Starting licensing after the hardware is built. Frequency coordination and FCC review can take longer than integration. The orbit you can license may also drive the five year disposal analysis.
• Flying the cFS demo bundle as is. Its own README says the lab apps are examples and the bundle "should not be flown as is".
• Freezing an old framework release and never revisiting it. cFS does not backport fixes to prior open source releases. Plan time to move forward, or arrange support.
• Forgetting the ground segment's software. Ground servers, web consoles and Python tooling carry the same kinds of dependencies as any business application, and SPD-5 explicitly calls for patching them.
• Leaving command links unauthenticated because the satellite is small. SPD-5 lets you scale measures to mission size, but NIST IR 8270 and SPD-5 both start from authenticated commanding.
• No inventory at launch. Without a record of exact software versions on the vehicle and the ground, you cannot answer whether a newly published vulnerability affects your mission.

FAQ

What is the difference between a satellite bus and a payload?

The payload does the mission, such as imaging, communications or science. The bus provides everything the payload needs to work: power, pointing, propulsion, thermal control, structure, a flight computer and radios. Buses are often bought as a standard platform and the payload is integrated onto them.

What are the main subsystems of a satellite?

Electrical power, attitude determination and control, propulsion, thermal control, structures and mechanisms, command and data handling, and communications. NASA's 2026 small spacecraft report adds ground data systems and mission operations as a chapter, because the ground segment is part of the system.

How big and heavy is a 3U CubeSat?

A 3U is three 10 cm units long, about 34 cm, with a typical maximum mass of 6.00 kg under CubeSat Design Specification Rev. 14.1. A 6U has a typical maximum of 12.00 kg and a 12U 24.00 kg, though dispensers and launch providers can allow more.

Do satellites use radiation hardened chips?

Some do. Long missions, high orbits and deep space missions use space qualified, radiation hardened or radiation tolerant parts. Many CubeSats in low Earth orbit use commercial parts, or a mix, and rely on design measures such as error correcting memory, watchdogs and latch up protection.

What tests does a satellite go through before launch?

Typically random vibration, thermal vacuum (or at least a thermal vacuum bakeout for CubeSats), EMC, deployment tests and end to end tests with the ground system, plus shock if the launch provider requires it. NASA Goddard's GEVS standard and the launch provider's requirements set the levels.

What software runs on a satellite?

A flight software stack: a real time operating system or embedded Linux, a framework such as NASA cFS or JPL F Prime, and mission applications for commanding, telemetry, fault protection, attitude control and payload operations. On the ground, mission control software sends commands and processes telemetry.

Is NASA cFS open source?

Yes. The open source cFS distribution is released under Apache 2.0 and includes cFE, OSAL, PSP and a set of common apps and tools. NASA also offers a Government use version, cFS Gov, under a software user agreement.

Do I need an FCC licence to launch a CubeSat?

If you are under US jurisdiction and your satellite transmits, you need authorization for the radio operations, and the FCC reviews your orbital debris plan. Small satellites that meet the criteria in 47 CFR 25.122 can use a streamlined process. Remote sensing payloads may also need a Commerce Department licence.

What is the FCC five year rule for satellites?

Satellites ending their mission in or passing through low Earth orbit below 2,000 km and relying on natural re-entry must be disposed of as soon as practicable and no later than five years after mission end. It applies to satellites launched after 29 September 2024.

How can satellites be hacked, and what guidance applies?

The main concerns are unauthorized commands over the radio link, jamming and spoofing, compromise of ground systems and supply chain weaknesses. SPD-5, NIST IR 8270 and NIST IR 8441 ask builders and operators to authenticate or encrypt command links, develop software securely, manage supply chain risk and plan to recover control.

Fix it without waiting for upstream

A satellite's flight software and ground segment are built from open source frameworks, operating systems, Python tooling and container images, and every one of those components receives security fixes over a mission that can last years. The fit with Safeguard here is the software around the spacecraft, not the hardware or anything already in orbit, and it is still the part of the programme where unpatched versions most often go unnoticed.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos involves a satellite. They show the software side of the workflow above: scanning and fixing the open source dependencies that flight and ground software are built from, with a person approving each step. To try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real Safeguard CLI session. Asked to fix the lodash CVE in a repo, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The same approve each step flow fits a ground software repository, where a web console or Python tool needs an upgrade before the next software freeze. You can read more about the assistant in the Safeguard CLI as a security aware coding assistant.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. For a mission team that keeps flight software source on internal machines, that is the pattern for scanning code where it lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is a way to ask questions about your scan results in plain language, for example which projects carry a given package version, while keeping the assistant limited to the tools you pick.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NASA: State of the Art of Small Spacecraft Technology (2026 report page)
• NASA: 2026 State of the Art Small Spacecraft Technology report (PDF)
• Cal Poly CubeSat Program: CubeSat information and specification downloads
• Cal Poly: CubeSat Design Specification Rev. 14.1 (PDF)
• NASA: CubeSat 101, Basic Concepts and Processes for First-Time CubeSat Developers (PDF)
• NASA Technical Standards: GSFC-STD-7000, General Environmental Verification Standard
• NASA: GSFC-STD-7000B GEVS (PDF)
• NASA cFS on GitHub (README, licence, releases)
• NASA cFS website
• NASA F Prime on GitHub
• F Prime requirements file
• F Prime overview
• F Prime projects
• F Prime Hello World tutorial
• FCC 22-74: Second Report and Order on orbital debris, five year rule (PDF)
• FCC: FCC adopts new 5-year rule for deorbiting satellites
• eCFR: 47 CFR 25.122, streamlined small space station authorization
• eCFR: 47 CFR 25.283, end of life disposal
• eCFR: 15 CFR Part 960, licensing of private remote sensing space systems
• Office of Space Commerce: Commercial Remote Sensing Regulatory Affairs
• ITU: Space Services Department
• ESA: Zero Debris approach
• ESA: Clean Space
• CCSDS 355.0-B-2: Space Data Link Security Protocol (PDF)
• Federal Register: Memorandum on Space Policy Directive 5, Cybersecurity Principles for Space Systems
• GovInfo: SPD-5 as published at 85 FR 56155 (PDF)
• NIST IR 8270: Introduction to Cybersecurity for Commercial Satellite Operations
• NIST IR 8441: Cybersecurity Framework Profile for Hybrid Satellite Networks
• Automotive Electronics Council: AEC documents (Q100, Q101, Q200)
• CycloneDX: bill of materials schema 1.6 (component types)
• CycloneDX: cyclonedx-python

Last reviewed: 23 October 2026. Rules, standards and framework releases change; check the linked sources for the latest versions before you rely on a figure.