A Satellite Can Be Cyber-Secure and Still Execute the Wrong Command

Author: Sangam Das
Independent Inventor, India

Abstract

Europe is moving toward a more harmonised regulatory framework for commercial space activities. The European Commission proposed the EU Space Act in June 2025 around three principal objectives: safety, resilience and environmental sustainability. As of 14 August 2026, the proposal remains under legislative negotiation; the Council’s May 2026 progress report confirms that examination of the Regulation continues and that important issues remain open.

The emerging framework is particularly relevant to cybersecurity and operational resilience. The Council’s March 2026 compromise text links the proposed Space Act with NIS2, provides for cybersecurity risk-management measures, access controls, cryptographic practices, incident handling, business continuity and supply-chain security, and contemplates sector-specific technical requirements. Particularly significant for smaller operators, the text envisages a lighter regime while still addressing high-consequence risks associated with losing control of spacecraft capable of propulsion or harmful electromagnetic interference.

This paper examines an additional technical question: even where a satellite system is authenticated, encrypted and cyber-secured, what determines whether a particular software-, AI-, autonomous-, or remotely generated command is actually permitted to produce an external consequence?

A command can be technically authentic yet inappropriate for the current mission state. An authorised software component can be compromised. An autonomous system can produce an unsafe but syntactically valid manoeuvre. A legitimate operator credential can potentially be used outside its intended purpose, destination, temporal scope or operational context.

This paper therefore explores execution-finality governance as a potential infrastructure-level complement to conventional satellite cybersecurity.

The basic principle is:

Computation is not authority. A proposed satellite action should not obtain authority merely because software generated it or a valid communication channel delivered it.

Under the conceptual architecture examined here, a consequential operation—such as an RF transmission, orbital manoeuvre, payload activation, software reconfiguration or inter-satellite command—first exists as a Candidate Act in a Non-Effective State. Relevant authority, purpose, mission, jurisdiction, destination, temporal, revocation and operational conditions can then be evaluated before a bounded execution authority is issued. The relevant Finality Sink, meaning the protected boundary at which the operation first becomes externally effective, independently verifies that authority before permitting the consequence.

The proposal does not claim that the EU Space Act currently requires such an architecture. Nor does it claim that execution-finality controls would prevent every satellite cyber incident. Rather, the paper identifies a possible technical research and standardisation direction for converting high-level requirements concerning resilience, access control, risk management and spacecraft control into enforceable pre-effectuation constraints.

The objective is not additional regulation for its own sake. It is to investigate whether Europe can make consequential space operations secure not only at the communication boundary, but also at the point of irreversible effectuation.

Keywords: EU Space Act, satellite cybersecurity, execution finality, autonomous satellites, AI governance, spacecraft control, cyber resilience, NIS2, satellite communications, space infrastructure.

1. Europe’s Emerging Space-Regulatory Environment

Space infrastructure is becoming increasingly important to telecommunications, navigation, Earth observation, financial services, emergency communications, transport, governmental services and critical infrastructure.

At the same time, national regulatory approaches within Europe remain fragmented. The Commission presented the proposed EU Space Act in June 2025 partly to establish a more harmonised European framework and improve the ability of operators to function across the internal market while addressing safety, resilience and sustainability.

The Council’s March 2026 compromise text describes a framework covering space operators and certain space-based data providers and establishes provisions relating to certification, registration, supervision and technical requirements. It also contemplates certain third-country operators providing relevant services within the Union. Defence and national-security uses are subject to important exclusions.

The text remains under negotiation. The Council reported in May 2026 that substantial technical examination had occurred but that questions concerning scope, dual-use activities, governance, third-country operators and other matters remained unresolved.

This distinction is essential:

This paper discusses an emerging regulatory direction, not a final adopted EU Space Act.

2. Cybersecurity Is Already Part of the European Space Discussion

Satellite regulation is no longer limited to orbital debris, registration and physical space safety.

Cyber resilience is becoming a central issue.

NIS2 already covers certain operators of ground-based infrastructure supporting space-based services.

The Council’s 2026 Space Act compromise goes further in its proposed treatment of space-sector cybersecurity. Its cybersecurity provisions contemplate risk analysis, incident handling, continuity and disaster recovery, supply-chain security, secure development and maintenance, cryptographic policies, access-control measures and authentication.

