Cybersecurity requirements for space suppliers: NIS2, the proposed EU Space Act, ESA and prime contractors

For most space suppliers, cybersecurity requirements arrive through customers, not regulators. NIS2 obliges operators of ground-based space infrastructure to manage the security of their direct suppliers, and ESA, EU Space Programme and prime contracts write security terms in. Manufacturers and managed service providers of medium size or larger can also fall under NIS2 directly.

This guide covers whether NIS2 applies to you, the EU Space Act proposal, ESA and EU programme rules, what prime contractors ask, which comes first, what to build once, what the rules leave open, and a checklist.

Regime	Who it binds	Status, September 2026	How it reaches a supplier
NIS2, Annex I space	Ground segment operators, medium-sized or larger	Applies through national law	Article 21 supply chain duty: questionnaires, clauses
NIS2, Annex II and MSPs	Manufacturers in NACE divisions 26 and 30, managed service providers	Applies through national law	Directly, if medium-sized or larger
EU Space Act	Space operators, including small ones	Proposal COM(2025) 335, not adopted	Operators’ supply chain risk management
ESA and EU Space Programme	ESA and programme contractors	In force	Contract terms, security accreditation, clearances
Prime contractor or operator	You, by signature	Now	Security annex, questionnaire, audit rights

Does NIS2 apply to space suppliers?

Through one of three doors. Most suppliers come in by the third.

Annex I: the space sector is the ground segment

Annex I lists space as a sector of high criticality. The entities are “operators of ground-based infrastructure, owned, managed and operated by Member States or by private parties, that support the provision of space-based services, excluding providers of public electronic communications networks”. Recital 37 makes clear that infrastructure owned, managed or operated by or on behalf of the Union as part of its space programme is not covered.

It is ground segment, not orbit. A company operating a teleport, a ground station network or mission control infrastructure is inside. A company that builds a reaction wheel is not, at least not through this door.

Size decides the rest. An operator larger than medium-sized is an essential entity, a medium-sized one important (Articles 2(1) and 3). Small and micro operators are outside unless one of the size-independent cases in Article 2(2) applies.

Manufacturers and managed service providers

Annex II covers manufacture of other transport equipment (NACE division 30), whose class 30.30 includes spacecraft, launch vehicles and satellites. It also covers computer, electronic and optical products (division 26), including communication equipment such as antennas (class 26.30) and navigation and guidance instruments (class 26.51). A medium-sized or larger manufacturer there is, as a rule, an important entity.

Services can bring you in too. A managed service provider (Article 6(39)) provides “installation, management, operation or maintenance” of ICT products, networks or systems, on site or remotely. If you run or maintain an operator’s ground systems and are medium-sized or larger, you may be in scope yourself, with detailed rules in Implementing Regulation (EU) 2024/2690. The full programme is on our NIS2 page.

Everyone else: Article 21(2)(d)

Article 21(2)(d) requires in-scope entities to address “security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”. Article 21(3) makes them consider each direct supplier’s vulnerabilities, product quality and cybersecurity practices, including secure development.

Their obligation becomes your contract clause. How operators run that assessment is in NIS2 supply chain security, and what they check before granting access is in ground segment security.

Transposition was uneven: in July 2026 the Commission referred four Member States to the Court of Justice for not notifying their NIS2 laws. Two customers in two countries can quote different requirements for the same directive.

If you sell hardware or software products on the EU market, the Cyber Resilience Act also applies. Its reporting obligations have applied since 11 September 2026, the rest from 11 December 2027.

What would the EU Space Act mean for suppliers?

The Commission proposed it on 25 June 2025 as COM(2025) 335, a regulation on the safety, resilience and sustainability of space activities. It is still a proposal. The Parliament’s lead committee has not voted on its draft report of 3 March 2026, and the Council’s progress report of 8 May 2026 records no general approach. Trilogues have not started.

Three parts of the proposal would reach suppliers through their customers:

