When Attestation Is Not Enough: Execution Finality for High-Assurance Resource Transitions

Introduction Infrastructure security commonly establishes the trustworthiness of components. A verifier may determine that a device possesses an expected identity, that firmware measurements correspond to an acceptable state, that a protected channel exists, or that a requesting principal is authorized. Remote attestation architectures such as RATS explicitly separate Attesters, Verifiers, and Relying Parties and define how evidence can support appraisal and trust decisions . These properties remain necessary. They do not necessarily establish that the exact physical or logical transition that is about to occur remains the transition that was evaluated. This distinction becomes important as infrastructure becomes composable. Memory can be added to or released from a host at runtime. Accelerators and device interfaces can move among workloads. Storage regions can be remapped. Network or I/O state can be reconfigured without moving the resource itself. In each case, security ultimately depends on a transition between two states.

The security-sensitive object is the transition Previous State New State Resource R Resource R controlled by A --------> controlled by B inaccessible to B addressable by B Authentication can establish properties of A, B, or R. The problem addressed by this document is the arrow: whether the exact transition that creates the new consequence is still authorized when it becomes effective. The core requirement is therefore: a security-critical transition remains non-effective until the concrete transition that is about to become effective has been checked against the transition that was authorized.

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 when, and only when, they appear in all capitals, as shown here.

Motivating Scenario: Residual State Across Dynamic Memory Reassignment Consider a multi-tenant AI infrastructure using dynamically assignable memory. Tenant A operates a workload containing valuable model state. Some pages associated with the workload reside in a dynamically managed memory resource. Eventually the workload terminates and an extent, E42, is released for later use by another host. The example is intentionally not a claim that CXL lacks residual-data protections. CXL 4.0 includes Trusted Execution Environment Security Protocol requirements for Dynamic Capacity. In particular, its Dynamic Capacity security requirements state that before capacity is added to a host, including after release from a different host, the relevant memory is overwritten or cryptographically cleared and the trusted-execution state is reset . The scenario below instead illustrates the cross-layer failure that occurs if an implementation, integration, stale management state, replay, or alternate effectuation path causes new addressability to become effective without the required precondition being current and binding at the effectuation boundary.

Residual-state exposure caused by premature effectuation Tenant A | | uses v +-----------+ | Memory E42| | State S | +-----------+ | | release v +----------------+ | SANITIZE / | | STATE RESET | +----------------+ | X ordering, replay, stale-state, | or alternate-path failure v +-----------+ | Host B | | maps E42 | +-----------+ | v residual state becomes observable The important point is not that Tenant A sends a file to Tenant B. The security consequence is created by changing who can address the resource. A memory read still transfers cache-line data over the interconnect, but the previous tenant did not transmit or authorize an application payload for the new tenant. The disclosure is created by a state transition in addressability. The same structure applies to other resources: a GPU partition can become visible to another workload; a device interface can be attached to a different VM; a DMA mapping can become active; a storage namespace can be remapped; or a network rule can become externally active.

Problem Space Security systems commonly contain logically distinct stages such as authentication, attestation, policy evaluation, authorization, configuration, and external effect. Security reasoning often concentrates on the earlier stages while the consequential state change occurs later and may be performed by different components.

The authorization-to-effect gap Request | v Authentication | v Attestation | v Policy Evaluation | v Authorization | | security-relevant state may change here | ---------------------------------------- v Configuration | v External Effect Between authorization and effectuation, security-relevant state may change. A resource can be substituted, a destination can change, an authorization can become stale, sanitization can remain incomplete, ownership or generation can advance, policy can be revoked, or a previously valid operation can be replayed. The problem can therefore be stated as follows: authorization of a requested operation is not necessarily equivalent to authorization of the concrete operation that ultimately becomes effective.

Attestation Answers a Different Question SPDM provides messages and procedures for hardware identity authentication, measurement of firmware identities, key exchange, and protected sessions . These are important inputs to a resource-transition decision. A valid attestation can establish that a device or environment has an acceptable identity or measured state. It does not, by itself, prove that a particular resource extent is still owned by the expected source, that a required sanitize operation has completed, that the destination has not changed, that a generation number is current, or that an authorization has not already been consumed.