The same text recognises that proportionality matters and that smaller operators should not necessarily face identical implementation burdens. Nevertheless, its lighter approach for small and micro-enterprises specifically retains attention to high-consequence spacecraft risks, including loss of control over spacecraft with propulsion or interference-producing capabilities.

That observation is technically important.

It shifts the discussion from merely:

“Was the network attacked?”

toward:

“Could an attacker, compromised component or erroneous control process obtain effective control over a consequential spacecraft capability?”

Execution-finality governance is directly concerned with that second question.

3. Cyber-Secure Does Not Necessarily Mean Consequence-Secure

Consider a satellite command system with:

• encrypted communications;

• authenticated ground stations;

• access-controlled operator accounts;

• protected cryptographic keys;

• secure software;

• intrusion detection;

• logging; and

• incident-response processes.

This system may satisfy a sophisticated cybersecurity architecture.

Yet another question remains.

Suppose an authenticated command states:

Fire Thruster B for 14 seconds.

The communication may be authentic.

But is the command:

• appropriate for the current orbit?

• within an authorised manoeuvre envelope?

• associated with the permitted mission purpose?

• intended for this spacecraft?

• intended for this actuator?

• still valid?

• inconsistent with a later revocation?

• produced by an authorised AI or planning system?

• within current collision-avoidance constraints?

• approved by a human where approval is required?

• compatible with the spacecraft's current safety state?

Authentication primarily answers:

“Who or what presented this command?”

Execution-finality governance asks an additional question:

“Does this exact proposed consequence possess valid authority to become effective now?”

Those are not necessarily the same question.

4. From Command Security to Effectuation Security

The conceptual execution-finality architecture can be represented as:

AI / Operator / Autonomous Software
↓
Candidate Act
↓
Non-Effective State
↓
Protected Validation
↓
Scoped Execution Authority
↓
Finality Sink Verification
↓
External Effect

The key architectural rule is that the Candidate Act cannot directly produce the external consequence.

The act remains non-effective while the relevant conditions are evaluated.

Only after successful validation is a bounded execution authority generated.

The Finality Sink then verifies that authority at the point where the consequential operation can actually occur.

If validation fails, authority expires, state becomes ambiguous, or required evidence cannot be verified, the consequential operation can remain non-effective or move into an appropriate safe-state procedure.

5. What Is the Finality Sink in a Satellite?

A Finality Sink is not necessarily one physical chip.

It is better understood as the first protected boundary at which a proposed operation can produce the relevant usable external consequence.

Depending on the operation, the satellite Finality Sink might therefore correspond conceptually to different boundaries.

RF transmission

The relevant sink could be the protected release boundary immediately controlling the ability of the radio subsystem to radiate the authorised transmission.

Orbital manoeuvre

The relevant sink could be the protected boundary controlling actual thruster actuation.

Imaging payload

The sink could be the boundary at which an imaging command results in operational sensor activation or release of protected collected data.

Software-defined radio

The sink might control the effective application of frequency, power, waveform or beam configuration.

Inter-satellite communication

The sink could govern the point at which information or a command is actually released toward another spacecraft.

Software update

The sink could govern the transition from received software package to executable operational state.

The important point is that verification occurs before the irreversible or externally consequential transition, not merely after the event through logging.

6. Example One: AI-Generated Orbital Manoeuvre

Consider an autonomous collision-avoidance system.

The onboard AI detects a conjunction risk.

It calculates:

Proposed manoeuvre: +0.35 m/s at 03:42 UTC.

Under a conventional autonomous architecture:

Detection → Calculation → Decision → Thruster command

Under execution-finality governance:

Detection
↓
AI calculates manoeuvre
↓
Candidate Act created
↓
Candidate remains non-effective
↓
Validation of applicable conditions
↓
Scoped execution authority
↓
Thruster-control Finality Sink verifies
↓
Thruster actuation

Validation could conceptually consider:

• spacecraft identity;

• authorised control domain;

• permitted manoeuvre envelope;

• mission state;

• collision-avoidance policy;

• fuel constraints;

• command freshness;

• security epoch;

• destination actuator;

• conflicting commands;

• revocation state;

• required human approval; and

• operational safety conditions.

The AI remains free to calculate.

It does not automatically possess authority to move the spacecraft.

This produces a simple principle:

Autonomy may generate a decision. Finality determines whether the decision may alter the physical world.

7. Example Two: Satellite RF Transmission

Consider an AI-enabled communications satellite.

An onboard system proposes:

Transmit Payload X using Beam Y on Frequency Z toward Ground Station A.

The operation could be represented as a Candidate Act.

Before RF effectuation, relevant conditions might include:

• authorised spacecraft;

• permitted transmitting subsystem;

• permitted mission purpose;

• destination;

• frequency configuration;

• power envelope;

• beam direction;

• temporal validity;

• operator authority;

• current mission state;

• revocation state; and

• applicable policy or jurisdictional constraints.

If those conditions are successfully established, a scoped authority can permit the specific transmission.

The radio subsystem should not treat possession of a general operator credential as unlimited authority to transmit anything, anywhere, at any time.

The authority should instead be bounded to the particular consequential act.

This distinction becomes particularly relevant for software-defined spacecraft in which operational characteristics can increasingly be changed through software.

8. Example Three: Ground-to-Space Command

Suppose a legitimate ground-station account becomes compromised.

The attacker successfully authenticates through mechanisms that were expected to protect the command channel.

Traditional architecture may now face a difficult problem:

Authenticated entity → technically valid command → spacecraft execution

An execution-finality layer introduces another barrier.

Even after authentication, a command could remain non-effective until additional conditions are established.

For example:

Identity: recognised
Command class: manoeuvre
Purpose: maintenance
Destination: Satellite 17
Actuator: Thruster B
Maximum duration: authorised envelope
Mission state: compatible
Temporal window: valid
Revocation: clear
Second approval: required and verified

A stolen or misused credential therefore does not necessarily become unrestricted spacecraft authority.

This represents a move from bearer-like command authority toward scoped consequence authority.

9. Example Four: Autonomous Payload Control

Future spacecraft may increasingly use onboard AI for:

• Earth observation;

• prioritising imagery;

• processing sensor data;

• selecting communications opportunities;

• routing;

• anomaly response;

• constellation coordination; and

• mission optimisation.

An AI system may legitimately require broad computational freedom.

But computational freedom need not imply unrestricted physical or communications authority.

An AI might therefore be permitted to:

observe → reason → simulate → rank → recommend

while a protected execution layer separately determines whether it may:

transmit → actuate → reconfigure → release → delete → overwrite → redirect

This distinction can become increasingly important as space systems become more autonomous.

10. A Real European Warning: KA-SAT

Europe has already experienced the cross-border consequences of attacks on satellite infrastructure.

The EU formally attributed the February 2022 cyberattack targeting Viasat's KA-SAT network to Russia and stated that the incident disrupted communications in Ukraine and affected several EU Member States.

ENISA has subsequently used the incident to illustrate the cascading risks associated with commercial satellite cybersecurity and the dependency of terrestrial services on space infrastructure.

Execution-finality governance should not be presented as proof that the KA-SAT attack would have been prevented. The specific attack chain and affected infrastructure involved different security failures.

The relevance of KA-SAT is broader:

A compromise involving space infrastructure can rapidly produce consequences far beyond the initially affected technical system.

That makes pre-effectuation control of high-consequence operations worthy of additional research.

11. Possible Relationship With the Emerging EU Space Act

The proposed execution-finality framework should not be described as an existing requirement of EU space law.

Instead, it can be positioned as a possible technical mechanism supporting some of the regulatory objectives currently being discussed.

Emerging EU direction	Possible execution-finality contribution
Cyber-risk management	Restrict consequential operations according to machine-verifiable risk conditions
Access control	Extend control from system access to authority over specific consequences
Authentication	Bind authenticated authority to a particular act, destination, state and period
Cryptographic protection	Protect validation evidence and scoped execution authority
Incident prevention	Stop certain invalid operations before effectuation rather than relying solely on detection
Business continuity	Support controlled safe-state or alternative-authority mechanisms
Spacecraft control	Require protected validation before propulsion, transmission or payload consequences
Technical conformity evidence	Produce evidence showing what conditions were evaluated before execution

The Council compromise also specifically contemplates technical and sectoral implementing requirements and future standardisation activity.

This does not establish that execution-finality architecture will become a standard.

It does demonstrate that technical implementation mechanisms remain relevant to the evolving framework.

12. VI and Jurisdiction-Aware Authority

