How Space Sector Operators Satisfy CIR Annex 5 Supply Chain Audits: Launch Vehicles, Satellite Firmware SBOMs, and COTS Risk

The KA-SAT cyberattack of February 2022 disabled tens of thousands of satellite internet terminals across Europe — wind turbines lost remote management, emergency services lost communications, and the cascading harm crossed borders within hours. It demonstrated why NIS2 classifies space operators as essential entities. It also revealed how a single compromise at the ground segment — a software vulnerability in Viasat’s ground management network — propagates through the satellite tier to critical infrastructure downstream.

For ground-based space operators, the question is no longer whether NIS2 applies. The October 2024 transposition deadline has passed and member states are enforcing. The more pressing question is whether your supply chain documentation would withstand a CIR 2024/2690 audit today — specifically, the controls in Annex Title 5 that govern supply chain security.

Standard NIS2 supply chain guides were written for IT services organisations, not satellite operators. They do not address the firmware running in your onboard computer, the proprietary avionics supplied under ITAR export controls, or the commercial-off-the-shelf (COTS) components in your CubeSat constellation. This guide maps CIR Title 5 directly against the three-tier supply chain topology specific to space operations, and provides a framework for compliance gaps that no existing guidance covers.

If you are new to NIS2 scope determination, see the Essential vs Important Entities guide first. For the incident reporting obligations that accompany these supply chain requirements, see GPS Spoofing, KA-SAT, and Art. 23: What Space Sector Operators Must Report Under NIS2.

Is Your Organisation in Scope? The NIS2 Space Sector Classification

NIS2 Directive (EU) 2022/2555 places the space sector in Annex I as a sector of high criticality [4]. The operative definition covers “operators of ground-based infrastructure, owned, managed and operated by Member States or by private parties, that support the provision of space-based services.” The phrase “support the provision” is broader than it appears — it captures not just direct satellite operators but any organisation whose ground systems are essential to the continuity of in-scope space services.

Entity type	NIS2 status	Primary scope trigger
Ground station / TT&C site operators	Essential Entity	Direct operation of in-scope ground infrastructure
Mission control centres	Essential Entity	Direct operation of systems supporting space-based services
Satellite manufacturers (EU-market placing)	Important Entity	Supplying equipment to in-scope operators; CIR 5.1.4 flow-down
Launch service providers (EU-established)	Important Entity	ICT services supporting launch of in-scope satellites
COTS component distributors (ICT system access)	Indirect scope	CIR 5.1.4 contractual obligations from ground operator

Two common scoping mistakes arise repeatedly. First, operators assume that because the satellite is in orbit it falls outside NIS2. The directive scopes to ground-based infrastructure — but your ground systems’ availability, integrity, and confidentiality obligations extend to the security of the command link your ground stations operate. Second, size thresholds matter for the Essential vs Important distinction, but operators of critical space infrastructure may be classified as Essential regardless of size where their services underpin other regulated sectors. Verify your classification against your national competent authority’s transposition rules.

For CISOs: Every ground station, TT&C site, relay node, data centre, and mission control system supporting regulated services is directly in scope under Article 21(2). All ten mandatory measures apply immediately — including supply chain security under Article 21(2)(d) [1].

For Compliance Officers: The first NIS2 audit cycle is already running in most member states. Supply chain documentation under CIR Title 5 is typically among the first evidence requests, because it demonstrates whether the entity has mapped its third-party dependencies and operationalised the risk management framework.

The Three-Tier Space Supply Chain Under CIR Title 5

CIR 2024/2690 structures supply chain obligations around your direct suppliers. But in space operations, “direct suppliers” span three qualitatively different tiers — each with distinct documentation requirements, different exposure to export controls, and different audit evidence expectations [3].

Tier 1 — Ground infrastructure operator (the CIR-obligated party). This is where all CIR Title 5 obligations originate. The ground operator must implement a supply chain security policy (CIR 5.1.1), maintain the supplier directory (CIR 5.2), flow down cybersecurity requirements contractually (CIR 5.1.4), and conduct planned-interval monitoring reviews (CIR 5.1.7). Everything in this guide derives from your obligations as the Tier 1 entity.