Secure Transport Is Not Secure Consequence PCIe Integrity and Data Encryption provides confidentiality, integrity, and replay protection for protected Transaction Layer Packets . This protects communication in transit. A cryptographically protected request can nevertheless represent a stale, mis-bound, or no-longer-authorized operation. TDISP defines mechanisms for establishing a trust relationship with a device, securing the interconnect, and trusted attach/detach of a device interface to a trusted VM . The model in this document is complementary: it asks what invariant applies at the boundary where a specific resource transition first becomes effective.

Design Goals and Non-Goals The design goal is to bind authorization to the concrete transition that will create a protected consequence, and to verify that binding at a non-bypassable or equivalently protected effectuation boundary. This document does not replace remote attestation, SPDM, IDE, TDISP, CXL security, confidential computing, hypervisor isolation, IOMMU protection, or existing access control. Those mechanisms may provide evidence, isolation, transport protection, or enforcement used by the model. This document also does not require one physical implementation point. The final enforcement function can be implemented in hardware, firmware, a hypervisor, device logic, a switch, an operating-system security boundary, or a combination, provided the protected consequence cannot be produced through an unmediated alternate path.

Terminology Candidate Transition: A proposed security-relevant state change that has been prepared but has not yet been allowed to create its protected consequence. Non-Effective State: A condition in which preparation and validation may occur, but the requester does not yet possess the means required to create the protected consequence. Transition Descriptor: A canonical representation of the exact resource transition to which authorization is bound. Validation Evidence: Protected evidence used to establish that a Candidate Transition satisfies required conditions. Attestation Evidence or an Attestation Result as used in RATS can be among these inputs . Execution Handle: A narrowly scoped authorization bound to a specific validated Transition Descriptor and its execution constraints. Possession of the handle is not intended to provide unconstrained bearer authority for a different transition. Final Enforcement Boundary: The protected boundary controlling the operation that first makes the Candidate Transition externally effective. The term identifies a functional role, not a required physical device or software component.