A further component of the conceptual architecture is a protected, non-bearer authority identity, referred to here broadly as a Virtual Identity (VI).

In a satellite environment, an execution authority could potentially be associated with contextual conditions such as:

Spacecraft: SAT-17
Mission: Earth observation
Operator: authorised mission domain
Purpose: telemetry transmission
Destination: authorised ground station
Command class: permitted
Operational epoch: current
Revocation state: active
Jurisdictional context: applicable environment

The purpose is not to place legislation directly into a token or have software independently interpret international space law.

Rather, once competent human, organisational and regulatory processes determine the applicable constraints, the technical system could help enforce selected constraints at execution time.

The distinction is important:

Law determines obligations.

Governance determines applicable policy.

Infrastructure enforces machine-verifiable conditions derived from those decisions.

13. Why Post-Event Logs Are Not Enough

Logging is essential.

Incident reporting is also an important component of the emerging EU framework; the March 2026 Council text includes mechanisms for reporting significant cyber incidents and links those mechanisms with NIS2 structures.

But logging primarily answers:

“What happened?”

Execution-finality asks:

“Should we permit it to happen?”

Both functions are necessary.

For a routine software event, post-event detection may be adequate.

For certain satellite operations, it may not be.

Once a satellite:

• fires a thruster;

• radiates a transmission;

• changes orbital configuration;

• releases sensitive information;

• disables a subsystem; or

• applies a destructive software change,

the consequence may be difficult or impossible to reverse.

That makes pre-effectuation evidence potentially more valuable than evidence generated only after the consequence.

14. Small Satellite Operators and the Compliance Problem

The emerging European discussion also recognises proportionality.

The Council compromise takes entity size and implementation cost into account when considering cybersecurity measures and includes a lighter proposed regime for certain smaller organisations.

This raises an additional infrastructure question.

Should every small satellite company separately engineer:

• cryptographic command controls;

• purpose restrictions;

• mission-state checking;

• revocation;

• authorisation logic;

• operational evidence;

• actuator gating;

• incident evidence;

• policy enforcement; and

• cross-platform validation?

Or could parts of this functionality eventually become reusable space-governance infrastructure?

The Council text already contemplates capacity-building support for SMEs and research and development directed toward technologies that facilitate conformity, including encryption, protocols and safety systems.

A reusable execution-finality mechanism could therefore also be studied from an SME competitiveness perspective.

Large satellite operators can maintain substantial cybersecurity and mission-assurance teams.

A ten-person space startup cannot.

Infrastructure may allow smaller operators to obtain sophisticated execution controls without independently recreating every mechanism.

15. Implementation Neutrality

Execution-finality governance does not require one predetermined technical implementation.

It could potentially be realised through combinations of:

• trusted hardware;

• secure elements;

• isolated execution environments;

• cryptographic validation;

• protected control processors;

• spacecraft flight computers;

• ground infrastructure;

• distributed validation;

• secure radio subsystems;

• policy engines; or

• other future architectures.

Likewise, the concept does not require a specific:

• token;

• cryptographic algorithm;

• ledger;

• satellite bus;

• operating system;

• AI model;

• communication protocol;

• ground-station architecture;

• frequency;

• identity standard; or

• cloud service.

The architectural invariant is simpler:

A consequential Candidate Act remains non-effective until the required authority is established and verified at the relevant release boundary.

15.1 A Non-Normative Reference Implementation

Implementation neutrality does not require implementation abstraction. A future standard could remain neutral as to hardware, cryptographic primitive, spacecraft bus and operating system while still permitting concrete reference architectures to demonstrate engineering feasibility.

The following example is therefore illustrative rather than normative.

Precedent in existing spacecraft engineering

Space systems already use independent inhibits, interlocks and safe/arm mechanisms for operations whose unintended execution could produce serious or irreversible consequences. Pyrotechnic deployment systems and other hazardous functions, for example, may be designed so that issuance of a software command alone is insufficient to produce physical actuation.

This provides a useful engineering analogy for execution-finality.

The flight computer may generate or transmit a command, while a separate protected condition must still be satisfied before the physical consequence can occur.

Execution-finality generalises that principle:

Command generation does not itself constitute authority for physical effectuation.

The proposed architecture extends this separation beyond traditionally hazardous functions toward other consequential software-controlled operations, including propulsion, RF transmission, payload activation, protected data release and operational software transition.

