Command Accepted Is Not Actuation Authorized: Execution Finality for Cyber-Physical and Industrial Control Systems

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).

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 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.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.¶

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.¶

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.¶

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.¶

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].¶

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.¶

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

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?

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.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.¶

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.¶

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.¶

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.

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.¶

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.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

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

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)

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.¶

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

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.¶

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.¶

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

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

19.1. Canonicalize the Physical Candidate Act

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

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

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

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

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

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

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

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(
            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

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

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

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
    }

23.1. Command-Parameter Substitution

Parameters change after approval. Exact-effect binding at the AFB detects the mismatch.¶

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.¶

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.¶

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.¶

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.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.¶

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.¶

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.¶

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.¶

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.¶

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.¶

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.¶

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.¶

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.¶