Every satellite has a command path. It runs from an operator’s console through a ground station, up the radio link and into the flight software, and it ends with the spacecraft doing what it was told. The firmware update path runs next to it. If either one accepts something it should not, the operator may not get a second chance.
SATShow Week 2027 includes two sessions on this subject, back to back, on the afternoon of Monday, March 8, at the Walter E. Washington Convention Center in Washington, DC. The first is about post-quantum signatures and firmware trust that can be recovered when something goes wrong. The second is about attacks on the hardware those signatures run on. Read together, they cover both halves of the problem: the cryptography, and the chip that has to run it correctly.
This is the fourth piece in our SATShow Week 2027 series. The first explained the week itself, the second looked at the early GovMilSpace agenda, and the third took an Africa angle on the Sovereign Networks session.
The two sessions, as posted
Titles, times, names, job titles and affiliations below are copied from the satshow.com program page as CTN read it on October 26, 2026. The program does not give a time zone, so times below run as listed in the program.
- Mon, Mar 8, 1:30 to 1:55 pm. “Protecting the Command Path: Post-Quantum Authentication and Recoverable Firmware Trust for Long-Lived Satellites.” Ankit Gupta, a doctoral researcher at the University of North Texas (listed as “PhD Researcher in PQC”).
- Mon, Mar 8, 2:00 to 2:25 pm. “Hardware Security Attacks and Defense in Satellite Communication.” Marc Witteman, Senior Director Device Security, Keysight.
The program lists the first talk under the Tech Seminar, Government, Inner Circle Access and Military Access passes. The second is listed under those four and the Conference Pass.
Gupta’s program bio says he is pursuing a PhD in Information Science, with a concentration in cybersecurity, at the University of North Texas. It says his current research develops “vendor-neutral and testable methods for cryptographic inventory, hybrid transition, interoperability, performance validation, operational continuity, and rollback, with emerging applications to satellite communications and long-lived mission systems.” Witteman’s bio says he has “more than 25 years experience in device security testing” and now leads Keysight’s device security team.
Why the command path is harder in orbit
When a server on the ground is compromised, someone can wipe it and rebuild it. When a firmware update bricks a router, someone can walk over and reflash it. A satellite offers neither fix. The Gupta abstract says so directly: “Unlike terrestrial systems, an operator may have no physical access to recover a spacecraft after launch.”
The abstract then lists what else makes the job hard: “Long mission lifetimes, intermittent communication, limited bandwidth, constrained onboard computing, and dependence on pre-established trust anchors.” Each of those bends a control that is routine on the ground.
A long mission means the keys and algorithms picked before launch have to stay trustworthy for years. Intermittent contact means a key rotation or revocation can only happen while a ground station has the satellite in view. Limited bandwidth means a large signature uses up contact time that could carry something else. Constrained onboard computing means verification has to run on the flight processor the satellite already has. Pre-established trust anchors are the public keys loaded before launch. If they are wrong or lost, nobody can fix them in person.
The abstract names the ways it can go wrong: “A forged command, a compromised signing key, a malicious firmware image, or a failed credential transition can affect an entire mission.” The fourth case deserves attention from anyone planning a migration. Swap keys or algorithms badly and the operator can lock itself out of its own spacecraft. That is why the abstract calls post-quantum authentication “a mission-resilience problem, not simply an algorithm-selection exercise.”
The instruments, defined
Digital signature. NIST’s FIPS 204 page says digital signatures “are used to detect unauthorized modifications to data and to authenticate the identity of the signatory.” The signer holds a private key, and anyone with the matching public key can check the signature. In a satellite, the ground signs a telecommand or a firmware image, and the spacecraft checks it against a public key it already holds.
Why post-quantum. NIST SP 800-208 says that “all of the digital signature schemes specified in FIPS 186 will be broken if large-scale quantum computers are ever built.” FIPS 186 is the NIST standard for today’s widely used signature algorithms. A satellite launched with only those algorithms has to hope that question stays open for its whole service life.
ML-DSA (FIPS 204). The Module-Lattice-Based Digital Signature Standard, published by NIST on August 13, 2024. NIST describes ML-DSA as “a lattice-based digital signature algorithm” and says it “is believed to be secure, even against adversaries in possession of a large-scale quantum computer.” The FIPS 204 page carries a planning note dated July 31, 2026, pointing to an errata spreadsheet listing “several minor issues” to be corrected in a future update or revision.
SLH-DSA (FIPS 205). The Stateless Hash-Based Digital Signature Standard, also published August 13, 2024. NIST says SLH-DSA “is based on SPHINCS+, which was selected for standardization as part of the NIST Post-Quantum Cryptography Standardization process.” “Stateless” is the word to notice: the signer does not have to keep a record of which keys it has already used.
LMS and XMSS (NIST SP 800-208). The Leighton-Micali Signature system and the eXtended Merkle Signature Scheme, with their multi-tree variants, HSS and XMSS^MT. NIST specified them in SP 800-208 in October 2020. Both are stateful hash-based signature schemes, and NIST says their security “depends only on the security of the underlying hash functions.”
There is a procurement hook here for government buyers. The applicability sections of FIPS 204 and FIPS 205 each name four options (FIPS 204, FIPS 205, FIPS 186-5 and NIST SP 800-208) and say that one of them “shall be used in designing and implementing public-key-based signature systems that federal departments and agencies operate or that are operated for them under contract.”
The state problem, in NIST’s words
Stateful schemes have a catch, and SP 800-208 spends a lot of words on it. An LMS or XMSS private key “consists of a large set of one-time signature (OTS) private keys,” and “the signer needs to ensure that no individual OTS key is ever used to sign more than one message.” If an attacker obtains two signatures made with the same one-time key, “it would become computationally feasible for that attacker to forge signatures on arbitrary messages.”
NIST draws the operational conclusions itself. Stateful schemes “are not suitable for general use because they require careful state management that is often difficult to assure.” The recommendation “requires that key and signature generation be performed in hardware cryptographic modules that do not allow secret keying material to be exported, even in encrypted form.” Ordinary backups are out, because “simply copying the private key would create a risk of OTS key reuse.” For resilience, NIST describes alternatives such as several independent keys on separate modules, or a two-level tree with the lower trees on different modules. It warns that the module holding the top-level tree “is a potential single point of failure.” It also warns that a crash between issuing a state update and that update reaching non-volatile memory can lead to a one-time key being used again after restart.
NIST also says who these schemes are for: cases where a signature scheme is needed soon, “the implementation will have a long lifetime,” and moving to a different scheme after deployment “would not be practical.” Its example is “the authentication of firmware updates for constrained devices,” some of which “will be in use for decades.” That is close to a description of a satellite. Note where the state lives. It sits with the signer, which here is the ground segment. The satellite only verifies.
Signature sizes, from the standards
The Gupta abstract lists “bytes transmitted per contact window” among its comparison criteria, so size matters. These figures come from the tables in FIPS 204 and FIPS 205.
| Scheme | Parameter set | Public key (bytes) | Signature (bytes) |
|---|---|---|---|
| ML-DSA (FIPS 204) | ML-DSA-44 | 1,312 | 2,420 |
| ML-DSA (FIPS 204) | ML-DSA-65 | 1,952 | 3,309 |
| ML-DSA (FIPS 204) | ML-DSA-87 | 2,592 | 4,627 |
| SLH-DSA (FIPS 205) | SLH-DSA-128s | 32 | 7,856 |
| SLH-DSA (FIPS 205) | SLH-DSA-128f | 32 | 17,088 |
| SLH-DSA (FIPS 205) | SLH-DSA-256s | 64 | 29,792 |
| SLH-DSA (FIPS 205) | SLH-DSA-256f | 64 | 49,856 |
SLH-DSA has very small public keys and large signatures. ML-DSA signatures are smaller, with larger public keys. CTN has not tested these against any uplink rate or flight processor and makes no claim about which suits a given mission. That comparison is what the talk says it will make.
What the post-quantum session proposes
The abstract describes a proposal. It does not report results. The presentation, it says, “proposes a recoverable post-quantum trust architecture for satellite command authentication, secure boot, onboard software, and firmware updates.”
The core idea is separation. The proposed architecture “separates offline mission roots, operational command authorities, firmware-signing services, ground-station identities, and onboard verification keys to limit the effect of a single credential compromise.” In plain English: the key that signs routine commands should not be able to sign new firmware, and neither of them should be the root that can replace both.
On top of the signatures, it “combines post-quantum digital signatures with role separation, command sequencing, anti-replay controls, pre-positioned credential epochs, protected recovery keys, and authenticated activation procedures.” Pre-positioned credential epochs, as we read the phrase, means loading future keys before they are needed, so a rotation does not depend on pushing a large upload through a short pass.
On algorithms, the abstract says the evaluation “considers ML-DSA and SLH-DSA, together with stateful hash-based alternatives such as LMS or XMSS where operational key-state controls are feasible.” That condition lines up with NIST’s warning above. The abstract says that “rather than declaring a single algorithm appropriate for every mission,” the study compares “signature size, verification time, processor and memory utilization, onboard storage, key management complexity, bytes transmitted per contact window, and recovery behavior.”
The abstract lists the test scenarios as proposed, not completed, and the list reads like a threat model: “a valid command sequence; replayed and delayed commands; unauthorized command sources; compromised ground credentials; missed key rotations; loss of time synchronization; interrupted firmware transmission; corrupted images; attempted downgrade to vulnerable software; and failure of a newly activated verification key.” According to the abstract, the proposed architecture would use “authenticated version metadata, monotonic security state, staged activation, independent image verification, and recoverable fallback paths to prevent an unsuccessful cryptographic transition from permanently disrupting spacecraft control.” The abstract gives no results for these tests, and CTN does not treat any of them as findings.
The talk also “examines hybrid verification periods in which classical and post-quantum trust can coexist until defined technical and operational acceptance conditions are satisfied.” The abstract says attendees “will receive a reference trust architecture, an algorithm-selection matrix, a command-authentication test plan, a firmware-transition workflow, and a recovery checklist.” CTN has not seen any of these materials.
In CTN’s reading, if you map security work to NIST-style control themes, the proposal covers familiar ground: separation of duties, cryptographic key management, replay-resistant authentication, software and firmware integrity, and contingency and recovery planning. What changes in orbit is that every one of those controls has to work without anyone being able to touch the hardware.
What the hardware session adds
The second session picks up where the cryptography leaves off. Its abstract says “logical protection relies on physical protection.” A signature check can be bypassed if the chip running it, or the memory holding the trusted key, can be made to misbehave.
The talk will “first review the principle of a root-of-trust, and the architecture of secure boot,” including “cryptographic signing and encryption schemes.” It will also review “the dilemma of storing firmware in persistent memory, versus making it updateable.” That is the same trade-off the first session is managing from the other direction. Code that cannot be changed cannot be corrupted by a bad update, and it cannot be patched either.
It then turns to “the main hardware attack vectors,” listed as “direct hardware access to various (hidden) interfaces, but also listening in to side channels, or manipulating functionality through fault injection.” Side-channel analysis tries to recover secrets from physical effects of computation rather than from the cryptography itself. Fault injection disturbs a chip on purpose so that it skips or corrupts a step, such as a signature check. The abstract says the talk will “review a few real-life cases of attacks on satellite communication systems.” CTN has not seen those cases and makes no claim about them.
The abstract’s tone is restrained. It says satellite communication “relies on a strong identification mechanism to authenticate terminals and prevent abuse,” calls for “a mix of measures” at the hardware, software and application levels, and ends: “While perfect security does not exist, there is often a path to effective security that would discourage adversaries by making attacks impractical.” Our reading: the attack vectors the abstract lists generally need physical access to a device, and the devices that are easiest to reach are on the ground, in user terminals and ground equipment. The command path starts there.
A Tuesday tie-in: the CTO Forum on AI
On Tuesday, March 9, from 11:00 am to 12:00 pm, the CTO Forum is titled “The Efficiencies and Security Concerns Over AI Integration.” The program lists Alissa Knight, CEO, CAIO, Assail, Inc., as moderator, and Luca Petronzio, Chief Technology and Innovation Officer, Telespazio S.p.A.
The organiser’s description says this year’s forum “focuses on the risk and rewards of broader AI integration in satellite operations,” and that “large language models and agentic AI, however, are becoming central to satellite operations.” It adds that while AI “can identify network anomalies and even recommend corrections, whether customers in 2026 will allow systems to automatically make those changes is still an open question.”
From where we sit, that is a command-path question. A system allowed to apply its own corrections is a command source, and the Gupta abstract’s test for “unauthorized command sources” and its separation of “operational command authorities” are, in our view, a useful way to think about it. Whether the forum takes it up is something to find out in March.
Questions to ask vendors before March
These are for operators and government buyers evaluating satellites, payloads, flight software or ground systems. Each one ties back to the sources above.
- Which signature scheme protects telecommands, and which protects firmware images? Ask for the algorithm and parameter set for each (for example ML-DSA-65, SLH-DSA-128s, LMS or XMSS) and the FIPS 204, FIPS 205 or SP 800-208 reference. Federal buyers can cite the “shall be used” language in FIPS 204 and FIPS 205.
- If you use LMS or XMSS, how is the state managed? Ask where signing happens, whether keys are generated and used inside hardware modules that do not export secret keying material, how the state update reaches non-volatile memory before a signature leaves the module, and what stops a one-time key being reused after a crash or failover. SP 800-208 says copying the private key creates reuse risk, so ask what replaces a backup.
- How are roles separated? Ask which keys can sign routine commands, which can sign firmware, which can replace the trust anchors, and whether the mission root is kept offline.
- How do rotation and revocation work over limited contact windows? Ask whether future keys or credential epochs are loaded before launch, how many bytes a rotation takes, and what the spacecraft does if a scheduled rotation is missed.
- What is the fallback and recovery boot path, and who can authorize it? Ask how the spacecraft recovers from an interrupted update, a corrupted image or a newly activated key that fails, how recovery keys are protected, and how many people must approve a recovery.
- How are replay and downgrade blocked? Ask about command sequencing and anti-replay controls, what happens when time synchronization is lost, and whether authenticated version metadata and monotonic security state stop a rollback to vulnerable software.
- How crypto-agile is the spacecraft? Ask whether the verification algorithm can be changed on orbit, how a hybrid classical and post-quantum period would work, and what acceptance conditions would end it.
- What does verification cost onboard? Ask for measured verification time, memory use, storage and bytes per contact window on the actual flight processor, not on a lab workstation.
- What hardware security testing evidence exists? Ask for side-channel and fault-injection test results on the root of trust and secure boot, who did the testing, and what was in scope, including user terminals and ground hardware.
- Who holds the keys on the ground? Ask where the mission root, command-authority and firmware-signing keys are kept, in what kind of module, who has access, and how access changes when staff or contractors change.
What to watch at SATShow in March
- Whether the post-quantum talk publishes its algorithm-selection matrix and test plan, and what measurements back them.
- Whether it recommends a stateful scheme for firmware, in line with SP 800-208’s firmware example, or steers away because of state management.
- Which parts of a system the hardware talk treats as most exposed: terminals, ground equipment or spacecraft.
- Whether the CTO Forum gets into who authorizes AI-initiated changes.
Method note
CTN read the satshow.com program page on October 26, 2026, and compared it with the copy we read on October 19. The two security sessions’ titles, times, speakers and abstracts were unchanged; the CTO Forum listing had added a moderator. The program page listed 46 sessions on October 26. Session details and quotations come from that page. The program does not state a time zone, so session times are given as listed in the program. Definitions, quotations and sizes for ML-DSA, SLH-DSA, LMS and XMSS come from NIST’s FIPS 204, FIPS 205 and SP 800-208 pages and documents. The abstracts describe what the talks propose; none of the planned tests, results or deliverables were public when we read the page. CTN did not request comment from the organiser or the speakers.
Sources
All pages read October 26, 2026.
- SATShow Week 2027, program page (“Protecting the Command Path” and “Hardware Security Attacks and Defense in Satellite Communication,” Mon Mar 8; CTO Forum, Tue Mar 9)
- NIST, FIPS 204, Module-Lattice-Based Digital Signature Standard (publication page)
- NIST, FIPS 204 (PDF)
- NIST, FIPS 205, Stateless Hash-Based Digital Signature Standard (publication page)
- NIST, FIPS 205 (PDF)
- NIST, SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes (publication page)
- NIST, SP 800-208 (PDF)
- SATShow Week 2027 explainer (piece 1)
- GovMilSpace 2027 early agenda (piece 2)
- SATShow 2027 Sovereign Networks, the Africa angle (piece 3)
- NASA Image and Video Library, “STS-43 TDRS-E & IUS over the Pacific Ocean after deployment from OV-104’s PLB” (sts043-601-033)
Disclosure: Lone Cowry, the publisher of Cowry Tech News, plans to attend SATShow Week 2027. It has no sponsorship or partnership with the event.