Transition Model Let a transition T contain the security-relevant parameters shown below. The field set is illustrative; a concrete binding can add or remove fields according to the resource type and threat model. T = (r, s, d, o, g, q, p, n, tau) r = resource identifier s = source security domain d = destination security domain o = operation g = resource generation or epoch q = required security state p = policy state or policy version n = nonce or unique transition identifier tau = freshness or validity constraint A canonical transition digest can be constructed as follows, where Encode is deterministic and H is a cryptographic hash appropriate to the deployment. D_T = H(Encode(T)) Authorization A is bound to that transition digest and to validation evidence and execution constraints. A = Protect(D_T, Evidence, Constraints) The required semantic property is that authorization for T does not silently become authorization for a security-relevant T-prime that differs from T. A(T) does not imply A(T') when T' != T

Finality Predicate and Safety Invariant Immediately before effectuation, the Final Enforcement Boundary evaluates a predicate Phi over the concrete transition, current protected state, authorization, and evidence. Phi(T, S, A, E) = ExactBinding AND FreshnessValid AND OwnershipValid AND GenerationValid AND PolicyStillValid AND RequiredSecurityStateValid AND RequiredSanitizationComplete AND AuthorizationUseValid AND EffectuationPathAuthorized The fundamental safety invariant is: Effective(T) => Phi(T, S, A, E) = TRUE It is insufficient that the transition was valid at some earlier time. Where mutable state is security relevant, the enforcement boundary MUST establish a protected correspondence between the state that was validated and the state that exists immediately before effectuation.

State Machine A deployment MAY collapse internal states, but it MUST preserve the property that a Candidate Transition cannot create the protected consequence before final verification.

Solution Overview

Prepare The system constructs a Candidate Transition and a canonical Transition Descriptor. Preparation MUST NOT itself create the protected consequence.

Validate The system evaluates policy and obtains the evidence required by the resource transition. Evidence can include attestation results, current ownership, lifecycle state, sanitization state, resource generation, destination authorization, or other protected state.

Authorize The system issues an Execution Handle bound to the exact Transition Descriptor and its constraints. A field that is security-relevant to the transition MUST either be bound into the authorization or be re-established at finalization under an equivalently strong invariant.

Finalize At the Final Enforcement Boundary, the system reconstructs or observes the concrete transition that is about to become effective, verifies its correspondence with the authorized transition, verifies required current state, consumes or bounds the authorization according to its allowed-use semantics, and only then permits effectuation.

Illustrative Pseudocode The following pseudocode is non-normative and intentionally independent of a particular cryptographic token format. function prepare_transition(resource, source, destination, operation): T.resource = resource.id T.source = source.id T.destination = destination.id T.operation = operation T.generation = protected_generation(resource) T.securityState = required_security_state(resource) T.policyVersion = current_policy_version() T.nonce = secure_random() T.expiry = current_time() + MAX_WINDOW return canonical_encode(T) function validate_transition(T): if not authenticated(T.source): return DENY if not authorized_destination(T.destination): return DENY if current_owner(T.resource) != T.source: return DENY if current_generation(T.resource) != T.generation: return DENY evidence = collect_required_evidence(T) if not policy_accepts(T, evidence): return DENY return issue_execution_handle( digest = HASH(T), generation = T.generation, expiry = T.expiry, nonce = T.nonce, constraints = policy_constraints(T)) function finalize_transition(observed_T, handle): begin_protected_finality_section() if handle.expired: reject() if handle.consumed: reject() if HASH(observed_T) != handle.digest: reject() if current_generation(observed_T.resource) != observed_T.generation: reject() if current_owner(observed_T.resource) != observed_T.source: reject() if not required_security_state_holds(observed_T): reject() if not sanitization_complete_if_required(observed_T): reject() if not current_policy_allows(observed_T): reject() protected_consume(handle) make_transition_effective(observed_T) commit_protected_finality_section() return SUCCESS The relationship between authorization consumption and hardware or system state change requires atomicity, idempotence, protected journaling, monotonic generations, or equivalent crash-consistency semantics. A failure between those operations MUST NOT create replayable authority or an effective transition that cannot be reconciled with protected state.

End-to-End Architecture

Execution-finality architecture +--------------------+ | Requester / | | Orchestrator | +---------+----------+ | | propose T v +--------------------+ | Candidate | | Transition | | no external effect | +---------+----------+ | v +--------------------+ +------------------+ | Policy / Evidence |<------| Attestation / | | Validator | | device evidence | +---------+----------+ +------------------+ | | exact-transition authorization v +--------------------+ | Non-Effective | | Ready State | +---------+----------+ | v ===================================================== FINAL ENFORCEMENT BOUNDARY ===================================================== | | exact resource / destination | generation / freshness | policy / security state | replay / required preconditions v +-----------+ | ALL TRUE? | +-----+-----+ / \ no yes | | v v REJECT PROTECTED COMMIT | v EXTERNAL EFFECT Components above the boundary can calculate, recommend, attest, validate, or prepare an operation. They do not independently possess authority to create the protected consequence unless they also satisfy the Final Enforcement Boundary role.

Attack Analysis

Replay Assume an attacker captures a previously valid authorization issued when resource E42 had generation 7802. Protected current state records generation 7814. Because the authorized generation and current generation do not correspond, finalization fails even if the captured object remains cryptographically authentic.

Resource Substitution Authorization is issued for E42. Malware substitutes E43 after policy evaluation. Exact transition binding causes the observed descriptor to differ from the authorized descriptor, and the transition is rejected.

Destination Substitution Authorization is issued for destination Host B. An intermediary changes the destination to Host C. Because destination identity is security relevant, the resulting transition no longer matches the authorized transition and is rejected.

Premature Reassignment The resource, source, and destination are correct, but required sanitization or security-state reset has not completed. The finality predicate is false and addressability MUST NOT change.

Duplicate Execution Where an Execution Handle is single-use, protected consumption of that handle makes a repeated attempt invalid. More generally, the implementation MUST enforce the handle's authorized use count or equivalent bounded-use semantics.

Bounded and Non-Bearer-Like Authorization A broad authorization such as "Host B may acquire memory" leaves several security-relevant dimensions unresolved. It may not identify the exact physical extent, previous owner, sanitize operation, allocation epoch, security state, or permitted number of executions. An execution-finality binding instead seeks to make authorization specific to the concrete transition. The desired property is that possession of authorization for T does not enable a different T-prime merely by changing parameters after validation. For T' != T: Pr[ Finalize(T', A_T) = SUCCESS ] <= epsilon where epsilon is negligible under the assumed cryptographic and enforcement security model.