Possible physical integration

A Finality Sink does not necessarily require an additional spacecraft box.

Protected validation could potentially be integrated into existing command-and-data-handling or security functionality, while final verification could be positioned within protected interface logic close to the consequential subsystem.

For example:

• propulsion authority could be verified before the thruster-driver enable boundary;
• RF authority could be verified before transmitter or power-amplifier enablement;
• payload authority could be verified before protected payload activation;
• data-release authority could be verified before information leaves a protected processing boundary; and
• software-transition authority could be verified before a received image becomes operationally executable.

Where spacecraft already employ secure elements, protected processors, FPGAs or isolated control logic, portions of the validation and sink functions could potentially reuse those resources.

The architectural requirement is therefore not the addition of a particular physical device. It is preservation of a protected verification boundary between command generation and consequential effectuation.

Latency

The relevant engineering question is not whether execution-finality introduces zero latency. It is whether verification latency is compatible with the timescale of the operation being protected.

Many consequential spacecraft operations—including planned orbital manoeuvres, scheduled RF transmissions, payload activation and software reconfiguration—operate on timescales that may permit authority verification before effectuation.

Very fast control functions require different treatment.

Attitude-control loops, fault-protection mechanisms, thermal protection and autonomous spacecraft safing should not necessarily require a new cryptographic authorisation for every individual low-level operation. Such functions could instead operate under previously established and narrowly bounded standing authority, protected operational envelopes or dedicated safety authority.

The architecture therefore need not place a cryptographic transaction in every spacecraft control loop.

Relationship with existing space-security infrastructure

Execution-finality can also build upon existing spacecraft security mechanisms rather than replacing them.

Existing space-security architectures already address functions such as authenticated telecommand, cryptographic key management, anti-replay protection, sequence management and protected communications.

Execution-finality introduces a different control question:

Can authenticated authority be narrowed from authority to communicate with the spacecraft into authority for a particular consequential act to become effective?

A mission could therefore retain its existing communication-security infrastructure while adding protected act-specific validation closer to the consequential release boundary.

Scope discipline

Execution-finality is not intended to gate every spacecraft instruction.

A practical architecture could reserve finality enforcement for a relatively narrow class of high-consequence operations, such as:

• propulsion actuation;
• consequential RF radiation or reconfiguration;
• payload activation;
• release of protected mission data;
• transition of uploaded software into executable operational state; and
• consequential inter-satellite commands.

Routine telemetry, housekeeping queries, ordinary computation and other reversible internal operations need not pass through the same finality mechanism.

This substantially limits the additional processing and assurance surface.

Engineering cost

The architecture is not cost-free.

Potential implementation costs include additional verification and validation, qualification of any newly introduced hardware or firmware, protected-state management, cryptographic key and credential management, integration with ground infrastructure, recovery procedures and analysis of failure modes in which valid operations could be incorrectly denied.

Those costs must be evaluated against mission criticality and consequence severity.

The engineering proposition is therefore not that execution-finality adds no weight, latency, complexity or cost.

It is narrower:

A Finality Sink need not be a new spacecraft subsystem. It can be a protected verification function positioned at an existing consequence boundary, applied selectively to operations for which incorrect execution carries sufficient risk to justify the additional assurance.

This preserves implementation neutrality while providing a concrete path from the abstract execution-finality model to a spacecraft architecture that engineers can evaluate, test and potentially standardise

 16. Fail-Closed Does Not Mean “Disable the Satellite”

A further distinction is necessary.

Fail-closed execution governance should not be interpreted simplistically as turning off a satellite whenever communications fail.

Spacecraft require sophisticated autonomous safe-state behaviour.

For example, loss of ground communication may require the spacecraft to:

• maintain attitude;

• preserve thermal conditions;

• protect battery state;

• avoid collision;

• transmit emergency telemetry;

• enter safe mode; or

• perform narrowly predefined autonomous survival operations.

Execution-finality governance can therefore distinguish between:

ordinary operational authority

and

pre-authorised safety authority.

Emergency capabilities could have separately bounded conditions.

The objective is not to make spacecraft incapable of autonomous survival.

It is to avoid converting necessary autonomy into unbounded authority.

17. From Cybersecurity to Consequence Security

Traditional security architecture often concentrates on:

Who entered the system?

