Ground segment security: what a satellite operator checks before giving a supplier access

Before a supplier gets into a ground segment, a satellite operator checks who will have access, how they connect and what that access can reach: named users, MFA on every path, a jump host with session logging, separation on the supplier’s side, patching of the software supplied, and subcontractors. In the EU, NIS2 requires in-scope ground segment operators to manage that supplier risk.

This guide covers why the ground segment is the target, the six areas operators check, where the requirements come from, whether operator size matters, the EU Space Act, what follows the questionnaire, what to build first, and a checklist.

Area	What the operator checks	Evidence that answers it
Identity and access	Named users, MFA on every path, no shared accounts	Access list reconciled to HR, MFA coverage
Connection path	Jump host, session logging, time-boxed access, managed devices	Access design, sample session logs
Separation on your side	What the engineer’s workstation can also reach	Network diagram, device management records
Software you supply	Secure development, SBOM, patch and notification clock	SBOM, patch records, notification terms
Your subcontractors	Who inherits your access, and whether the operator knows	Subcontractor register, disclosed
People and jurisdiction	Screening for privileged staff, where staff are located	Screening records, staff location list

Why is the ground segment the target of an attack?

Attacking a satellite in orbit is difficult. Attacking the network that commands it is an ordinary intrusion against ordinary infrastructure, and the shortest route in is often a supplier with remote access and weaker controls than the operator.

ENISA’s Space Threat Landscape (March 2025) lists control centres and ground control stations among ground segment assets. One of its scenarios starts with social engineering and reaches a satellite through mission control software linked to the telemetry, tracking and command ground station, helped by weak network segmentation and a vulnerable link security protocol. The CCSDS report on threats against space missions lists trusted business partners and dishonest maintenance and systems personnel among insider threat sources. A supplier with remote access is both.

What does a satellite operator check before giving a supplier access?

The questionnaire varies. The underlying concerns do not. In the reviews we see, they fall into six areas: practice, not a legal list.

Identity and access

Who has access, named rather than a team. MFA on every path in, including the one your engineers use at two in the morning. No shared accounts, and no shared credentials in a password manager folder marked “ops”. Privileged access separated from day-to-day access. Joiner and leaver records with dates, because the question behind the question is whether someone who left last quarter can still reach their systems.

How the connection is made

A jump host or bastion rather than direct access. Session logging, and for privileged work sometimes session recording. Access that is requested and time-boxed rather than permanently open. Engineers connecting from managed devices, not from whatever laptop is nearest.

Separation on your side

Whether the environment you use to reach their systems is separated from your corporate network, your development environment and web browsing. An operator that grants access to your workstation has effectively granted access to everything that workstation can reach.

The software you supply

Secure development practice, dependency management, a software bill of materials, how fast you patch, and how you tell the operator about a vulnerability in something they already run. ENISA lists regular patching and hardening of space systems among its recommendations, so expect questions on your patch clock. This is increasingly the longest section.

Your own subcontractors

Which subcontractors touch the work, whether they inherit your access, and whether the operator is told. Undisclosed subcontractors with inherited access are a recurring finding and a fast way to lose a contract.

People and jurisdiction

Screening for staff with privileged access, and where those staff are located. For space work this also raises export control and dual-use questions that have nothing to do with cybersecurity but arrive in the same document.

If you received such a questionnaire and could not answer half of it, the method is in how to answer a security questionnaire.

Where do ground segment security requirements come from?

From NIS2, and from the contracts above the operator.

NIS2 Annex I: space

Annex I lists space as a sector of high criticality, covering “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.

Ground segment, not orbit: a teleport, ground station network or mission control operator is inside. A company that builds a reaction wheel is not, at least not through this entry.

Article 21: how the operator’s duty becomes your clause

Four points of Article 21 turn the operator’s obligation into your contract terms:

• Article 21(2)(d): supply chain security, “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”.
• Article 21(3): the operator must take into account each direct supplier’s specific vulnerabilities and the overall quality of its products and cybersecurity practices, including secure development procedures.
• Article 21(2)(i): human resources security, access control policies and asset management.
• Article 21(2)(j): multi-factor or continuous authentication and secured communications, “where appropriate”.

Recital 89 names network segmentation and identity and access management among basic cyber hygiene practices, and recital 85 encourages entities to put security measures into supplier contracts. NIS2 never says “jump host”. In practice, a jump host with MFA and logging is how operators meet it for remote supplier access. The ten measures are in NIS2 Article 21: the 10 measures, the operator’s side in NIS2 supply chain risk assessment.

No detailed implementing rules for space

Implementing Regulation (EU) 2024/2690 sets detailed Article 21 requirements only for DNS, TLD, cloud, data centre, CDN, managed and managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers. Ground segment operators are not on the list, so their detail comes from national law, their risk assessment and their contracts. Its annex, with sections on supply chain security and access control, is still a useful benchmark.

One exception can land on you. If you install, manage, operate or maintain an operator’s systems, on site or remotely, you may be a managed service provider (Article 6(39)). A medium-sized or larger MSP is in scope in its own right, and 2024/2690 applies to it directly.

Contracts upstream

Agency and prime contractor requirements arrive as contract terms, not law. There is no transposition delay to wait out and no proportionality test to argue. The clauses you are likely to see are taken apart in the security annex, clause by clause.

Does the operator’s size change what a supplier is asked?

Less than you would expect. Under NIS2, a ground segment operator larger than a medium-sized enterprise is an essential entity, a medium-sized one an important entity, and both take the same Article 21 measures. Supervision differs: essential entities face proactive supervision including regular audits, important ones are supervised after the fact. Small and micro operators are generally outside NIS2 unless one of the size-independent cases in Article 2 applies.