• Critical assets. Risk assessments at segment, system and component level, covering assets such as engineering systems, flight software, telemetry and telecommand, and mission or spacecraft control centres (recital 74).
• Testing. Operators would regularly test systems, which “may include” threat-led penetration testing (recital 79). Whoever supplied the software under test is inside that scope.
• Supply chain. A supply chain risk management framework, with security terms in contracts with suppliers (Article 92), software integrity and authenticity controls, criteria for choosing software products, and attention to systems “temporarily interconnected, such as in the context of the provision of maintenance or support” (recital 80). That describes a supplier’s remote maintenance session exactly.

On NIS2, Article 75(1) would make the Space Act a sector-specific act, for space operators that are essential or important entities, only as regards the Article 21 risk-management measures (recital 72: lex specialis). NIS2 Article 23 incident reporting would still apply (Article 93(4), recital 87). The proposal adds its own incident reporting, including for Union-owned assets of the EU Space Programme (Article 93, recital 86). In the Council, the presidency compromise text of 5 December 2025 drops the lex specialis recital and calls for requirements “synchronised and coordinated” with NIS2. The May 2026 progress report left the cybersecurity articles unchanged, pending alignment with the incident reporting regime proposed in the Digital Omnibus.

Scope would widen to operators below medium size and to research and education institutions, with simplified risk management limited to critical assets and functions and core risks such as loss of control (Article 79, recitals 68 and 75). Small operator customers that NIS2 never reached would start asking the same questions.

As proposed, it would apply from 1 January 2030 (Article 119), with a transitional period to 1 January 2032 for certain assets (Article 118). Do not build to the article numbers, which can move. Build to the shape: tested rather than declared security, and supply chain duties that land on you through your customer.

What security rules do ESA and the EU Space Programme set?

ESA

ESA’s Security Regulations apply to the Agency, its Member States and staff and, “under certain conditions, to its contracting personnel and to its contractors”.

The engineering standard is ECSS-E-ST-80C, Space engineering: Security in space systems lifecycles, published on 1 July 2024. It covers the space, ground, launch and support segments across the lifecycle, and may be tailored for each project. In practice it reaches a supplier when a contract lists it as an applicable document.

The EU Space Programme

Galileo, EGNOS, Copernicus, GOVSATCOM and space situational awareness form the Union Space Programme under Regulation (EU) 2021/696, outside NIS2. The Security Accreditation Board within EUSPA is the security accreditation authority for all its components. Work there means accreditation requirements and often security clearances: even EUSPA’s own tender for penetration testing support to the Board required cleared staff.

National space law

National law licenses the activity itself: the European Parliament’s research service counted at least 13 laws related to space activities in force in EU countries by the end of 2024. They bind the licensed operator, not you. In practice, what an operator commits to its licensing authority becomes a term in its supplier contracts.

What do prime contractors and operators ask space suppliers?

Flow-down does not wait for law, and it asks questions more specific than anything in NIS2:

• how command links are authenticated;
• how flight software is signed and verified;
• who has physical access to the integration facility;
• how long telemetry is retained and who can read it;
• what happens to a subcontractor’s access when the subcontract ends.

The clauses are taken apart in the security annex, clause by clause, and the method for questionnaires in how to answer a security questionnaire. The questionnaire is not really asking whether you are secure. It is asking whether you can demonstrate it, which is a different capability and usually the missing one.

Which requirement reaches a space supplier first?

In practice, for most suppliers:

1. The customer’s questionnaire, attached to a tender with a two-week return date.
2. The security annex in the contract, at signature or renewal.
3. NIS2 directly, if you manufacture in scope or manage a customer’s systems.
4. ESA or programme security rules, when you bid for that work.
5. The EU Space Act, from 2030 at the earliest as proposed.

Building for the regulation furthest away is the wrong sequence. Build for the questionnaire that arrives next, in a way that also satisfies the regulation later.

What should a space supplier build once?

