How a CubeSat Is Made: Structure, Power, Radios and Flight Software

A CubeSat is made by fitting a standard aluminium frame, sized in 10 cm units called U, with solar cells and batteries, an attitude control unit, an on-board computer running flight software, one or more radios and a payload, then shaking, baking and fit checking the finished spacecraft before it rides to orbit inside a spring loaded deployer. The rules for size, mass, power inhibits and testing come from the CubeSat Design Specification, which Cal Poly maintains and whose current revision is 14.1 from February 2022. Before it can transmit, the team also needs a radio licence, frequency coordination and a working ground station, and the command link should be authenticated.

This post goes one level deeper than our explainers on how a spacecraft gets to space and how satellite internet works. Those cover rockets, orbits and large constellations. This one stays with the small, standard box that universities, start ups and government labs build by the hundred, and it walks through each subsystem, the test campaign, the paperwork, the software and the security questions that come with a radio anyone can point an antenna at.

We cite primary documents throughout: the CubeSat Design Specification (CDS) Revision 14.1, NASA's CubeSat 101 guide, NASA's State of the Art of Small Spacecraft Technology report, the FCC rules in Title 47 of the Code of Federal Regulations, the CCSDS Space Data Link Security standard, and the project documentation for NASA's core Flight System and JPL's F Prime. Where a document gives a number we quote it. Where none does, we describe the step without inventing one.

Key takeaways

• The CubeSat Project started in 1999 as a collaboration between Prof. Jordi Puig-Suari at Cal Poly San Luis Obispo and Prof. Bob Twiggs at Stanford's Space Systems Development Laboratory, according to the CDS. A 1U CubeSat is a 10 cm cube with a mass of up to 2 kg, and the specification covers sizes from 1U to 12U.
• The CDS mass table lists typical maximums of 2 kg for 1U, 6 kg for 3U, 12 kg for 6U and 24 kg for 12U. Heavier spacecraft can be evaluated mission by mission, and the dispenser provider has the final word.
• Inside the box sit six or seven subsystems: structure, electrical power, attitude determination and control, the on-board computer (often called command and data handling), communications, thermal control and the payload. NASA's state of the art report says aluminium alloys 6061 and 7075 remain the dominant choice for primary structures and puts triple junction solar cell efficiency at 30 to 34 percent.
• The CDS requires the spacecraft to stay powered off from delivery until deployment, with at least one deployment switch, a Remove Before Flight pin, at least three independent RF inhibits, a 30 minute wait before deploying antennas or panels and a 45 minute wait before transmitting.
• Testing follows the launch provider's levels. The CDS lists random vibration, thermal vacuum bakeout, shock (typically not required for CubeSats) and visual inspection, and it defines qualification, protoflight and acceptance flows. Materials must meet low outgassing limits of 1.0 percent total mass loss and 0.1 percent collected volatile condensable material.
• Two open source flight software frameworks dominate public CubeSat work: NASA's core Flight System (cFS), released under Apache 2.0, and JPL's F Prime, a component based C++ framework with code generation. cFS says vulnerability fixes go into the next release and are not backported.
• In the United States most university CubeSats use an FCC experimental licence under Part 5, according to CubeSat 101. Pure amateur status under Part 97 is hard to qualify for, and amateur band missions must coordinate with the IARU. Part 97 still lets a telecommand station send codes that obscure the meaning of commands, so an amateur mission can protect its uplink.
• Security guidance converges on one point: protect the command path. Space Policy Directive 5 (4 September 2020) asks for authentication or encryption on command, control and telemetry links, NASA's small spacecraft report says NASA missions shall use authenticated encryption for command authority, and CCSDS 355.0 B 2 (July 2022) defines frame level authentication, encryption and anti replay sequence numbers.

From mission concept to a CubeSat in orbit: the step table

This is the map for the rest of the post. Durations come from the ranges in NASA's CubeSat 101 guide, which also says a CubeSat can be designed, built, tested and delivered in as little as 9 months but typically takes 18 to 24 months. The review or test at each step is what turns a pile of parts into flight hardware.

The order is not strictly linear. Licensing, documentation and the ground station all run in parallel with the build, and CubeSat 101 warns that a team without licences at delivery risks being removed from the launch.

What is a CubeSat?

A CubeSat is a class of satellite defined by a standard size and form factor rather than by a mission. The CDS says the project began in 1999 to reduce cost and development time, increase access to space and sustain frequent launches. The basic unit, 1U, is a 10 cm cube of up to 2 kg. Larger CubeSats stack or tile that unit: a 3U is three units long, a 6U is two 3U stacks side by side, and a 12U is two 6U stacks side by side. The current CDS covers 1U, 1.5U, 2U, 3U, 6U and 12U.