The Alternate-Path Requirement Exact binding is insufficient if another mechanism can directly produce the same protected consequence without passing through the finality check.

A secure validator does not help if an effectuation bypass exists +--> Finality Check --> Effect | Request ----------+ | +---------------------> Effect bypass Every mechanism capable of producing the protected consequence MUST either pass through the Final Enforcement Boundary or enforce an equivalent invariant. This property may require hardware, firmware, hypervisor, device, switch, kernel, or other privileged enforcement depending on the protected resource.

Concurrency and Resource Generations Two transitions can race for the same resource. If T1 assigns E42 to B and T2 assigns E42 to C, both MUST NOT succeed for the same exclusive resource generation. A successful state transition SHOULD advance a protected generation, epoch, or equivalent version so a competing authorization bound to the previous state becomes stale. generation(E42) = g Success(T1, g) => generation(E42) = g + 1 therefore, for mutually exclusive T2: Success(T1, g) => Failure(T2, g)

Applicability Beyond Dynamic Memory The same invariant can apply when the protected consequence is accelerator assignment, device-interface assignment, DMA authority, storage-namespace remapping, network forwarding activation, or another transition where control or visibility changes between security domains. GPU slice: Tenant A -> Tenant B Device interface: Host A -> confidential VM B DMA region: unmapped -> device-readable Storage namespace: Tenant A -> Tenant B Network state: candidate -> externally active The concrete enforcement mechanism differs by resource. The shared principle is that computation, attestation, or policy approval does not itself create authority for a different or stale consequence.

Industrial Relevance and Standards Alignment This section identifies published industry directions to which the execution-finality model may be relevant. The examples are alignment points, not findings that the named technologies are insecure, non-conformant, or missing their documented protections. In particular, this document does not assume that a fabric forms one unrestricted trust zone merely because it provides fast peer communication. Existing access-control, confidential-computing, link-protection, and isolation mechanisms remain part of the security model.

Scale-Up Accelerator Fabrics: NVLink and UALink Modern AI fabrics intentionally make accelerator-to-accelerator communication less dependent on host-CPU mediation. NVIDIA's CUDA Compute Fabric Transport documentation describes unicast and multicast memory-sharing APIs that can map remote GPU physical memory into a local virtual address space; once a peer allocation is mapped and given access rights, kernels can access it using load and store operations . NVIDIA also documents multi-GPU confidential-computing configurations in which NVLink and NVSwitch participate in a protected system and in which GPU and switch attestation are part of the trust-establishment workflow . UALink is likewise designed as a low-latency, high-bandwidth scale-up interconnect for AI accelerators. The UALink Consortium describes direct load, store, and atomic operations between accelerators, and the UALink 1.0 specification defines UALinkSec to protect tenant traffic, including confidentiality and optional integrity with replay protection in supported confidential-computing deployments . These capabilities motivate, but do not prove, a need for an additional transition invariant. Where an accelerator fabric already authenticates endpoints, protects the link, and applies mapping or access rights, execution finality asks a narrower question: whether authority for a consequential operation is bound to the exact resource, destination, generation, and current security state that will be made effective. For example, authorization to map or move one region need not become reusable authority for a different region, destination, epoch, or later operation. This document therefore does not describe a "picosecond firewall" and does not assign a universal timing target. A hardware implementation can place final checks near an effectuation point, but achievable latency depends on the interconnect, protocol, implementation technology, and predicates being checked. Performance claims require measurement in a concrete implementation.

