An autonomous system that asks for a privileged physical action is usually gated on integrity evidence: a platform proves what it is running, and the request is granted or refused on that basis. Such a gate is normally treated as a predicate, yet the evidence behind it has an age, the decision that consumes it has a latency, and the physical system that waits for it has a deadline. We formulate mission-aware attestation as a runtime assurance contract that holds only when integrity is valid, the evidence is fresh enough, and the decision completes inside a budget derived from the current physical state. The contract yields four operational outcomes where a binary gate yields two, separating a refusal caused by tampering from one caused by stale evidence and from one caused by a late decision. We evaluate it on a hardware-in-the-loop vehicle-to-infrastructure platform: a driving simulator supplies the physical state and the authorisation deadline, while a microcontroller on-board unit and a TPM-backed roadside unit running Linux integrity measurement supply the assurance evidence. A security-blind model admits the whole operating space and a hardware-informed one three quarters of it, and every point it refuses fails the freshness margin rather than the response margin. Moving the attestation interval across the range the verifier permits costs about as much as a fivefold scaling of the latency distribution, and the interval is directly configurable, which makes it the immediately actionable deployment parameter. If the freshness bound does not exceed the authorisation budget, every late decision is also stale and lateness becomes unobservable, so the attestation interval and the freshness bound cannot be chosen from security requirements alone.
Why Mission-Aware Attestation Matters for Time-Critical Autonomous Systems
Autonomous platforms that execute privileged physical actions—such as emergency braking, door unlocking, or power shutdown—typically rely on integrity evidence to decide whether to proceed. The platform presents a proof of its current software state, and the request is granted or refused on that basis. This gate is usually treated as a simple binary check: if the proof is valid, proceed; otherwise, refuse. But the evidence behind the gate is not timeless. It ages with every system call, every firmware update, every tick of the internal clock. The decision that consumes the evidence also takes time—the latency of measurement, of comparison, of the choice itself. And the physical system that waits for the decision has a deadline; if the action is delayed past that deadline, the opportunity is lost or danger is increased. Prior work has examined each of these dimensions separately: freshness of measurements, latency of decision processes, and deadlines of physical responses. This paper argues that treating them in isolation misses the contract that binds them together.
The authors formulate mission-aware attestation as a runtime assurance contract. The contract holds only when three conditions are met: integrity is valid, the evidence is fresh enough, and the decision completes inside a budget derived from the current physical state. If any condition fails, the contract is broken and the system takes one of several possible actions. The key insight is that a binary gate collapses three-dimensional failure space into one bit, losing the information needed to distinguish among different failure modes. By preserving the distinctions, the contract yields four operational outcomes instead of two.
From Binary Gates to Runtime Assurance Contracts
In a traditional attestation setup, the gate is a predicate: valid evidence implies proceed, invalid evidence implies refuse. The authors show that this collapse loses distinguishability. When the gate refuses, the system cannot tell whether the refusal was because the platform was tampered with, because the evidence had grown too stale, or because the decision took too long and missed its deadline. Each of these origins calls for a different response: tampering may warrant a full system lockdown and forensic investigation; stale evidence may suggest refreshing the measurement before retrying; a late decision may indicate that the deadline was too tight and should be relaxed. The runtime assurance contract keeps these distinctions alive.
Formally, the contract evaluates three propositions: (1) integrity is valid—does the platform's current software state match an approved reference? (2) the evidence is fresh enough—is the evidence within a freshness bound derived from the current physical state? (3) the decision completes inside the authorisation budget—does the time from evidence collection to final decision stay within a deadline derived from the physical system's remaining time? The contract is satisfied only when all three hold. When the contract fails, the system can output one of four outcomes: proceed when all hold, refuse due to tampering when integrity is invalid and the other two hold, refuse due to stale evidence when integrity holds but freshness fails, and refuse due to a late decision when integrity and freshness hold but the decision exceeds the budget. The authors argue that this richer taxonomy enables more precise recovery actions and more informative logging for later security analysis.
The Freshness-Latency-Deadline Trade-Off
Freshness, latency, and deadline are not independent. The freshness bound—the maximum age that integrity evidence may have at the moment of decision—must be compatible with the latency of the decision process and the remaining deadline of the physical system. If the freshness bound is set too tight relative to what the decision process can achieve, every decision that attempts to use fresh evidence will miss its deadline. If the bound is set too loose, the system may accept stale evidence and proceed with a state that no longer reflects the true platform condition.
The authors characterize the cost of moving the attestation interval across the range the verifier permits. They show that it costs about as much as a fivefold scaling of the latency distribution. In other words, widening the interval to accept slightly older evidence has a similar operational impact as dramatically increasing the permitted decision latency. This equivalence means that system designers have a lever: they can trade off freshness against latency, or they can tighten one and loosen the other to achieve the desired overall success rate. The interval is directly configurable, which makes it the immediately actionable deployment parameter.
Hardware-in-the-Loop Evaluation: V2I Platform Results
The authors evaluate the mission-aware attestation contract on a hardware-in-the-loop vehicle-to-infrastructure platform. The setup consists of a driving simulator that supplies the physical state and the authorisation deadline, a microcontroller on-board unit running on the vehicle, and a TPM-backed roadside unit running Linux integrity measurement. The TPM, or Trusted Platform Module, provides hardware-rooted measurements of the platform's boot process and runtime state. Linux integrity measurement extends the TPM's capabilities by recording measurements of the kernel, filesystem, and other software components at boot and at specified events.
The simulator presents the vehicle with a sequence of scenarios that require a privileged physical action, such as an emergency stop or a safe pull-over. At each decision point, the vehicle's on-board unit collects integrity evidence and presents it to the roadside unit for verification. The roadside unit runs the mission-aware attestation contract and returns a decision: proceed, refuse-tampering, refuse-stale, or refuse-late. The simulator records the physical state at each moment, so the authors can correlate the contract's outcomes with the remaining deadline, the age of the evidence, and the latency of the decision.
A security-blind model admits the whole operating space. This means that, without any freshness or deadline constraints, the model would allow every decision to proceed, regardless of the platform's actual state. A hardware-informed model admits three quarters of the operating space, meaning that it rejects one quarter of decisions based on the mission-aware constraints. Every point that the hardware-informed model refuses fails the freshness margin rather than the response margin. In other words, the system more often refuses because the evidence had grown too stale than because the decision took too long. This finding suggests that, in this deployment, the freshness constraint is the active constraint, while the decision latency is comfortably within the budget for most scenarios.
Configurability and the Actionable Deployment Parameter
The authors move the attestation interval across the range the verifier permits and measure the cost in terms of overall success rate. They show that the cost is about as much as a fivefold scaling of the latency distribution. This means that, for example, widening the interval to accept evidence that is slightly older has a similar effect on the success rate as permitting a decision that takes five times longer. The interval is directly configurable, which makes it the immediately actionable deployment parameter.
System operators can therefore adjust the attestation interval to match the operational context. In a scenario where the physical deadline is tight and every millisecond counts, a narrow interval ensures that only very fresh evidence is accepted, at the cost of more frequent refusals. In a scenario where the deadline is generous and the system can afford more deliberation, a wider interval reduces refusals caused by stale evidence, at the cost of accepting evidence that is older. The authors' empirical results show that the fivefold equivalence holds across the evaluated range, giving operators a predictable knob to turn.
The Freshness Bound and the Authorization Budget
The authors also examine the interaction between the freshness bound and the authorisation budget. The freshness bound is the maximum age that integrity evidence may have at the moment of decision; it is derived from the current physical state and the remaining deadline. The authorisation budget is the time allowed from evidence collection to final decision; it is also derived from the physical state. The two are not independent: if the freshness bound does not exceed the authorisation budget, then every late decision is also stale. Conversely, if the authorisation budget is very tight, then even very fresh evidence may not be usable if the decision process cannot complete within the budget.
The critical finding is that when the freshness bound does not exceed the authorisation budget, every late decision is also stale and lateness becomes unobservable. This means that, under this condition, the system cannot distinguish between a refusal caused by stale evidence and a refusal caused by a late decision: both are observed as refusals due to stale evidence. The attestation interval and the freshness bound cannot be chosen from security requirements alone; they must also respect the budget constraints imposed by the physical system's deadline. This interdependence means that system designers must consider all three dimensions—freshness, latency, and deadline—simultaneously when configuring the mission-aware attestation contract.
Limitations and Open Questions
The authors acknowledge several limitations. The evaluation was conducted on a specific V2I platform with a particular combination of simulator, microcontroller, and TPM-backed roadside unit; other hardware configurations may yield different freshness-latency-deadline trade-offs. The fivefold equivalence between interval movement and latency scaling was observed on the evaluated range; it may not hold under radically different workloads or system architectures. The results show that the hardware-informed model more often refuses due to freshness than due to latency, but the reverse may be true in other contexts, such as systems with very fast decision processes or evidence that ages very quickly. The authors also note that the contract's four outcomes depend on the precise definitions of integrity validity, freshness, and budget compliance; different choices of thresholds and bounds would yield different outcome distributions.
What This Means for Autonomous System Deployments
For practitioners building or operating autonomous systems that require privileged actions, the paper's results offer several practical takeaways. First, the runtime assurance contract framework provides a richer basis for decision-making than a simple binary gate. By preserving the distinctions among tampering, staleness, and lateness, the system can take more precise recovery actions and produce more informative logs. Second, the attestation interval is a directly configurable parameter that has a predictable cost in terms of success rate. Operators can adjust the interval to match the operational context, knowing that widening the interval has a similar effect to permitting slower decisions. Third, the freshness bound and the authorisation budget are interdependent; they cannot be chosen independently from security requirements. System designers must ensure that the freshness bound does not exceed the authorisation budget if they wish to keep lateness observable as a distinct failure mode. Fourth, the evaluation shows that, in the tested V2I deployment, freshness is the more frequently triggered constraint; systems where latency is the dominant concern may need different configuration choices or process optimizations to reduce decision time.
The paper's released code, benchmark scenarios, and measured trade-offs provide a starting point for teams seeking to implement mission-aware attestation in their own platforms. The hardware-in-the-loop V2I testbed, with its driving simulator, microcontroller on-board unit, and TPM-backed roadside unit, can be adapted to other physical systems—marine vessels, industrial robots, warehouse automation cells—where privileged actions must be gated on fresh integrity evidence. The authors' empirical characterization of the fivefold equivalence between interval movement and latency scaling, and the freshness-bound-to-budget interdependence, are concrete data points that can inform configuration choices in real deployments.