Signed close

What a signed close establishes

A signed close is the final, verifier-facing marker that a run reached its intended endpoint. It is distinct from intermediate progress evidence because it is meant to confirm completion, not just that activity continued.

That distinction matters when a record is used as proof of execution, compliance, or workflow integrity. A close marker that is only implied by later activity can be ambiguous, while a preserved terminal attestation can anchor the end state of the run.

Why the close must be independently preserved

The value of a signed close depends on being separable from the recorder or execution stream that produced it. If the close is only visible inside mutable logs or transient runtime state, a verifier may not be able to distinguish a clean completion from an interrupted, replayed, or partially recorded run.

Independent preservation gives the close evidentiary weight. It lets reviewers compare the recorded boundary against expected sequencing and determine whether the run terminated at the claimed point.

How verifiers use boundary checks

A signed close is most useful as a boundary check. Verifiers examine whether the terminal attestation aligns with the expected end point, whether preceding events form a coherent sequence, and whether the run appears to stop where it should.

In practice, this supports auditability and post-event validation. If a run was supposed to end after a specific action, the signed close helps show that the terminal condition was reached rather than merely assumed from surrounding telemetry.

What can still go wrong

Signed closes are only as reliable as the controls around them. If a close can be forged, replayed, detached from the right run, or recorded without strong binding to the underlying execution, it can create false confidence about completion.

The strongest use case is one where the close is tied tightly to the specific run, retained independently, and checked against the expected lifecycle so that completion evidence cannot be confused with ordinary continuity evidence.

Risk and Threat Considerations

Signed close is attractive anywhere completion must be provable, because weak terminal evidence can hide interruption, truncation, replay, or fabricated success. The security risk is not only missing proof, but also false proof that a process finished cleanly when it did not.

Failure mechanism: An attacker or faulty pipeline can suppress the real terminal state, substitute a close from another run, or leave only partial records that make the sequence look complete.

Impact: Verifiers may accept an incomplete or tampered run as finished, which can undermine auditability, incident reconstruction, workflow integrity, and any downstream decision that depends on a confirmed endpoint.

Practitioner Guidance

Why practitioners should care: Treat the signed close as a control point, not a decorative log line. It should be designed so that the end of the run can be verified even when the surrounding recorder is unavailable, altered, or incomplete.

What to watch for: Be cautious when completion is inferred from continuity alone, when terminal evidence is mutable, or when multiple runs could be confused with one another. The close should identify one run and one endpoint unambiguously.

Practitioner takeaway: A signed close is most valuable when it survives independently and can be checked on its own as the final proof of completion.

Related resources from NHI Mgmt Group

• Why are signed OAuth messages relevant to NHI security?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?
• What is the difference between self-signed and CA-signed client certificates?
• When should organisations require signed commits for production code?