A newly critical sector gets its own framework
With GOVSATCOM, IRIS² and a growing number of commercial satellite operators, European infrastructure's dependence on space systems is rising visibly — and the NIS2 Directive ((EU) 2022/2555) responded: Annex I explicitly names the space sector as highly critical. For operators of satellites, ground stations and control centers, this creates a binding regulatory framework that did not previously exist in this form.
The BSI responded with a dedicated Technical Guideline: TR-03184 “Information Security for Space Systems.” For organizations that have run ISMS programs under ISO 27001 or BSI IT-Grundschutz for years, this is not a leap into the unknown — it is the consistent application of familiar methodology to a new, demanding asset class.
From IT-Grundschutz profile to a two-part guideline
TR-03184 is not an isolated document but the provisional culmination of a multi-year BSI document series on space cybersecurity:
Document family at a glance
- 12021 — The BSI forms a working group with OHB Digital Connect, Airbus Defence and Space, and the German Space Agency at DLR on minimum cybersecurity requirements for satellites.
- 2June 30, 2022 — Publication of the IT-Grundschutz Profile for Space Infrastructure: general minimum requirements.
- 3May 31, 2023 — Publication of BSI TR-03184 Part 1 (space segment): the satellite/spacecraft across its full lifecycle, including communication links.
- 4April 22/23, 2024 — Publication of the IT-Grundschutz Profile for Space Systems, Part 2 (ground segment): a structural analysis of the business processes, applications and IT systems of an exemplary ground segment.
- 5May 14, 2025 — Publication of BSI TR-03184 Part 2 (ground segment): extends the 2024 profile with a detailed threat/mitigation-measure table.
All documents in the series were developed together with representatives of the space and information-security industries in the “Cybersecurity in Space” expert group of the Alliance for Cyber Security (ACS) — which grew out of the BSI working group founded in 2021, with participants including OHB Digital Connect, Airbus Defence and Space, secunet Security Networks, and Jade University of Applied Sciences Wilhelmshaven.
Methodology: threats, mitigation measures, lifecycle
Both TR parts follow the same logic: business processes and assets are examined across seven lifecycle phases — conception, manufacturing, testing, transport, commissioning, operations, decommissioning. Protection needs are assessed against the classic protection goals of confidentiality, integrity and availability; the focus is on systems with high or very high protection needs, though the recommendations are also meaningfully applicable to lower protection needs. For the risk analysis itself, the guideline leaves a choice between ISO/IEC 27005 and BSI Standard 200-3.
The core is an extensive table that systematically maps identified threats to mitigation measures. One concrete example makes the principle tangible: the measure BM18 “Define/Implement Configuration Management” requires continuous monitoring of configuration and configuration changes on devices — not a one-off hardening exercise at commissioning.
| Threat | Description | Addressed by (e.g.) |
|---|---|---|
| G09 | Exploitation of software vulnerabilities | BM18 Configuration Management |
| G18 | Information leakage | BM18 Configuration Management |
| G22 | Sabotage via hardware/software | BM18 Configuration Management |
| G30 | Data falsification | BM18 Configuration Management |
| G32 | Device failure/malfunction | BM18 Configuration Management |
| G42 | Parameter tampering | BM18 Configuration Management |
Selection from the TR-03184 threat/mitigation-measure table — a single measure typically addresses several threats at once.
Not a new discipline — applied ISMS methodology
Anyone who has built an ISMS under ISO 27001 or BSI IT-Grundschutz will recognize the structure of TR-03184 immediately: structural analysis, protection-needs assessment, threat catalogs and building-block thinking match the classic IT-Grundschutz logic exactly (G for threat, M/BM for measure, B for building block). The TR is explicitly conformant with ISO 27001/27002 — without mandating the IT-Grundschutz methodology itself; other ISO 27001/27005-conformant approaches are expressly permitted.
TR-03184 is not a parallel universe to established ISMS practice — it is that practice applied to a new asset class. Organizations with a working ISO 27001 or IT-Grundschutz ISMS transfer their existing methodology to satellites and ground segments instead of building an entirely new discipline from scratch.
Why this is day-to-day work for us, not uncharted territory
Our consultants bring over a decade of hands-on experience building and operating ISMS under ISO 27001 and BSI IT-Grundschutz — from engagements across regulated industries including energy, finance, insurance, and critical infrastructure, covering KRITIS-relevant environments with high and very high protection needs. This includes gap assessments, external information security officer roles, continuously certified ISMS operations, and building information risk management structures — applied practice, not textbook knowledge.

