EU Council secures command channel in EU Space Act; No runtime validation for exact commands.

EU Council secures command channel in EU Space Act; No runtime validation for exact commands.

Futurium | Apply AI Alliance - Europe Secures the Command Channel. Who Authorises the Command to Act?

Sangam Das 1 September 2026 - updated 22 hours ago

A standards question for the proposed EU Space Act

Author: Sangam Das, Independent Inventor, India Working group: EU AI Alliance Futurium — WG1 (Technology Standards)

Related paper: Execution-Finality Governance for Europe’s Emerging Space-Regulatory Framework (Zenodo) https:

IETF draft: RF Enable Is Not Transmit Authority: Finality for LEO

NTN and Inter-Satellite Control (draft-das-ntn-rf-execution-finality-00), individual Informational Internet-Draft, 27 August 2026 https:

This post is independent research. It does not claim institutional endorsement, and it does not claim that EU law already requires what it describes.

The European Commission’s proposed EU Space Act (June 2025) marks a genuine shift in how Europe thinks about space regulation. For decades the emphasis was orbital debris, registration, and physical safety. The Council’s March 2026 compromise text goes considerably further. It links the proposed Regulation to NIS2 and contemplates cybersecurity risk-management measures, access controls, cryptographic practices, incident handling, business continuity, and supply-chain security for space operators. It even carves out a lighter regime for smaller operators while still holding the line on high-consequence risks: loss of control over spacecraft capable of propulsion, or capable of harmful electromagnetic interference.

As of mid-2026 the text remains under negotiation. Scope, dual-use treatment, governance, and third-country operator rules are all still open, per the Council’s own May 2026 progress report. Nothing here should be read as a claim about settled EU law. It isn’t.

There is, however, a technical question sitting underneath the draft that the current text does not yet ask. I want to put it to this working group plainly:

Europe’s emerging framework secures the command channel. It does not yet secure the command — meaning, it does not yet ask whether that exact instruction is still authorised to take effect.

That distinction sounds subtle. It is not. It is the difference between knowing who sent an instruction and knowing whether that exact instruction should be allowed to happen, right now, given everything that is true about the spacecraft at this moment. Those are two different questions. Only one of them is currently on the table.

A thought experiment worth sitting with

Picture a satellite command system built to a high standard: encrypted communications, authenticated ground stations, access-controlled operator accounts, protected cryptographic keys, secure software, intrusion detection, logging, incident response. On paper, and in most audits, this system is cyber-secure. It would likely satisfy much of what the current Space Act compromise text is reaching for.

Now an authenticated command arrives:

Fire Thruster B for 14 seconds.

The communication is authentic. The credential is valid. The signature checks out.

appropriate for the satellite’s current orbit?

within an authorised manoeuvre envelope?

tied to the permitted mission purpose?

intended for this spacecraft, this actuator?

still valid, or has something since revoked it?

consistent with current collision-avoidance constraints?

something a human was supposed to approve first?

compatible with the spacecraft’s present safety state?

Authentication answers none of these. It only answers: who or what presented this command? Not: does this exact proposed consequence hold valid authority to become effective, right now?

Treating those questions as interchangeable is the central blind spot in how satellite cybersecurity is currently being framed — in Europe and elsewhere.

Where the current framework still falls short

Read against that lens, five gaps stand out in the Council’s March 2026 text.

No consequence-level authority concept. The provisions address authentication, encryption, and access control. All necessary. None of them ask, at the moment of execution, whether this specific act still has permission to occur. The framework stops at “was the sender who they claimed to be,” when the harder question is “should this exact effect happen now.”

Compliance is largely procedural, not runtime-enforced. Interference coordination, jurisdiction enforcement, and risk management remain mostly paper-and-process: planned, documented, checked at licensing or planning time. None of it is re-verified as orbital and mission conditions change in flight. A plan that was correct at submission can be stale at execution. Nothing in the current framework catches that gap.

No shared pre-effectuation validation layer. Every operator currently has to build — or skip — its own purpose checks, destination checks, and revocation checks. There is no standardised, reusable concept a smaller operator could adopt off the shelf. That matters directly for the SME proportionality the Council text is already trying to solve for. Without shared infrastructure, a “lighter regime” risks becoming weaker enforcement, not lower cost with equal protection.

Audit remains detection after the fact. The NIS2-linked incident-reporting provisions tell you what already happened. They do not require evidence generated before a consequential act completes. For a routine software event, that is probably fine. For a thruster firing, an RF transmission, or a destructive software transition — actions that may be difficult or impossible to reverse — post-event evidence is a record of damage, not a prevention mechanism.