Tier 2 — Launch service provider. The launch vehicle’s software stack — guidance, navigation and control (GNC) algorithms, telemetry management, range safety systems — is a direct upstream ICT dependency. A compromise of launch vehicle software does not just affect launch day; it affects initial orbit insertion, which is irreversible. Under CIR 5.1.2, your supplier selection documentation must demonstrate that the launch provider’s software development lifecycle was assessed against the criterion of “quality and resilience of ICT products/services with embedded risk management” [3]. Accepting a launch contract without this on record is a CIR 5.1.2 gap.

Tier 3 — Satellite component manufacturers (including ITAR/EAR-restricted suppliers). Satellite hardware typically includes components from multiple international suppliers operating under US export control law — ITAR (22 CFR §§ 120–130) or the Export Administration Regulations (EAR, 15 CFR § 734). These are your direct ICT suppliers under CIR 5.1.4 if their components carry embedded software that affects the command link’s security or integrity. The documentation challenge: CIR 5.1.4 requires audit rights and vulnerability handling obligations in contracts, but export controls may legally restrict the supplier’s ability to disclose technical specifications. This tension is the most under-addressed compliance gap in NIS2 space sector guidance.

Supply chain tier	CIR Title 5 control	Space-specific challenge	Evidence required
Ground operator (Tier 1)	5.1.1 policy; 5.2 directory	Policy must cover satellite segment threat vectors, not just IT services	Written policy + quarterly review logs
Launch service provider (Tier 2)	5.1.2 selection criteria; 5.1.4 contracts	GNC/telemetry software SDL documentation; SLA coverage of pre-launch window	Selection assessment record + contractual SLAs
Component manufacturer (Tier 3)	5.1.4 audit rights; 5.1.7 monitoring	ITAR/EAR disclosure restrictions vs CIR audit obligation	Redacted SBOM or third-party escrow audit record

What CIR Title 5 Actually Requires — and How Auditors Read It

The Annex to CIR 2024/2690 is structured in 13 Titles. Title 5 covers supply chain security across six operational controls (5.1.1–5.1.7) plus the supplier directory requirement (5.2) [3]. These are not one-time documentation tasks — they are procedural obligations that produce living, updatable records. Understanding the exact requirements matters for audit preparation.

5.1.1 — Supply chain security policy. The policy must govern your relationships with direct suppliers and communicate your organisation’s role in the supply chain to those suppliers [3]. A generic IT vendor management policy does not satisfy this control for space operators: it must explicitly address the satellite segment’s threat landscape, including firmware update chains, command-link integrity, and the specific sub-supplier tiers that can affect service availability. Per the NIS2 supply chain security overview, this policy is typically the first document reviewed in a supply chain audit.

5.1.2 — Supplier selection criteria. Four specific criteria must appear in your selection framework: (1) cybersecurity practices and secure development procedures, (2) ability to meet specified cybersecurity requirements, (3) quality and resilience of ICT products/services with embedded risk management, and (4) capacity to diversify supply sources and limit vendor lock-in [3]. Criterion 4 matters specifically in space: where a satellite’s primary processor comes from a sole-source licensed manufacturer — a common situation — the selection record must document how vendor lock-in risk was assessed, even if it could not be eliminated. See also the supplier classification framework for a criticality-tiered approach.

5.1.3 — Coordinated risk assessments. Entities must incorporate results from EU-level coordinated supply chain risk assessments conducted under the NIS2 framework. ENISA publishes coordinated assessments for critical sector supply chains; the space sector assessment results should be integrated into your risk methodology as published [3].

5.1.4 — Contractual specifications. This is the audit-critical control. Contracts must include: cybersecurity requirements aligned with acquisition standards, background verification of supplier employees where proportionate, incident notification to the operator without undue delay, audit rights over the supplier’s cybersecurity practices, vulnerability handling and disclosure obligations, sub-contracting requirements with equivalent controls passed down, and post-contract data retrieval and disposal obligations [3]. For satellite component manufacturers, the audit rights clause creates the tension detailed below.

5.1.7 — Monitoring activities. Required activities include: regular SLA implementation reports, review of supplier-related incidents, assessment of need for unscheduled reviews, and risk analysis of changes to ICT products or services with documented findings [3]. Auditors interpret “planned intervals” as requiring a defined, documented frequency — not an annual default. The space sector guidance from ISMS.online recommends quarterly supplier reviews as the practical benchmark [4].

