changed deployment context, use term "owner control"

<mark>FIXME How are these functions reflected in security profiles?</mark>

## 4.4 Requirement applicability model

## 4.4 Architecture

### 4.4.1 Functional categories

## 4.4.1 Overview

<mark>FIXME Add when functional categories defined.</mark>

## 4.4.2 Deployment context

### 4.4.2 Applicable requirements

Boot managers face different security risks based on whether physical access is controlled. While physical access is the primary concern for local boot, network boot shifts the trust boundary to network infrastructure.

To determine which requirements apply:

In a protected environment physical access requires some form of authorization, either specific permission or organizational membership. Includes some levels of monitoring to minimal oversight. Examples: datacenter servers, network infrastructure, office workstations, corporate laptops, retail POS systems.

- Fundamental requirements (applies to all boot managers)

- If implementing functions, corresponding requirements apply

- Platform capabilities (TPM, secure storage) trigger additional requirements where specified

<mark>FIXME Criteria for when a function is implemented? How does a lab verify presence/absence?</mark>

<mark>FIXME Acceptable simulation/emulation environments</mark>

<mark>FIXME Test procedures for component-level verification</mark>

## 4.5 Deployment context

Unprotected environments don't offer reliable physical access control, anyone can reach and tamper with the device. No monitoring or detection of physical access. Examples: personal devices, ATMs, IoT devices, smart meters, vehicles, public kiosks.

Boot managers are a core component of hardware and software products. The difference is how the product is exposed to physical access by by authorized and unauthorized third-parties. While physical access is the primary concern for devices with local boot storage, network boot scenarios shift the trust boundary to network controls and boot image integrity.

Controlled environments restrict physical access to specifically authorized personnel through multiple security layers. Threat actors must either be authorized insiders or successfully bypass physical security controls. Examples include datacenter servers, HSMs, and critical infrastructure where access is logged and monitored.

Semi-controlled environments allow any organizationally authorized person to physically access the device without specific permission or detection. Threat actors with basic organizational access (employees, contractors or visitors) may modify boot configuration without raising alerts. Examples include office workstations, corporate laptops, and shared printers.

Uncontrolled environments expose devices to physical access by anyone. Threat actors have unlimited time and opportunity for tampering without detection. Examples include personal devices, ATMs, IoT devices, and other systems deployed outside organizational physical control.

<mark>FIXME add use cases</mark>

<mark>FIXME overhaul this section and or integrate with use cases</mark>

NOTE: Individual hardware components and software that contain or manage boot processes inherit security requirements from the complete system they're deployed in. 

## 4.6 Users and their interactions

## 4.5 Users

Boot managers operate in many cases without traditional user interaction during normal operation.

Boot managers operate in many cases without traditional user interaction during normal operation. Security decisions are predetermined by configuration, not made by users at runtime.

Users with direct interaction

- System administrators for configuration in enterprise context

- End users for selection of boot options when permitted

- Service technicians for maintenance and repair

- Testing labs

- Forensic analysts and security researchers

<mark>FIXME Automated tools?</mark>

- Firmware updates and rollback

- Bootloader unlocking for development or research

NOTE: Security decisions are predetermined by configuration, not made by users at runtime.

<mark>FIXME Boot managers collect hardware identifiers (MAC addresses, TPM IDs) that may be considered personal information when correlated by third parties, especially for remote attestation.</mark>

## 4.6 Use cases

<mark>FIXME use cases</mark>

## 4.7 Threat considerations

<mark>FIXME Detailed description and mitigations into Annex C</mark>

- Network boot attacks: Threats specific to network-based booting.

- Rollback and downgrade attacks: Attempts to revert to vulnerable versions.

For devices with a long lifetime, the following considerations should been taken into account:

- Cryptographic algorithm deprecation

- Key compromise over time

- Hardware aging and faults

## 4.8 Implementation considerations

### 4.8.1 Component testing

<mark>FIXME Proper grouping, formal requirement with SHALL statements; add requirement identifiers </mark>

<mark>FIXME Specify test methods for each requirement</mark>

<mark>FIXME adapt to PT1 structure?</mark>

<mark>FIXME Specify observable failure behaviors</mark>

<mark>FIXME Map threats to mitigation requirements (here or  Annex C)</mark>

## 5.1 Applicable requirements

- Basic requirements (applies to all boot managers)

- If implementing functions, corresponding requirements apply

- Platform capabilities (TPM, secure storage) trigger additional requirements where specified

<mark>FIXME Criteria for when a function is implemented? How does a lab verify presence/absence?</mark>

<mark>FIXME Acceptable simulation/emulation environments</mark>

<mark>FIXME Specify test methods for each requirement</mark>

## 5.1 Basic security requirements

- Update integrity verification

- Recovery if update fails

<mark>FIXME How to handle devices that cannot be updated?</mark>

<mark>FIXME Update mechanisms for constrained devices</mark>

<mark>FIXME How to handle devices that cannot easily be updated?</mark>

## 5.5 Attack resilience

- Debug interface exploitation

- Time-bounded operations to prevent delays

- Clear sensitive data after use

- Protect against fault injection where feasible

<mark>FIXME How to verify "secure key storage" without access to internals?</mark>

## 5.6 Vendor neutrality

## 5.6 Owner control

<mark>FIXME Better term for "vendor neutrality"</mark>

- Support for multiple certificate authorities

- Backup/recovery of trust settings and keys

- User-enrollable keys

- Alternative boot paths

- Support for multiple certificate authorities

<mark>FIXME Develop requirements ensuring boot managers don't create vendor lock-in</mark>