Was the communication encrypted?

Was the command authenticated?

Was malware detected?

Was an incident recorded?

These remain essential.

But increasingly autonomous space infrastructure creates another category:

Consequence security

What exact consequence is being requested?

Who authorised that consequence?

For what purpose?

Under what mission state?

For which spacecraft and subsystem?

Until when is that authority valid?

Has anything changed since authority was issued?

Can the actuator or release boundary independently verify the authority?

This is the conceptual space occupied by execution-finality governance.

18. Standardisation Opportunity

The Council’s current compromise text provides for the possibility of European standardisation requests relating to requirements under the proposed Regulation and contemplates reliance on existing European and international standards where appropriate.

That creates a legitimate research question for future technical discussions:

Should standards for autonomous and software-defined space systems distinguish between authority to communicate with a spacecraft and authority to cause a particular externally effective spacecraft operation?

Possible future standardisation questions include:

1. How should consequential spacecraft acts be represented?

2. Which attributes should remain bound to an execution authorisation?

3. How should freshness and revocation be verified?

4. How should authority survive intermittent communications?

5. How should emergency autonomy be treated?

6. Where should the Finality Sink exist for RF, propulsion and payload systems?

7. How should evidence be generated without exposing unnecessary mission-sensitive information?

8. How can SMEs implement such controls without excessive cost?

9. How should inter-satellite delegation be bounded?

10. How should autonomous AI-generated commands be distinguished from human-approved commands?

These questions can be investigated without prescribing a single technology.

19. What This Proposal Does Not Claim

Several limits should be explicit.

This paper does not claim that:

• the EU Space Act has already been adopted;

• EU law currently requires execution-finality architecture;

• execution-finality replaces NIS2;

• authentication or encryption are unnecessary;

• every satellite operation requires identical validation;

• every legal obligation can be represented in software;

• AI should control regulatory interpretation;

• a Finality Sink must take a particular hardware form;

• the architecture eliminates human oversight; or

• execution-finality would prevent every cyberattack.

The narrower claim is:

For satellite operations capable of producing significant external consequences, cybersecurity may be strengthened by separating generation or receipt of a command from authority for that command to become effective.

20. Policy Proposition for Europe

Europe's emerging space-regulatory framework provides an opportunity to consider a distinction that may become increasingly important as satellites become more autonomous:

Security of access

versus

Security of effectuation

The first protects entry into the system.

The second protects the transition from a proposed machine operation to a real consequence.

Both are necessary.

A secure communication link can protect a command in transit.

A cryptographic identity can establish who issued it.

An access-control system can determine who may enter the system.

But an execution-finality mechanism can additionally ask:

Does this particular action possess valid authority to become externally effective at this exact boundary and state?

That additional question may become increasingly important for:

• autonomous collision avoidance;

• AI-enabled satellite operations;

• software-defined radios;

• large constellations;

• inter-satellite networks;

• commercial Earth observation;

• orbital servicing;

• automated ground systems; and

• future highly autonomous spacecraft.

Conclusion

Europe's proposed Space Act reflects a significant transition in space governance.

Satellite regulation is moving beyond traditional licensing and orbital safety toward a framework that gives greater attention to cyber resilience, operational control, supply chains, incident handling, technical conformity and the protection of consequential space infrastructure.

The next technical question is therefore not simply whether a satellite is connected securely.

It is whether security persists all the way to the moment of consequence.

An autonomous AI may calculate an orbital manoeuvre.

A ground station may transmit an authenticated instruction.

A software-defined system may request a new RF configuration.

A constellation-management agent may generate thousands of machine decisions.

But none of those facts alone should necessarily constitute unlimited authority to alter the physical or communications environment.

Execution-finality governance introduces a clear separation:

Computation is permitted.

Commands may be generated.

Plans may be calculated.

AI may recommend.

Networks may transport.

But a consequential act remains non-effective until the applicable authority is established and independently verified at the point where external effectuation becomes possible.

For Europe, this could represent a useful research direction linking:

cyber resilience → operational authority → autonomous systems → technical standards → pre-effectuation enforcement.

The central proposition can be stated in one sentence:

The future satellite should not merely ask whether a command is authentic; it should be able to establish whether that exact command possesses authority to become a real-world consequence.

That is the transition from satellite cybersecurity to satellite execution-finality security.