The standard matters because of the deployer. A CubeSat does not bolt directly to a rocket. It slides into a box, the deployer or dispenser, that bolts to the rocket and carries one or several CubeSats. The CDS describes two families of deployer constraint. The first, originally developed by Cal Poly for the Poly Picosatellite Orbital Deployer (P-POD), uses four rails along the spacecraft's corners that glide along matching rails inside the dispenser. The second uses tabs clamped by a flange to create a stiff load path. In both, a spring drives a pusher plate that ejects the spacecraft when the door opens. The CDS is clear that a CubeSat is not expected to fit both types, so the design commits to one early.

CubeSat sizes and limits compared

The CDS mass and centre of gravity tables are the hard numbers every design starts from. Centre of gravity is measured from the geometric centre on each axis, with Z along the long axis that runs down the deployer.

Two notes in the CDS soften the mass column: heavier spacecraft may be evaluated mission by mission, and acceptable mass varies with the dispenser. In practice your launch provider's interface control document overrides the generic table.

Older documents use smaller numbers. CubeSat 101, written in 2017, describes the original 1U mass as 1 to 1.33 kg. If you see 1.33 kg quoted for a 1U, it is from an earlier revision, not the current CDS.

Other CDS rules that shape the build

Beyond size and mass, the CDS sets rules that every subsystem designer meets on day one:

• All parts must stay attached during launch, ejection and operation. Nothing is allowed to drift off.
• Materials must be low outgassing: total mass loss at or below 1.0 percent and collected volatile condensable material at or below 0.1 percent. NASA maintains an outgassing database that teams use to pick adhesives, plastics and coatings.
• Passive magnets are limited to 0.5 gauss above Earth's field outside the spacecraft envelope, so they do not disturb neighbours in the same deployer.
• The ends of the rails need at least 6.5 mm by 6.5 mm of contact area with the neighbouring CubeSat's rails, and at least 75 percent of each rail must touch the dispenser rails.
• Any propulsion must have at least three inhibits and follow the range safety manual referenced in the CDS.
• The CDS recommends considering airline battery rules, noting the 100 Wh per battery limit for consumer lithium ion cells in carry on baggage, because teams often fly with their spacecraft to the integrator.
• Any component must re enter with less than 15 joules of energy, in line with NASA's orbital debris procedural requirements.

Dated timeline: the CubeSat standard, rules and software

Every date below was checked against the document named in the source column.

What goes inside a CubeSat?

NASA's State of the Art of Small Spacecraft Technology report, first published in 2012 and updated most recently in 2026, organises small spacecraft into chapters that map neatly onto the boxes inside a CubeSat. It only reports technologies at Technology Readiness Level 5 or above, which means each has at least been validated in a relevant environment.

Structure

The structure is usually the first part machined and the last part a team worries about, which is a mistake because everything bolts to it. NASA's report says aluminium alloys remain the dominant approach for primary structures, and that commercial CubeSat frames are commonly 6061 or 7075 alloy with several mounting locations so components can be arranged freely. The CDS says the structure should be aluminium alloy, typically 7075, 6061, 6082, 5005 or 5052, and that any aluminium surface touching the dispenser rails, such as rails and standoffs, shall be hard anodised to prevent cold welding inside the dispenser. Using any other material means a conversation with the launch provider or dispenser maker first. The CDS drawings set the rails' dimensions and finish.

Internally, most CubeSats stack printed circuit boards. NASA's avionics chapter describes standard CubeSat command and data handling designs as boards stacked vertically with board to board connectors, often without a backplane and sometimes without a formal chassis, with PC/104 style stacks as the common example. It notes that this format is compact and light but limited in bandwidth compared with backplane based plug in card systems. A shared footprint lets a team mix boards from different sources, as long as the connector pinouts agree. Side panels close the box and often carry body mounted solar cells. Larger spacecraft add deployable solar panels and antennas, held closed by burn wires or similar release mechanisms until the timers in the CDS allow them to open.

Electrical power

The electrical power subsystem is the heartbeat. Solar cells charge batteries during the sunlit part of each orbit, and the batteries carry the load through eclipse. NASA's power chapter says multi junction cells achieve efficiencies of 30 to 34 percent and that lithium ion and lithium polymer cells have replaced older nickel based chemistries in modern spacecraft.

The power board does more than convert voltages. It manages battery charging and protection, distributes regulated rails to each subsystem, and implements the inhibits the CDS requires. The CDS demands that the spacecraft stay in a power off state from delivery until deployment, that at least one deployment switch disconnect the power system from powered functions while the spacecraft sits in the dispenser, and that a Remove Before Flight pin cut all power when inserted. It also requires battery protection circuitry against unbalanced cells, with extra documentation or testing for non UL listed or modified cells, and a real time clock that is isolated from the main power system if one stays powered.