A recommendation with practical bindingness
Formally, TR-03184 remains a BSI recommendation, not a law. Practical bindingness nonetheless arises through three channels: inclusion in tender specifications and contracts; the BSI's own certification scheme (audit specification) for proving conformity at system or component level; and the regulatory context of NIS2's classification of the space sector as highly critical.
Based on our research, TR-03184 itself does not explicitly reference NIS2 — the link between the two is regulatory context, not a textual statement in the BSI document. In Germany, NIS2 has been binding law since the NIS2UmsuCG was promulgated in the Federal Law Gazette on December 6, 2025, with no transition period; the BSI registration deadline for affected entities expired on March 6, 2026.
A pragmatic path for space- and ground-segment operators
For organizations with established ISMS practice, getting started with TR-03184 is best described as an extension of the existing approach, not a rebuild from scratch.
Seven-step approach
- 1Clarify mission and protection needs: which service or mission depends on the system, which failures are not tolerable.
- 2Define scope: does this affect the space segment (Part 1), the ground segment (Part 2), or both?
- 3Structural analysis: capture assets, business processes and interfaces across the seven lifecycle phases.
- 4Protection-needs assessment for confidentiality, integrity, availability — focused on high/very high protection needs.
- 5Threat mapping against TR-03184: compare existing measures to the threats described, prioritize gaps.
- 6Reuse existing ISO 27001/IT-Grundschutz building blocks instead of reinventing them, wherever an ISMS already exists.
- 7Establish continuous configuration monitoring (BM18) and prepare for certification/the audit specification where contractual or customer requirements demand it.
Common pitfalls
Treating TR-03184 as an isolated specialty topic: setting it up as an entirely new field instead of understanding it as an application of the existing ISMS creates duplicate structures.
One-off hardening instead of monitoring: mistaking a security sign-off at commissioning for ongoing conformity — BM18 explicitly requires continuous configuration monitoring.
Key and certificate management as the supplier's black box: if the operator cannot independently demonstrate rotation cycles or key ownership, a central layer of evidence is missing.
Mistaking TR-03184 for a law: the guideline is formally a recommendation — its practical bindingness through contracts, certification and the NIS2 context is not reduced by that, but the legal characterization should stay accurate.
Assessment and next steps
TR-03184 makes a growing, regulatorily highly critical sector auditable — with a methodology that has been established in information security for years. Organizations that already operate an ISMS under ISO 27001 or BSI IT-Grundschutz do not need to build a new discipline; they need to transfer existing structural-analysis, protection-needs and threat logic to satellites and ground segments.
That transfer is exactly our long-standing practice — not since TR-03184, but for over a decade of ISMS work under ISO 27001 and BSI IT-Grundschutz across regulated, partly KRITIS-relevant industries.
Frequently asked questions about BSI TR-03184
What exactly does BSI TR-03184 regulate?
The Technical Guideline TR-03184 "Information Security for Space Systems" describes security measures across the entire lifecycle of a space system — from conception and manufacturing through testing, transport and commissioning to operations and decommissioning. Part 1 (May 2023) covers the space segment, i.e. the satellite or spacecraft itself; Part 2 (May 2025) covers the ground segment, i.e. ground stations and control centers. The core of both parts is a table that systematically maps identified threats to mitigation measures.
Is BSI TR-03184 mandatory?
Formally, TR-03184 is a BSI recommendation, not a law. Practical bindingness arises through three channels: it is increasingly referenced in tender specifications and contracts; a dedicated audit specification exists, under which the BSI issues official conformity certificates at system or component level; and it sits in the regulatory context of the NIS2 Directive, which explicitly classifies the space sector in Annex I as highly critical — in Germany legally binding since the NIS2 implementation act (NIS2UmsuCG) was promulgated in the Federal Law Gazette on December 6, 2025. Based on our research, TR-03184 itself does not explicitly reference NIS2 — the connection is regulatory context, not a statement within the BSI document itself.
What is the difference between TR-03184 Part 1 and Part 2?
Part 1 (published May 31, 2023) addresses the space segment: the satellite or spacecraft itself, including its communication links. Part 2 (published May 14, 2025) addresses the ground segment: ground stations, control centers and the associated business processes. Both parts build on previously published IT-Grundschutz profiles (2022 for space infrastructure generally, 2024 specifically for the ground segment) and extend them with a detailed threat/mitigation-measure table.
How does TR-03184 relate to ISO 27001 and BSI IT-Grundschutz?
TR-03184 is explicitly conformant with ISO 27001/27002 and methodologically rooted in IT-Grundschutz: the threat/measure logic mirrors the established IT-Grundschutz notation (G for threat, BM for mitigation measure). The IT-Grundschutz methodology itself is not mandatory — other ISO 27001/27005-conformant approaches are explicitly permitted — but the guideline builds on it in substance. Organizations that already operate an ISMS under ISO 27001 or BSI IT-Grundschutz transfer their existing methodology to a new asset class rather than building an entirely new discipline.
What role does NIS2 play for space systems?
The NIS2 Directive ((EU) 2022/2555) explicitly names the space sector in Annex I as highly critical — covering operators of ground-based infrastructure that supports the provision of space-based services, as well as providers of space-based services themselves. One important caveat: infrastructure operated by the EU itself under its own space programme is, according to several assessments, not covered — this needs to be checked case by case. In Germany, NIS2 has been binding law since the NIS2UmsuCG was promulgated on December 6, 2025; the BSI registration deadline for affected entities expired on March 6, 2026.
What is the best way for a company to start implementation?
A pragmatic starting point is not the guideline itself, but the organization’s own mission: which service or mission depends on the system, which failures are not tolerable? From there follow scope clarification (space segment, ground segment, or both?), structural analysis and protection-needs assessment, threat mapping against TR-03184, and — where an ISO 27001 or IT-Grundschutz ISMS already exists — reusing existing building blocks instead of starting from scratch. External ISO support experienced in both frameworks shortens this path considerably.