5.2 — Supplier directory. The directory must list: contact points for each direct supplier or service provider, and a list of ICT products, services, and processes provided [3]. For space operators, this extends beyond IT vendors to the software stack embedded in satellite hardware that interfaces with ground control systems — a scope that most existing templates do not cover.

Building an SBOM for Satellite Firmware Under CIR Requirements

The CIR does not mention Software Bill of Materials by name, but CIR 5.1.4’s vulnerability handling and audit obligations effectively require SBOM-level visibility for any supplier providing software embedded in systems that could affect service availability or command-link integrity [6]. For satellite firmware, this creates a specific documentation challenge: satellite firmware may be burned into onboard computers (OBCs) pre-launch with limited or no over-the-air update capability, making vulnerability remediation potentially impossible without physical access.

An SBOM produced at manufacture time is necessary — but insufficient under CIR 5.1.7’s monitoring obligation, which requires review at planned intervals even when remediation is architecturally infeasible. The ground operator must maintain a process for receiving newly discovered CVE notifications for frozen firmware components and documenting the risk treatment decision for each.

SBOM field	CIR obligation satisfied	Space-specific consideration
Component name, version, supplier identity	5.2 directory; 5.1.4 vulnerability handling	OBC firmware, attitude control software, RF management stack
Known CVE list at time of manufacture	5.1.4 audit rights	Document accepted risks with risk treatment rationale per CIR risk assessment framework
Patch/update feasibility assessment	5.1.7 monitoring	State whether OTA update is architecturally possible post-launch
Third-party open-source components	5.1.2 selection criteria	FOSS licence compliance + CVE watch obligations for each dependency
Supplier ITAR/EAR classification	5.2 directory	Flag export-controlled components with US Munitions List or ECCN number

ESA’s operational experience illustrates the gap in practice. The SatNOGS network, which ESA’s OPS-SAT CubeSat used for initial status observations after its December 2019 launch, consists of ground station operators who typically do not maintain SBOMs for the components they receive. When CVEs emerge in embedded firmware, the propagation path through the supply chain is opaque [5]. NIS2 closes this gap for in-scope operators: the ground operator, as the CIR-obligated party, must maintain SBOM-level visibility even when the satellite manufacturer has not provided it proactively. Even a documented absence of SBOM access, with a compensating monitoring plan, is materially better than silence.

The ITAR/EAR Paradox: When Export Controls Block Audit Rights

The hardest compliance gap in NIS2 space sector supply chain security is the conflict between CIR 5.1.4’s audit rights requirement and US export control law. Most existing guides avoid it. This section addresses it directly.

Under ITAR (22 CFR §§ 120–130), technical data relating to defense articles on the US Munitions List — which includes satellite components above certain capability thresholds — cannot be disclosed to foreign nationals without a State Department licence. The EAR (15 CFR § 734) similarly controls dual-use technology with space applications. A US-based satellite component manufacturer faces a genuine legal conflict: CIR 5.1.4 requires them to accept audit rights and vulnerability disclosure obligations in contracts with European ground operators, but disclosing detailed firmware architecture or component specifications to a non-US auditor may require a Technical Assistance Agreement (TAA) or equivalent export authorisation that does not yet exist.

Three practical resolution mechanisms are in use among space operators working through this conflict:

1. Redacted SBOM with classification markers. The component manufacturer provides an SBOM in which sensitive design parameters are redacted, but component identities, version numbers, CVE watch status, and update feasibility are disclosed. The redaction itself is documented in the contract. In most cases, CVE data and version identifiers do not constitute controlled technical data under ITAR’s definition — they identify the component without disclosing design data. The ground operator’s risk register documents what visibility it has and what it cannot access, with the redacted SBOM as audit evidence of best-effort compliance.

2. Third-party security escrow audit. The contract designates a ITAR-cleared (US Person) independent third-party auditor who reviews the supplier’s full technical documentation and produces an unclassified conformance report — without disclosing controlled technical data to the European ground operator. The conformance report satisfies CIR 5.1.4’s audit rights clause by providing third-party attestation of the supplier’s cybersecurity practices. This mechanism is established in defence procurement and is increasingly applied to NIS2 supply chain compliance.