A worked example shows why power budgets dominate early design. Suppose a 3U spacecraft has body mounted cells giving an average of 6 W over an orbit, and the orbit lasts about 95 minutes with roughly 35 minutes in eclipse. The energy collected per orbit is 6 W times 95 minutes, about 9.5 watt hours. If the radio transmits at 5 W for a 10 minute pass and everything else draws 2 W continuously, consumption is 2 W times 95 minutes (about 3.2 Wh) plus 5 W times 10 minutes (about 0.8 Wh), or roughly 4 Wh. That leaves margin for charging losses and a payload. These figures are illustrative arithmetic, not data from a particular mission.

Attitude determination and control

Attitude determination works out which way the spacecraft is pointing. Attitude control changes it. NASA's guidance, navigation and control chapter lists the usual sensors (star trackers, sun sensors, horizon sensors, magnetometers and gyros) and actuators (magnetorquers, reaction wheels and, on larger spacecraft, thrusters). The simplest CubeSats use magnetorquers alone to slow their spin after deployment, a step called detumbling, and point roughly. Imaging and high rate radio missions add reaction wheels and a star tracker for much finer pointing. Integrated units that package wheels, torquers, sensors and the control computer in one module are common, and the report's tables list several such units with sub degree to arcsecond class pointing knowledge.

On-board computer and data handling

The on-board computer runs the flight software, stores telemetry and payload data, executes commands, and supervises everything else. NASA's avionics chapter spends a lot of space on radiation, because commercial microcontrollers and memory can suffer single event upsets and latch up in orbit. Common mitigations are watchdog timers, error correcting memory, redundant copies of critical software images, current limiting with automatic power cycling, and keeping software simple enough that a reset is always safe. The chapter also discusses flight software frameworks, which we cover below.

Communications

Most first time CubeSats carry a UHF or VHF transceiver for commands and low rate telemetry, often in amateur satellite bands. Missions that need more data add an S band or X band transmitter. NASA's communications chapter notes that lower bands such as UHF and S band are the most mature for small satellites but crowded, which makes licensing harder, and that UHF has a higher chance of local interference. It also says most small satellite designers will not need a separate cryptographic unit and may be able to use the communications radio for simple encryption, a point we return to in the security section.

Payload and thermal

The payload is whatever the mission is for: a camera, a radiation detector, a new radio, a deployable sail. It drives the rest of the design, because a camera needs pointing and downlink capacity, while a radiation sensor may need little of either. Thermal control on a CubeSat is mostly passive: surface coatings and tapes set how much sunlight is absorbed and how much heat radiates away, and small heaters keep batteries above their minimum charging temperature during eclipse.

How is a CubeSat built and qualified?

Assembly in a clean, controlled area

Flight units are assembled in a clean area with electrostatic discharge controls, gloves and logged handling. The CDS does not set a cleanroom class, so the level of cleanliness comes from the launch provider and the payload's own sensitivity. Optics and some sensors need far cleaner conditions than a power board. What the CDS does set is the materials rule (low outgassing), which is why teams keep a materials list and check each adhesive, cable jacket and printed part against NASA's outgassing database before it goes near the flight unit.

A typical assembly order is: inspect and clean the frame, install harnesses, mount and test each board on a flat bench (sometimes called a flatsat) before it goes into the stack, integrate the stack, close the panels, fit deployables in their stowed state, and run a full functional test with the RBF pin and deployment switches exercised. Every connector mate, torque value and staking step is recorded, because the integrator will ask for proof.

The inhibit and timer rules

Before testing begins the safety design must be correct, because it is very hard to change afterwards. The CDS requires:

• At least one deployment switch that, while actuated (pressed by the dispenser), disconnects the power system from powered functions. If the switch toggles off and back on, the spacecraft must reset its timers.
• An RBF pin within the designated access ports that cuts all power when inserted and protrudes no more than 6.5 mm from the rail surface.
• At least three independent RF inhibits to prevent accidental transmission. The CDS notes that a timer does not count as an independent inhibit.
• At least three independent inhibits for deployables such as antennas and panels.
• Deployables wait at least 30 minutes after the deployment switches release, and transmitters wait at least 45 minutes after on orbit deployment. The spacecraft may power on immediately.

Environmental tests

The CDS lists the tests every CubeSat typically faces, with levels set by the launch provider:

Where the launch environment is not yet known, the CDS points developers to NASA's General Environmental Verification Standard (GSFC-STD-7000, which the CDS cites as 7000A; NASA's standards page now lists Revision B dated 28 April 2021) and the military standard SMC-S-016 as guides, with a clear warning that launch provider requirements supersede any other source.

Qualification, protoflight and acceptance

The CDS describes three test philosophies. Qualification testing runs on an engineering unit identical to the flight model at qualification levels, after which the flight model is tested to lower acceptance levels. Protoflight testing runs the flight model itself at protoflight levels, and after that the flight unit must not be disassembled or modified without a waiver. Acceptance testing may then run on the CubeSat already integrated into the flight dispenser. The CDS adds a warning that catches many teams: some launch providers treat any physical change, including actuating a deployment mechanism for a deployment test, as invalidating earlier vibration tests.