Model Weights and Runtime Inference State Model weights and inference state are security-sensitive assets in commercial AI infrastructure. Microsoft describes Confidential AI as protecting data and models throughout the AI lifecycle and specifically notes that protecting model weights can be critical where model training is resource-intensive or the weights embody sensitive model intellectual property . AWS describes architectures that use attested isolated execution and key release to protect proprietary model weights . Google Cloud similarly recommends Confidential Computing for GPUs where sensitive training data or model parameters require protection while in use . Runtime state can also be substantial and mobile. NVIDIA describes the LLM KV cache as GPU-resident intermediate attention state derived from prior tokens, and documents distributed KV-cache management and remote sharing across heterogeneous environments . This document does not assert that a particular cloud or accelerator implementation exposes such state across tenants. The relevance is that as weights, buffers, mappings, and runtime caches become more dynamically placed or shared, the lifecycle transitions governing who can address them become security sensitive in their own right. Execution finality can complement encryption and attestation by binding a specific release, mapping, copy, reassignment, or key-use decision to the concrete asset and current security domain at effectuation time. It is not a substitute for memory isolation, confidential computing, access control, or secure erasure.

Ordering, State-Transition, and Silicon Defects Some hardware or firmware security failures depend on a protected state transition occurring while a prerequisite is stale, incomplete, reordered, or observable through an unintended path. The finality model can serve as a compensating invariant for that class of failure when the consequential transition remains controllable: the operation stays non-effective until the required protected predicates are true, and stale generation or ownership state causes rejection. This scope is intentionally narrower than claiming to "fix unpatchable silicon". Execution finality does not, by itself, solve speculative-execution vulnerabilities, arbitrary microarchitectural side channels, analog leakage, Rowhammer-class faults, or any defect that leaks information without traversing a controlled effectuation path. It can reduce exposure only where the attack depends on a transition that the protected boundary can actually mediate. The residual limitations are discussed further in .

CXL and Disaggregated Memory CXL Dynamic Capacity provides a concrete example of why resource transitions deserve explicit security semantics. CXL 4.0 permits memory capacity to be added to or released from hosts at runtime and, for Dynamic Capacity used with its trusted-execution security mechanisms, requires memory to be overwritten or cryptographically cleared and trusted- execution state to be reset before capacity released by one host is added to another . CXL also specifies multi-host considerations intended to prevent simultaneous transactions to the same device-physical-address range. The execution-finality model aligns with those requirements rather than replacing them. A binding for pooled memory can make sanitization and revocation explicit predicates of the final transition. For resource r, old domain A, new domain B, and generation g, an illustrative invariant is: SafeReassign(r,A,B,g) => ResidualContentCleared(r,g) AND OldReferencesRevoked(A,r,g) AND CurrentOwner(r,g) = A AND DestinationBound(B,r,g+1) AND SingleUseAuthorization(r,A,B,g) AND NoBypassPath(r) "ResidualContentCleared" is intentionally defined by the underlying memory/security technology rather than by this document. "OldReferencesRevoked" means that mappings, capabilities, decoder state, DMA authority, or other references that would let the old security domain continue to exercise the protected access have been invalidated to the extent required by the concrete binding. These terms provide a protocol-independent way to express the preconditions; they do not redefine CXL's own conformance requirements.

Hyperscaler and Confidential-AI Alignment The relevance to cloud and confidential-computing infrastructure is not based on an assertion that Microsoft Azure, AWS, Google Cloud, NVIDIA, Arm, or another named platform is vulnerable to the motivating attack. Their published material instead demonstrates that protection of model weights, data in use, accelerator state, isolated execution, and attestation is already an industrial priority . Arm CCA, for example, provides Realm-based confidential computing with attestation and dynamic assignment of protected memory resources. The proposed model is intended to compose with such mechanisms by constraining the last security-sensitive transition rather than replacing the mechanisms that establish confidential execution or platform trust.

Open Questions, Critique, and Corrections Invited This document is an individual submission intended to expose the proposed invariant to adversarial technical review. Corrections are explicitly invited, including corrections to the descriptions of CXL, PCIe, SPDM, NVLink, UALink, confidential-computing systems, or other cited technologies. Brand and consortium names are used only to identify published mechanisms and possible alignment points, not to allege defects or non-conformance. Review is particularly requested on the following questions:

