Modify On-Board Values is detected by comparing live device settings against approved baselines and expected sensor or control outputs. Monitor configuration stores, calibration data and safety thresholds for unauthorised changes, then verify them with signed updates or trusted management paths. Alert when values change outside maintenance windows or without a valid change record.
What “Modify On-Board Values” Usually Means in Practice
Security teams should treat Modify On-Board Values as a device integrity problem first, not just a logging problem. The values in scope are the settings, thresholds, calibration points or control outputs that the device uses to behave safely and predictably. If those values drift from approved baselines, the device can still look “up,” while operating outside its intended safety envelope.
The key question is whether the live value is still the one engineering approved. That means checking the current state against a trusted reference, then confirming the change path is legitimate. In well-run environments, the reference is not a spreadsheet alone, it is a controlled configuration source with traceability to an authorised change.
A useful way to frame this is that the attacker or failure mode is not necessarily replacing the whole device configuration. It may be a targeted alteration of a single on-board parameter that changes alarms, thresholds, or control logic. That is why detection should include both state comparison and validation of the update mechanism, not one or the other.
How to Detect Drift Without Creating Noise
Detection works best when live telemetry, configuration stores and change records are correlated. Compare current device settings to approved baselines, then look for mismatches in the values that matter most operationally, such as safety thresholds, calibration data and control limits. A single unexpected change may be enough to justify escalation if it affects a safety-critical function.
Alerting should be time-aware as well as state-aware. Changes made outside a maintenance window, or without a corresponding change ticket or signed update, deserve higher priority because they are harder to explain benignly. If the environment supports it, use trusted management paths and signed updates as the default verification method so the team can distinguish approved modification from silent tampering.
The practical challenge is avoiding alert fatigue from legitimate operational tuning. Teams need a clear inventory of which on-board values are allowed to change, who can approve them, and what evidence proves the change was expected. Without that context, even accurate detections can be too ambiguous to drive fast response.
What Good Detection Coverage Looks Like
Good coverage extends across the full lifecycle of the value, from original provisioning through maintenance and replacement. The device may be healthy in a narrow health-check sense while still carrying a modified value that changes its behaviour under specific conditions. Coverage should therefore include periodic reconciliation, not only event-driven alerts.
Look for three control points: the baseline source, the update channel, and the runtime state. If any one of those is weak, an unauthorised change can survive long enough to matter. For that reason, teams should verify that configuration stores are protected, that calibration data is versioned, and that safety thresholds cannot be altered without auditable approval.
When the device is part of a larger operational chain, a value change on one component can create secondary effects elsewhere. That makes it important to monitor not just the setting itself, but the observed output that should result from it. If the output no longer matches the expected sensor or control behaviour, the issue may be more serious than a simple configuration mismatch.
Risk and Threat Considerations
Unauthorised on-board value changes are risky because they can alter how a device behaves without immediately breaking availability. That makes the issue hard to spot until a threshold is crossed, a safety control fails, or an output no longer matches expected behaviour. In operational environments, silent parameter drift can be as dangerous as a full compromise.
Failure mechanism: An attacker, insider, or faulty process modifies a permitted setting, calibration value, or threshold through an approved-looking path, then the device continues operating with altered behaviour because the change was not reconciled against a trusted baseline.
Impact: Safety controls can be weakened, sensor readings can become misleading, and downstream systems may make decisions based on false or degraded device behaviour. In the worst case, a single changed value can create a durable integrity problem that persists across restarts and routine checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1565 — Data Manipulation | Modify-on-board values alters trusted device state and outputs. |
| Recommendation — Monitor for unauthorized parameter changes and correlate them with expected device behavior. | ||
| NIST CSF 2.0 | PR.DS-06 — Data-at-rest is protected | Approved baselines and configuration stores must be protected from unauthorized modification. |
| Recommendation — Protect configuration and calibration stores from unauthorized write access. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Detection depends on approved change records and controlled updates. |
| SI-7 — Software, Firmware, and Information Integrity | Unexpected value changes can indicate integrity compromise in device state or firmware-adjacent logic. | |
| AU-6 — Audit Review, Analysis, and Reporting | Change detection needs alerting and review of suspicious value changes. | |
| Recommendation — Require documented authorization before changing device configurations. Verify device integrity against trusted baselines and signed updates. Analyze audit events for unexpected configuration or threshold changes. | ||
Practitioner Guidance
What to verify: Confirm that your detection logic checks both state and provenance. A mismatch alone is useful, but the strongest signal is a mismatch plus an unapproved source, unsigned update, or missing change record.
Decision rule: If the value can affect safety, thresholds, or control output, treat any unauthorised or unexplained change as an integrity event, not a routine configuration issue. If the change is expected but undocumented, pause on closure until the change path is proven.
What practitioners underestimate: The most dangerous values are often the least visible ones, because they do not crash the device. The control objective is not only to catch obvious tampering, it is to detect subtle state drift before it becomes an operational incident.
Practitioner takeaway: The best detection strategy is to make configuration drift provable or suspicious, never merely observable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org