In practice, the access you would hold drives the review more than the operator’s size. A small operator serving an agency passes the agency’s requirements on anyway. Size shows in the follow-up: in our experience, larger operators ask for evidence sooner and write in audit rights. How the regimes stack up is in space suppliers: the four regimes.

What about the EU Space Act?

The Commission proposed the EU Space Act, a regulation, on 25 June 2025 as COM(2025) 335. It contains cybersecurity requirements for space operators, including supply chain risk management with security terms in supplier contracts (Article 92). Article 75(1) would make it a sector-specific act, for space operators that are essential or important entities under NIS2, only as regards the Article 21 risk-management measures. NIS2 incident reporting would still apply (Article 93(4)). As proposed, it would apply from 1 January 2030.

It is still a proposal. As of September 2026, the European Parliament’s lead committee has a draft report of 3 March 2026 but has not voted, and the Council’s progress report of 8 May 2026 says several issues remain open, including scope and governance. Trilogues have not started.

For a supplier, the Space Act will not be the first thing that obliges you. The customer contract will, and it already does. Build for the contract and the regulation arrives as a formality rather than a project.

What happens after the security questionnaire?

For standing access to operational systems, the questionnaire is the filter, not the finish. Operators follow up with evidence requests, a technical review call, sometimes a site visit, and a right to audit. There, self-declared answers meet reality. The common failures are not exotic:

• an access list that does not match the people who actually hold accounts;
• MFA on the corporate identity provider but bypassed on a legacy jump host;
• a leaver process that revokes email but not the VPN certificate;
• a subcontractor nobody mentioned.

These are reconciliation failures, not capability failures, and reconciliation is fixable in weeks.

What should a supplier build first?

For a supplier of thirty to a hundred people, this sequence clears most reviews:

1. An accurate list of who has access to what, reconciled against payroll and contracts.
2. MFA on every path into customer environments, with no legacy bypass.
3. A separated environment for customer work, even if it is a few managed devices and a jump host.
4. Joiner and leaver handling with dates and evidence, the control most often tested and most often failed.
5. Logging of privileged sessions, kept long enough to answer a question about last quarter.
6. A notification commitment you can meet, with a named contact and a stated clock. An in-scope operator owes its CSIRT or authority an early warning within 24 hours of becoming aware of a significant incident (Article 23), and it often learns from you.
7. A written list of subcontractors with access, disclosed rather than discovered.

None of this needs a security team. All of it needs an owner. One record per customer environment keeps it answerable:

GROUND SEGMENT ACCESS RECORD (one per customer environment)
Customer / environment:     ...
Named users:                name, role, employer, screening date
Access path:                jump host / VPN / vendor portal, from where
Authentication:             MFA method per path; shared accounts: none
Privileged accounts:        which, approved by, last review date
Session logging:            where stored, retention, who reviews
Separation on our side:     managed devices, admin network, no browsing
Software supplied:          versions deployed, SBOM, patch clock
Notification terms:         contact, channel, timescale per contract
Subcontractors with access: name, scope, date disclosed to customer
Revocation trigger:         leaver or contract end, revoked within ...
Last reconciliation:        date, accounts found, accounts removed

What do the rules leave open?

Access is granted to an identity and revoked on a spreadsheet. Granting is precise: a person is named, an account created, a certificate issued. Revocation runs on memory and goodwill. Someone leaves, a project ends, a subcontractor is stood down, and the account persists because no process connects the business event to the technical one.

NIS2 asks the operator to manage supplier risk and, where appropriate, to use MFA. It says nothing about how the supplier knows, on a given day, who still holds access. The operator’s controls are usually sound; the supplier’s access list is usually wrong, and nobody finds out until an audit or an intrusion. A questionnaire cannot detect this: it asks whether you have a leaver process, and you truthfully answer yes.

Closing it means generating the access list from the systems that grant access (identity provider, VPN, jump host, certificate authority), reconciling it continuously against HR records and contract end dates, and raising orphaned accounts as findings with an owner rather than finding them once a year. That is how the CloudSoul platform works: automated evidence collection, with human-in-the-loop expertise on the exceptions. A security audit measures that reconciliation before an operator does. The sector view is on the space page.

Ground segment supplier access checklist

• Name every person with access to each customer environment, reconciled against HR.
• Enforce MFA on every access path, including jump hosts and vendor portals.
• Route access through a jump host from separated, managed devices, with privileged sessions logged.
• Tie leaver and contract-end events to revocation, with the date recorded.
• Keep an SBOM and a patch clock for the software you supply, and agree notification terms with each operator.
• Disclose every subcontractor that holds or inherits access.

Sources

• Directive (EU) 2022/2555 (NIS2), Articles 2, 3, 6, 21 and 23, Annex I and recitals 37, 85 and 89, EUR-Lex.
• Commission Implementing Regulation (EU) 2024/2690, Article 1 and Annex, EUR-Lex.
• 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, 92, 93 and 119, EUR-Lex; European Parliamentary Research Service, EU space act briefing.
• European Parliament, Legislative Observatory, procedure 2025/0335(COD); Council of the EU, progress report 8861/26 of 8 May 2026, Council register.
• ENISA, Space Threat Landscape 2025, 26 March 2025, ENISA.
• CCSDS 350.1-G-3, Security Threats Against Space Missions, Informational Report, February 2022, CCSDS.

Frequently asked questions