Do existing interconnect or attestation specifications already provide an equivalent exact-transition and final-effect invariant, and if so, under what threat model and at what boundary?
Can a valid authorization be transformed, replayed, or substituted after appraisal but before the consequential mapping, reassignment, copy, or state change becomes effective?
Are the generation, residual-content, revocation, and single-use predicates sufficient to model pooled-memory transitions, or are additional load-bearing states required?
What alternate effectuation paths would bypass the proposed boundary in realistic accelerator, CXL, SmartNIC, hypervisor, or firmware deployments?
Which parts of the problem properly belong in IETF security architecture, and which should remain in PCI-SIG, CXL, UALink, DMTF, vendor, or other domain-specific specifications?
What latency, concurrency, crash-consistency, or availability costs would make a proposed binding impractical on a hot path?

A useful negative result is also welcome: if a cited deployment already guarantees the invariant in across all relevant effectuation paths, documenting that fact would narrow the problem space and improve this work.

Relationship to Existing Work

RATS The RATS architecture defines roles and information flows for remote attestation . This document does not redefine Evidence, Attestation Results, Verifiers, or Relying Parties. Attestation output can be used as Validation Evidence. The additional question addressed here is whether the exact transition that consumes that evidence remains bound to current protected state at effectuation. A related individual submission applies execution-finality concepts more directly to attestation-bound authorization . This document narrows the motivating problem to security-critical resource transitions and composable interconnects.

SPDM SPDM provides device authentication, measurement, key exchange, and secured messaging capabilities . Those properties can supply identity, measurement, and session evidence. Execution finality does not replace SPDM; it constrains how such evidence is connected to a concrete resource transition.

PCIe IDE and TDISP PCIe IDE protects Transaction Layer Packets for confidentiality, integrity, and replay resistance . TDISP defines trusted device-interface assignment functions including trusted attach and detach . These mechanisms address transport and device-assignment security. The abstract model here focuses on exact transition binding and final verification of mutable resource state immediately before the protected consequence becomes effective.

CXL Dynamic Capacity CXL is used as a motivating example because Dynamic Capacity makes resource reassignment explicit and because CXL 4.0 already defines security requirements for clearing memory and resetting trusted-execution state when capacity is added to a host after release from another host . The proposal in this document should therefore be read as a general finality invariant that can complement such protocol requirements, not as a claim that CXL omits the sanitize-before-reassignment requirement.

IETF Security-Area Relevance The problem intersects remote attestation, authorization, secure channels, workload identity, capability use, TOCTOU resistance, replay prevention, and cross-layer security. The RATS Working Group is directly relevant to the attestation portion of the problem . The Security Area Open Meeting (SAAG) provides a cross-area forum for security discussion . This document does not claim a specific Working Group adoption path.

Related Execution-Finality Work A separate individual submission describes hardware-enforced execution finality for consequential actions . The present document is intentionally narrower: it focuses on the resource-transition problem exposed by dynamic composability and interconnect-mediated changes in authority.

Operational and Deployment Considerations

Placement of the Final Enforcement Function The finality role need not be a single physical component. It can be distributed across a device, host, switch, hypervisor, kernel, security processor, or other protected subsystem. What matters is that all paths capable of creating the protected consequence satisfy the invariant in .

Latency Rechecking mutable state on the effectuation path introduces work. Deployments can reduce hot-path cost through protected caches, prevalidated evidence, local generation counters, or precomputed policy artifacts. Such optimization MUST NOT make stale precomputation independently sufficient to create the protected consequence.

Failure Handling If a required protected predicate cannot be established, high-consequence deployments SHOULD keep the Candidate Transition non-effective. Missing evidence, stale generation, indeterminate sanitization state, unavailable replay state, or conflicting ownership information SHOULD NOT silently become permission to proceed.

Security Considerations The security of this model depends on the completeness of the protected effectuation path. A correct Transition Descriptor and a valid Execution Handle do not provide the intended property if an attacker can create the same consequence through an unmediated alternate path.

