VisualPro Tech BriefYou Cannot Bolt Security On Later
ECSS-E-ST-80C and IEEE P3536 moved space security into design
Space System Security | Lifecycle and Design-Stage Standards | Industry Trend Brief
ECSS-E-ST-80CIEEE P3536IEEE P3349CCSDS SDLSNIST IR 8270
01Overview (TL;DR) — Two Events That Made Space Security a Design Requirement
Space system security was treated as an operations problem for a long time. Ground station access control, link encryption, anomaly monitoring — things you do after launch. That premise changed over the past two years. Security moved into design and development, and two standards now say so.
ECSS-E-ST-80C, Space engineering — Security in space systems lifecycles, took effect on 1 July 2024. Issued by the engineering branch of the European Cooperation for Space Standardization, it covers the space, ground, launch, and support segments and imposes security requirements across the entire lifecycle, from initial definition through decommissioning.
IEEE P3536, Standard for Space System Cybersecurity Design, was approved by the IEEE SA Standards Board on 26 March 2026. It is the first international technical standard requiring satellite manufacturers and operators to build cybersecurity in at design time, defining a component-level design process spanning the ground system, the space vehicle, the link, and the integration layer.
Ruling out entire categories of attack through how a system is engineered — rather than layering monitoring and patches onto a design that was never built with security in mind.
— Gregory Falco, chair of the IEEE Space System Cybersecurity Working Group (Cornell University)
The two standards are not the same kind of instrument. ECSS is the framework cited contractually in European space projects. IEEE P3536 is voluntary with no built-in enforcement mechanism; adoption depends on contracts, insurers, regulators, and export-control regimes. Confusing the two leads to the wrong response priority.
02Why Now — Three Shifts That Pulled Space Security Into Design
1The Whole Lifecycle Is In ScopeLifecycle scope
ECSS-E-ST-80C is not about operational security. It is about lifecycle security management: implementing security functionality (an information security management system, for instance), protecting design information, and — critically — using security risk assessment to identify sensitive information and apply the corresponding protective marking and measures. It applies not only to classified governmental projects but to unclassified missions as well.
Its exclusions are equally explicit. Formal System Security Accreditation processes fall outside the standard, and it does not impose corporate security constraints that conflict with an organization’s own policies. Tailoring to project characteristics is permitted.
2Security Moved Into Design (Secure by Design)Design stage
IEEE P3536 defines cybersecurity controls across five areas — the ground system, the space vehicle, the link segment connecting them, and an integration layer covering the APIs, data links, and test environments that tie a mission together — with a fifth subcommittee addressing the user segment: handsets, tablets, base stations, and navigation and remote-sensing applications.
Note the reach. It is not written only for large national programs: it provides technical cybersecurity specifications for modular commercial-off-the-shelf systems, CubeSats, and smallsat buses. As the barrier to commercial space fell, the design security requirement followed it down.
3The Standards Landscape Thickened All At OnceLandscape
IEEE P3349, Standard for Space System Cybersecurity, is being developed in parallel by the same working group (S2CY) from a controls perspective. In the United States, NIST IR 8270 offers a method for applying the Cybersecurity Framework to commercial satellite operations. At the link layer, CCSDS SDLS provides the space data link security protocol; for threat knowledge, The Aerospace Corporation maintains SPARTA.
What all of these demand converges on one thing: identify the assets, derive the threats, assess the risk, turn countermeasures into requirements, and leave evidence that they were implemented and verified. That is the flow the automotive and defense sectors call TARA.
03What the Two Standards Actually Require
ECSS-E-ST-80C at a Glance
| Item | Content |
|---|
| Full title | Space engineering — Security in space systems lifecycles |
| Effective | 1 July 2024 |
| Segments | Space, ground, launch, support (spacecraft, launchers, payloads, associated ground infrastructure) |
| Lifecycle scope | Initial definition through decommissioning |
| Core requirements | Security functionality (ISMS and similar), lifecycle security management, protection of design information, risk-assessment-driven identification of sensitive information with protective marking and measures |
| Applicability | Both classified governmental projects and unclassified missions |
| Out of scope | Formal System Security Accreditation processes; corporate security constraints conflicting with organizational policy |
| Tailoring | Permitted per project characteristics (ECSS-S-ST-00 guidance) |
The Five Areas IEEE P3536 Divides
| Area | Coverage | What the analysis must address |
|---|
| Ground system | Control centers, ground stations, operations networks | Access control compromise, command forgery, insider threat |
| Space vehicle | Satellite bus, onboard software, internal buses | Command acceptance logic, software upload paths, safe mode |
| Link segment | Uplink, downlink, relay | Jamming, spoofing, replay, cryptographic operations |
| Integration layer | APIs, data links, test environments | Interface trust boundaries, asset exposure in test environments |
| User segment | Handsets, tablets, base stations, navigation and remote-sensing applications | Intrusion via end-user devices, application data integrity |
Two pairs that are easy to confuse First, IEEE P3349 and P3536 are different standards. They come from the same working group (S2CY), but P3349 specifies what protections must exist (controls) while P3536 specifies how to design (process). One is prescriptive, the other procedural.
Second, ECSS-E-ST-80C and ECSS-Q-ST-80C look like the same number but are entirely different standards. E is the engineering branch (security); Q is the product assurance branch (software product assurance). Always check the branch letter when citing a document or reviewing a contract requirement.
04Space Programs Already Have an Analysis Discipline — Security Now Stands Beside It
Space has practiced reliability and safety analysis longer and more rigorously than almost any other field. ECSS-Q-ST-30-02C sets out the principles and requirements for FMEA/FMECA, classifying failure modes by criticality — the combined measure of severity and probability of occurrence. The ECSS-Q-ST-40 family defines the principles, process, and requirements of hazard analysis.
What E-ST-80C and P3536 add is not a new analysis technique but a new causal axis. Until now the causes were random failure and design or manufacturing defect. Now an actor with intent joins them.
| Existing analysis (ECSS Q branch) | Newly required security activity | What they share |
|---|
| FMEA / FMECA (Q-ST-30-02C) | Impact assessment of threat scenarios | The same functional and structural decomposition |
| Hazard analysis (Q-ST-40 family) | Security risk assessment | Risk identification and classification procedure |
| FTA and reliability analysis | Attack path analysis | Event logic and minimal cut sets |
| Requirement decomposition and tracing | Security requirement decomposition and tracing | Requirement hierarchy and design allocation |
| Verification evidence package | Evidence of countermeasure effectiveness | The basis for review and audit response |
The problem appears when the two axes live in different tools If safety analysis sits in the reliability team’s FMECA and security analysis sits in a separate threat worksheet, you model the same satellite twice — and the mission loss caused by a security compromise never reaches the FMECA. In the other direction, what the redundancy introduced for safety means to an attacker never gets examined either.
In space, the cost of that omission is higher than elsewhere. Contact opportunities are limited, physical access is impossible, and missions run beyond ten years. There is very little room to catch later what design missed. That is precisely why both standards target design.
05How VisualPro Supports It
One Structure Tree, Five AnalysesShared structure
FMEA, FTA, HARA, TARA, and STPA share a single system structure database. Put the satellite bus, payload, ground station, and link on one tree, and the five areas IEEE P3536 defines become nodes on that same tree. Reliability analysis and security analysis reference one model.
TARA — From Assets to Security RequirementsStandards fit
Asset identification, threat scenario derivation, risk assessment, countermeasures, and security requirements are carried out and traced inside the tool. The security risk assessment and sensitive-asset identification ECSS-E-ST-80C requires, and the artifacts P3536’s design process expects, sit on this flow.
Traceability Across Analyses (Digital Thread)Core value
Threat to countermeasure to security requirement to verification item, and failure mode to effect to severity to design action, are linked in a single database. When a design changes or a new threat arrives, the related analyses update with it, so live traceability is available at review time.
MCP-Based AI Agent IntegrationAI integration
VisualPro’s MCP (Model Context Protocol) capability for FMEA, FTA, HARA, TARA, and STPA lets AI agents such as Claude communicate directly with the tool. Candidate threat and hazard identification through to draft scoring can be done conversationally, leaving the analyst to verify and judge.
06Frequently Asked Questions (FAQ)
Q1Is IEEE P3536 mandatory?
No. P3536 is voluntary and carries no built-in enforcement mechanism. Its force comes from procurement contracts, insurer underwriting conditions, regulator reference, and export-control regimes. ECSS-E-ST-80C is different in kind — it is the framework cited contractually in European space projects. If you are evaluating entry into European programs, ECSS comes first; treat P3536 as the international baseline for the design process.
Q2Are ECSS-E-ST-80C and ECSS-Q-ST-80C the same standard?
No. The numbers look alike but the branches differ. E-ST-80C is security (engineering branch); Q-ST-80C is software product assurance (product assurance branch). This trips people up in practice, so verify the branch letter whenever you cite the document or review a contract requirement.
Q3Does automotive cybersecurity (ISO/SAE 21434) experience transfer to space?
The methodological flow transfers directly. Asset identification, threat scenarios, risk assessment, countermeasure derivation, and traceability form the same skeleton in TARA and in the space security standards. What differs is the segment structure (ground, link, orbit, user), the constraint on contact opportunity (visibility windows and bandwidth), the mission life (ten years and beyond), and the governing standards. What has to be learned is the domain constraint and the standards landscape, not the analysis method.
Q4Does VisualPro produce ECSS-format deliverables directly?
To be precise: VisualPro produces standard-format outputs for AIAG-VDA FMEA, ISO 26262 HARA (ASIL), ISO/SAE 21434 TARA, and FTA. The FMECA in ECSS-Q-ST-30-02C differs in field structure and in how criticality is derived, so field mapping is required. The substance of the analysis, however — structural decomposition, failure modes, effects, severity, countermeasures, traceability — is managed in the same database, so output definitions matching a project’s format are agreed and configured during deployment.
07Start Now (Next Step)
In space systems, safety and security are no longer activities from different phases. ECSS-E-ST-80C pins security to the whole lifecycle; IEEE P3536 pins it to design. And the artifacts both standards require stay affordable only when they are built on the same structure as the reliability and safety analysis you already run. Start with VisualPro — proven in automotive, defense, aviation, robotics, and semiconductors — and put threat analysis and failure analysis on one structure.
Threat analysis and failure analysis on one structure — meeting the space security standards with VisualPro.
Sources: ECSS, “ECSS-E-ST-80C — Security in space systems lifecycles” (2024-07-01) · CYSAT News, “IEEE Approves First Space Cybersecurity Design Standard” (2026-07-10) · IEEE SA, “P3349 — Standard for Space System Cybersecurity” · NIST IR 8270 · ECSS-Q-ST-30-02C FMEA/FMECA
VisualPro Inquiries & Demo
Space system security was treated as an operations problem for a long time. Ground station access control, link encryption, anomaly monitoring — things you do after launch. That premise changed over the past two years. Security moved into design and development, and two standards now say so.
ECSS-E-ST-80C, Space engineering — Security in space systems lifecycles, took effect on 1 July 2024. Issued by the engineering branch of the European Cooperation for Space Standardization, it covers the space, ground, launch, and support segments and imposes security requirements across the entire lifecycle, from initial definition through decommissioning.
IEEE P3536, Standard for Space System Cybersecurity Design, was approved by the IEEE SA Standards Board on 26 March 2026. It is the first international technical standard requiring satellite manufacturers and operators to build cybersecurity in at design time, defining a component-level design process spanning the ground system, the space vehicle, the link, and the integration layer.
The two standards are not the same kind of instrument. ECSS is the framework cited contractually in European space projects. IEEE P3536 is voluntary with no built-in enforcement mechanism; adoption depends on contracts, insurers, regulators, and export-control regimes. Confusing the two leads to the wrong response priority.
Its exclusions are equally explicit. Formal System Security Accreditation processes fall outside the standard, and it does not impose corporate security constraints that conflict with an organization’s own policies. Tailoring to project characteristics is permitted.
Note the reach. It is not written only for large national programs: it provides technical cybersecurity specifications for modular commercial-off-the-shelf systems, CubeSats, and smallsat buses. As the barrier to commercial space fell, the design security requirement followed it down.
What all of these demand converges on one thing: identify the assets, derive the threats, assess the risk, turn countermeasures into requirements, and leave evidence that they were implemented and verified. That is the flow the automotive and defense sectors call TARA.
Second, ECSS-E-ST-80C and ECSS-Q-ST-80C look like the same number but are entirely different standards. E is the engineering branch (security); Q is the product assurance branch (software product assurance). Always check the branch letter when citing a document or reviewing a contract requirement.
Space has practiced reliability and safety analysis longer and more rigorously than almost any other field. ECSS-Q-ST-30-02C sets out the principles and requirements for FMEA/FMECA, classifying failure modes by criticality — the combined measure of severity and probability of occurrence. The ECSS-Q-ST-40 family defines the principles, process, and requirements of hazard analysis.
What E-ST-80C and P3536 add is not a new analysis technique but a new causal axis. Until now the causes were random failure and design or manufacturing defect. Now an actor with intent joins them.
In space, the cost of that omission is higher than elsewhere. Contact opportunities are limited, physical access is impossible, and missions run beyond ten years. There is very little room to catch later what design missed. That is precisely why both standards target design.
In space systems, safety and security are no longer activities from different phases. ECSS-E-ST-80C pins security to the whole lifecycle; IEEE P3536 pins it to design. And the artifacts both standards require stay affordable only when they are built on the same structure as the reliability and safety analysis you already run. Start with VisualPro — proven in automotive, defense, aviation, robotics, and semiconductors — and put threat analysis and failure analysis on one structure.