-**[REQ-UPDATES-1]:** The product shall maintain a monotonic version counter or equivalent mechanism to prevent installation of updates with an older vulnerable version.
-**[REQ-UPDATES-2]:** If the product supports intentional rollback, this action shall require explicit authorisation and shall be based on separately versioned and signed rollback metadata.
-**[REQ-UPDATES-3]:** The product shall apply updates in an atomic manner such that incomplete or failed updates do not result in a partially updated state. In the event that an update cannot be completed successfully, the product shall automatically restore a previously operational software state, ensuring the product remains functional.
-**[REQ-UPDATES-5]:** The product shall log update availability if applicable.
-**[REQ-UPDATES-6]:** The product shall log start and finish of the update download if applicable.
These requirements are generally binding, and there is no low-medium-high tiering available.
<mark>Editor's Note: Consider making [REQ-UPDATES-3] applicable only for high tier.</mark>
The requirements REQ-UPDATES-5 and REQ-UPDATES-6 are conditional due to different operative management models.
A cellphone that is connected to a corporate inventory management often has it's own update manager, and the device does not rely on the centralised control.
Similary in a modern cluster deployment, the application can not update itself, as the control is in the cluster, which makes the provisioning, scheduling and network shaping decisions for all applications ran in the same context.
Applying automatic updates are also subject to the operative environment design.
In some occasions, the cluster design does not have the capasity to provison the extra workload needed to make a seameless trasfer of application functions.
Distributed application design and delay lines built with buffers might tolerate partial downtime of individual components and services, but as the upgrade controller designs are not fully matured, the evaluation of upgrade structures needs to be left for the assessors.
### 5.3.5 Logging
@@ -877,10 +885,8 @@ The following requirements apply where the corresponding function exists:
-**[REQ-LOG-2a]:** The product shall log boot or initialisation events including timestamped boot stage progression.
-**[REQ-LOG-2b]:** The product shall log boot or initialisation events including component verification and initialisation actions.
-**[REQ-LOG-2c]:** The product shall log boot or initialisation events including recovery mode activations if in use.
-**[REQ-LOG-3a]:** The product shall log update availability.
-**[REQ-LOG-3b]:** The product shall log start and finish of the update download.
-**[REQ-LOG-3c]:** The product shall log events described by [5.3.4 Secure updates].
-**[REQ-LOG-3d]:** The product shall log installation successes and failures.
-**[REQ-LOG-3d]:** The product shall log installation successes and failures in the managed devices and the product itself if that information can be extracted from the targets.
For medium risk:
@@ -1344,6 +1350,8 @@ There are three different types of assessments used in this document.