Software is part of this picture too. If you plan to reflash the on-board computer after vibration testing, confirm with the integrator whether that counts as a change, and get your final flight software image under configuration control before the protoflight test.

Which flight software frameworks do CubeSats use?

Flight software runs on the on-board computer and does the same jobs on almost every spacecraft: schedule tasks, accept and validate commands, produce telemetry, log events, store and move files, check health, and recover from faults. Two open source frameworks from NASA dominate public CubeSat work.

NASA core Flight System (cFS)

The cFS repository describes it as a generic flight software architecture framework used on flagship spacecraft, human spacecraft, CubeSats and Raspberry Pi. It is layered:

• The Operating System Abstraction Layer (OSAL) hides the real time operating system or Linux underneath, so the same application code can run on several operating systems.
• The Platform Support Package (PSP) adapts the framework to a specific board.
• The core Flight Executive (cFE) provides the core services: executive services that start and supervise applications, a software bus that passes messages between them, event services, table services for runtime configurable data, and time services.
• Applications sit on top and talk only through the software bus. The open source bundle includes lab apps for command ingest and telemetry output, plus a sample app, and the wider ecosystem lists apps for file transfer with the CCSDS File Delivery Protocol (CF), housekeeping, health and safety, limit checking, stored commands, checksums and more.

NASA's small spacecraft report describes cFS as geared towards homogeneous, single node avionics and not optimised for extremely tight computational environments, which matters when you choose a microcontroller. The cFS README is explicit that the open source bundle is a starting point, not a verified operational system, and that a Government use version with more features and security measures is available under a software user agreement. It also says bug and vulnerability fixes land in the next sequential release and are not backported, so users are encouraged to upgrade. The latest full bundle in the GitHub releases is v7.0.1 from 14 May 2026, with v7.0.2-rc1 published on 22 October 2026. That release candidate's notes say the Memory Manager application is being deprecated from the open source version and will continue in the Government version with additional security measures.

JPL F Prime (F´)

F Prime, originally developed at JPL, describes itself as a component driven framework for spaceflight and other embedded software. Its README lists the pieces: an architecture that breaks flight software into components with defined interfaces, a C++ framework with message queues and threads, modelling tools (the FPP language) that specify components and connections and generate code, a library of ready to use components, and testing tools for unit and integration tests. The core service components in the repository include a command dispatcher, a command sequencer, file uplink and file downlink, and a health component. Projects are created with a Python bootstrap tool, built with a utility called fprime-util, and operated through a browser based Ground Data System (GDS).

NASA's report says F Prime is more rigid than cFS, with much of the architecture fixed at compile time, but that it can be extended to distributed systems with extra effort. The latest release on GitHub at the time of writing is v4.4.1, published on 7 October 2026. The current README lists Python 3.10 or newer and a C or C++ compiler as requirements, with an optional Rust toolchain 1.87 or newer for components that depend on Rust.

cFS and F Prime compared

How flight software updates are uplinked

Updating software on a spacecraft you cannot touch is the riskiest thing an operations team does. The usual pattern, in both frameworks, is file based:

1. Build the new application or table image on the ground, from a tagged commit, and record its hash.
2. Uplink the file in pieces over several passes using a file transfer protocol (CFDP through the CF app in cFS, or the FileUplink component in F Prime) to a staging area in non volatile memory.
3. Verify the received file on board with a checksum or, better, a cryptographic signature check before it is used.
4. Command the switch over: reload one application, swap a table, or mark a new boot image as preferred.
5. Keep the previous known good image and a watchdog or boot counter that falls back automatically if the new image does not check in.

Steps 3 and 5 are where missions differ most. A checksum only proves the file was not corrupted in transit. It does not prove who sent it. That is why NASA's small spacecraft report lists cryptographic verification of on board software and secure boot among its recommended defence in depth measures.

How do CubeSat radios, licensing and ground stations work?

Every CubeSat that transmits needs authorisation. CubeSat 101 explains the split in the United States: the NTIA handles licences for satellites operated by the federal government, and the FCC handles everyone else. Internationally, the CDS points operators to the ITU to find what their own country requires, and it requires proof of licences before integration. For amateur bands, it requires proof of IARU frequency coordination.

Which licence fits?

If the spacecraft carries a camera or other imager and is privately owned in the United States, CubeSat 101 says the team must contact NOAA about a commercial remote sensing licence, and that the FCC will want to see that licence before it finishes the radio licence.

What the amateur rules say about encryption

This is where documents appear to disagree, and it matters for security. CubeSat 101 says amateur satellite transmissions cannot be encrypted in any way. The regulation is more nuanced. Section 97.113 prohibits messages encoded to obscure their meaning, "except as otherwise provided herein". Section 97.211(b) then provides that a space telecommand station "may transmit special codes intended to obscure the meaning of telecommand messages" to the spacecraft. The same section lists the bands and segments telecommand stations may use, including 144 to 146 MHz and 435 to 438 MHz.

