4 Hardware Components Behind SpaceComputer's Satellite Architecture
By 2027, several orbital compute platforms will be live. Most will depend on their single compute chip vendor never being compromised. Once a satellite is in orbit, that dependency is permanent. The hardware choices made before launch determine whether the system can be trusted, as there is no way to patch the satellite hardware once operating in orbit.
A satellite's security foundation starts at the hardware level. Whether anyone can independently verify what the satellite is doing depends on its hardware architecture and the supply chain behind the compute chip on board.
Four hardware components show up frequently in conversations our team has about satellite security: Secure Elements (SEs), Hardware Security Modules (HSMs), Trusted Execution Environments (TEEs), and Trusted Platform Modules (TPMs). Each does a different job. Below, we walk through each one and show how it fits into Space Fabric, our satellite-native trusted computing architecture.
The Hardware Components in SpaceComputer Satellites
Secure Elements (SEs)
A Secure Element is a tamper-resistant chip designed for cryptographic key custody and signing. Private security keys are generated inside the chip and never leave it or are shared in plaintext.
In satellite systems, the SE keeps these security keys protected even if the operating system, or other software is breached.
Space Fabric uses two SEs from different vendors: the NXP SE050 and the Tropic Square TROPIC01. Both must co-sign every attestation we produce. All secure signing keys are generated on-orbit after launch, inside the chips themselves. No SpaceComputer signing key has ever existed on Earth, eliminating the pre-launch supply chain attack surface.
Hardware Security Modules (HSMs)
A Hardware Security Module is dedicated hardware for cryptographic key management and signing, designed to keep keys locked inside a tamper-resistant boundary. HSMs are widely used in banking, certificate authorities, and any system that needs to manage keys (or access) under strict access policies.
In satellite systems, HSMs provide certified key management under enforced access policies, in a form factor that fits the size and power constraints of a smaller satellite payload.
In Space Fabric's architecture, the SEs (mentioned above) serve as embedded HSMs on the satellite. The NXP SE050 is certified to Common Criteria EAL 6+, providing HSM functionality at the chip level. On Earth, traditional HSMs can pair with our Veraison verifier for customer-side key custody.
Trusted Execution Environments (TEEs)
A Trusted Execution Environment is an isolated region inside a general-purpose computer, where code and data are protected from the rest of the system, including the operating system and hypervisor (a software that can create and run multiple virtual machines on a physical computer). Common examples of a TEE include Intel SGX, AMD SEV-SNP, and ARM TrustZone.
In satellite systems, the TEE is where customer workloads run isolated from the operator, the host OS, and any other software on the satellite.
Space Fabric uses ARM TrustZone on the USB Armory Mk II as the satellite's TEE. Customer workloads are deployed into this isolated environment, and the surrounding software stack is treated as untrusted by design. Even if the operator or another tenant tries to inspect what is running, the TEE keeps the workload's execution and data inaccessible.
Trusted Platform Modules (TPMs)
A Trusted Platform Module is a dedicated chip for measuring boot and platform attestation. In other words, it verifies or certifies each task or progress step in a tamper-evident register, to create a verifiable record of what software the system loaded.
In satellite systems, the TPM makes tampering with the platform's software stack detectable.
Space Fabric uses a discrete TPM 2.0 module on the on-board Raspberry Pi 5, where it provides defense-in-depth by raising the cost of compromising the relay. It also serves as the natural integration point for post-quantum cryptography (PQC) during pre-launch provisioning.
How the Components Work Together in Space Fabric's Trusted Execution Architecture
Each of these components matters on its own, but the architectural decisions in Space Fabric support independently verifiable security claims rather than needing to trust the vendor is secure.
The trust anchor is split across the two SEs from different vendors, so no single chip supplier holds all the keys to attestation. All signing keys are generated on-orbit after launch, eliminating the pre-launch supply chain attack surface entirely. The TPM provides defense-in-depth on the on-board relay without sitting in the protocol's trust path, and serves as a natural integration point for the post-quantum cryptographic primitives that will become standard over the next decade.
The term "hardware root of trust" means exactly what it says: the trust is in the hardware. If the hardware is compromised, the rest of the stack has nothing to fall back on. That is why every architectural choice about which chip does what, which vendors are involved, and where the keys come from matters to whether the system can be trusted at all.
As more compute moves to space, the hardware layer is what higher-level security claims will be built upon.
Visit the SpaceComputer website.
Follow us on X (Twitter) and LinkedIn.
Read more about our trust architecture in our newest research paper Space Fabric here.
Read more on our satellite architecture:
Tara Jean