Jurisdiction is still treated as static. Nothing in the current text ties authority to live orbital or coverage-footprint state. That assumption held reasonably well for older, simpler satellite architectures. It breaks down quickly for moving NTN beams, LEO constellations, and multi-country core connectivity, where “where is this service actually being delivered right now” is a shifting answer, not a fixed line on a map.

None of these are attacks on the drafting effort. Cybersecurity provisions in space legislation are already a meaningful step relative to where the sector was five years ago. The point is narrower. The current architecture, even fully implemented, secures entry and transit. It does not yet secure the transition from an authenticated instruction to an irreversible physical or RF consequence.

What an execution-finality layer would concretely add

This is where the broader execution-finality governance architecture I have been developing becomes directly relevant. The core idea, stripped down:

Computation is not authority. A proposed satellite action should not gain the right to happen merely because software generated it, an AI system calculated it, or a valid communication channel delivered it.

Concretely, that looks like this:

Non-Effective State step. A proposed action — human operator, autonomous system, or onboard scheduling logic — does not become real the instant it is generated. It exists first as a request, and stays non-effective until validated.

Scoped, bounded authority. Authority attaches to the specific act: this purpose, this destination, this mission state, this time window. It does not attach broadly to an identity, a role, or a session. A general operator credential should not translate into unlimited authority to transmit anything, anywhere, at any time.

A Finality Sink at the actual release boundary — the thruster-driver enable line, the transmitter power-amplifier enable, the payload activation gate — verified independently of whatever produced the command. If an upstream component is compromised — ground software, an AI planner, even a legitimate but hijacked operator account — it does not automatically inherit downstream physical authority.

Fail-closed behaviour by default. Stale, ambiguous, or revoked authority blocks the action. The system does not wait for a human to notice afterwards, or for a monitor to flag it in a post-incident review.

Reusability, applied selectively. This is not a gate on every spacecraft instruction. That would be neither necessary nor affordable. It is scoped to high-consequence operations: propulsion, consequential RF transmission or reconfiguration, payload activation, protected data release, software transition into an executable state, and consequential inter-satellite commands. Routine telemetry and reversible internal operations do not need the same treatment.

There is already engineering precedent for this pattern. Pyrotechnic deployment systems and other hazardous functions use independent inhibits, interlocks, and safe

arm mechanisms — a software command alone is deliberately insufficient to trigger physical actuation. Execution-finality generalises that principle beyond traditionally hazardous functions to the broader class of software-controlled consequential operations that increasingly autonomous, software-defined spacecraft now perform.

The same distinction is now written as a radio-side profile, posted as an individual Informational Internet-Draft: RF Enable Is Not Transmit Authority: Finality for LEO

NTN and Inter-Satellite Control (draft-das-ntn-rf-execution-finality-00, 27 August 2026). https:

The draft is not a working-group item and does not claim IETF consensus. It specifies what the Space Act discussion above leaves open at the aperture: a proposed RF, ISL, beam, gateway, or payload act remains a Candidate Act until a Finality Sink at PA enable, ISL switch, beam driver, feeder gateway, or user-terminal transmit path verifies scoped authority immediately before energy leaves the system. Authentication of TT&C, NTN registration, and operator allowlists still decide who may talk to the vehicle. They do not decide whether this burst, on this beam, to this next hop, over this territory, in this mission epoch, may leave the aperture. That is the standards-shaped form of the question this post is putting to WG1.

The narrower claim, stated precisely

Overclaiming here would undercut the argument. So, explicitly, this is not claiming:

that execution-finality would have prevented the 2022 KA-SAT attack against Viasat’s network — an incident the EU formally attributed to Russia, and one that disrupted communications in Ukraine and affected several Member States. That attack chain involved different security failures. Its relevance is broader: it showed how quickly a compromise touching space infrastructure can cascade across borders and into terrestrial dependencies. That is the class of consequence a pre-effectuation control layer is meant to limit, even if it would not have stopped that particular chain;

that EU law currently requires execution-finality architecture;

that such a layer should gate every spacecraft instruction. Fast control loops — attitude control, fault protection, thermal safing — need different treatment and should operate under pre-authorised, narrowly bounded standing authority;

that it replaces authentication, encryption, or NIS2-aligned cyber-risk management. It sits on top of them, at the point where a command would otherwise become an irreversible physical or RF effect.

The narrower, testable proposition is this:

For satellite operations capable of producing significant external consequences, security may be strengthened by separating generation or receipt of a command from authority for that command to become effective — verified independently at the boundary where the consequence actually occurs.

Why this belongs in WG1, not only in a compliance conversation

The Council’s current compromise text already leaves room for future European standardisation requests tied to the Regulation’s requirements, and contemplates reliance on existing European and international standards where appropriate. That is the opening worth using. This is a standards and technical-architecture question, not merely