3. Export licence as part of the compliance timeline. Where neither redaction nor escrow is feasible, the European operator should require the US supplier to apply for the relevant export authorisation as part of the procurement timeline. CIR 5.1.5 requires incorporating compliance requirements into “new supplier processes and procurement activities” — most effectively applied before a contract is signed, not retroactively [3].

For Compliance Officers: If any satellite component supplier is subject to ITAR or EAR, your CIR 5.1.4 contractual specifications should be reviewed by counsel with dual-use export control expertise before signing. The contractual mechanism used — escrow, redacted SBOM, or export licence — should be documented in your supplier directory entry as the audit evidence of your compliance approach. As a general guideline based on current practice, the escrow route is the fastest to implement once a qualified US Person auditor is identified.

COTS Components and the CIR 5.1.2 Procurement Criteria

Commercial off-the-shelf components are the economic backbone of modern small satellite programmes. CubeSats in particular — increasingly prevalent in LEO constellations — rely heavily on COTS processors, radio modules, and sensor arrays. The plug-and-play convenience creates a specific CIR compliance gap: the same vulnerability can be exploited across multiple satellites using the same COTS component, amplifying the blast radius in a way that a proprietary component does not.

ENISA’s commercial satellite operations guide specifically identifies COTS use as a dual-use concern, recommending “analysis and testing before introducing components into production environments” and security-by-design principles for components used in critical systems [5]. The practical gap: most ground operators’ procurement processes evaluate COTS components on performance and cost, with no formal CIR 5.1.2 assessment record. When an auditor asks for the selection record showing that cybersecurity practices were evaluated for a 2021-era OBC component, the documentation typically does not exist.

CIR 5.1.2 requires that supplier selection criteria assess “quality and resilience of ICT products/services with embedded risk management.” For COTS components, your selection record must document four things:

1. CVE baseline at procurement. What vulnerabilities existed in the component at the time of selection, and what was the risk treatment rationale for accepting them? A component selected in 2021 with no CVE baseline on record is a gap auditors consistently flag.

2. Vendor CVE notification commitment. Does the COTS supplier maintain a published vulnerability disclosure programme? If not, CIR 5.1.2 criterion 1 (cybersecurity practices) is weakened — this must be documented as a risk and compensated through the ground operator’s own CVE monitoring obligation.

3. Update/patch feasibility in the target environment. Firmware updates on satellite components may be impossible post-launch. This must be documented as an accepted residual risk under the CIR risk assessment framework — not left unaddressed in the procurement record.

4. Source diversity assessment. CIR 5.1.2 requires consideration of the capacity to “diversify supply sources and limit vendor lock-in” [3]. For COTS components with a single EU-approved distributor, this must appear in the selection record, even if sole-source procurement was the only viable option.

Closing this gap retroactively requires a retrospective CIR 5.1.2 assessment for critical satellite components already in service — documenting what was known at procurement, what CVEs have emerged since, and the current risk treatment position. This retrospective assessment feeds into the supplier directory entry under CIR 5.2 and establishes the monitoring baseline for CIR 5.1.7. It is also the type of documentation that converts an audit gap into a managed, documented risk — a materially different position.

Building the Supplier Directory Under CIR 5.2

CIR 5.2 requires an updated directory containing contact points and a list of ICT products, services, and processes for each direct supplier. For space operators, “ICT products and services” extends well beyond enterprise software vendors — it includes the software stack embedded in satellite hardware that interfaces with ground control systems [3].

Supplier category	ICT products/services to list	Contact requirement
Launch service provider	Flight software stack (GNC, telemetry, range safety), ground support systems, mission ICD	Security incident contact; vulnerability disclosure contact; pre-launch SLA holder
Satellite component manufacturers	OBC firmware, RF stack, onboard software modules; ITAR/EAR status flag per component	Firmware CVE notification contact; update availability contact
Ground segment software providers	Mission planning, TT&C software, orbital mechanics tools	Patch notification SLA; incident response contact
Cloud/managed infrastructure	Data processing, monitoring, analytics platforms	CIR-compliant SLA; incident notification obligation per CIR 5.1.4
COTS hardware distributors	Where distributor is intermediary for critical components	Pass-through security obligations per CIR 5.1.4 sub-contracting clause

The directory must be updated after “significant incidents or operational changes” per CIR 5.1.6. A satellite constellation operator that changes its launch provider, upgrades onboard firmware, or adds a new ground station must trigger a directory update. Auditors look for evidence of this change management process — not just a current snapshot of the directory.