Read together, downlinked telemetry and payload data on an amateur licence should be in the clear, while the command uplink may be protected. The safe summary for a team planning an amateur mission is: you can authenticate and even obscure commands, you should not hide downlink content, and you should confirm the specifics with your licensing adviser.

IARU coordination and the ITU

The IARU's Satellite Frequency Coordination Panel reviews requests from amateur and experimental missions that want to use amateur satellite bands. The IARU's satellite page says the panel has received and processed 1,000 coordination requests since it began in the late 1990s, and it publishes the meeting schedule and the current request form. Because volunteers run it and it meets periodically, CubeSat 101 advises sending the request immediately after manifesting, if not earlier.

At the international level, the ITU is developing a Small Satellite Handbook in its Study Group 4, Working Party 4A, and runs a support page for small satellite operators that explains notification and registration. Your national administration files with the ITU on your behalf.

What a CubeSat ground station looks like

CubeSat 101 says the two basic components are a radio and an antenna, and warns that launching with an inadequate ground station is "a mission killer". A typical university station for UHF or VHF has:

• Crossed Yagi antennas on an azimuth and elevation rotator, with a low noise amplifier near the antenna for receive.
• A transceiver or software defined radio, plus a terminal node controller or software modem for packet protocols such as AX.25.
• Tracking software that computes passes from orbital elements and steers the rotator and corrects for Doppler shift.
• Mission control software that encodes commands, decodes telemetry and stores everything, often the ground tools that come with cFS or F Prime.

NASA's report also describes ground station networks. The open source, community driven SatNOGS network lets many volunteer stations receive and share telemetry. Ground station as a service offerings rent antenna time on a pay as you go basis, and NASA's own Near Space Network supports missions in S, X and Ka bands. The report notes NASA merged its Space Network into the Near Space Network in October 2020.

The practice advice in CubeSat 101 is good security advice too: build the ground station early, test it on existing satellites, and keep it in the loop during development. A ground station you understand is one you can harden.

How do university teams get a launch?

In the United States the most familiar route is NASA's CubeSat Launch Initiative (CSLI). NASA's page says CSLI provides launch opportunities for CubeSats built by US educational institutions and non profit organisations, including informal educational institutions such as museums and science centres. Selected spacecraft fly on missions called ELaNa (Educational Launch of Nanosatellites), each with a number. NASA says its Announcement of Partnership Opportunity is typically released each August with proposals due in November, and that CSLI has launched over 150 CubeSats.

CubeSat 101 adds the practical side. Proposals need a merit review and a technical feasibility review. After selection, the wait to be manifested on a specific launch can be anything from 1 to 36 months, and the mission coordination phase with the integrator starts about 18 months before launch. Selection covers the launch, not the spacecraft: teams still fund their own hardware, testing, licensing and ground station.

Other routes exist. Commercial rideshare brokers and launch providers sell slots in dispensers, some space agencies run their own education programmes, and some missions are deployed from the International Space Station. The process is similar everywhere: an interface control document, a licence, a test campaign to the provider's levels and a delivery date that does not move.

What are the security issues for a CubeSat?

NASA's small spacecraft report opens its cyber security section with the core problem: security must cover the flight platform, payload, ground segment and supporting services, because attackers can target any part of the system of systems. It says the most accessible path for a remote adversary is usually the end to end command path, whether by injecting signals over the radio link, subverting ground or space networks, or compromising the operations centre. NIST IR 8270 (July 2023) frames the same problem for commercial satellite operators, and NIST IR 8401 (December 2022) applies the NIST Cybersecurity Framework to the ground segment.

Unauthenticated uplinks