The regimes ask overlapping questions in different words. The core is small:

• An asset inventory that includes the ground segment, where most inventories stop.
• A supplier register with security terms and review dates, because you are also someone’s customer.
• Access control with an expiry discipline, particularly for contractors and integration facilities.
• Logging with retention that survives an investigation, not retention that satisfies a default.
• An incident process rehearsed against your customers’ notification clocks, which must fit inside their own 24-hour NIS2 early warning.
• Evidence that regenerates, produced by systems rather than assembled by a person each time.

One register keeps each requirement tied to the control that answers it:

SPACE SUPPLIER REQUIREMENTS REGISTER (one line per requirement)
Customer / contract:     ...
Source:                  NIS2 flow-down / ESA / EU programme / annex
Clause or question:      e.g. annex 4.2, command link authentication
Control that answers it: e.g. MFA on jump host, signed releases
Evidence and location:   system report, log, record, where kept
Owner:                   name
Last verified:           date, by whom

The general argument for one programme serving several frameworks is in ISO 27001 and NIS2, once instead of twice.

What do the rules leave open?

Every one of these regimes sets a clock and says almost nothing about the instrument that starts it.

NIS2 gives an operator 24 hours “of becoming aware” of a significant incident to send an early warning, and contracts usually pass a shorter clock to you. Both assume something detects. A supplier with no log aggregation, no alerting on its build pipeline and default retention on systems that touch the ground segment does not have a reporting problem. It has a discovery problem.

That gap is specific enough to close: telemetry from the systems that matter, retention long enough to reconstruct a compromise, alerting tuned to the few abnormal things in a small engineering estate, and one evidence record a customer, a regulator and an auditor can all read. That is how the CloudSoul platform works: automated evidence collection, with human-in-the-loop expertise on the exceptions. To measure the gap before a customer does, start with a security audit. The sector view is on the space page.

Regulation asks you to declare. Space customers increasingly ask you to demonstrate. The work is in the gap.

Space supplier cybersecurity checklist

• Check whether you are in NIS2 scope directly: ground segment, manufacturing or managed services.
• List every customer requirement in one register with the control that answers it.
• Inventory the systems that touch customer ground segments, not only corporate IT.
• Tie leaver and contract-end events to access revocation, with dates.
• Keep logs long enough to reconstruct an incident, and alert on the few that matter.
• Agree a notification clock with each customer that fits inside their 24 hours.
• Record which contracts make ECSS-E-ST-80C or ESA security rules applicable.

Sources

• Directive (EU) 2022/2555 (NIS2), Articles 2, 3, 6, 21 and 23, Annexes I and II and recital 37, EUR-Lex.
• Commission Implementing Regulation (EU) 2024/2690, EUR-Lex.
• NACE Rev. 2, class 30.30, Manufacture of air and spacecraft and related machinery, EU Publications Office.
• European Commission, NIS2 Directive (referrals of July 2026) and Cyber Resilience Act summary.
• European Commission, Proposal for a Regulation on the safety, resilience and sustainability of space activities in the Union (EU Space Act), COM(2025) 335, Articles 75, 79, 92, 93, 118 and 119 and recitals 68, 72, 74, 75, 79, 80, 86 and 87, EUR-Lex.
• European Parliamentary Research Service, EU space act briefing, September 2025; Legislative Observatory, procedure 2025/0335(COD).
• Council of the EU, presidency compromise text 16437/25 of 5 December 2025 (recital 71a), Council register; progress report 8861/26 of 8 May 2026, Council register.
• ESA, Highlights of ESA rules and regulations (Security Regulations).
• ECSS-E-ST-80C, Space engineering: Security in space systems lifecycles, 1 July 2024, ECSS.
• Regulation (EU) 2021/696 establishing the Union Space Programme and EUSPA, EUR-Lex; EUSPA, About EUSPA and penetration testing support for the Security Accreditation Board, 21 November 2024.

Frequently asked questions