Command Accepted Is Not Actuation Authorized: Execution Finality for Cyber-Physical and Industrial Control Systems
draft-das-actuation-bound-execution-finality-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
An Architecture for Technical Enforcement for GDPR and the EU AI Act in Critical AI Systems
The Internet Solved Communication. It Never Solved Authority. |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-actuation-bound-execution-finality-00
Individual Submission S. Das
Internet-Draft Independent
Intended status: Informational 16 September 2026
Expires: 20 March 2027
Command Accepted Is Not Actuation Authorized: Execution Finality for
Cyber-Physical and Industrial Control Systems
draft-das-actuation-bound-execution-finality-00
Abstract
Cyber-physical and industrial systems increasingly accept commands
from cloud services, AI agents, remote operators, enterprise
applications, and distributed control software. A high-consequence
failure can occur even when identity, authorization, message
integrity, platform attestation, and functional-safety mechanisms are
individually correct: a digitally valid command can remain apparently
acceptable while the target actuator, command parameters, machine
mode, process state, safety/interlock state, authority state, or
effectuation path has changed. The consequence is no longer merely
an incorrect API call. It can be drive energization, robotic motion,
valve or pump actuation, material release, process transition, or
another physical effect. No token forgery, cryptographic break, or
defeat of the safety protocol is necessarily required; the failure
can be a loss of continuity between earlier digital authority and the
exact physical act that becomes effective.
Existing industrial mechanisms already solve major parts of this
problem. IEC 61508 and IEC 61511 define mature functional-safety
engineering and Safety Instrumented Systems; IEC 62443 defines
cybersecurity requirements for industrial automation and control
components; OPC UA provides industrial security mechanisms, while OPC
UA Safety defines a functional-safety communication layer; ACE-OAuth
[RFC9200] provides authorization for constrained IoT environments;
RATS [RFC9334] provides trusted platform Evidence and Attestation
Results; and existing safety PLCs/controllers from Siemens, Rockwell
Automation, Schneider Electric, ABB, and other vendors provide mature
safety logic and output control. These are complementary precedents,
not examples of missing safety engineering. Where an existing safety
controller or protected actuator boundary already makes exact command
authority, current safety/process state, and final output mediation
non-bypassable, that deployment already satisfies the core property
described here.
The residual gap exists only where one of those mechanisms stops at a
boundary upstream of the first physical effect or does not carry the
complete cyber-authority predicate required by the deployment. IEC
Das Expires 20 March 2027 [Page 1]
Internet-Draft Actuation-Bound Finality September 2026
functional-safety mechanisms can correctly enforce safety functions
without necessarily expressing the provenance and exact scope of an
AI-, cloud-, or enterprise-originated command. IEC 62443 controls
can correctly protect identity, use, integrity, and information flow
without by themselves defining the final application's exact
actuation predicate. OPC UA Safety can correctly deliver SafetyData
while the receiving safety application still determines whether a
cyber-originated act is applicable. ACE can correctly authorize a
constrained resource while current machine/process/safety state may
be evaluated later. RATS can correctly attest the controller while
platform trust is not authorization for a particular torque, motion,
valve transition, or output. Current application-layer action-
evidence work [SOKOLOV-AEP] can strengthen accountability while
remaining distinct from pre-actuation non-completability. If any
existing deployment already composes these properties at the true
output boundary, no residual gap remains for that deployment.
This document therefore proposes a narrower actuation-bound
execution-finality invariant. A Candidate Act remains in a Non-
Effective State until a protected Actuation Finality Boundary (AFB)
verifies the exact pending command, current execution authority,
target actuator identity, freshness and replay state, required
current machine/process/safety predicates, and authorized
effectuation path immediately before or atomically with the physical
output becoming effective. The AFB is an architectural role, not a
mandatory new appliance: an existing safety PLC, safety controller,
protected drive, robot controller, SIS function, secure I/O stage, or
device controller can already be the AFB when it enforces the
required invariant.
Prevention is claimed only where the protected physical effect cannot
occur without those checks and where existing functional-safety
controls remain authoritative rather than being bypassed or replaced.
Execution-finality logic MUST NOT convert an existing safety DENY
into ALLOW. If enforcement is upstream-only, mutable context is
stale, path coverage is incomplete, or the mechanism merely records
what occurred, the result is mitigation, detection, or auditability
rather than the same prevention guarantee. The architecture
complements functional safety; it does not replace hazard analysis,
define a safe state, certify an unsafe controller, or claim that an
IETF mechanism establishes SIL or PL.
The problem is industrially relevant to robotics and motion control,
process plants, manufacturing and warehouse automation, power and
critical infrastructure, and other systems where remote or AI-
generated commands can cross several cyber layers before becoming
physical. Siemens Safety Integrated, Rockwell GuardLogix, Schneider
Electric Modicon M580 Safety, ABB AC500-S, and OPC UA Safety are
Das Expires 20 March 2027 [Page 2]
Internet-Draft Actuation-Bound Finality September 2026
cited politely as mature safety precedents and potential integration
points. No vulnerability, deficiency, non-conformance, affiliation,
or endorsement is asserted. Criticism, corrections, counterexamples,
prior art, real-time implementation experience, and evidence that
existing safety or authorization mechanisms already provide the full
invariant are explicitly invited.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Vulnerability: A Valid Command Can Become an Invalid
Physical Act . . . . . . . . . . . . . . . . . . . . . . 8
1.2. Existing Safety and Security Mechanisms Already Address
Major Parts . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Why the Residual Gap Can Remain . . . . . . . . . . . . . 9
1.3.1. Functional Safety and Safety Controllers . . . . . . 9
1.3.2. IEC 62443 and Industrial Cybersecurity . . . . . . . 9
Das Expires 20 March 2027 [Page 3]
Internet-Draft Actuation-Bound Finality September 2026
1.3.3. OPC UA Safety and Safe Communication . . . . . . . . 10
1.3.4. ACE and Constrained-Device Authorization . . . . . . 10
1.3.5. RATS and Action Evidence . . . . . . . . . . . . . . 10
1.3.6. Alternate Physical Effectuation Paths . . . . . . . . 10
1.4. What This Architecture Introduces . . . . . . . . . . . . 11
2. Conventions and Requirements Language . . . . . . . . . . . . 11
3. Direct Question: What Threat Does This Architecture Solve? . 11
4. Motivating Scenario: Authorized at X17, Actuated at X18 . . . 12
5. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Digital Authorization Is Not Physical Authority . . . . . 13
5.2. Functional Safety Is Not Replaced . . . . . . . . . . . . 13
5.3. Secure Communication Is Not Final Actuation Authority . . 13
5.4. Attestation Is Not Physical-State Truth . . . . . . . . . 13
5.5. Audit Is Not Prevention . . . . . . . . . . . . . . . . . 13
6. Threat Model and Assurance Scope . . . . . . . . . . . . . . 14
6.1. Adversary Capabilities . . . . . . . . . . . . . . . . . 14
6.2. Threat Severity and Applicability . . . . . . . . . . . . 14
6.3. Baseline Actuation-Finality Profile . . . . . . . . . . . 14
6.4. High-Assurance Actuation-Finality Profile . . . . . . . . 14
6.5. Trusted Roots and Limits . . . . . . . . . . . . . . . . 15
7. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 15
8. Existing Mechanisms and the Proposed Delta . . . . . . . . . 15
8.1. IEC 61508 . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. IEC 61511 . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. IEC 62443 . . . . . . . . . . . . . . . . . . . . . . . . 15
8.4. OPC UA Security . . . . . . . . . . . . . . . . . . . . . 16
8.5. OPC UA Safety . . . . . . . . . . . . . . . . . . . . . . 16
8.6. ACE-OAuth . . . . . . . . . . . . . . . . . . . . . . . . 16
8.7. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.8. Application-Layer Action Evidence . . . . . . . . . . . . 16
8.9. Safety PLCs and Safety Controllers . . . . . . . . . . . 17
8.10. Comparison Summary . . . . . . . . . . . . . . . . . . . 17
8.11. What Is New in This Document . . . . . . . . . . . . . . 18
9. Prevention and Mitigation Property . . . . . . . . . . . . . 19
9.1. Prevention Profile . . . . . . . . . . . . . . . . . . . 19
9.2. Mitigation, Detection, or Audit Profile . . . . . . . . . 19
9.3. Unknown Safety or Process State . . . . . . . . . . . . . 20
10. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Actuation Context Model . . . . . . . . . . . . . . . . . . . 20
11.1. Typed Actuation-State Vector . . . . . . . . . . . . . . 21
11.2. State Semantics . . . . . . . . . . . . . . . . . . . . 22
11.3. Sensor and State-Source Trust . . . . . . . . . . . . . 23
11.4. Cross-State Consistency . . . . . . . . . . . . . . . . 23
11.5. Effect-Type Semantics . . . . . . . . . . . . . . . . . 23
12. Formal Mathematical Model . . . . . . . . . . . . . . . . . . 24
12.1. Safety-Dominance Rule . . . . . . . . . . . . . . . . . 25
12.2. Bounded Prevention Argument . . . . . . . . . . . . . . 25
12.3. Canonical Physical Candidate Act . . . . . . . . . . . . 25
Das Expires 20 March 2027 [Page 4]
Internet-Draft Actuation-Bound Finality September 2026
12.4. Trusted State-Evidence Predicate . . . . . . . . . . . . 26
12.5. Current Cyber-Authority Predicate . . . . . . . . . . . 26
12.6. Existing Safety Predicate . . . . . . . . . . . . . . . 26
12.7. Actuator and Output Identity . . . . . . . . . . . . . . 27
12.8. Effect-Lifecycle Authority . . . . . . . . . . . . . . . 27
12.9. Actuation Generation Vector . . . . . . . . . . . . . . 28
12.10. State-Transition Applicability . . . . . . . . . . . . . 28
12.11. Check-to-Output Serialization . . . . . . . . . . . . . 28
12.12. Replay and Sequence Formalism . . . . . . . . . . . . . 29
12.13. Actuation-Path Completeness . . . . . . . . . . . . . . 29
12.14. Expanded Actuation Validity . . . . . . . . . . . . . . 29
12.15. Expanded Strict Prevention Invariant . . . . . . . . . . 30
12.16. Continuing and Latched Effects . . . . . . . . . . . . . 30
12.17. Expanded Bounded Prevention Proof . . . . . . . . . . . 31
13. State, Safety, and Authority Continuity . . . . . . . . . . . 31
14. Exact Command and Actuator Binding . . . . . . . . . . . . . 33
15. Freshness, Replay, and Sequence Control . . . . . . . . . . . 35
16. Actuation Finality Boundary . . . . . . . . . . . . . . . . . 35
17. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 37
18. Solution Architecture . . . . . . . . . . . . . . . . . . . . 38
18.1. Prepare Candidate Act . . . . . . . . . . . . . . . . . 39
18.2. Remain Non-Effective . . . . . . . . . . . . . . . . . . 39
18.3. Observe Current Actuation Context . . . . . . . . . . . 39
18.4. Verify Exact Act and Current Applicability . . . . . . . 39
18.5. Protected Output Commit . . . . . . . . . . . . . . . . 39
18.6. Architecture Diagram . . . . . . . . . . . . . . . . . . 39
19. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 40
19.1. Canonicalize the Physical Candidate Act . . . . . . . . 40
19.2. Bind Cyber Authority to the Exact Act . . . . . . . . . 41
19.3. Acquire Current Actuation State . . . . . . . . . . . . 41
19.4. Verify Trusted State Sources . . . . . . . . . . . . . . 42
19.5. Verify Actuator and Output Identity . . . . . . . . . . 43
19.6. Compose with Existing Safety Functions . . . . . . . . . 44
19.7. Evaluate Effect-Lifecycle Authority . . . . . . . . . . 44
19.8. Verify Replay and Sequence State . . . . . . . . . . . . 45
19.9. Verify the Complete Actuation Predicate . . . . . . . . 45
19.10. Handle Safety, Process, Authority, or Topology Change . 46
19.11. Validate Whether a State Transition Is Irrelevant . . . 47
19.12. Verify Consequence-Wide Actuation-Path Coverage . . . . 47
19.13. Protected Real-Time Finalization . . . . . . . . . . . . 48
19.14. Supervise Continuing or Latched Effects . . . . . . . . 49
19.15. Emergency-Stop Precedence . . . . . . . . . . . . . . . 50
19.16. Separate Cold-Path and Hot-Path Work . . . . . . . . . . 50
19.17. Crash-Safe Physical-Effect Recovery . . . . . . . . . . 51
19.18. Generate a Reviewable Actuation Failure Explanation . . 52
20. Composition with Existing Safety Controllers . . . . . . . . 52
21. RATS-Based High-Assurance Actuation . . . . . . . . . . . . . 54
22. Alternate-Path Resistance . . . . . . . . . . . . . . . . . . 55
Das Expires 20 March 2027 [Page 5]
Internet-Draft Actuation-Bound Finality September 2026
23. Attack Analysis . . . . . . . . . . . . . . . . . . . . . . . 55
23.1. Command-Parameter Substitution . . . . . . . . . . . . . 55
23.2. Target-Actuator Substitution . . . . . . . . . . . . . . 56
23.3. Replay and Duplicate Actuation . . . . . . . . . . . . . 56
23.4. Safety or Process-State Race . . . . . . . . . . . . . . 56
23.5. Machine-Mode Confusion . . . . . . . . . . . . . . . . . 56
23.6. Maintenance or Engineering Bypass . . . . . . . . . . . 56
23.7. Compromised Non-Safety Controller . . . . . . . . . . . 56
23.8. Action Evidence Without Prevention . . . . . . . . . . . 56
24. High-Assurance Enforcement . . . . . . . . . . . . . . . . . 56
25. Deployment Patterns . . . . . . . . . . . . . . . . . . . . . 57
25.1. Safety PLC as AFB . . . . . . . . . . . . . . . . . . . 58
25.2. Protected Drive or Robot Controller as AFB . . . . . . . 58
25.3. SIS / Process Controller as AFB . . . . . . . . . . . . 58
25.4. Constrained Device / ACE Resource Server as AFB . . . . 58
25.5. Distributed AFB . . . . . . . . . . . . . . . . . . . . 58
26. Real-Time Performance and Availability . . . . . . . . . . . 58
27. Relationship to ACE . . . . . . . . . . . . . . . . . . . . . 59
28. Relationship to CoRE . . . . . . . . . . . . . . . . . . . . 59
29. Relationship to RATS . . . . . . . . . . . . . . . . . . . . 60
30. Relationship to OPC UA and Industrial Safety Standards . . . 60
31. Industrial Relevance . . . . . . . . . . . . . . . . . . . . 60
31.1. Robotics and Machine Motion . . . . . . . . . . . . . . 60
31.2. Process Control . . . . . . . . . . . . . . . . . . . . 60
31.3. Manufacturing and Warehouse Automation . . . . . . . . . 61
31.4. Critical Infrastructure . . . . . . . . . . . . . . . . 61
32. Complementary Industrial Alignment . . . . . . . . . . . . . 61
32.1. Siemens Safety Integrated . . . . . . . . . . . . . . . 61
32.2. Rockwell Automation GuardLogix . . . . . . . . . . . . . 61
32.3. Schneider Electric Modicon M580 Safety . . . . . . . . . 61
32.4. ABB AC500-S . . . . . . . . . . . . . . . . . . . . . . 61
32.5. OPC Foundation . . . . . . . . . . . . . . . . . . . . . 62
32.6. Non-Endorsement and Non-Criticism . . . . . . . . . . . 62
33. Required Classes of Test Vectors . . . . . . . . . . . . . . 62
34. Questions to the IETF Community . . . . . . . . . . . . . . . 63
35. Potential IETF Discussion Venues and External Standards
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 65
35.1. ACE . . . . . . . . . . . . . . . . . . . . . . . . . . 65
35.2. CoRE . . . . . . . . . . . . . . . . . . . . . . . . . . 65
35.3. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 66
35.4. DISPATCH . . . . . . . . . . . . . . . . . . . . . . . . 66
35.5. SAAG . . . . . . . . . . . . . . . . . . . . . . . . . . 66
35.6. IEC, OPC Foundation, and Industrial Safety
Communities . . . . . . . . . . . . . . . . . . . . . . 66
35.7. No Presumed Home . . . . . . . . . . . . . . . . . . . . 66
36. Relationship to Other Execution-Finality Internet-Drafts . . 66
37. Public Implementations and Companion Engineering Material . . 68
38. Security Considerations . . . . . . . . . . . . . . . . . . . 68
Das Expires 20 March 2027 [Page 6]
Internet-Draft Actuation-Bound Finality September 2026
38.1. Command Parameter Substitution . . . . . . . . . . . . . 68
38.2. Target-Actuator Substitution . . . . . . . . . . . . . . 68
38.3. Command Replay . . . . . . . . . . . . . . . . . . . . . 68
38.4. Duplicate Actuation . . . . . . . . . . . . . . . . . . 68
38.5. Stale Authority . . . . . . . . . . . . . . . . . . . . 68
38.6. Stale Safety State . . . . . . . . . . . . . . . . . . . 69
38.7. Stale Process State . . . . . . . . . . . . . . . . . . 69
38.8. Interlock Race . . . . . . . . . . . . . . . . . . . . . 69
38.9. Machine-Mode Confusion . . . . . . . . . . . . . . . . . 69
38.10. Maintenance-Mode Abuse . . . . . . . . . . . . . . . . . 69
38.11. Local or Manual Override . . . . . . . . . . . . . . . . 69
38.12. Engineering Workstation Bypass . . . . . . . . . . . . . 69
38.13. Direct Fieldbus Write . . . . . . . . . . . . . . . . . 69
38.14. Direct I/O Path . . . . . . . . . . . . . . . . . . . . 69
38.15. Recovery and Disaster-Recovery Control Paths . . . . . . 70
38.16. Firmware-Level Actuation . . . . . . . . . . . . . . . . 70
38.17. Compromised Non-Safety PLC . . . . . . . . . . . . . . . 70
38.18. Compromised Gateway . . . . . . . . . . . . . . . . . . 70
38.19. Compromised Host OS . . . . . . . . . . . . . . . . . . 70
38.20. Safety-Controller Compromise . . . . . . . . . . . . . . 70
38.21. Sensor Spoofing . . . . . . . . . . . . . . . . . . . . 70
38.22. Sensor Authenticity Is Not Physical Truth . . . . . . . 70
38.23. Actuator Feedback Spoofing . . . . . . . . . . . . . . . 70
38.24. Sequence and Reordering Attacks . . . . . . . . . . . . 71
38.25. TOCTOU Between Check and Output . . . . . . . . . . . . 71
38.26. Crash Consistency . . . . . . . . . . . . . . . . . . . 71
38.27. Fail-Open Behavior . . . . . . . . . . . . . . . . . . . 71
38.28. Loss of Safety-State Source . . . . . . . . . . . . . . 71
38.29. Denial of Service . . . . . . . . . . . . . . . . . . . 71
38.30. Emergency Stop Precedence . . . . . . . . . . . . . . . 71
38.31. Fail-Safe Output State . . . . . . . . . . . . . . . . . 71
38.32. Output Latching . . . . . . . . . . . . . . . . . . . . 71
38.33. Authority Consumption State . . . . . . . . . . . . . . 72
38.34. Actuation Path Completeness . . . . . . . . . . . . . . 72
38.35. RATS Attestation Overclaim . . . . . . . . . . . . . . . 72
38.36. Action Evidence Confused with Prevention . . . . . . . . 72
38.37. Audit Is Not Prevention . . . . . . . . . . . . . . . . 72
38.38. Real-Time Latency and Jitter . . . . . . . . . . . . . . 72
38.39. Functional-Safety Certification Boundary . . . . . . . . 72
38.40. Physical Tampering . . . . . . . . . . . . . . . . . . . 72
39. Privacy Considerations . . . . . . . . . . . . . . . . . . . 73
40. Criticism, Corrections, and Review Invited . . . . . . . . . 73
41. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
42. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 73
43. Normative References . . . . . . . . . . . . . . . . . . . . 74
44. Informative References . . . . . . . . . . . . . . . . . . . 74
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 78
Das Expires 20 March 2027 [Page 7]
Internet-Draft Actuation-Bound Finality September 2026
1. Introduction
1.1. Vulnerability: A Valid Command Can Become an Invalid Physical Act
In cyber-physical systems, command validity and actuation validity
are not always the same temporal property. A command can be
authenticated and authorized while the machine is in one operating
state, then execute later after the process, actuator, safety
interlock, mode, authority, or route has changed.
t0 t1 t2
| | |
| C authorized | machine/process | physical
| under state X17 | state becomes X18 | output requested
|------------------------|-------------------------|
|
v
EFFECT under X18
Valid(C, X17) does not automatically imply Valid(C, X18).
Figure 1: A valid digital command can become invalid physical
authority
Relevant state can include robot or machine mode, guard state,
process pressure or temperature, tool identity, actuator mapping,
human-presence state, motion envelope, authority or revocation state,
interlock state, line configuration, or maintenance mode. A
digitally authentic command is therefore not automatically current
physical authority.
1.2. Existing Safety and Security Mechanisms Already Address Major
Parts
IEC 61508 provides foundational functional-safety requirements for
electrical/electronic/programmable electronic safety-related systems
[IEC61508]. IEC 61511 applies functional-safety principles to Safety
Instrumented Systems in the process industry and defines requirements
so that a SIS can achieve or maintain a safe process state
[IEC61511]. IEC 62443-4-2 specifies technical security requirements
for IACS components around foundational requirements including
identification/authentication, use control, system integrity,
restricted data flow, timely response, and availability [IEC62443].
OPC UA Safety is a functional-safety communication layer for exchange
of SafetyData using OPC UA mechanisms and is intended for
implementation in safety devices [OPCUA-SAFETY]. ACE-OAuth provides
authorization for constrained environments [RFC9200]. RATS supplies
Das Expires 20 March 2027 [Page 8]
Internet-Draft Actuation-Bound Finality September 2026
Evidence and Attestation Results about trusted platform state
[RFC9334]. Current individual work also composes signed application-
layer action records with RATS platform evidence [SOKOLOV-AEP].
Industrial safety controllers already provide the strongest practical
overlap. Safety PLCs and controllers from Siemens, Rockwell
Automation, Schneider Electric, ABB, and others implement certified
safety logic, safety I/O, diagnostics, and protected output behavior.
This document does not claim that industrial systems lack final
safety enforcement.
1.3. Why the Residual Gap Can Remain
The residual gap is not that industrial safety, authorization, or
attestation mechanisms are missing. It exists only when the complete
cyber-authority-to-physical-effect predicate is not enforced at the
first physical consequence boundary. The following distinctions
define that gap mechanism by mechanism.
1.3.1. Functional Safety and Safety Controllers
IEC 61508/61511, safety PLCs, SIS functions, safety I/O, and
certified controller logic can already provide authoritative safety
decisions and safe-state behavior. This document does not claim
otherwise. A residual cyber-authority question exists only where the
safety function does not already bind the exact upstream cyber-
originated command, its current authority, and its target identity to
the protected output. If the safety controller already does so, the
property is already satisfied.
1.3.2. IEC 62443 and Industrial Cybersecurity
IEC 62443 can correctly address industrial identification/
authentication, use control, system integrity, restricted data flow,
timely response, and availability. Those controls materially reduce
the attack surface. The narrower question is whether a deployment
also makes the exact pending physical act — including its current
parameters, actuator, authority state, and required machine/process
state — the load-bearing object of the final output decision. That
application predicate is not inferred merely from the existence of
strong component cybersecurity controls.
Das Expires 20 March 2027 [Page 9]
Internet-Draft Actuation-Bound Finality September 2026
1.3.3. OPC UA Safety and Safe Communication
OPC UA Safety already defines a safety communication layer for
SafetyData and is intended for safety devices [OPCUA-SAFETY]. The
draft therefore does not claim that safety-relevant communication is
unprotected. The residual question arises only where the receiving
safety application or output controller must also establish the exact
cyber-originated act and current cyber authority before permitting
the physical effect. If the receiving safety device already performs
that composition, no gap remains.
1.3.4. ACE and Constrained-Device Authorization
ACE-OAuth [RFC9200] can correctly authorize a client to a constrained
resource. If that Resource Server is itself the non-bypassable
actuator boundary and checks every required current process/safety
predicate, it may already satisfy this document's invariant. The
residual gap exists only when ACE authorization terminates upstream
while another controller, worker, fieldbus path, or device later
determines the physical effect.
1.3.5. RATS and Action Evidence
RATS [RFC9334] can correctly establish trusted platform or controller
state. That state is a valuable input to actuation authority, but it
is not automatically authorization for a particular motor torque,
valve transition, robotic motion, or other exact physical effect.
Current action-evidence work [SOKOLOV-AEP] can bind signed
application-layer action records to platform evidence and strengthen
provenance. Its scope remains distinct from the pre-effectuation
property here: a physical effect must stay technically unavailable
until the required actuation predicates hold.
1.3.6. Alternate Physical Effectuation Paths
Even perfect cyber authorization at one path is not consequence-wide
prevention if a maintenance port, engineering workstation, local/
manual mode, direct fieldbus write, direct I/O, recovery path, drive-
local interface, or firmware path can cause the same physical effect
without equivalent enforcement. Actuation finality therefore
composes with consequence-path completeness.
Das Expires 20 March 2027 [Page 10]
Internet-Draft Actuation-Bound Finality September 2026
1.4. What This Architecture Introduces
The proposed contribution is an authorization-to-physical-effect
continuity invariant. A cyber-originated Candidate Act remains in a
Non-Effective State until the protected Actuation Finality Boundary
verifies the exact pending command, target actuator, current
authority, required current machine/process/safety conditions,
freshness/replay state, and authorized path immediately before or
atomically with the physical output commitment.
* Bind authority to the exact command and security-relevant
parameters.
* Bind the command to the intended physical actuator or output
endpoint.
* Re-establish mutable machine, process, authority, and required
safety state at actuation time.
* Keep the command non-effective after upstream authorization.
* Preserve the authority of existing certified safety functions and
fail-safe behavior.
* Prevent replay, duplicate actuation, stale authorization, and
target substitution.
* Require every physical effectuation path to cross the AFB or
enforce an equivalent invariant.
* Couple successful verification to protected output commit.
2. Conventions and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals.
3. Direct Question: What Threat Does This Architecture Solve?
If a digital command is valid and authenticated, what prevents it
from producing a physical effect after its parameters, target
actuator, process state, safety state, execution authority, or
actuation path has changed?
Das Expires 20 March 2027 [Page 11]
Internet-Draft Actuation-Bound Finality September 2026
NOT ActuationApplicable(C, A, X_now)
==>
NOT PhysicalEffect(K, C)
The target is not to make ordinary control software into a safety
system. The target is to preserve cyber authority and exact-act
applicability until the existing or newly protected physical output
boundary.
4. Motivating Scenario: Authorized at X17, Actuated at X18
Consider a robot command approved while the cell is in automatic
mode, the target axis is known, a guard is closed, and the intended
operating envelope permits the motion. The command is queued.
Before the drive receives the final output request, a human enters
the cell or the mode changes. The earlier command can remain
authentic while current actuation applicability has changed.
Candidate C:
move axis-X, 10 mm, speed=5
|
| authorized under X17
v
NON-EFFECTIVE
|
state changes
v
X18:
guard open / mode changed / person present
|
v
+----------------------+
| ACTUATION FINALITY |
| BOUNDARY |
| evaluate CURRENT X18 |
+----------+-----------+
|
fail / pass
/ \
REJECT OUTPUT
Figure 2: Actuation after a safety or process-state change
5. Problem Space
Das Expires 20 March 2027 [Page 12]
Internet-Draft Actuation-Bound Finality September 2026
5.1. Digital Authorization Is Not Physical Authority
Authentication and authorization can establish who may request an
operation. Physical authority additionally depends on whether the
exact operation is still applicable to the current actuator and
current operating state.
5.2. Functional Safety Is Not Replaced
Functional-safety engineering covers hazard analysis, safety
functions, safe states, safety integrity, diagnostic design,
lifecycle, validation, and certification. This document does not
replace those disciplines and does not claim that an uncertified
controller becomes safe by implementing execution finality.
Existing safety result:
SAFE_TO_ACTUATE = FALSE
Execution-finality result:
MUST remain NON-EFFECTIVE
Execution finality MUST NOT transform
a safety DENY into ALLOW.
5.3. Secure Communication Is Not Final Actuation Authority
An authenticated, integrity-protected, or functionally safe
communication channel can deliver a command faithfully. The
receiving actuator boundary still needs to apply any deployment-
specific current authority and current actuation predicates that are
not already enforced by the safety application.
5.4. Attestation Is Not Physical-State Truth
RATS can establish technical claims about an Attester. It does not
make an unmeasured physical sensor reading true. A profile must
state which physical/process facts come from trusted sensing and
which facts are merely software/platform claims.
5.5. Audit Is Not Prevention
A signed action record generated after motion can provide useful
accountability. It does not establish that the physical effect was
technically conditional on a pre-actuation check.
Das Expires 20 March 2027 [Page 13]
Internet-Draft Actuation-Bound Finality September 2026
6. Threat Model and Assurance Scope
6.1. Adversary Capabilities
The adversary MAY control or influence the AI agent, HMI/client,
application process, enterprise gateway, ordinary operating system,
ordinary network path, non-safety PLC task, orchestration software,
queue/broker, maintenance software, command cache, command
sequencing, or other non-safety controller elements included in the
deployment threat model.
The adversary MAY attempt parameter substitution, target-actuator
substitution, replay, duplicate actuation, stale approval reuse, mode
confusion, command reordering, alternate- path actuation,
maintenance-interface abuse, direct device commands, or a race
against safety/process/revocation state.
6.2. Threat Severity and Applicability
Severity is consequence-dependent. The issue deserves high attention
for robotics, autonomous machinery, manufacturing cells, industrial
motion, valves and pumps, process control, chemical plants, power
systems, transport control, warehouse automation, critical
infrastructure, and other systems in which a digitally initiated
action can produce material physical consequences.
Not every actuator command is safety-critical. Profiles SHOULD
identify which physical consequences justify the stronger prevention
property and real-time enforcement cost.
6.3. Baseline Actuation-Finality Profile
The requester, remote agent, application, network, and ordinary
command path are untrusted. Existing required safety functions, the
AFB, the authoritative actuation- policy source, and protected
current-state sources used by the profile are trusted.
6.4. High-Assurance Actuation-Finality Profile
A higher-assurance profile MAY additionally distrust the host OS,
ordinary PLC task, orchestrator, gateway, maintenance workstation,
and software-only fieldbus mediator. In that case the AFB can reside
in a certified safety controller, protected drive/device controller,
separate safety island, secure I/O, hardware controller, TEE/security
processor where appropriate, or another independently enforceable
boundary.
Das Expires 20 March 2027 [Page 14]
Internet-Draft Actuation-Bound Finality September 2026
6.5. Trusted Roots and Limits
The base model does not claim to survive compromise of every safety/
finality root, mechanical failure outside modeled protections, sensor
falsification outside the trusted sensing model, physical wiring
bypass outside scope, incorrect hazard analysis, unsafe engineering
design, or an effect outside the declared actuation domain.
7. Design Goals and Non-Goals
The design goal is to preserve exact cyber authority and current
applicability until the first protected physical effect, while
composing with — and never weakening — existing safety functions.
This document does not define a safety lifecycle, SIL/PL calculation,
hazard analysis method, safety protocol, safety PLC certification
process, new OPC UA Safety transport, new ACE profile, new RATS
evidence format, or universal real-time control protocol.
A deployment MAY use an existing safety controller as the AFB. In
many industrial systems that is likely to be the preferred design
rather than adding a separate component.
8. Existing Mechanisms and the Proposed Delta
8.1. IEC 61508
IEC 61508 is foundational functional-safety engineering for E/E/PE
safety-related systems [IEC61508]. Functional safety itself is
therefore prior and mature engineering. The proposed delta is not a
new safety lifecycle; it is the continuity of a cyber-originated
Candidate Act to the protected physical effect.
8.2. IEC 61511
IEC 61511 specifies requirements for Safety Instrumented Systems in
the process industry so that they can achieve or maintain a safe
process state [IEC61511]. Where the SIS already receives the
relevant command, evaluates all required process and safety
conditions, and exclusively controls the defined output, it may
already serve as the AFB.
8.3. IEC 62443
IEC 62443-4-2 specifies component security requirements around
foundational categories including identification/authentication, use
control, system integrity, confidentiality, restricted data flow,
timely event response, and resource availability [IEC62443].
Das Expires 20 March 2027 [Page 15]
Internet-Draft Actuation-Bound Finality September 2026
The residual effectuation question exists only if those controls are
not already coupled to exact current physical-output eligibility at
the consequence boundary.
8.4. OPC UA Security
OPC UA provides industrial authentication, authorization, secure
communication, and information-model mechanisms. Secure delivery of
a command does not by itself define the application's final actuation
policy, although an OPC UA server/controller can implement that
policy directly.
8.5. OPC UA Safety
OPC UA Safety defines a safety communication layer for exchange of
SafetyData using OPC UA mechanisms and is intended for safety devices
[OPCUA-SAFETY]. The OPC Foundation explicitly notes that merely
implementing OPC UA Safety does not by itself make an arbitrary
device suitable for safety-related applications; required safety-
development processes and assessment still apply
[OPCUA-SAFETY-POLICY].
This draft does not claim that safety communication is missing. It
asks only whether an additional cyber-originated exact-act/current-
authority condition must be made load-bearing at the receiving
safety/output boundary.
8.6. ACE-OAuth
RFC 9200 defines the ACE framework for OAuth-based authentication and
authorization in constrained environments [RFC9200]. If the ACE
Resource Server is the true actuator boundary and it evaluates every
required current actuation condition, the core property can already
be satisfied.
8.7. RATS
RATS provides Evidence and Attestation Results about trusted platform
state [RFC9334]. An attested controller can therefore be a higher-
assurance input to actuation policy. Platform trust does not by
itself authorize a particular physical effect.
8.8. Application-Layer Action Evidence
[SOKOLOV-AEP] sketches composition of signed application-layer action
records with RATS platform evidence. It explicitly states that the
composition does not turn a self-reported action or outcome into
independently observed fact.
Das Expires 20 March 2027 [Page 16]
Internet-Draft Actuation-Bound Finality September 2026
This document does not compete on post-action evidence. It focuses
on pre-actuation non-completability: before the physical output
occurs, the required exact-act and current- context predicates must
be load-bearing.
8.9. Safety PLCs and Safety Controllers
Existing certified safety controllers may already be the best AFB.
Rockwell GuardLogix, Schneider Modicon M580 Safety, ABB AC500-S,
Siemens fail-safe S7/Safety Integrated, and comparable systems
demonstrate mature safety logic and protected safety-output
architectures [ROCKWELL-GUARDLOGIX] [SCHNEIDER-M580] [ABB-AC500S]
[SIEMENS-SAFETY].
No deficiency is asserted. A deployment that binds the cyber-
originated exact act and authority into an existing certified safety
output decision may already satisfy the proposal without another
hardware layer.
8.10. Comparison Summary
+============+=======================+============================+
| Mechanism | Strong existing | Residual question only |
| | property | where not already covered |
+============+=======================+============================+
| IEC 61508 | Functional-safety | Is exact cyber-command |
| | lifecycle and safety- | authority preserved to |
| | related systems | physical output? |
+------------+-----------------------+----------------------------+
| IEC 61511 | Achieve or maintain | Does the SIS already |
| / SIS | safe process state | mediate this exact |
| | | actuation? If yes, |
| | | property may be satisfied. |
+------------+-----------------------+----------------------------+
| IEC 62443 | IACS security | Is exact current actuation |
| | controls and | eligibility enforced at |
| | component | the physical boundary? |
| | requirements | |
+------------+-----------------------+----------------------------+
| OPC UA | Functional-safety | Does the receiving safety |
| Safety | communication | application already |
| | | enforce exact cyber |
| | | authority/current context? |
+------------+-----------------------+----------------------------+
| ACE | Constrained-device | Is the Resource Server the |
| | authorization | true non-bypassable |
| | | actuator boundary? |
+------------+-----------------------+----------------------------+
Das Expires 20 March 2027 [Page 17]
Internet-Draft Actuation-Bound Finality September 2026
| RATS | Trusted platform | Is trusted state made |
| | evidence | load-bearing for the exact |
| | | physical act? |
+------------+-----------------------+----------------------------+
| Action | Signed action record | Is effect prevented before |
| evidence | plus platform | actuation rather than |
| | evidence | merely evidenced |
| | | afterward? |
+------------+-----------------------+----------------------------+
| Safety | Certified safety | Often may already be the |
| PLC/ | logic and safety- | correct AFB. |
| controller | output control | |
+------------+-----------------------+----------------------------+
Table 1: Existing mechanisms and residual actuation question
8.11. What Is New in This Document
The proposed delta is deliberately narrower than functional safety or
industrial cybersecurity. This document does not claim invention of
safety interlocks, SIS, safety PLCs, fail-safe behavior, safe
communication, command authentication, ACE authorization, RATS
attestation, or action evidence. It proposes a composition rule over
those mechanisms when a cyber-originated command must remain bound to
the exact physical consequence.
Existing mechanisms may correctly establish:
WHO sent the command
WHETHER the client may access the resource
WHETHER the platform is trusted
WHETHER safety communication was valid
WHETHER existing safety logic permits output
Actuation finality asks the joint effectuation-time question:
Is THIS exact command,
for THIS actuator,
under CURRENT cyber authority,
CURRENT required process/machine state,
CURRENT required safety predicates,
on THIS non-bypassable output path,
still eligible to become physical NOW?
Das Expires 20 March 2027 [Page 18]
Internet-Draft Actuation-Bound Finality September 2026
The Actuation Finality Boundary makes that joint predicate load-
bearing immediately before or atomically with the protected output
commit. It is a role, not necessarily a new component. An existing
certified safety controller can already be the AFB when it enforces
the complete required predicate. Where that is already true, this
document introduces no additional security layer for that deployment.
9. Prevention and Mitigation Property
9.1. Prevention Profile
Prevention of the governed stale/substituted/bypassed-command class
can be claimed only when the exact command and actuator are bound,
current authority is valid, required existing safety and process
predicates are current, freshness/replay rules apply, the AFB
controls the first physical effect, alternate actuation paths cannot
bypass equivalent checks, and verification-to-output ordering is
protected.
exact command
+
target actuator
+
current cyber authority
+
current required machine/process state
+
current required safety predicates
+
freshness / replay / sequencing
+
non-bypassable actuation path
+
protected check-to-output ordering
=
PREVENTION of the governed command-to-actuation gap
9.2. Mitigation, Detection, or Audit Profile
Upstream gateways, network IDS, command logs, stale safety snapshots,
advisory actuator labels, post-motion receipts, or software checks
that coexist with ungoverned direct I/O can reduce risk or improve
accountability but do not establish the same prevention guarantee.
Das Expires 20 March 2027 [Page 19]
Internet-Draft Actuation-Bound Finality September 2026
9.3. Unknown Safety or Process State
A prevention profile SHOULD define explicit UNKNOWN states. Where a
required current safety/process predicate cannot be established, the
system MUST NOT silently treat UNKNOWN as ALLOW. Existing safety
logic can require a safe state or a system-specific fail-safe
response.
10. Terminology
*Candidate Act:* A proposed cyber-originated command capable of
producing a physical consequence but not yet permitted to make that
consequence effective.
*Protected Physical Consequence:* The first physical, mechanical,
electrical, thermal, fluid, motion, process, or other material effect
governed by the deployment.
*Actuation Finality Boundary (AFB):* The protected functional
boundary at which a Candidate Act first acquires the technical
ability to cause the protected physical effect.
*Actuation Context:* The current set of actuator, machine, process,
safety, authority, replay, and path facts required by the deployment.
*Actuation Generation:* A protected epoch/version identifying the
current load-bearing actuation-policy/context generation.
*Non-Effective State:* The state in which the Candidate Act cannot
yet produce the protected physical consequence.
*Protected Output Commit:* The protected transition that makes the
physical output effective, such as enabling a drive command,
energizing an output, opening a valve, or issuing another
consequence-bearing hardware action.
*Existing Safety Predicate:* A required decision produced by or
derived from the deployment's functional-safety system. Execution
finality cannot weaken it.
11. Actuation Context Model
Not every deployment requires every context dimension. A
representative context is:
Das Expires 20 March 2027 [Page 20]
Internet-Draft Actuation-Bound Finality September 2026
X_now = (
actuator_identity,
controller_identity,
machine_mode,
process_state,
safety_state,
interlock_state,
operating_envelope,
tool_or_payload_state,
human_presence_state_if_required,
authority_state,
revocation_state,
path_identity,
generation
)
Safety/process fields must come from sources whose trust and
freshness are adequate for the intended profile. A software field
called "guard_closed" is not automatically equivalent to a trusted
safety input.
11.1. Typed Actuation-State Vector
Actuation context is modeled as a typed state vector rather than a
single "safe/unsafe" flag. A deployment selects only the dimensions
that are load-bearing for the Candidate Act.
Das Expires 20 March 2027 [Page 21]
Internet-Draft Actuation-Bound Finality September 2026
X_now(C,t) = {
actuator_identity,
controller_identity,
machine_mode,
process_state,
safety_state,
interlock_state,
operating_envelope,
tool_or_payload_state,
human_presence_state_if_required,
energy_state,
authority_state,
revocation_state,
sequence_state,
path_identity,
safety_generation,
process_generation,
authority_generation,
topology_generation
}
Each dimension d has:
Value_d
Source_d
Freshness_d
Assurance_d
Generation_d
Scope_d
11.2. State Semantics
State_d ∈ {
KNOWN_ALLOWED,
KNOWN_DENIED,
UNKNOWN,
STALE,
CONFLICTING,
UNAVAILABLE
}
Strict profile:
UNKNOWN
OR STALE
OR CONFLICTING
OR UNAVAILABLE
MUST NOT silently become ALLOW.
Das Expires 20 March 2027 [Page 22]
Internet-Draft Actuation-Bound Finality September 2026
11.3. Sensor and State-Source Trust
A state value is useful only to the extent that the deployment trusts
the source that produced it. Authentic provenance does not prove
physical correctness, and a safety-rated input need not have the same
semantics as an ordinary software variable.
StateEvidenceValid(E_d, d, C, t) :=
IntegrityValid(E_d)
AND SourceTrustedForDimension(E_d.source, d)
AND ScopeApplies(E_d, C)
AND FreshnessValid(E_d,t)
AND GenerationCurrent(E_d)
AND AssuranceSufficient(E_d,d)
AND NotSuperseded(E_d)
11.4. Cross-State Consistency
ContextConsistent(C, X_now, E_set) :=
SameActuatorContext(E_set,C)
AND SameControllerContext(E_set,C)
AND SameMachineInstance(E_set,C)
AND CompatibleStateGenerations(E_set)
AND NoContradictorySafetyClaims(E_set)
AND NoContradictoryProcessClaims(E_set)
AND NoCrossTenantOrCrossCellMixing(E_set)
This prevents combining a valid safety-state assertion for one robot
cell with a valid process-state assertion for another cell and
accidentally treating the bundle as current authority for C.
11.5. Effect-Type Semantics
Not every physical effect is a one-shot transition. The policy can
distinguish authority to initiate, continue, stop, or release a
physical effect.
Das Expires 20 March 2027 [Page 23]
Internet-Draft Actuation-Bound Finality September 2026
EffectAuthority(C) may include:
INITIATE
CONTINUE
MODIFY
STOP
RELEASE
RESET
UNLATCH
Examples:
open valve = INITIATE
keep motor enabled = CONTINUE
change torque = MODIFY
emergency stop = STOP
release brake = RELEASE
reset trip = RESET
12. Formal Mathematical Model
Let C be the concrete Candidate Act, K the Protected Physical
Consequence, A the target actuator or actuation endpoint, S the AFB,
X_now the current actuation context, P the applicable actuation
policy, and g the current actuation generation.
ActuationContextValid(C, A, X_now, P, g) :=
ExactActBinding(C)
AND TargetActuatorMatches(C, A)
AND AuthorityApplicable(C, X_now.authority_state)
AND RevocationAllows(C, X_now.revocation_state)
AND MachineModeAllows(C, X_now.machine_mode)
AND ProcessStateAllows(C, X_now.process_state)
AND RequiredSafetyPredicatesTrue(
C, X_now.safety_state, X_now.interlock_state)
AND OperatingEnvelopeAllows(C, X_now.operating_envelope)
AND FreshnessAndReplayValid(C)
AND PathAuthorized(C, X_now.path_identity)
AND GenerationCurrent(g, X_now.generation)
The actuation-finality safety invariant is:
PhysicalEffect(K, C)
==>
ActuationContextValid(C, A, X_now, P, g)
AND ProtectedCommitAtAFB(C, A)
For the strict prevention profile:
Das Expires 20 March 2027 [Page 24]
Internet-Draft Actuation-Bound Finality September 2026
NOT ActuationContextValid(C, A, X_now, P, g)
==>
NOT PhysicalEffect(K, C)
12.1. Safety-Dominance Rule
Where an existing safety function participates in actuation, its
negative decision is authoritative:
SafetyDecision(C, X_now) = DENY
==>
NOT PhysicalEffect(K, C)
regardless of:
cyber authorization,
AI recommendation,
operator request,
token validity,
or execution-finality approval.
12.2. Bounded Prevention Argument
Assume: (1) the AFB exclusively controls every modeled path capable
of producing K or an equivalent invariant exists on each such path;
(2) the exact pending command and actuator identity are observable at
the AFB; (3) every required current safety/process/authority
predicate is available from an adequately trusted source; (4) safety
DENY remains authoritative; and (5) verification-to-output ordering
is atomic or equivalently protected. Under those assumptions, an
attacker cannot produce K using a stale, substituted, replayed,
wrong-target, or context-inapplicable Candidate Act without violating
at least one explicit assumption.
The argument does not prove that the hazard analysis, sensor model,
safety application, mechanical system, or certified controller design
is correct.
12.3. Canonical Physical Candidate Act
Das Expires 20 March 2027 [Page 25]
Internet-Draft Actuation-Bound Finality September 2026
C := CanonicalAct(
actuator_id,
operation,
parameters,
effect_type,
destination_or_axis_if_required,
purpose_if_required,
sequence,
nonce,
authority_generation,
constraints)
D_C = H(Encode(C))
Canonicalization MUST cover every field whose change can alter the
physical consequence or the authorization/safety meaning of the act.
12.4. Trusted State-Evidence Predicate
TrustedState(C, X_now, E_set, t) :=
ContextConsistent(C,X_now,E_set)
AND FOR EACH required state dimension d:
EXISTS e_d ∈ E_set:
StateEvidenceValid(e_d,d,C,t)
AND State_d(X_now) ∉ {
UNKNOWN,
STALE,
CONFLICTING,
UNAVAILABLE
}
12.5. Current Cyber-Authority Predicate
CyberAuthorityValid(C,X_now) :=
AuthorityPresent(C)
AND ExactActBindingValid(C)
AND AuthorityGenerationCurrent(C)
AND RevocationAllows(C,X_now.revocation_state)
AND UseConstraintsSatisfied(C,X_now)
AND FreshnessAndReplayValid(C)
AND SequenceValid(C,X_now.sequence_state)
12.6. Existing Safety Predicate
Das Expires 20 March 2027 [Page 26]
Internet-Draft Actuation-Bound Finality September 2026
SafetyAllows(C,X_now) :=
RequiredSafetyFunctionsAvailable(C)
AND RequiredInterlocksSatisfied(C,X_now.interlock_state)
AND SafetyStateAllows(C,X_now.safety_state)
AND MachineModeAllows(C,X_now.machine_mode)
AND ProcessStateAllows(C,X_now.process_state)
AND OperatingEnvelopeAllows(C,X_now.operating_envelope)
This predicate is subordinate to the existing safety application.
Execution finality does not redefine what a safety function considers
safe.
12.7. Actuator and Output Identity
TargetValid(C,A,S) :=
C.actuator_id == ProtectedIdentity(A)
AND SinkControls(A,S)
AND OutputChannelBoundTo(A,S)
AND NoAliasOrRemapChangesTarget(C,A,S)
12.8. Effect-Lifecycle Authority
LifecycleAuthorityValid(C, X_now) :=
CASE C.effect_type OF
INITIATE:
CyberAuthorityValid(C,X_now)
AND SafetyAllows(C,X_now)
CONTINUE:
ContinueAuthorityCurrent(C,X_now)
AND SafetyAllowsContinuation(C,X_now)
MODIFY:
ModificationWithinAuthorizedEnvelope(C,X_now)
STOP:
StopAuthorityPolicy(C,X_now)
# Safety/emergency stop MAY dominate cyber policy.
RELEASE:
ReleaseAuthorityCurrent(C,X_now)
AND ReleaseSafetyPredicatesTrue(C,X_now)
RESET:
ResetAuthorityCurrent(C,X_now)
AND ResetSafetyPredicatesTrue(C,X_now)
Das Expires 20 March 2027 [Page 27]
Internet-Draft Actuation-Bound Finality September 2026
12.9. Actuation Generation Vector
G_now = (
G_safety,
G_process,
G_machine_mode,
G_authority,
G_revocation,
G_sequence,
G_actuator_mapping,
G_topology
)
GenerationVectorCurrent(G_eval,G_now,C) :=
FOR EACH generation component g_d
load-bearing for C:
G_eval[d] == G_now[d]
OR
AuthoritativeCompatibilityProof(
G_eval[d], G_now[d], C, d)
A vector avoids invalidating unrelated state while still preventing a
relevant safety, process, authority, actuator-mapping, or topology
change from silently preserving stale authority.
12.10. State-Transition Applicability
TransitionAffects(C, X_old, X_new) :=
EXISTS required dimension d:
NOT EquivalentForActuation(
C,
X_old[d],
X_new[d])
If TransitionAffects(...) = TRUE:
prior actuation approval MUST NOT automatically survive.
12.11. Check-to-Output Serialization
Let ≺_A denote the authoritative ordering between safety/authority
state changes and protected physical output commit.
Das Expires 20 March 2027 [Page 28]
Internet-Draft Actuation-Bound Finality September 2026
VerifyActuation(C,G17)
|
v
Change(G17 -> G18)
|
v
CommitPhysical(C)
If:
VerifyActuation(C,G17)
≺_A
Change(G17->G18)
≺_A
CommitPhysical(C)
then:
CommitPhysical(C) MUST NOT proceed
unless the transition is authoritatively proven irrelevant.
12.12. Replay and Sequence Formalism
ReplaySafe(C,X_now) :=
NonceFresh(C.nonce)
AND SequenceWithinWindow(C.sequence,X_now)
AND NOT AlreadyConsumed(C.nonce,C.sequence)
AND (
IdempotentByPolicy(C)
OR SingleUse(C)
OR TransactionScopedReuse(C)
)
12.13. Actuation-Path Completeness
ActuationPathSafe(K,D,F) :=
FOR ALL technically viable paths p
capable of producing K:
p intersects protected AFB set F
OR
p enforces an equivalent finality + safety invariant
If EXISTS bypass path p:
strict consequence-wide prevention fails.
12.14. Expanded Actuation Validity
Das Expires 20 March 2027 [Page 29]
Internet-Draft Actuation-Bound Finality September 2026
ActuationValid(C,A,S,X_now,E_set,G_now) :=
TrustedState(C,X_now,E_set,t_now)
AND CyberAuthorityValid(C,X_now)
AND TargetValid(C,A,S)
AND SafetyAllows(C,X_now)
AND LifecycleAuthorityValid(C,X_now)
AND GenerationVectorCurrent(
C.bound_generation_vector,
G_now,
C)
AND ReplaySafe(C,X_now)
AND ActuationPathSafe(
C.protected_consequence,
C.effectuation_domain,
C.afb_set)
12.15. Expanded Strict Prevention Invariant
PhysicalEffect(K,C)
=>
ActuationValid(C,A,S,X_now,E_set,G_now)
AND ProtectedCommitAtAFB(C,A,S)
Strict prevention:
NOT ActuationValid(...)
=>
NOT PhysicalEffect(K,C)
Safety dominance:
SafetyDecision(C,X_now) = DENY
=>
NOT PhysicalEffect(K,C)
Emergency-stop dominance:
EmergencyStopActive(X_now) = TRUE
=>
NO cyber authorization may force protected motion.
12.16. Continuing and Latched Effects
A physical effect can remain active after its initiating command has
completed. The security property therefore distinguishes initiation
from continued authorization.
Das Expires 20 March 2027 [Page 30]
Internet-Draft Actuation-Bound Finality September 2026
InitiateAllowed(C,t0)
does NOT imply
ContinueAllowed(C,t1)
For latched/continuing effects:
ContinueEffect(K,C,t)
=>
ContinueAuthorityCurrent(C,t)
AND RequiredSafetyPredicatesCurrent(C,t)
AND ContinuationPathStillProtected(C,t)
12.17. Expanded Bounded Prevention Proof
Assume: (1) the canonical Candidate Act fully captures every
security-relevant actuation field; (2) the AFB observes the actual
pending physical output and controls the first protected physical
effect; (3) every required safety/process/state dimension comes from
an adequately trusted and current source; (4) the existing safety
system remains authoritative; (5) every load-bearing state change
advances or validates the actuation generation vector; (6) check-to-
output ordering is protected; (7) replay/sequence state cannot be
rolled back; and (8) every path capable of producing the protected
consequence crosses the AFB or an equivalent invariant.
Suppose the protected physical effect occurs while the command is
substituted, the actuator is wrong, current authority is invalid, a
required safety/process predicate is false or unknown, the generation
vector is stale, replay protection fails, or the path bypasses final
enforcement. Then ActuationValid is false. The strict prevention
invariant prohibits PhysicalEffect, producing a contradiction unless
at least one premise — act representation, sensing/state trust,
safety authority, generation handling, serialization, replay
protection, or path completeness — was violated. The proof is
bounded; it does not prove that hazard analysis, sensors, mechanics,
or the safety application itself are correct.
13. State, Safety, and Authority Continuity
A command approved under one state is not automatically applicable
after a load-bearing state change.
Das Expires 20 March 2027 [Page 31]
Internet-Draft Actuation-Bound Finality September 2026
Generation X17:
mode=AUTO
guard=CLOSED
actuator=A
safety=PASS
authority=VALID
|
+---- C authorized
Guard / mode / process / authority / mapping changes
|
v
Generation X18:
one or more load-bearing predicates differ
Result:
Valid(C, X17) does NOT imply Valid(C, X18)
Figure 3: Actuation generation after a state change
A relevant change SHOULD advance or invalidate actuation generation,
invalidate pending authority, require re-evaluation, or provide an
authoritative proof that the change is irrelevant to C.
Das Expires 20 March 2027 [Page 32]
Internet-Draft Actuation-Bound Finality September 2026
At authorization:
G_eval = {
safety: 17,
process: 42,
mode: 5,
authority: 11,
revocation: 8,
sequence: 91,
actuator_map: 7,
topology: 30
}
Before physical commit:
G_now = {
safety: 18, <-- changed
process: 43, <-- changed
mode: 5,
authority: 11,
revocation: 8,
sequence: 91,
actuator_map: 7,
topology: 31 <-- changed
}
Result:
revalidate affected state and path coverage.
Figure 4: Multi-dimensional actuation generation vector
AFB / Finalizer Safety / Process State
| |
| verify under G17 |
| |
| change -> G18 |
| |
| protected output commit |
| assert G == G17 ----------- FAIL |
| |
+---- re-sample / revalidate ----------+
Figure 5: Check-to-output race
14. Exact Command and Actuator Binding
Das Expires 20 March 2027 [Page 33]
Internet-Draft Actuation-Bound Finality September 2026
Approved Candidate C1:
actuator = Robot-7
axis = X
distance = 10 mm
speed = 5
Observed pending output C2:
actuator = Robot-7
axis = X
distance = 100 mm
speed = 50
H(C1) != H(C2)
|
v
REJECT
Figure 6: Command substitution after approval
The act representation must cover every parameter whose change can
affect authority or the physical consequence. Target-actuator
identity must be load-bearing where redirection to another device
would change the safety/security meaning.
Authorization time:
logical target = Valve-A
physical mapping = Output-17
Before commit:
logical target = Valve-A
mapping changed = Output-22
If Output-22 controls a different physical device:
TargetValid(C,A,S) = FALSE
=> REJECT / REVALIDATE
Figure 7: Actuator remapping after authorization
Das Expires 20 March 2027 [Page 34]
Internet-Draft Actuation-Bound Finality September 2026
15. Freshness, Replay, and Sequence Control
Physical effects are often non-idempotent. Replaying an otherwise
valid command can repeat motion, dispense material twice, reopen a
valve, or duplicate another physical action. Profiles therefore need
explicit replay and sequencing semantics.
Candidate authority can include:
act_digest
actuator_id
nonce / transaction_id
sequence
validity bounds
authority_generation
consume_once state
A valid signature alone does not imply reusability.
Authorized sequence:
... 90, 91, 92, 93 ...
Pending C:
sequence = 92
nonce = N92
Cases:
first valid use of 92 -> eligible
replay of N92 -> reject
sequence 89 after window -> reject
duplicate retry after K -> reject unless idempotent policy
93 before required 92 -> reject if ordering is load-bearing
Figure 8: Replay and sequence window
16. Actuation Finality Boundary
The AFB is a role, not a new mandatory device. Possible realizations
include an existing safety PLC, safety controller, protected drive,
robot controller, SIS function, protected device firmware, secure I/O
stage, hardware interlock controller, or a distributed set of
equivalent output mediators.
Das Expires 20 March 2027 [Page 35]
Internet-Draft Actuation-Bound Finality September 2026
AI / HMI / Cloud
|
v
+------------------+
| Authz Gateway | <-- useful upstream authorization
+--------+---------+
|
v
PLC
|
v
Fieldbus / I/O
|
v
+------------------+
| AFB / Safety or |
| Protected Output | <-- first boundary that can make K physical
+--------+---------+
|
v
Drive / Valve / Motor / Robot
Figure 9: Upstream authorization versus true physical finality
+----------------+
| INITIATE |
+-------+--------+
|
v
effect active
|
+-------------+-------------+
| | |
v v v
CONTINUE MODIFY STOP
| | |
+------+------+ |
| |
v v
effect active safe/stopped
|
v
RELEASE
|
v
effect ends
Each transition can have different authority and safety predicates.
Das Expires 20 March 2027 [Page 36]
Internet-Draft Actuation-Bound Finality September 2026
Figure 10: Initiate, continue, modify, stop, and release authority
t0:
authorize START_MOTOR
|
v
motor enabled
t1:
start token expires / authority revoked
|
v
Question:
may motor CONTINUE running?
Initiation authority alone is insufficient if policy
requires continuing authorization.
Figure 11: Latched physical effect requires continuation semantics
17. State Machine
Das Expires 20 March 2027 [Page 37]
Internet-Draft Actuation-Bound Finality September 2026
+----------------+
| CANDIDATE ACT |
+-------+--------+
|
v
+---------------------+
| BIND EXACT COMMAND |
| + TARGET ACTUATOR |
+---------+-----------+
|
v
+---------------------+
| NON-EFFECTIVE |
| pending actuation |
+---------+-----------+
|
v
+---------------------+
| OBSERVE CURRENT |
| ACTUATION CONTEXT |
+---------+-----------+
|
v
+---------------------+
| AFB FINAL CHECK |
| cyber authority |
| safety predicates |
| process / mode |
| replay / path |
+----+-----------+----+
| |
fail pass
| |
v v
SAFE / PROTECTED
DENIED OUTPUT COMMIT
|
v
PHYSICAL EFFECT
Figure 12: Actuation-finality state machine
18. Solution Architecture
Das Expires 20 March 2027 [Page 38]
Internet-Draft Actuation-Bound Finality September 2026
18.1. Prepare Candidate Act
The cyber-originating component constructs a Candidate Act containing
the target actuator, operation, security-relevant parameters, purpose
where applicable, freshness state, and applicable authority-
generation context.
18.2. Remain Non-Effective
Upstream authorization does not itself energize the actuator. The
Candidate Act remains unable to create K until it reaches a valid
AFB.
18.3. Observe Current Actuation Context
The AFB reads or receives current required machine/process/safety/
authority inputs from sources appropriate to the assurance profile.
18.4. Verify Exact Act and Current Applicability
The AFB reconstructs or observes the pending physical command,
compares it with the Candidate Act, evaluates current authority,
required safety/process state, freshness, replay, target identity,
and path applicability.
18.5. Protected Output Commit
Successful verification is coupled to the hardware or controller
transition that enables the physical output. If a required safety
function returns DENY, the output remains in or transitions to the
deployment-defined safe state.
18.6. Architecture Diagram
Das Expires 20 March 2027 [Page 39]
Internet-Draft Actuation-Bound Finality September 2026
Cyber / AI / HMI / Control Application
|
v
+----------------+
| Candidate Act |
| exact command |
| actuator ID |
| authority |
+-------+--------+
|
v
NON-EFFECTIVE
|
v
+----------------------------------+
| ACTUATION FINALITY BOUNDARY |
| |
| observe pending output |
| exact command / actuator |
| current cyber authority |
| current process / machine state |
| existing required safety logic |
| freshness / replay / sequence |
| path authorization |
+---------------+------------------+
|
pass | fail
+-------+---------+
| |
v v
PROTECTED OUTPUT SAFE / DENY
|
v
PHYSICAL EFFECT K
Figure 13: Actuation-bound execution-finality architecture
19. Illustrative Pseudocode
The following pseudocode is non-normative. It separates act
canonicalization, authority binding, state acquisition, trust/
consistency checks, safety composition, lifecycle authority, replay/
sequence enforcement, target validation, topology/path coverage,
generation transitions, real-time finalization, continuing-effect
supervision, emergency-stop handling, and crash-safe recovery.
19.1. Canonicalize the Physical Candidate Act
Das Expires 20 March 2027 [Page 40]
Internet-Draft Actuation-Bound Finality September 2026
function canonicalize_candidate(command):
C = CanonicalAct(
actuator_id = protected_target_identifier(command),
operation = command.operation,
parameters = canonical_security_parameters(command),
effect_type = classify_effect_type(command),
destination_or_axis =
command.destination_or_axis_if_required,
purpose = command.purpose_if_required,
sequence = command.sequence,
nonce = command.nonce,
constraints = command.constraints)
C.effect_digest = H(encode(C))
return C
19.2. Bind Cyber Authority to the Exact Act
function bind_cyber_authority(candidate):
C = canonicalize_candidate(candidate)
decision = current_authorization_policy(C)
if decision != ALLOW:
reject("cyber authorization denied")
return protect_execution_authority(
act_digest = C.effect_digest,
actuator_id = C.actuator_id,
effect_type = C.effect_type,
generation_vector =
current_actuation_generation_vector(C),
sequence = C.sequence,
nonce = C.nonce,
constraints = decision.constraints,
expiry = decision.expiry)
19.3. Acquire Current Actuation State
Das Expires 20 March 2027 [Page 41]
Internet-Draft Actuation-Bound Finality September 2026
function acquire_current_state(candidate, actuator):
X = {}
X.actuator_identity =
protected_actuator_identity(actuator)
X.controller_identity =
protected_controller_identity()
X.machine_mode =
read_authoritative_machine_mode()
X.process_state =
read_required_process_state(candidate)
X.safety_state =
read_required_safety_state(candidate)
X.interlock_state =
read_required_interlocks(candidate)
X.operating_envelope =
current_operating_envelope(candidate)
X.human_presence_state =
read_if_required(candidate, "human_presence")
X.energy_state =
read_if_required(candidate, "energy_state")
X.revocation_state =
current_revocation_state(candidate)
X.sequence_state =
current_sequence_state(candidate.actuator_id)
X.path_identity =
current_actuation_path()
X.generation_vector =
current_actuation_generation_vector(candidate)
return X
19.4. Verify Trusted State Sources
Das Expires 20 March 2027 [Page 42]
Internet-Draft Actuation-Bound Finality September 2026
function verify_state_sources(candidate, state):
for d in required_state_dimensions(candidate):
evidence = state.evidence[d]
if evidence == NONE:
return UNKNOWN(d)
if !verify_state_evidence_integrity(evidence):
reject("invalid state evidence", d)
if !source_trusted_for_dimension(
evidence.source, d):
reject("untrusted state source", d)
if !fresh_enough(
evidence,
freshness_bound_for(candidate,d)):
return STALE(d)
if !assurance_sufficient(
evidence.assurance,
required_assurance(candidate,d)):
reject("state assurance too weak", d)
if !cross_state_context_consistent(
candidate, state):
reject("inconsistent state bundle")
return VALID
19.5. Verify Actuator and Output Identity
Das Expires 20 March 2027 [Page 43]
Internet-Draft Actuation-Bound Finality September 2026
function verify_target(candidate, actuator, sink):
if protected_actuator_identity(actuator)
!= candidate.actuator_id:
reject("wrong actuator")
if !sink_controls_actuator(sink, actuator):
reject("sink does not control target")
if actuator_mapping_generation(candidate.actuator_id)
!= candidate.bound_actuator_mapping_generation:
return REVALIDATE("actuator mapping changed")
if !output_channel_bound_to_actuator(
sink, actuator):
reject("output path not bound to target")
return VALID
19.6. Compose with Existing Safety Functions
function evaluate_existing_safety(candidate, state):
result = existing_safety_system.evaluate(
candidate,
safety_inputs = state.safety_state,
interlocks = state.interlock_state,
process_state = state.process_state,
machine_mode = state.machine_mode,
operating_envelope = state.operating_envelope)
if result == DENY:
return DENY
if result in {UNKNOWN, UNAVAILABLE, STALE}:
return SAFE_RESPONSE_REQUIRED
if result != SAFE_TO_ACTUATE:
return DENY
return SAFE_TO_ACTUATE
19.7. Evaluate Effect-Lifecycle Authority
Das Expires 20 March 2027 [Page 44]
Internet-Draft Actuation-Bound Finality September 2026
function evaluate_lifecycle_authority(candidate, state):
switch candidate.effect_type:
case INITIATE:
return initiate_authority_current(candidate, state)
case CONTINUE:
return continue_authority_current(candidate, state)
case MODIFY:
return modification_within_authorized_envelope(
candidate, state)
case STOP:
return stop_policy(candidate, state)
case RELEASE:
return release_authority_current(candidate, state)
case RESET:
return reset_authority_current(candidate, state)
default:
reject("undefined effect lifecycle semantics")
19.8. Verify Replay and Sequence State
function verify_replay_and_sequence(candidate, state):
if nonce_already_consumed(candidate.nonce):
reject("replayed command")
if !sequence_within_allowed_window(
candidate.sequence,
state.sequence_state):
reject("sequence outside allowed window")
if ordering_is_load_bearing(candidate):
if !required_predecessors_complete(candidate):
reject("command ordering violation")
if !candidate_is_idempotent(candidate)
and duplicate_effect_detected(candidate):
reject("duplicate physical effect")
return VALID
19.9. Verify the Complete Actuation Predicate
Das Expires 20 March 2027 [Page 45]
Internet-Draft Actuation-Bound Finality September 2026
function verify_actuation(candidate, actuator, sink, state):
verify_target(candidate, actuator, sink)
verify_state_sources(candidate, state)
if H(canonical_pending_physical_output(
actuator,
observed_pending_output()))
!= candidate.effect_digest:
reject("exact physical output mismatch")
if !cyber_authority_current(candidate, state):
reject("cyber authority invalid or stale")
if !revocation_allows(
candidate, state.revocation_state):
reject("authority revoked")
if evaluate_existing_safety(
candidate, state) != SAFE_TO_ACTUATE:
reject_or_safe_state("safety did not allow actuation")
if !evaluate_lifecycle_authority(
candidate, state):
reject("effect lifecycle authority invalid")
verify_replay_and_sequence(candidate, state)
if !actuation_path_authorized(
candidate, state.path_identity):
reject("unmediated actuation path")
return VALID
19.10. Handle Safety, Process, Authority, or Topology Change
Das Expires 20 March 2027 [Page 46]
Internet-Draft Actuation-Bound Finality September 2026
function on_actuation_relevant_change(change):
affected = actuation_dimensions_affected_by(change)
for d in affected:
advance_protected_generation(d)
pending = pending_candidates_depending_on(affected)
for candidate in pending:
mark_revalidation_required(candidate)
if change_definitively_invalidates(candidate):
mark_non_effective(candidate)
if change_requires_safe_response(change):
request_existing_safety_system_safe_response()
19.11. Validate Whether a State Transition Is Irrelevant
function transition_irrelevant_to_candidate(
candidate, old_state, new_state):
for d in required_state_dimensions(candidate):
if !actuation_equivalence_rule(candidate,d)(
old_state[d], new_state[d]):
return FALSE
if new_state[d].assurance
< required_assurance(candidate,d):
return FALSE
if !fresh_enough(
new_state[d],
freshness_bound_for(candidate,d)):
return FALSE
return TRUE
19.12. Verify Consequence-Wide Actuation-Path Coverage
Das Expires 20 March 2027 [Page 47]
Internet-Draft Actuation-Bound Finality September 2026
function verify_actuation_path_coverage(
consequence,
path_inventory,
afb_inventory):
for path in paths_capable_of(
consequence, path_inventory):
intersections =
path.intersection(afb_inventory)
if intersections is not EMPTY:
if any_valid_afb(intersections):
continue
if path.enforces_equivalent_finality_and_safety:
continue
return CoverageFailure(
reason="actuation bypass path",
witness=path)
return COVERAGE_VALID
19.13. Protected Real-Time Finalization
function finalize_actuation(candidate, actuator):
sink = current_actuation_finality_boundary()
begin_protected_actuation_section()
state = acquire_current_state(candidate, actuator)
if verify_actuation(
candidate,
actuator,
sink,
state) != VALID:
remain_non_effective_or_enter_safe_state()
return REJECTED
observed_vector = state.generation_vector
atomic_or_safety_equivalent {
current_vector =
current_actuation_generation_vector(candidate)
assert generation_vector_matches_or_is_compatible(
Das Expires 20 March 2027 [Page 48]
Internet-Draft Actuation-Bound Finality September 2026
observed_vector,
current_vector,
candidate)
current_state =
acquire_minimum_hot_path_state(
candidate, actuator)
assert evaluate_existing_safety(
candidate,
current_state) == SAFE_TO_ACTUATE
assert exact_pending_output_still_matches(
candidate, actuator)
assert actuation_path_still_authorized(
candidate,
current_state.path_identity)
protected_consume_once(
candidate.nonce,
candidate.sequence)
commit_physical_output(
actuator,
candidate.operation,
candidate.parameters)
}
return EFFECT_COMMITTED
19.14. Supervise Continuing or Latched Effects
Das Expires 20 March 2027 [Page 49]
Internet-Draft Actuation-Bound Finality September 2026
function supervise_continuing_effect(effect_handle):
while effect_is_active(effect_handle):
state = acquire_continuation_state(effect_handle)
if !continue_authority_current(
effect_handle, state):
request_safe_stop_or_release(effect_handle)
return CONTINUATION_DENIED
if evaluate_existing_safety(
effect_handle.candidate,
state) != SAFE_TO_CONTINUE:
request_safe_stop_or_release(effect_handle)
return SAFETY_STOP
if generation_changed_relevantly(
effect_handle.bound_generation_vector,
state.generation_vector):
if !revalidate_continuation(effect_handle, state):
request_safe_stop_or_release(effect_handle)
return REVALIDATION_FAILED
wait_until_next_required_supervision_point()
return EFFECT_ENDED
19.15. Emergency-Stop Precedence
function on_emergency_stop(event):
if !verify_emergency_stop_source(event):
return INVALID_EVENT
existing_safety_system.request_emergency_safe_state(event)
invalidate_or_suspend_pending_motion_authority(
scope=event.scope)
mark_all_affected_candidates_non_effective()
return EMERGENCY_STOP_ACTIVE
# No cyber ALLOW path may override this state.
19.16. Separate Cold-Path and Hot-Path Work
Das Expires 20 March 2027 [Page 50]
Internet-Draft Actuation-Bound Finality September 2026
function prepare_hot_path(candidate):
cold = {
attestation_result:
obtain_or_refresh_attestation_if_required(candidate),
policy:
resolve_actuation_policy(candidate),
operating_envelope:
precompute_allowed_envelope(candidate),
path_coverage:
verify_actuation_path_coverage(
candidate.protected_consequence,
current_path_inventory(),
current_afb_inventory()),
bound_generations:
current_actuation_generation_vector(candidate)
}
return protect_hot_path_context(cold)
19.17. Crash-Safe Physical-Effect Recovery
function recover(candidate_id):
state = protected_commit_state(candidate_id)
if state == EFFECTIVE:
return DO_NOT_REPLAY
if state == COMMITTING:
result = resolve_atomic_or_safety_commit(candidate_id)
if result == EFFECT_COMMITTED:
return DO_NOT_REPLAY
if result == OUTPUT_NOT_COMMITTED:
return REVALIDATE_CURRENT_STATE_BEFORE_RETRY
return ENTER_SAFE_RECOVERY_MODE
if state == PENDING:
return REVALIDATE_CURRENT_STATE_BEFORE_RETRY
return FAIL_CLOSED_OR_SAFE
Das Expires 20 March 2027 [Page 51]
Internet-Draft Actuation-Bound Finality September 2026
19.18. Generate a Reviewable Actuation Failure Explanation
function explain_actuation_failure(result):
return {
exact_act_failure:
result.effect_digest_mismatch,
actuator_failure:
result.target_or_mapping_mismatch,
cyber_authority_failure:
result.authority_or_revocation_failure,
safety_failure:
result.safety_or_interlock_failure,
process_failure:
result.process_or_envelope_failure,
state_source_failure:
result.missing_stale_or_untrusted_state,
generation_failure:
result.changed_generations,
replay_failure:
result.replay_or_sequence_failure,
path_failure:
result.bypass_path_if_any
}
20. Composition with Existing Safety Controllers
In many real systems the existing safety controller is the correct
AFB. The architecture can provide cyber exact-act/current-authority
inputs to that controller or to a protected supervisory layer without
changing the safety controller's authority over safety outputs.
Das Expires 20 March 2027 [Page 52]
Internet-Draft Actuation-Bound Finality September 2026
Candidate C
|
| cyber authority + exact command
v
+--------------------------------+
| Existing Safety PLC / |
| Protected Safety Controller |
| |
| cyber act applicable? |
| current safety inputs? |
| safety application says ALLOW? |
| current process state? |
+---------------+----------------+
|
pass | safety DENY
+------+------+
| |
v v
SAFETY OUTPUT SAFE STATE
|
v
ACTUATOR
Figure 14: Existing safety controller as the Actuation Finality
Boundary
This composition is preferable to duplicating or bypassing certified
safety logic.
Cyber Finality Existing Safety Logic
| |
| exact act = PASS |
| authority = PASS |
| |
+------------------------------->|
| guard = OPEN
| safety = DENY
v
+--------------+
| FINAL RESULT |
| DENY |
+--------------+
Cyber PASS cannot override Safety DENY.
Figure 15: Safety decision remains authoritative
Das Expires 20 March 2027 [Page 53]
Internet-Draft Actuation-Bound Finality September 2026
21. RATS-Based High-Assurance Actuation
RATS can establish that the controller, AFB, or another software/
hardware component is in an expected state before it participates in
actuation. An Attestation Result can therefore become a required
input to cyber actuation authority.
Controller / AFB
|
| platform Evidence
v
Verifier
|
| Attestation Result
v
+----------------------------+
| Actuation Policy / AFB |
| trusted controller state? |
| exact Candidate Act? |
| current safety/process? |
+-------------+--------------+
|
v
protected output
Attestation proves technical platform claims.
It does NOT make an untrusted physical sensor reading true.
Figure 16: RATS evidence as a trust input to actuation finality
RATS / Attestation can establish:
controller identity
firmware/software state
protected execution state
Trusted sensing may establish:
guard state
pressure
human presence
shaft speed
actuator position
Actuation Finality needs whichever dimensions
the policy actually requires.
Attestation does not manufacture physical truth.
Figure 17: Attested controller state versus physical state
Das Expires 20 March 2027 [Page 54]
Internet-Draft Actuation-Bound Finality September 2026
22. Alternate-Path Resistance
A protected cyber path is insufficient if a maintenance, engineering,
local/manual, direct-fieldbus, direct-I/O, recovery, drive-local, or
firmware path can create the same physical effect without equivalent
safety/finality enforcement.
Normal path:
AI/HMI -> Authz -> AFB/Safety Controller -> Output -> K
^
|
protected path
Bypass:
Maintenance / Engineering / Direct I/O / Firmware
|
+------------------------> K
If the bypass can create K without an equivalent invariant,
consequence-wide prevention is not established.
Figure 18: Alternate actuation path bypass
Normal path:
App -> PLC -> [Safety AFB] -> Drive -> K
Maintenance path:
Eng WS -> [Maintenance AFB] -> Drive -> K
Local path:
Panel -> [Local Safety Logic] -> Drive -> K
Strict prevention requires every path capable of K
to enforce an equivalent finality + safety invariant.
Figure 19: Distributed actuation cut across multiple physical paths
23. Attack Analysis
23.1. Command-Parameter Substitution
Parameters change after approval. Exact-effect binding at the AFB
detects the mismatch.
Das Expires 20 March 2027 [Page 55]
Internet-Draft Actuation-Bound Finality September 2026
23.2. Target-Actuator Substitution
An otherwise valid command is redirected from actuator A to B.
Target identity binding rejects the act.
23.3. Replay and Duplicate Actuation
A previously valid command is repeated. Nonce/sequence/consume-once
state rejects replay according to the profile.
23.4. Safety or Process-State Race
A safety predicate changes after upstream authorization. The AFB re-
establishes required current state immediately before protected
output commit.
23.5. Machine-Mode Confusion
A command authorized in one mode is used in another. Mode becomes a
load-bearing actuation predicate.
23.6. Maintenance or Engineering Bypass
An engineering workstation or local maintenance interface sends the
output directly. A prevention profile must block, include, or
equivalently mediate that path.
23.7. Compromised Non-Safety Controller
A compromised ordinary PLC task attempts to generate the physical
output. Where the AFB/safety controller is independent and non-
bypassable, the ordinary task still cannot complete the protected
effect without passing the final checks.
23.8. Action Evidence Without Prevention
A signed action record is produced after the actuator moves. The
record may be valuable for accountability, but the physical effect
was not conditional on the record.
24. High-Assurance Enforcement
Das Expires 20 March 2027 [Page 56]
Internet-Draft Actuation-Bound Finality September 2026
Compromisable cyber plane
+------------------------------------------------+
| AI agent | HMI | app | OS | gateway | broker |
+-------------------------+----------------------+
|
v
+-----------------------------+
| PROTECTED AFB / SAFETY |
| CONTROLLER |
| exact command / actuator |
| current authority |
| current safety/process |
| replay / sequence |
| protected output |
+--------------+--------------+
|
v
ACTUATOR
Figure 20: Actuation finality below a compromisable cyber plane
Cyber Authority Root
|
v
+-----------+
| AFB Logic |
+-----+-----+
|
+--------------+--------------+
| | |
v v v
Safety Inputs Attestation Sequence/
/ Interlocks Root Replay Root
\ | /
+-------------+-------------+
|
v
Protected Output
|
v
Physical K
Figure 21: Multiple protected roots for high-assurance actuation
25. Deployment Patterns
Das Expires 20 March 2027 [Page 57]
Internet-Draft Actuation-Bound Finality September 2026
25.1. Safety PLC as AFB
The existing safety PLC receives or reconstructs cyber exact-act
authority and combines it with its normal safety application before
enabling the output.
25.2. Protected Drive or Robot Controller as AFB
Motion or torque authority is verified at the controller that can
actually energize the drive or robot output.
25.3. SIS / Process Controller as AFB
A process-sector deployment can integrate cyber authority into an
existing SIS decision without weakening the SIS safe-state function.
25.4. Constrained Device / ACE Resource Server as AFB
A constrained device can act as both ACE Resource Server and final
actuator boundary when it directly controls the protected output and
evaluates all required current predicates.
25.5. Distributed AFB
Some systems require multiple enforcement points, for example a robot
controller plus a safety I/O stage. The profile must define how
their decisions compose and how partial failure is handled.
26. Real-Time Performance and Availability
Industrial actuation can have strict cycle times. A design MUST NOT
require remote policy or attestation calls on every control-loop
iteration unless the deployment can satisfy its real-time
requirements. Expensive policy/attestation work can occur on
supervisory or cold paths, while the real-time path verifies compact
protected generations, command digests, actuator identity, local
safety state, sequence state, and precomputed authority.
Profiles SHOULD state worst-case verification latency, jitter, state-
sampling freshness, generation-update latency, safe-state reaction
behavior, and how real-time constraints interact with fail-closed
cyber enforcement.
Das Expires 20 March 2027 [Page 58]
Internet-Draft Actuation-Bound Finality September 2026
Availability pressure does not justify overriding functional safety.
When cyber authority is unavailable but safety permits motion, the
system follows the deployment's explicit policy; it MUST NOT silently
infer cyber authority. When cyber authority is valid but the safety
system denies or is in an unsafe/unknown state, the protected act
remains non-effective.
Cold / supervisory path:
policy resolution
attestation
authority issuance
topology review
envelope computation
|
v
protected state
|
v
Real-time hot path:
exact command digest
current safety inputs
generation vector
sequence / replay
local finality predicate
protected output commit
Figure 22: Cold-path and real-time hot-path split
27. Relationship to ACE
ACE is highly relevant because RFC 9200 defines OAuth-based
authorization for constrained environments [RFC9200]. The main
architectural question is whether the ACE Resource Server is itself
the true actuator boundary. If it is and it evaluates all required
current actuation predicates, the core property can already be
satisfied.
This document does not propose a new ACE token format in its base
form.
28. Relationship to CoRE
CoRE maintains CoAP and related mechanisms for constrained resources
[RFC7252]. Physical devices using CoAP can expose protected actuator
resources, but this document does not presume that CoRE owns
functional-safety semantics.
Das Expires 20 March 2027 [Page 59]
Internet-Draft Actuation-Bound Finality September 2026
29. Relationship to RATS
RATS is relevant when actuation depends on trusted controller/device
state [RFC9334]. A profile can require an acceptable Attestation
Result before cyber authority becomes actuation-eligible. Physical-
state truth remains outside attestation unless the measurement/
evidence architecture actually supports it.
30. Relationship to OPC UA and Industrial Safety Standards
OPC UA Safety already defines functional-safety communication for
safety devices [OPCUA-SAFETY]. IEC 61508/61511 and product-specific
safety certification remain authoritative for functional-safety
engineering. This draft is a security/authority composition
proposal, not a functional-safety standard and not a certification
claim.
IETF is not the owner of industrial functional-safety certification.
Cross-community review with IEC TC 65, the OPC Foundation, industrial
vendors, and safety engineers is essential before asserting any
production profile.
31. Industrial Relevance
The industrial relevance is not based on an assertion that major
automation vendors lack safety enforcement. The opposite is the
useful starting point: mature safety controllers already demonstrate
protected safety logic, safety I/O, diagnostics, and final output
control. The question for increasingly cloud-connected and AI-
assisted systems is how upstream cyber authority is bound to those
mature physical safety boundaries without bypassing, weakening, or
duplicating them.
31.1. Robotics and Machine Motion
Agentic or remote software can generate motion proposals, but actual
motion can remain non-effective until the robot/safety controller
verifies exact command authority and current cell/safety conditions.
31.2. Process Control
Valve, pump, dosing, pressure, and process-state changes can be bound
to current process and SIS conditions at the true output boundary.
Das Expires 20 March 2027 [Page 60]
Internet-Draft Actuation-Bound Finality September 2026
31.3. Manufacturing and Warehouse Automation
Queued or AI-generated tasks can survive substantial delays before
physical execution. Revalidation at actuation prevents stale digital
authority from silently surviving a changed cell or line state.
31.4. Critical Infrastructure
High-consequence control actions can require hardware/protected-
controller enforcement below compromise-prone enterprise and AI
layers.
32. Complementary Industrial Alignment
32.1. Siemens Safety Integrated
Siemens documents fail-safe S7 controllers and Safety Integrated
designs using fail-safe programs and certified safety blocks
[SIEMENS-SAFETY]. Such a controller can potentially serve as the AFB
for a deployment. No deficiency is asserted.
32.2. Rockwell Automation GuardLogix
Rockwell documents GuardLogix controller systems for safety
applications including SIL 3 / PL e configurations
[ROCKWELL-GUARDLOGIX]. Existing GuardLogix safety logic and output
authority should remain authoritative; an execution-finality profile
would compose with it rather than replace it.
32.3. Schneider Electric Modicon M580 Safety
Schneider's current M580 Safety system guide describes how the system
addresses IEC 61508 safety requirements and safe system operation
[SCHNEIDER-M580]. This is a mature safety-controller architecture
and a possible AFB integration point.
32.4. ABB AC500-S
ABB documents AC500-S safety PLCs and safety I/O for applications up
to SIL 3 / PL e [ABB-AC500S]. Its documented safety function reads
safety inputs and controls safety outputs according to safety logic,
including de-energize-to-trip safe behavior [ABB-SAFETY-FUNCTION].
This is direct overlap with the AFB role, not an example of missing
safety enforcement.
Das Expires 20 March 2027 [Page 61]
Internet-Draft Actuation-Bound Finality September 2026
32.5. OPC Foundation
OPC UA Safety is a strong interoperability precedent for functional-
safety communication and explicitly remains subject to safety-
development and assessment requirements [OPCUA-SAFETY]
[OPCUA-SAFETY-POLICY].
32.6. Non-Endorsement and Non-Criticism
Named vendors and standards are included only as documented examples
of mature safety engineering, architectural overlap, or possible
integration points. The document does not assert that Siemens,
Rockwell Automation, Schneider Electric, ABB, the OPC Foundation, or
any other named organization has a vulnerability, deficiency, non-
conformance, or obligation to adopt this architecture, and no
affiliation or endorsement is implied.
33. Required Classes of Test Vectors
A concrete implementation or profile SHOULD test at least:
* exact command, correct actuator, current authority, safe/current
process state: output succeeds;
* parameter changed after authorization: reject;
* target actuator changed: reject;
* guard/interlock changes after authorization: reject or safe
response;
* machine mode changes: reject/revalidate;
* process state leaves allowed envelope: reject;
* cyber authority revoked before output: reject;
* identical command replayed after consume-once: reject;
* out-of-order sequence: reject according to profile;
* safety controller returns DENY while cyber authority is valid:
reject;
* safety state UNKNOWN under strict profile: remain non-effective/
safe;
Das Expires 20 March 2027 [Page 62]
Internet-Draft Actuation-Bound Finality September 2026
* cyber authority missing while safety state is permissive: reject
under protected cyber profile;
* valid RATS Attestation Result but physical/process predicate
missing: reject or UNKNOWN;
* action-evidence record present only after actuation: classify as
audit, not prevention;
* maintenance/direct-I/O path reaches actuator without equivalent
AFB: prevention profile fails;
* ACE Resource Server is the actual actuator and checks all required
current conditions: succeed without extra component;
* existing safety PLC fully mediates exact cyber act plus safety
output: recognize property as already satisfied;
* generation changes between verification and output: retry/
revalidate;
* crash after consume-before-output: recover without duplicate
actuation;
* emergency stop active: safety DENY dominates all cyber
authorization.
Additional high-assurance tests SHOULD include: valid cyber authority
with a stale but cryptographically authentic safety snapshot; correct
safety value from an under-assured source; conflicting trusted
process-state sources; actuator remapping after authorization;
sequence-window rollback; continuing effect after initiation
authority expires; release/reset operations with different authority
rules; emergency-stop activation during protected commit; topology
change that introduces a maintenance bypass; crash after protected
consume but before confirmed physical output; and recovery after an
uncertain actuator state.
34. Questions to the IETF Community
Criticism, corrections, counterexamples, industrial implementation
experience, prior art, evidence of equivalent existing mechanisms,
and reasons to narrow, merge, or stop the work are explicitly
invited. Negative answers are useful outcomes.
1. Is actuation-bound execution finality a useful security
abstraction, or is it already fully covered by functional-safety
controllers and existing authorization patterns?
Das Expires 20 March 2027 [Page 63]
Internet-Draft Actuation-Bound Finality September 2026
2. Where an ACE Resource Server is the final actuator and checks
current conditions, does RFC 9200 already provide all required
protocol semantics?
3. Should this work be a BCP/composition guide rather than a new
protocol?
4. Does OPC UA Safety plus a certified safety PLC already satisfy
the full invariant for typical industrial deployments?
5. What residual property, if any, remains between an authorized
digital command and certified safety output?
6. Should exact cyber-command binding be handled by industrial
application protocols rather than IETF?
7. How should a Candidate Act be canonically bound to actuator,
operation, parameters, sequence, and constraints?
8. Which physical/process state belongs in cyber authorization, and
which must remain solely within functional safety?
9. Should a safety-controller result be treated as a required
external decision input while still remaining authoritative?
10. How fresh must safety/process state be when an actuation
completes?
11. How should state changes during the verification-to-actuation
interval be serialized?
12. Which interfaces constitute alternate actuation paths:
maintenance, engineering, local/manual, direct I/O, fieldbus,
firmware, or recovery?
13. How can path completeness be demonstrated for a physical
actuation surface?
14. Can RATS Evidence establish enough controller/device state
without overclaiming physical facts that are not measured?
15. How should sensor trust be represented without implying that
attestation makes sensor readings true?
16. Does [SOKOLOV-AEP] already cover enough action/platform
composition that only the pre-effectuation boundary remains?
Das Expires 20 March 2027 [Page 64]
Internet-Draft Actuation-Bound Finality September 2026
17. Is post-actuation action evidence useful as an audit complement
even though it is not prevention?
18. How should fail-safe or de-energize behavior interact with cyber
execution authority?
19. What is the correct fail behavior when cyber authority is valid
but required safety state is UNKNOWN?
20. What is the correct fail behavior when safety permits motion but
cyber authority is missing?
21. Should AI agents ever hold direct actuator authority, or should
agent authority always terminate in an industrial controller
profile?
22. What performance bounds are acceptable for high-rate motion and
control loops?
23. Which checks belong on the real-time path versus a supervisory/
cold path?
24. Which existing Siemens, Rockwell, Schneider, ABB, OPC UA Safety,
or other deployments already guarantee this exact invariant?
25. What counterexample would falsify or materially narrow the
proposed architecture?
26. Is ACE, CoRE, RATS, DISPATCH, SAAG, or an external industrial
standards body the appropriate venue for further discussion?
35. Potential IETF Discussion Venues and External Standards Boundaries
35.1. ACE
ACE is directly relevant for constrained-device authorization and has
active work in 2026. A central review question is whether an ACE
Resource Server that is itself the actuator already provides the
required protocol boundary.
35.2. CoRE
CoRE is relevant where actuators expose CoAP resources or participate
in constrained messaging. This document does not presume CoRE owns
functional-safety semantics.
Das Expires 20 March 2027 [Page 65]
Internet-Draft Actuation-Bound Finality September 2026
35.3. RATS
RATS is relevant for controller/device trust evidence and action/
platform evidence composition. The preferred question is whether
actuation trust should be an application-layer Relying Party decision
rather than a new RATS evidence format.
35.4. DISPATCH
DISPATCH can be useful for routing if no current WG owns the cross-
cutting composition problem.
35.5. SAAG
SAAG is useful for broad Security Area architectural review. It is
not a Working Group that adopts documents.
35.6. IEC, OPC Foundation, and Industrial Safety Communities
IEC TC 65, IEC 61508/61511/62443 stakeholders, the OPC Foundation,
safety assessors, industrial vendors, and functional-safety engineers
are essential adjacent communities. IETF is not the owner of
functional-safety certification.
35.7. No Presumed Home
This document does not claim that any named IETF group or external
standards body should adopt the work. Overlap analysis and
industrial safety review should precede any standardization proposal.
36. Relationship to Other Execution-Finality Internet-Drafts
This document isolates the cyber-command-to-physical-effect boundary.
* The protocol-layer draft defines the broad Candidate Act, Non-
Effective State, protected validation, and Finality Sink
architecture.
* The agentic draft applies execution finality to high-risk AI tool
dispatch.
* The hardware-enforced draft focuses on protected execution-
finality boundaries for agentic and industrial systems.
* The RATS/attestation-bound draft connects trusted workload state
to consequential authority.
Das Expires 20 March 2027 [Page 66]
Internet-Draft Actuation-Bound Finality September 2026
* The state/policy-continuity draft asks whether earlier
authorization remains applicable.
* The finality-bound-revocation draft asks whether withdrawn
authority survives to commit.
* The consequence-path-completeness draft asks whether the
consequence can bypass enforcement.
* The third-party-decision-binding draft asks whether a required
external authority actually issued the applicable decision.
* The jurisdiction-bound draft asks whether effectuation occurs
under the current permitted sovereign/governance context.
* This document asks whether the exact cyber-originated act is still
authorized under the current physical/process/safety context at
the first physical effect.
State continuity:
Is earlier authorization still applicable?
Revocation finality:
Has authority been withdrawn?
Path completeness:
Can the consequence avoid enforcement?
Third-party decision binding:
Did the required authority actually approve?
Jurisdiction finality:
Is effectuation occurring in the permitted sovereign context?
Actuation finality:
Is the exact cyber-originated act still authorized
under CURRENT physical/process/safety context
at the first physical effect?
Related documents include [DAS-PROTOCOL], [DAS-AGENTIC],
[DAS-HARDWARE], [DAS-RATS], [DAS-STATE], [DAS-REVOCATION],
[DAS-PATH], [DAS-THIRD-PARTY], and [DAS-JURISDICTION].
Das Expires 20 March 2027 [Page 67]
Internet-Draft Actuation-Bound Finality September 2026
37. Public Implementations and Companion Engineering Material
Public execution-finality repositories provide background
implementations of exact-effect binding, current policy/epoch/
revocation checks, challenge binding, replay resistance, and
protected finality [GH-ARCH] [GH-HARDENED].
Those repositories are not represented here as certified industrial-
safety implementations or as complete AFB implementations. A
production industrial profile would require real controller/actuator
integration, safety-engineering review, timing analysis, path
inventory, and test evidence.
38. Security Considerations
Security depends on exact command binding, current authority, trusted
current actuation context, preservation of existing safety authority,
output-path non-bypassability, and protected check-to-output
ordering.
38.1. Command Parameter Substitution
Every parameter whose change affects physical consequence or
authority must be covered by exact-act binding.
38.2. Target-Actuator Substitution
The target actuator or output endpoint must be bound where
redirection changes authority or safety meaning.
38.3. Command Replay
Non-idempotent physical commands require explicit replay/consume-
once/sequence semantics.
38.4. Duplicate Actuation
Retries and crash recovery must not cause duplicate physical effects
unless the application explicitly defines idempotent behavior.
38.5. Stale Authority
Authentic earlier authority can become inapplicable after policy,
operator, ownership, or authorization-state change.
Das Expires 20 March 2027 [Page 68]
Internet-Draft Actuation-Bound Finality September 2026
38.6. Stale Safety State
A safety result sampled before a load-bearing state change must not
be reused beyond the profile's allowed freshness semantics.
38.7. Stale Process State
Process variables can change faster than supervisory authorization.
Required state must be sampled or latched consistently with the real-
time profile.
38.8. Interlock Race
A guard/interlock change between verification and output can defeat
upstream checks. The AFB must use the safety system's protected
timing/ordering semantics.
38.9. Machine-Mode Confusion
Commands valid in AUTO, TEACH, MANUAL, MAINTENANCE, or another mode
are not automatically interchangeable.
38.10. Maintenance-Mode Abuse
Maintenance mode can expose powerful actuation paths. It must be
explicitly included, isolated, or excluded from the prevention claim.
38.11. Local or Manual Override
Local/manual controls can be legitimate higher-priority mechanisms.
Their relationship to the cyber prevention claim must be explicit
rather than silently omitted.
38.12. Engineering Workstation Bypass
An engineering tool or programming interface can become an alternate
effectuation path and must be governed by the deployment's path
model.
38.13. Direct Fieldbus Write
A direct fieldbus command that can energize or actuate a device can
bypass an application gateway and must cross equivalent enforcement.
38.14. Direct I/O Path
Direct I/O writes or output forcing can defeat higher-layer finality
unless physically or logically constrained.
Das Expires 20 March 2027 [Page 69]
Internet-Draft Actuation-Bound Finality September 2026
38.15. Recovery and Disaster-Recovery Control Paths
Recovery interfaces can bypass normal control logic and must be
explicitly included or placed in a separate assurance mode.
38.16. Firmware-Level Actuation
Device firmware capable of directly controlling outputs is part of
the trusted computing base or an alternate path under the relevant
threat model.
38.17. Compromised Non-Safety PLC
Where the ordinary PLC task is untrusted, the safety/AFB boundary
must prevent it from directly completing the protected effect.
38.18. Compromised Gateway
An upstream gateway may fabricate approval or modify commands. The
AFB independently verifies the exact act and current authority.
38.19. Compromised Host OS
Host-resident state and policy are insufficient for high-assurance
profiles when the host OS is inside the adversary model.
38.20. Safety-Controller Compromise
The base model does not claim to survive full compromise of the
authoritative safety controller/AFB. Higher assurance may use
architectural separation and certified mechanisms.
38.21. Sensor Spoofing
Execution finality can only rely on the sensing assurance provided by
the deployment. It does not make an untrusted sensor trustworthy.
38.22. Sensor Authenticity Is Not Physical Truth
A signed or attested sensor value can prove provenance/integrity
without proving that the sensor accurately represents physical
reality.
38.23. Actuator Feedback Spoofing
If feedback is used to establish current state or successful
completion, its trust model must be explicit.
Das Expires 20 March 2027 [Page 70]
Internet-Draft Actuation-Bound Finality September 2026
38.24. Sequence and Reordering Attacks
Commands that are safe only in an intended sequence require sequence
binding and rejection of unauthorized reorderings.
38.25. TOCTOU Between Check and Output
The final safety/authority check must be coupled to the output using
atomicity, safety-controller cycle semantics, generation locking, or
an equivalent protected ordering rule.
38.26. Crash Consistency
Crash recovery must not repeat an irreversible/non-idempotent
physical effect or re-enable an already consumed Candidate Act.
38.27. Fail-Open Behavior
Failure to obtain required cyber authority or required safety/process
state MUST NOT silently become ALLOW in a strict prevention profile.
38.28. Loss of Safety-State Source
When a required safety-state source is unavailable, existing safety
policy determines the safe response. Execution finality must not
invent a positive state.
38.29. Denial of Service
Attackers can make policy, sequence, or context state unavailable and
force fail-safe behavior. Availability engineering must not weaken
safety dominance.
38.30. Emergency Stop Precedence
Emergency stop and other required safety functions dominate cyber
authorization and execution-finality approval.
38.31. Fail-Safe Output State
The safe state is deployment/safety-design specific. Execution
finality does not define or certify the safe state.
38.32. Output Latching
Latched outputs can remain physically effective after authority
changes. Profiles must distinguish authority to initiate an effect
from authority to continue or release it.
Das Expires 20 March 2027 [Page 71]
Internet-Draft Actuation-Bound Finality September 2026
38.33. Authority Consumption State
Consume-once state must itself be protected against rollback or reset
where replay is in the threat model.
38.34. Actuation Path Completeness
All paths capable of producing the protected physical consequence
must cross the AFB or an equivalent finality/safety invariant.
38.35. RATS Attestation Overclaim
Attestation must not be interpreted as proof of unmeasured physical
facts or as functional-safety certification.
38.36. Action Evidence Confused with Prevention
Evidence that software reports an action does not prove that the
action was physically prevented until the required pre-actuation
conditions held.
38.37. Audit Is Not Prevention
Logging the physical effect after it occurred is useful for
accountability but is not the prevention invariant.
38.38. Real-Time Latency and Jitter
Adding verification to a real-time path can itself create unsafe
timing behavior. Profiles require timing analysis appropriate to the
industrial control loop.
38.39. Functional-Safety Certification Boundary
Implementing this document does not confer SIL, PL, safety
certification, regulatory approval, or a claim of functional-safety
compliance. The safety function, lifecycle, hazard analysis,
validation, and certification remain governed by applicable
industrial safety standards and competent assessors.
38.40. Physical Tampering
Direct rewiring, mechanical bypass, or physical modification outside
the declared threat model is outside the base prevention claim.
Das Expires 20 March 2027 [Page 72]
Internet-Draft Actuation-Bound Finality September 2026
39. Privacy Considerations
Actuation evidence and context can reveal machine state, human
presence, maintenance mode, production sequence, facility topology,
device identity, operator activity, or sensitive industrial process
information. Profiles SHOULD minimize disclosed context and keep
detailed physical-state evidence local where possible.
Human-presence or worker-location information can be especially
sensitive and should be represented only where the safety function
actually requires it.
40. Criticism, Corrections, and Review Invited
This document is intentionally presented for adversarial review.
Reviewers are invited to identify existing safety/controller
architectures that already guarantee the full property, incorrect
descriptions of industrial safety standards, unnecessary terminology,
unrealistic real-time assumptions, unmodeled actuation paths, unsafe
interactions with certified safety functions, sensor-trust mistakes,
prior art, or reasons that the work should be narrowed, merged, moved
to an industrial standards body, or stopped.
Particularly useful feedback is a concrete system in which a
certified safety controller, OPC UA Safety application, ACE Resource
Server, RATS-based controller, or another existing architecture
already makes exact cyber authority and current required physical/
safety context a non-bypassable precondition of the physical effect.
Such evidence should narrow the proposal rather than be treated as
opposition.
41. IANA Considerations
This document has no IANA actions.
42. Conclusion
Industrial functional safety, safety PLCs, secure industrial
communication, constrained- device authorization, and remote
attestation already solve essential parts of physical control
security. This document isolates one narrower continuity question:
when a cyber-originated command was valid earlier, what makes its
exact physical effect remain conditional on current cyber authority,
current process/safety applicability, and the actual non-bypassable
actuation path?
Das Expires 20 March 2027 [Page 73]
Internet-Draft Actuation-Bound Finality September 2026
COMMAND ACCEPTED
!=
ACTUATION AUTHORIZED
For strict actuation finality:
exact command
+ current cyber authority
+ current required safety/process state
+ correct actuator
+ authorized actuation path
=>
eligible for protected output
Any required safety DENY
=>
NO protected physical effect.
Existing systems that already enforce this relationship already
satisfy the core invariant. The purpose of the draft is to make the
cyber-authority-to-physical-effect relationship explicit, testable,
composable with mature safety engineering, and open to correction by
both IETF and industrial safety communities.
A practical implementation should be able to explain not merely that
actuation was denied, but whether the failure came from exact-command
mismatch, actuator identity or remapping, cyber-authority
currentness, revocation, safety/interlock state, process/envelope
state, state source assurance, generation drift, replay/sequence
semantics, continuing-effect authority, or an alternate physical
path. That diagnostic separation is essential for engineering review
without confusing cyber finality with functional-safety
certification.
43. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
44. Informative References
Das Expires 20 March 2027 [Page 74]
Internet-Draft Actuation-Bound Finality September 2026
[ABB-AC500S]
ABB, "AC500-S Safety PLC", 2026,
<https://www.abb.com/global/en/areas/motion/plc/
programmable-logic-controllers/ac500-s>.
[ABB-SAFETY-FUNCTION]
ABB, "AC500-S Safety Function and Fault Reaction", 2026,
<https://help.plc.abb.com/safety_function.html>.
[DAS-AGENTIC]
Das, S., "Tool Selection Is Not Execution: Finality for
Agentic Tool Dispatch in High-Risk AI Systems", Work in
Progress, Internet-Draft, draft-das-agentic-execution-
finality-02, September 2026,
<https://datatracker.ietf.org/doc/draft-das-agentic-
execution-finality/>.
[DAS-HARDWARE]
Das, S., "Computation Is Not Authority: Hardware-Enforced
Execution-Finality for Agentic AI, MCP Tool Calls, and
Industrial Agents", Work in Progress, Internet-Draft,
draft-das-hardware-enforced-execution-finality-02,
September 2026, <https://datatracker.ietf.org/doc/draft-
das-hardware-enforced-execution-finality/>.
[DAS-JURISDICTION]
Das, S., "Authorized Here, Not Authorized There:
Jurisdiction-Bound Execution Finality for Cross-Border and
Sovereign Systems", Work in Progress, Internet-Draft,
draft-das-jurisdiction-bound-execution-finality-00,
September 2026, <https://datatracker.ietf.org/doc/html/
draft-das-jurisdiction-bound-execution-finality-00>.
[DAS-PATH] Das, S., "When the Gate Can Be Bypassed: Consequence-Path
Completeness for Execution Finality", Work in Progress,
Internet-Draft, draft-das-consequence-path-completeness-
00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-
consequence-path-completeness-00>.
[DAS-PROTOCOL]
Das, S., "The Missing Protocol Layer for the Agentic
Internet: Computation Is Not Authority", Work in Progress,
Internet-Draft, draft-das-execution-finality-protocol-
layer-01, September 2026,
<https://datatracker.ietf.org/doc/draft-das-execution-
finality-protocol-layer/>.
Das Expires 20 March 2027 [Page 75]
Internet-Draft Actuation-Bound Finality September 2026
[DAS-RATS] Das, S., "Attestation-Bound Execution Finality for GPU, AI
Accelerator, DPU, SmartNIC, and Confidential-Computing
Infrastructure", Work in Progress, Internet-Draft, draft-
das-rats-attestation-bnd-execution-finality-04, September
2026, <https://datatracker.ietf.org/doc/draft-das-rats-
attestation-bnd-execution-finality/>.
[DAS-REVOCATION]
Das, S., "Revoked but Still Executable: Closing the
Authorization-to-Effect Gap with Finality-Bound
Revocation", Work in Progress, Internet-Draft, draft-das-
finality-bound-revocation-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-finality-
bound-revocation-00>.
[DAS-STATE]
Das, S., "When Valid Authorization Becomes Stale: State
and Policy Continuity at the Execution-Finality Boundary",
Work in Progress, Internet-Draft, draft-das-state-policy-
continuity-finality-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-state-
policy-continuity-finality-00>.
[DAS-THIRD-PARTY]
Das, S., "When I Checked Is Not Proof: Verifiable Third-
Party Decision Binding at the Execution-Finality
Boundary", Work in Progress, Internet-Draft, draft-das-
third-party-decision-binding-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-das-third-
party-decision-binding-00>.
[GH-ARCH] Das, S., "Execution-Finality Architecture for Machine-
Generated Acts", 2026, <https://github.com/sangmdas/
Execution-Finality-Architechture-for-AI-Machines->.
[GH-HARDENED]
Das, S., "Hardened Challenge-Bound Execution Finality for
AI Interoperability", 2026, <https://github.com/sangmdas/
Hardened-Challenge-Bound-Execution-Finality-for-AI-
Interoperability>.
[IEC61508] International Electrotechnical Commission, "IEC 61508 —
Functional safety of electrical/electronic/programmable
electronic safety-related systems", 2010,
<https://webstore.iec.ch/en/iec_catalog/product/
preview/?id=L3B1Yi9wZGYvcHJldmlldy9pbmZvX2llYzYxNTA4LTF7ZWQyLjB9Yi5wZGY=>.
Das Expires 20 March 2027 [Page 76]
Internet-Draft Actuation-Bound Finality September 2026
[IEC61511] International Electrotechnical Commission, "IEC
61511-1:2016 — Functional safety — Safety instrumented
systems for the process industry sector", 2016,
<https://webstore.iec.ch/en/publication/24241>.
[IEC62443] International Electrotechnical Commission, "IEC
62443-4-2:2019 — Security for industrial automation and
control systems — Technical security requirements for IACS
components", 2019,
<https://webstore.iec.ch/en/publication/34421>.
[OPCUA-SAFETY]
OPC Foundation, "OPC Unified Architecture — Part 15:
Safety", 2026, <https://reference.opcfoundation.org/specs/
OPC-10000-15/1>.
[OPCUA-SAFETY-POLICY]
OPC Foundation, "OPC UA Safety — Safety Policy", 2026,
<https://reference.opcfoundation.org/Safety/v104/
docs/12.1>.
[RFC7252] IETF, "The Constrained Application Protocol (CoAP)",
RFC 7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC9200] IETF, "Authentication and Authorization for Constrained
Environments Using the OAuth 2.0 Framework (ACE-OAuth)",
RFC 9200, August 2022,
<https://www.rfc-editor.org/rfc/rfc9200>.
[RFC9334] IETF, "Remote ATtestation procedureS (RATS) Architecture",
RFC 9334, January 2023,
<https://www.rfc-editor.org/rfc/rfc9334>.
[ROCKWELL-GUARDLOGIX]
Rockwell Automation, "CompactLogix 5380 and Compact
GuardLogix 5380 Controllers User Manual", March 2025,
<https://literature.rockwellautomation.com/idc/groups/
literature/documents/um/5069-um001_-en-p.pdf>.
[SCHNEIDER-M580]
Schneider Electric, "Modicon M580 Safety, System Guide",
July 2026,
<https://www.se.com/in/en/download/document/QGH60283/>.
[SIEMENS-SAFETY]
Siemens, "SIMATIC Safety Integrated — Fail-Safe S7
Controller Application Example", 2025,
Das Expires 20 March 2027 [Page 77]
Internet-Draft Actuation-Bound Finality September 2026
<https://cache.industry.siemens.com/dl/files/100/21331100/
att_1330853/
v3/21331100_TwoHandControlPanel_DOC_v4_1_en.pdf>.
[SOKOLOV-AEP]
Sokolov, A., "Composing Application-Layer Action Evidence
with Remote Attestation Procedures", Work in Progress,
Internet-Draft, draft-sokolov-rats-aep-composition-05,
August 2026, <https://datatracker.ietf.org/doc/draft-
sokolov-rats-aep-composition/>.
Author's Address
Sangam Das
Independent
Balasore
Odisha
India
Phone: +91-9861363532
Email: info@sangamdas.com
Das Expires 20 March 2027 [Page 78]