Compromised Requester The requester is not assumed to be trustworthy. It can construct malicious or inconsistent Candidate Transitions. The protected consequence therefore MUST NOT depend solely on requester-supplied claims about resource identity, ownership, generation, destination, sanitization, or current policy state.

Compromised Orchestrator If an orchestrator can directly control every protected state variable and can also make the resource transition effective, compromise of that orchestrator can defeat the model. Deployments that seek protection from a compromised orchestrator SHOULD ensure that security-critical resource identity, current generation, ownership, and effectuation parameters are independently observable or protected at the Final Enforcement Boundary.

Validator Compromise Compromise of an authoritative validator can produce unauthorized Execution Handles. Higher-assurance deployments MAY use hardware-rooted enforcement, multiple independent validators, threshold authorization, independent policy appraisal, or equivalent mechanisms appropriate to the threat model.

Time-of-Check to Time-of-Use Mutable state can change after validation. Implementations SHOULD use generation values, epochs, freshness constraints, monotonic counters, protected continuity, or equivalent mechanisms so that a transition authorized against state S cannot silently execute against materially different state S-prime.

Replay and Rollback Execution Handles and protected transition state SHOULD resist replay, rollback, snapshot restoration, stale-epoch completion, and cross-resource or cross-domain reuse. A cryptographically authentic old authorization is not sufficient if its bound state is no longer current.

Canonicalization and Semantic Equivalence Transition Descriptors MUST have an unambiguous representation before hashing, signing, or MAC protection. A concrete binding MUST define whether any distinct encodings are semantically equivalent. Attackers MUST NOT be able to create a security-relevant parameter change that is ignored by authorization binding.

Non-Bypassability Every path that can create the protected consequence MUST pass through the Final Enforcement Boundary or provide an equivalent enforcement invariant. Debug interfaces, emergency control paths, firmware commands, alternate management planes, recovery tooling, direct device access, and privileged host interfaces require explicit analysis.

Crash Consistency Authorization consumption and effectuation can span multiple components. A crash between those steps MUST NOT leave replayable authority or an untracked effective transition. Implementations SHOULD use atomic state changes, idempotent recovery, protected journals, monotonic generations, or equivalent mechanisms.

Stale Attestation and Evidence Valid attestation evidence can become stale relative to mutable resource state. A verifier or relying party SHOULD distinguish evidence about comparatively static component identity or measurement from evidence about rapidly changing resource ownership, mapping, generation, and sanitization state.

Fail-Closed Behavior and Denial of Service Failure to establish a required predicate SHOULD keep high-consequence transitions non-effective. Such fail-closed behavior can be abused for denial of service. Availability engineering is therefore necessary, but recovery mechanisms MUST NOT introduce a permissive bypass around the required finality checks.

Residual-State Scope The motivating example concerns residual data after reassignment, but the model does not claim to eliminate all side channels, inferential leakage, microarchitectural leakage, or implementation defects. Those threats require their own mitigations. The property defined here is narrower: the protected resource transition must not become effective unless its required current preconditions hold.

Privacy Considerations Transition Descriptors and receipts can reveal tenant identifiers, workload relationships, resource topology, timing, security-domain membership, and allocation patterns. Implementations SHOULD minimize retained information and SHOULD avoid exposing raw tenant or resource identifiers beyond what is required for enforcement and audit. Pseudonymous identifiers, keyed commitments, selective disclosure, or other privacy-preserving representations MAY be used when compatible with the enforcement requirement.

IANA Considerations This document presently requests no IANA actions.

Conclusion Composable infrastructure changes the security object. Trust in a device, workload, or protected channel is not always sufficient when the consequential event is a dynamic transition in resource ownership, visibility, mapping, or authority. Attestation can establish evidence about trusted state. Secure transport can protect a request in transit. Access control can authorize a class of operations. Execution finality adds a separate invariant: the exact transition that becomes effective must still correspond to the transition whose security conditions were evaluated. In short, a trusted component does not necessarily imply a trusted transition.