Integrate the supplier directory into your incident response function. The 24-hour early warning requirement under Article 23 of NIS2 is only achievable if supplier contact points are current and have been tested. Include supplier directory verification in annual tabletop exercises — the exercise log becomes evidence that the directory is operationally maintained, not just formally documented. For a full treatment of the incident notification cascade, see NIS2 incident reporting for space operators.

Pre-Audit Compliance Checklist: CIR Title 5 for Space Operators

Requirement	CIR control	Space-specific check
Supply chain security policy in place	5.1.1	Does the policy reference satellite segment threat vectors, firmware update chains, and launch service dependencies?
Selection criteria documented for all critical suppliers	5.1.2	Are CVE posture, OTA patch feasibility, and vendor lock-in risk assessed and on record for each tier?
Contracts include audit rights, incident notification, sub-contracting flow-down	5.1.4	For ITAR/EAR suppliers: is the audit mechanism documented (escrow or redacted SBOM)?
Supplier directory current and tested in IR exercises	5.2	Are satellite component manufacturers, launch provider, and firmware products listed with verified contacts?
Firmware SBOM or equivalent component inventory maintained	5.1.4 / 5.1.7	Does SBOM cover OBC firmware, patch feasibility, CVE treatment for frozen firmware?
Defined-interval review logs documented	5.1.7	Are supplier SLA reports and incident reviews on record with dated, named participants?
ENISA coordinated risk assessment results incorporated	5.1.3	Is the ENISA space sector guidance reflected in the organisation’s risk methodology?

Frequently Asked Questions

Is a launch service provider a “direct supplier” under CIR 5.1.1?
Yes, if the launch provider has direct ICT connectivity to systems that affect the ground operator’s service availability or command-link integrity. This includes pre-launch ground support equipment connectivity and any post-launch telemetry interface. The launch provider’s flight software represents a critical upstream ICT dependency that satisfies the CIR definition of a direct supplier for ICT services.

What if a satellite component manufacturer is non-EU and refuses to accept CIR contractual clauses?
CIR 5.1.4 requires the clauses in contracts, but does not give leverage over non-EU suppliers who decline. Document the gap in your risk register, apply mitigating controls (SBOM escrow, third-party audit), and factor the supplier’s non-compliance posture into your next selection cycle under CIR 5.1.5. National competent authorities assess proportionality — a documented, good-faith mitigation is materially better than an undocumented gap.

Does NIS2 apply to the satellite itself, or only to ground infrastructure?
NIS2 scopes to ground-based infrastructure. The satellite in orbit is not a directly regulated asset. However, the security of the satellite directly affects your ability to meet your ground-segment obligations (availability and integrity of the command link) — which is why upstream satellite component security becomes a CIR 5.1.x obligation for the ground operator.

How often must the supplier directory be updated?
CIR 5.1.6 requires review at “planned intervals” and “after significant incidents or operational changes.” Auditors treat this as requiring at minimum an annual formal review plus event-triggered updates: new supplier, change of critical component, security incident involving a listed supplier. The review must be documented — a timestamped log showing when the directory was last verified satisfies the evidence requirement.

Sources

1. European Parliament and Council, “NIS 2 Directive — Article 21: Cybersecurity risk-management measures”, Directive (EU) 2022/2555. Verified: Article 21(2)(d) exact text.
2. European Commission, “Commission Implementing Regulation (EU) 2024/2690”, EUR-Lex. Primary source for CIR Title 5 structure.
3. Advisera, “CIR 2024/2690 Annex — Technical and methodological requirements”. Full CIR Title 5 (5.1.1–5.1.7 and 5.2).
4. ISMS.online, “NIS 2 for Space Sector: Ground Infrastructure, Supply Chain, and Audit Evidence”. Space-sector scope, controls, and audit evidence.
5. ENISA, “From Cyber to Outer Space: A Guide to Securing Commercial Satellite Operations”. 125 controls; COTS risk; security-by-design.
6. Anchore, “NIS2 Compliance with SBOMs”. SBOMs and Article 21(2) supply chain obligations.
7. DLA Piper, “NIS2 Directive Explained Part 3: Supply Chain Security”. Contractual obligations and supplier registry.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.