The oldest and most common CubeSat security gap is an uplink that accepts any correctly formatted command. If the command format is public (for example in an amateur mission's documentation or in the default configuration of an open source framework) and the receiver only checks a callsign and a checksum, anyone with a transmitter and an antenna in view of the spacecraft can try to command it. The consequences range from a nuisance to a lost mission: a commanded transmitter shutdown, a drained battery, a corrupted file system.

The fix is cryptographic authentication of every command, plus replay protection, so that an old valid command recorded off the air cannot be sent again. CCSDS 355.0-B-2, the Space Data Link Security Protocol, defines exactly that at the data link layer for telecommand, telemetry, AOS and USLP frames: authentication, encryption or authenticated encryption, managed through security associations, with a sequence number and a window the receiver uses to detect unauthorised replay. Even a mission that cannot implement the full standard can follow the pattern: a per spacecraft key, a message authentication code over each command frame, a monotonically increasing counter, and a rule that unauthenticated frames are dropped and counted in telemetry.

Command encryption and policy

Space Policy Directive 5, issued on 4 September 2020, asks space system owners and operators to protect against unauthorised access to critical space vehicle functions, including "safeguarding command, control, and telemetry links using effective and validated authentication or encryption measures" for the whole mission life. NASA's small spacecraft report states that NASA missions shall protect command authority with authenticated encryption from the point of command generation to the spacecraft, with cryptographic modules meeting at least FIPS 140-3 Level 1 and authenticated modes such as AES-GCM, consistent with NASA-STD-1006A. It also says backup command links need authentication at a minimum, a detail that matters because CubeSats often keep a simple fallback receiver for recovery.

The same report's communications chapter notes that most small satellite designers will not need a separate cryptographic unit and may be able to use the radio for simple encryption. Simple is fine if it is sound: use a standard authenticated mode, keep keys out of the source repository, plan for key loading before delivery, and decide how keys are rotated or revoked over a mission that may last years.

Ground station compromise

A perfectly authenticated uplink is only as good as the computer that holds the keys and builds the commands. NIST IR 8401 treats the ground segment as the place to apply identification, protection, detection, response and recovery. NASA's report lists ground controls in the same spirit: unique user logons, least privilege, segmentation of critical networks and strict protection of the command database. For a university team that usually means a dedicated operations machine, no shared accounts, the signing key on that machine only (or in a hardware token), the ground station network separated from the campus network, and logs of every command sent.

Remote and shared ground stations add a twist. If you use a volunteer network for receive only, it never holds your keys, which is good. If you rent transmit time from a service, understand where commands are signed and whether the service ever sees key material.

External dependencies and jamming

NASA's report also asks for resilience to loss of GNSS and to jamming. Recommended practices include multiple GNSS constellations, autonomous fallback navigation, filtering out impossible position or time jumps in flight software, and logging jamming and spoofing indicators. For a CubeSat, the cheapest version is software that does not trust a single GNSS fix blindly and that never lets a time jump trigger a destructive action.

Open source dependencies in flight and ground software

The software on both ends of the link is built from open source. The cFS bundle pulls in its framework repositories as git submodules and its ground system depends on Python packages such as PyQt5 and PyZMQ. F Prime installs its tool suite as Python packages in a virtual environment and can pull Rust crates for some components. Ground stations add radio libraries, tracking tools and web dashboards. Each of these needs the same care as any other software supply chain:

• Pin framework versions to tags, not branches, and record the commit hashes that went into the flight image.
• Track upstream releases. cFS states that fixes are not backported, so staying on an old bundle means carrying any fixed bugs yourself.
• Generate a software bill of materials for the flight image and the ground tools, so that when an advisory lands you can answer "do we fly this?" in minutes.
• Rebuild ground tooling from a lockfile, and review new dependencies before they reach the operations machine.

NASA's report also recommends secure boot, runtime integrity checks and cryptographic verification of on board software. Those protect the spacecraft from a bad upload. The supply chain steps above protect you from shipping a bad component in the first place.

Step by step: build and run cFS and F Prime on a Linux desktop and send a command

This walkthrough follows the projects' own documentation. Neither framework needs special hardware for this; both run as normal Linux processes. Do it on a development machine or a virtual machine, not on your operations ground station, and keep the lab command interfaces on loopback or an isolated network, because they are lab tools and are not built to face a hostile network.

Part A: core Flight System with the sample app

1. Install the prerequisites named in the cFS README: Make, CMake, GCC and Git. On a Debian or Ubuntu desktop:

sudo apt update
sudo apt install -y build-essential cmake git python3-pyqt5 python3-zmq

2. Clone the bundle and its submodules. Check out a release tag so you know exactly what you built.

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

3. Build, run the unit tests and stage the executables using the native_std configuration the README describes.

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 the unit tests

4. Start the flight software from the staged directory. The README says the default Linux platform support package needs this working directory to find its startup script and shared objects.

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

You should see start up messages and the executive services report entering the OPERATIONAL state. Leave it running.

5. In a second terminal, build the command utility and start the cFS Ground System, as the README describes.

cd cFS/tools/cFS-GroundSystem/Subsystems/cmdUtil
make
cd ../..
python3 GroundSystem.py

6. In the ground system window, select Start Command System, then Enable Tlm, enter 127.0.0.1 as the address of the system running cFS, and select Start Telemetry System. The README says you should see telemetry and be able to send no operation commands and watch the command counters increment. Send a no operation command to the sample app and confirm its command counter goes up in housekeeping telemetry and an event message appears in the flight software terminal.

7. Notice what you did not have to do: you never proved who you were. That is expected for a lab bundle, and it is the point of the security section above. In a mission build, command ingest sits behind an authenticated link layer such as SDLS or an equivalent scheme you design.

Part B: F Prime HelloWorld deployment

1. Confirm the requirements from the F Prime README: git, Python 3.10 or newer with venv and pip, and a C and C++ compiler.

git --version
python3 --version
g++ --version

2. Install the bootstrap tool and create a project. The installation guide says this creates a git repository with the standard project structure and a virtual environment with the tool suite installed.

python3 -m venv ~/fprime-bootstrap-venv
. ~/fprime-bootstrap-venv/bin/activate
pip install fprime-bootstrap
fprime-bootstrap project     # answer: hello-project, HiNamespace
cd hello-project
. fprime-venv/bin/activate
fprime-util generate
fprime-util build

3. Follow the HelloWorld tutorial to create a component with fprime-util new --component, add the SAY_HI command, the SayHiEvent event and the GreetingCount telemetry channel, then create a deployment with fprime-util new --deployment and add the component instance to its topology as the tutorial shows. Build again from the deployment directory.

cd HiNamespace/FirstDeployment
fprime-util build

4. Start the ground data system from the deployment directory.

fprime-gds

The tutorial says the GDS page opens in your browser, or at http://127.0.0.1:5000. A green circle in the upper right shows the flight software has connected.

5. Open the Commanding tab, pick HiNamespace.hiCmpntInstance.SAY_HI, type a greeting and click Send Command. On the Events tab you should see SayHiEvent with your text, and on the Channels tab GreetingCount increments each time.

6. Stop it with Ctrl C and run deactivate. Before you take any of this towards flight, record the F Prime version and the pinned Python requirements in your repository, and keep the GDS bound to the local machine.

Part C: record what you built

Whichever framework you use, write down what went into the image. A minimal habit is a release note per flight build with the framework tag, the submodule or requirements hashes, the compiler version and the image hash.

# in the cFS checkout
git describe --tags
git submodule status > flight-build-submodules.txt
gcc --version | head -1 >> flight-build-submodules.txt
sha256sum build-native_std/exe/cpu1/core-cpu1 >> flight-build-submodules.txt

# in the F Prime project, with the project venv active
pip freeze > ground-tools-requirements.lock

That file set is what you will want on the day an advisory mentions a component in your stack.

Common mistakes

• Treating the CDS mass table as a promise. The CDS says acceptable mass depends on the dispenser. Check the interface control document before you size batteries.
• Building the ground station last. CubeSat 101 calls an inadequate ground station a mission killer and says to build it early and test it on existing satellites.
• Counting a timer as an inhibit. The CDS says a timer is not an independent RF inhibit. Three physical inhibits are the recommended baseline.
• Changing the spacecraft after protoflight testing. Some providers treat any mechanical change, including a deployment test, as invalidating vibration results. Plan software reflashes and deployments before the test, or get agreement in writing.
• Filing licences late. CubeSat 101 recommends filing within 30 days of manifesting and warns that missing licences at delivery can cost you the launch.
• Assuming amateur means no command security. Part 97 allows telecommand stations to obscure commands. Authenticate the uplink anyway.
• Using a checksum as proof of origin. A CRC or hash proves integrity in transit, not who sent the file. Sign software updates and verify the signature on board.
• Leaving keys in the repository. Command keys belong in the operations environment or a hardware token, never in the flight software source tree or the ground system configuration in git.
• Forgetting the backup receiver. NASA's report says backup command links need authentication too. A recovery mode that accepts anything is the easiest way in.
• Staying on an old framework release. cFS does not backport fixes. Track releases and plan an upgrade path, even if you freeze the flight image months before launch.

FAQ

How big is a 1U CubeSat?

A 1U CubeSat is a 10 cm cube. The CDS Revision 14.1 gives a typical maximum mass of 2 kg for 1U, though heavier spacecraft can be evaluated mission by mission depending on the dispenser.

Who invented the CubeSat?

The CDS says the CubeSat Project began in 1999 as a collaboration between Prof. Jordi Puig-Suari at Cal Poly San Luis Obispo and Prof. Bob Twiggs at Stanford University's Space Systems Development Laboratory. Cal Poly maintains the specification today.

How much does it cost to build a CubeSat?

There is no official figure. Costs depend on size, whether parts are bought or built, the payload, the test campaign and launch. CubeSat 101 tells teams to budget for hardware, the ground station, environmental testing and operations as well as launch, and NASA's CSLI covers launch only for selected missions.

How long does it take to build a CubeSat?

CubeSat 101 says a CubeSat can be designed, built, tested and delivered in as little as 9 months, but typically takes 18 to 24 months, and the wait from delivery to launch can be a few months to a few years.

Do CubeSats need a radio licence?

Yes, any CubeSat that transmits needs authorisation. In the United States, CubeSat 101 says most university and non profit missions use an FCC experimental licence under Part 5, purely amateur missions use Part 97 with IARU coordination, government spacecraft go through the NTIA, and commercial systems use Part 25, including the streamlined small satellite process in section 25.122.

Can amateur radio CubeSats encrypt their commands?

The regulation allows command protection. 47 CFR 97.211(b) says a space telecommand station may transmit special codes intended to obscure the meaning of telecommand messages. Downlink content on amateur frequencies should stay in the clear. CubeSat 101 says amateur transmissions cannot be encrypted at all, so check the current rule text and your licence conditions.

What software runs on a CubeSat?

Flight software on the on-board computer, often built on an open source framework such as NASA's core Flight System or JPL's F Prime, plus software in the radio, power board and attitude control unit. On the ground, mission control, tracking and radio software complete the system.

How do you get a CubeSat launched for free?

In the United States, NASA's CubeSat Launch Initiative selects CubeSats from US educational institutions and non profit organisations, including museums and science centres, to fly on ELaNa missions. NASA says the call is typically released each August with proposals due in November. Teams still pay for their own spacecraft.

How long does a CubeSat stay in orbit?

It depends mainly on altitude and the spacecraft's area to mass ratio. The FCC's streamlined small satellite rule requires an in orbit lifetime of six years or less and deployment at or below 600 km unless the spacecraft has propulsion for avoidance and deorbit. Lower orbits decay faster.

Where Safeguard fits, honestly

Safeguard does not design spacecraft, analyse hardware, scan firmware images, test radios or generate hardware bills of materials, and it has nothing to say about vibration levels, solar cells or orbital debris. Its fit here is indirect and limited to software. Flight software frameworks, ground system tools, tracking and mission control dashboards are code that teams keep in repositories, with open source dependencies in C and C++ submodules, Python requirements files and sometimes Rust crates or container images for ground services. Safeguard can scan those repositories and images (for example safeguard scan --dir . on a checkout, or safeguard scan --image followed by an image name), match components against vulnerability databases, rank findings with reachability analysis, and open fix pull requests when you switch autonomous remediation on. It does not replace link layer authentication, key management, secure boot or any of the mission assurance steps above.

A spacecraft's code is frozen months before launch, but its ground tools are rebuilt and reinstalled for years afterwards, and both are assembled from open source components that keep receiving fixes. The same software supply chain hygiene a web team uses applies to the repositories behind a mission, with the honest caveat that it covers the software you build, not the radio or the hardware.

Fix it without waiting for upstream

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

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: 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, and pushes nothing. The same ask and approve flow fits a mission control web dashboard or a ground tool repository, where you want a dependency bumped and tested without anything landing until a person approves it.

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 and scans from the terminal. That suits a university lab that keeps its flight software and ground station code on its own machines and prefers to scan them locally rather than connect them to a hosted service.

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

The third demo is a real Android session that sends work to a computer running the Safeguard CLI and approves the command on the phone with Allow once, Allow for turn or Deny. For a small team that is often away from the lab during a pass window, it shows how a dependency fix can wait on a human decision without anyone being at the desk.

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

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Cal Poly CubeSat Program, CubeSat Information
• Cal Poly, CubeSat Design Specification Rev. 14.1 (February 2022, PDF)
• NASA CubeSat Launch Initiative, CubeSat 101: Basic Concepts and Processes for First-Time CubeSat Developers (October 2017, PDF)
• NASA, CubeSat Launch Initiative
• NASA, State of the Art of Small Spacecraft Technology
• NASA SST SOA, Introduction
• NASA SST SOA, Structures, Materials and Mechanisms
• NASA SST SOA, Power Subsystems
• NASA SST SOA, Guidance, Navigation and Control
• NASA SST SOA, Small Spacecraft Avionics
• NASA SST SOA, Communications
• NASA SST SOA, Integration, Launch and Deployment
• NASA SST SOA, Ground Data Systems and Mission Operations
• NASA Technical Standards, GSFC-STD-7000 General Environmental Verification Standard
• NASA core Flight System, GitHub repository README
• NASA core Flight System, GitHub releases
• NASA F Prime, GitHub repository README
• NASA F Prime, GitHub releases
• NASA F Prime, Svc service components
• F Prime documentation, Installing F´
• F Prime community, HelloWorld tutorial
• FCC, Guidance on Obtaining Licenses for Small Satellites, DA 13-445 (15 March 2013)
• eCFR, 47 CFR 25.122, Applications for streamlined small space station authorization
• eCFR, 47 CFR 97.211, Space telecommand station
• eCFR, 47 CFR 97.113, Prohibited transmissions
• IARU, Satellites and frequency coordination
• ITU-R, Support for small satellites
• CCSDS 355.0-B-2, Space Data Link Security Protocol (July 2022, PDF)
• White House archive, Space Policy Directive 5, Cybersecurity Principles for Space Systems (4 September 2020)
• NIST IR 8270, Introduction to Cybersecurity for Commercial Satellite Operations (July 2023)
• NIST IR 8401, Satellite Ground Segment: Applying the Cybersecurity Framework (December 2022)

Last reviewed: 24 October 2026.