How can organisations reduce the risk of unauthorised modification of on-board values?

What “on-board values” are, and why modification control matters

On-board values are the stored parameters that govern how an embedded, device, or satellite system behaves in operation. They may cover safety thresholds, navigation constants, mode settings, limits, or other control data. The core risk is not just tampering, but tampering that changes how the system interprets commands, responds to faults, or protects itself.

That is why organisations should treat these values as security-relevant configuration, not as ordinary data. If write paths are weak, an attacker or careless operator can alter behaviour without changing software binaries, which makes the change harder to detect and often more dangerous than a visible reboot or patch event. For space and satellite environments, that concern is especially clear in the Space and Satellite Cybersecurity Guide, which covers command authentication, keys, and onboard command integrity.

How organisations reduce the chance of unauthorised changes

The first control is to make write access explicit and authenticated. Systems should distinguish read-only telemetry from privileged updates, and every write should be authorised, logged, and tied to an accountable operator or automation path. Least privilege matters here because a broad admin path often becomes the easiest route to silent configuration drift.

Integrity protection should sit around the configuration channel itself. That means checking that values come from an approved source, validating message integrity before acceptance, and rejecting out-of-band updates that bypass the normal change path. Where a system supports signed configuration bundles, secure command channels, or compare-and-commit workflows, those mechanisms should be used to reduce the chance that a malformed or injected update is accepted.

Baseline control is the other half of the problem. Approved values should be versioned, compared against a known-good baseline, and reviewed when drift appears. In practice, the strongest control is not one point check, but a chain of prevention, validation, and drift detection that makes unauthorised change both harder to perform and easier to spot.

Detecting drift, abuse, and unsafe update paths

Defenders should assume that value changes can happen without an obvious outage. A malicious or mistaken write may look like a normal update unless the organisation monitors for change timing, source, scope, and business context. Sudden updates outside maintenance windows, repeated parameter edits, and changes that affect safety or control logic deserve immediate review.

The supporting evidence is often operational rather than forensic at first. A change that arrives from an unexpected host, through an unapproved tool, or without the usual change record is already a warning signal. Teams should also look for secondary indicators such as failed integrity checks, replayed configuration messages, or a mismatch between active values and the documented approved state.

For organisations that need a broader detection and response lens, the NCSC UK Advice and Guidance is a useful reference point for operational security practices, while the NIST SP 800-53 Rev 5 Security and Privacy Controls aligns directly with access control, system integrity, audit, and configuration management expectations.

Risk and Threat Considerations

Unauthorised modification of on-board values is risky because it can change the system’s behaviour without changing the software itself. That makes the weakness attractive to attackers who want persistence, stealth, or a way to influence safety and control decisions while avoiding obvious alarms.

Failure mechanism: An attacker, rogue operator, or compromised integration path reaches a write function that was not tightly authorised or integrity-checked, then alters parameters that the system trusts at runtime.

Impact: The result can be unsafe operation, degraded navigation or control, altered fault handling, or a hidden persistence layer that survives ordinary software checks and complicates recovery.

Practitioner Guidance

What to verify: Confirm that every writable parameter has an owner, an approval path, and a logged source of truth. If a value can be changed from more than one interface, treat that as a control-design problem rather than a user-training problem.

What to prioritise: Protect the most safety-sensitive and mission-sensitive values first, especially those that influence limits, fail-safe behaviour, or control authority. In many environments, a small set of parameters deserves stricter handling than the rest of the configuration estate.

Decision rule: If a change can alter how the system behaves during an incident or fault, require strong authentication, change validation, and rapid detection before broad operational use is allowed. If that is not feasible, limit the value’s effect until the control gap is closed.

Practitioner takeaway: The goal is not to stop every configuration change, but to make sure only trusted, attributable, and integrity-checked writes can influence behaviour that matters.

Related resources from NHI Mgmt Group

• How should teams reduce the risk from exposed NHI secrets?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• How can organisations reduce the risk of registry modification abuse?