Who should read this: a supplier with any form of access to a ground station, a mission control network, telemetry and command systems, or the software running on them. That includes companies that never go near the site and only connect for maintenance.
Attacking a satellite in orbit is difficult. Attacking the network that commands it is an ordinary intrusion against ordinary infrastructure, and the shortest route into that network is frequently a supplier with remote access and weaker controls than the operator. Space operators know this, which is why their supplier access review is one of the more demanding ones a small company will meet.
The four regimes that reach a space supplier are set out in space suppliers: the four regimes you actually sit under. This piece is about the one that arrives first and with a date on it: the operator’s own review.
What the review actually covers
The questionnaire varies. The underlying concerns do not. In the reviews we see, they cluster into six areas.
Identity and access. Who specifically has access, named rather than a team. Multi-factor authentication on every path in, including the one your engineers use at two in the morning. No shared accounts, no shared credentials in a password manager marked “ops”. Privileged access separated from day to day access. Evidence of joiner and leaver handling with dates, because the question behind the question is whether someone who left your company last quarter can still reach their systems.
How the connection is made. Jump host or bastion rather than direct access. Session logging, sometimes session recording for privileged work. Access that is time-boxed and requested rather than permanently open. Whether your engineers connect from managed devices or from whatever laptop is nearest.
Segregation on your side. Whether the environment you use to reach their systems is separated from your corporate network, your development environment and your general internet 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 you patch and how fast, how you notify them of a vulnerability in something they are already running. This is increasingly the longest section.
Your own supply chain. Which subcontractors touch this work, whether they inherit your access, whether the operator gets told about them. Undisclosed subcontractors with inherited access are a recurring finding and a fast way to lose a contract.
People and jurisdiction. Personnel screening for staff with privileged access. Where those staff are located, which for space work also engages export control and dual use questions that have nothing to do with cybersecurity but arrive in the same document.
If you have received a document like this and could not answer half of it, that experience has its own article: the security questionnaire you cannot answer.
Where the operator’s demands come from
They are not invented. Three sources feed them.
NIS2, today. Ground based infrastructure operators in the space sector sit in Annex I. Article 21(2)(d) obliges them to manage risk in their own supply chain, which is the mechanism that turns their obligation into your contract clause. Article 21(2)(i) covers access control and asset management, and 21(2)(j) covers multi-factor authentication and secured communications. The full list is in the ten measures in NIS2 Article 21, and how the obligation travels is in NIS2 supply chain security and vendor risk.
The prime contractor or agency flow-down. ESA and prime contractor security requirements predate NIS2 and are frequently stricter. They also arrive as contract terms rather than as law, which means there is no proportionality argument and no transposition delay to wait out.
The EU Space Act, eventually. Proposed in June 2025 as COM(2025) 335, it devotes a substantial chapter to cyber resilience for ground based infrastructure. As proposed: lifecycle risk management from conception to end of life, identification of critical assets including ground stations, command and control assets and telemetry, continuous anomaly monitoring with encryption and key management, threat led penetration testing before launch and at intervals of no more than three years, and supply chain obligations requiring contractual information security requirements on manufacturers and service providers.
Where the Space Act has got to, as of 2026
Worth being accurate, because the timeline is being misreported and it changes what you should do now.
The three institutions do not agree on the most basic question, which is how the Act relates to NIS2.
- The Commission proposed it as lex specialis: space operators that are essential or important entities under NIS2 would apply the Space Act’s requirements instead of the general NIS2 ones.
- The Council, in its compromise text of December 2025, went the other way: major space operators would follow the implementing acts made under NIS2 Article 21(5), with the harmonised Space Act requirements reserved for smaller and non EU operators.
- The Parliament rapporteur’s draft of March 2026 rejects a separate regime altogether and proposes folding space activities directly into the scope of NIS2.
Trilogue has not concluded. Adoption is not realistically expected before late 2027, with entry into force and application staged after that, and the Council text contemplates transitional periods running as long as eight years. The proposed reporting clocks, which have been widely quoted as a flat twelve hours, are more specific than that: twelve hours for early warning on Union owned assets, twenty four hours for other significant incidents, a fuller report at seventy two hours, and a final report within a month. Compare that to the NIS2 incident reporting timeline, which is the baseline actually in force.
The practical reading for a supplier is straightforward. The Space Act will not be what obliges you this decade. The customer contract will, and it is already doing so. Build for the contract and the regulation arrives as a formality rather than a project.
The gap between the questionnaire and the audit
There is a step most suppliers do not anticipate. For anything that involves standing access to operational systems, the questionnaire is the filter and not the finish.
Operators increasingly follow up with evidence requests, a technical review call, sometimes a site visit, and for sustained access a right to audit written into the contract. At that point 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 present 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.
Those are all reconciliation failures rather than capability failures, which is a useful thing to know, because reconciliation is fixable in weeks.
What to build, in order
For a supplier of thirty to a hundred people, the sequence that clears most reviews:
- An accurate list of who has access to what, reconciled against payroll and contracts. Everything else depends on this being true.
- MFA on every path into customer environments, with no exceptions and no legacy bypass.
- A separated environment for customer work, even if it is a small set of managed devices and a jump host rather than a full enclave.
- Joiner and leaver handling with dates and evidence, because this is the control most often tested and most often failed.
- Logging of privileged sessions, retained long enough to answer a question about last quarter.
- A vulnerability notification commitment you can actually meet, with a named contact and a stated clock.
- A written list of subcontractors with access, disclosed rather than discovered.
None of that requires a security team. All of it requires someone to own it, which is the subject of who owns security when nobody owns it.
The technical reality: access is granted to an identity and revoked on a spreadsheet
Here is the failure that actually causes incidents, and it is not a missing control.
Access is granted precisely. A person is named, an account is created, a certificate is issued, an entry goes in a list. Revocation is the part that runs on memory and goodwill. Someone leaves, someone changes role, a project ends, a subcontractor is stood down, and the account persists because no process connects the business event to the technical one.
That is why supplier access is the route it is. The operator’s controls are usually sound. The supplier’s list of who still holds access is usually wrong, and nobody discovers it until either an audit or an intrusion. A questionnaire cannot detect this, because the questionnaire asks whether you have a leaver process and you truthfully answer yes.
Closing it means the access list is generated from systems rather than maintained by hand, reconciled continuously against your HR record and your contract end dates, with orphaned and stale accounts surfaced as findings rather than discovered annually. The same principle as evidence that assembles itself: what is generated stays true, what is maintained drifts.
If you want that reconciliation measured before an operator does it for you, an independent security audit starts there, and the space sector page sets out how the obligations fit together end to end.
