ETSI EN 304 623
CYBER; CRA; Essential cybersecurity requirements for boot managers · vertical pack 0.1.0 · 98 clause-5 requirements
INTERIM DRAFT — ETSI open consultation; subject to substantial change before publication (target: second half of 2026). Not cited in the Official Journal: conformance confers NO presumption of conformity today.
This is a vertical pack: a product-category standard, published in full and evaluated alongside the horizontal CRA rule pack— it supplements that pack for one Annex III category, it does not replace it. Everything below — every requirement, applicability entry, assessment block, correspondence row, threat and draft defect — is rendered from the same file the assessment engine reads. Nothing is generated at answer time, so this page cannot drift from what the product evaluates.
The same data, machine-readable, is served at /api/pack/vertical?id=en-304-623 — fetch it, keep a copy, and diff it when the draft moves. Because the standard is a moving draft, the source card pins exactly which text this pack was built from, and the draft gaps card records the defects we found in that text rather than papering over them.
On this page: source & license · how it attaches · requirement index · full text · CRA correspondence · threats · draft gaps · how it's built
Source, license and attribution
- Source: https://labs.etsi.org/rep/stan4cra/en-304-623 (the ETSI Labs draft repository), commit
b1611ce6, retrieved 2026-09-02. - License: BSD-3-Clause, © 2025 ETSI. Redistributed with attribution as the license requires; the verbatim requirement and assessment text below is reproduced from the interim draft.
To be plain about what that means: the normative requirement and assessment text on this page is reproduced verbatim from the interim draft under the license above, with the required copyright notice, conditions and disclaimer preserved in full below. The draft is a consultation document, not an ETSI deliverable — approved versions of ETSI standards are available only from the ETSI Documentation Service, and nothing reproduced here confers any presumption of conformity.
Full license text
Copyright 2025 ETSI
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors
may be used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
How this pack attaches
The pack applies to products classified under the CRA Annex III item “Boot managers” (pack category id: important-1). Attaches to a product whose CRA classification matched the Annex III boot managers item, or manually. The horizontal CRA pack keeps evaluating the product either way; this pack adds the category-specific requirements on top.
Scope (the draft’s own)
## 1.1 General
The present document specifies technical cybersecurity product requirements for boot managers based on the Essential Cybersecurity Requirements in the Regulation (EU) 2024/2847 (Cyber Resilience Act).
The scope covers software and firmware components that manage the boot process from power-on through establishment of the chain of trust to handoff to the boot target.
Requirements apply using a risk-based approach determined by risk factors in clause 4.7.8 and capability-based conditions defined in clause 4.3.3.
## 1.2 In-scope products
Products in scope include are boot management software and firmware regardless of distribution model or integration level. These are:
- System firmware that performs hardware initialisation and boot management
- Bootloaders that manage boot target selection, verification, and loading
- Embedded boot firmware in IoT and embedded devices
- Network boot implementations enabling remote boot capabilities
- Boot managers that integrate with hardware security components for chain of trust establishment
NOTE 1: Boot managers may be single-stage (direct loading) or multi-stage (staged verification).
NOTE 2: For microcontrollers (MCUs) and microprocessors (MPUs):
- Silicon-integrated immutable firmware: Mask ROM, fused code, or boot firmware integrated during chip manufacturing is assessed as part of MCU/MPU hardware under semiconductor standards.
- Updateable boot managers: Boot software in flash storage (including OTP programmed post-manufacture) is assessed using this standard when distinctly identifiable or independently updatable.
NOTE 3: Runtime services executing after boot target handoff (such as secure monitor mode handlers or attestation services) are in scope only if they provide verification or attestation services to the boot process itself, not to the boot target.
Applicability (the draft’s own)
This clause establishes cybersecurity requirements implementing Annex I Part I and Part II of Regulation (EU) 2024/2847.
Requirements apply based on risk level (LOW, MEDIUM, HIGH) derived from deployment context assessment per clause 4.7.8, ensuring cybersecurity measures are proportionate to identified risks and fit for purpose. Product capabilities (verified boot, updatability, configuration capability, etc.) determine additional applicability conditions. Each requirement explicitly specifies its applicability.
Requirements address boot manager security properties including initial trust establishment without prior security infrastructure, operation under resource constraints, and protection against persistent compromise.
The 5 use cases
Applicability is declared per use case: the draft defines 5 product contexts, and each clause-5 requirement states, per use case, whether it is required. The index below renders every column; enabling the pack on an assessment means choosing one of these.
Immutable embeddedUC-L1
Boot manager in isolated devices with no update capability and fixed configuration. Code is immutable after manufacture.
Examples: Environmental sensors, simple embedded controllers, basic IoT sensors, electronic toys, ROM-based microcontrollers.
Capabilities: No updates, no configuration, no logging, no recovery.
Updateable IoT and consumerUC-L2
Boot manager in connected consumer devices with update capability and basic configuration. Limited security features appropriate for non-sensitive applications.
Examples: Smart TVs, gaming consoles, smart home devices, e-readers, consumer appliances, development boards.
Capabilities: Updates, basic configuration, optional: verified boot, logging.
Consumer and SMB computingUC-M1
Boot manager in general-purpose computing devices storing personal or business data. Verified boot and logging enable security monitoring.
Examples: Laptops, desktops, tablets, smartphones, small business servers, NAS devices, connected vehicles.
Capabilities: Verified boot, logging, configuration, updates. Optional: recovery, authentication.
Enterprise managedUC-M2
Boot manager in enterprise infrastructure under centralised management. Full management suite enables policy enforcement and attestation.
Examples: Enterprise workstations, servers, network infrastructure, virtualisation hosts, managed endpoints.
Capabilities: Verified boot, measured boot, network boot, logging, configuration, authentication, recovery. Optional: hardware security storage.
Critical systemsUC-H1
Boot manager in systems where compromise causes safety impact, critical service disruption, or severe data breach. Maximum security controls with hardware enforcement.
Examples: Medical devices, industrial control systems, financial infrastructure, government systems, telecommunications infrastructure, critical facility management.
Capabilities: Full suite including hardware security storage and hardware security enforcement.
NOTE: UC-H1 includes varied deployment contexts (connected vs isolated, healthcare vs industrial). Manufacturers conduct detailed risk assessment per clause 4.7.8 based on specific deployment.
Requirement index
Every requirement in one place: the 98 clause-5 requirements with their per-use-case applicability. Ids link to the full verbatim text below; each row is addressable so a review can cite specific rows.
| Id | Requirement (first line) | UC-L1 | UC-L2 | UC-M1 | UC-M2 | UC-H1 |
|---|---|---|---|---|---|---|
| 5.2 — Security by Design | ||||||
| RQ-SBD-001 | The boot manager shall isolate boot components using memory protection, privilege separation, or hardware isolation mechanisms available on platform. | ● | ● | ● | ● | ● |
| RQ-SBD-002 | The boot manager shall restrict access to cryptographic key material to authorised boot components as defined by the boot manager's security policy. | ● | ● | ● | ● | ● |
| RQ-SBD-003 | The boot manager shall, before boot target handoff: disable debug interfaces, revoke DMA-capable device access, release hardware resources, free allocated memory, clear network buffers, and restrict memory regions to those required by the boot target. | ● | ● | ● | ● | ● |
| RQ-SBD-004 | The boot manager shall enforce privilege boundaries preventing privilege escalation between boot stages or across trust boundaries. | ● | ● | ● | ● | ● |
| 5.3 — Secure by Default Configuration | ||||||
| RQ-DEFAULT-001 | The boot manager shall enable cryptographic signature validation by default. | ● | ● | ● | ● | ● |
| RQ-DEFAULT-002 | The boot manager shall not contain any default passwords, maintenance backdoors, or undocumented access methods. | ● | ● | ● | ● | ● |
| RQ-DEFAULT-003 | The boot manager shall require credentials to be established during initial deployment when using password authentication. | ● | ● | ● | ● | ● |
| RQ-DEFAULT-004 | The boot manager shall prevent automatic fallback to less secure boot modes. | ● | ● | ● | ● | ● |
| RQ-DEFAULT-005 | The boot manager shall provide user-visible indication when security is being reduced. | ● | ● | ● | ● | ● |
| RQ-DEFAULT-006 | The boot manager shall support restoration of secure defaults. | ● | ● | ● | ● | ● |
| 5.4 — Authentication and Authorisation | ||||||
| RQ-AUTH-001 | The boot manager shall require physical presence for changes to trusted keys, certificates, or trust anchor databases. | ● | ● | ● | ● | ● |
| RQ-AUTH-002 | The boot manager shall protect boot order and boot parameters from unauthorised modification. | ● | ● | ● | ● | ● |
| RQ-AUTH-003 | The boot manager shall require explicit user action and authentication before weakening secure defaults, downgrading security settings, or modifying security-critical options. | ● | ● | ● | ● | ● |
| RQ-AUTH-004 | The boot manager shall limit authentication attempts with increasing delays between failed attempts where passwords are used. | ● | ● | ● | ● | ● |
| RQ-AUTH-005 | The boot manager shall verify digital signatures of boot security configuration policies before application. | ● | ● | ● | ● | ● |
| RQ-AUTH-006 | The boot manager shall indicate when running with modified policies through persistent visual indication or logged events. | ● | ● | ● | ● | ● |
| 5.5 — Confidentiality | ||||||
| RQ-CONFID-001 | The boot manager shall maintain separate key material for verification, encryption, and decryption operations. | ● | ● | ● | ● | ● |
| RQ-CONFID-002 | The boot manager shall protect trusted certificate stores from unauthorised modification. | ● | ● | ● | ● | ● |
| RQ-CONFID-003 | The boot manager shall exclude sensitive data from crash dumps and logs. | ● | ● | ● | ● | ● |
| RQ-CONFID-004 | The boot manager shall hash stored credentials including user passwords and recovery keys. | ● | ● | ● | ● | ● |
| RQ-CONFID-005 | The boot manager shall encrypt network boot parameters containing authentication information in storage. | ● | ● | ● | ● | ● |
| RQ-CONFID-006 | The boot manager shall exclude cryptographic keys and mask partial key material or authentication tokens from all logs. | ● | ● | ● | ● | ● |
| RQ-CONFID-007 | The boot manager shall cryptographically erase all sensitive data and clear all user-enrolled keys and certificates during secure disposal. | ● | ● | ● | ● | ● |
| RQ-CONFID-008 | The boot manager shall indicate successful sanitisation completion when secure disposal is supported. | ● | ● | ● | ● | ● |
| RQ-CONFID-009 | The boot manager shall protect the confidentiality of boot configuration data transmitted over network. | ● | ● | ● | ● | ● |
| RQ-CONFID-010 | The boot manager shall overwrite sensitive data after use, clear temporary data structures and credentials before boot target handoff, and not persist authentication credentials or cryptographic material beyond the current boot cycle. | ● | ● | ● | ● | ● |
| 5.6 — Integrity Protection | ||||||
| RQ-INTEGRITY-001 | The boot manager shall verify integrity and authenticity of each boot stage using cryptographic hashes and digital signatures, establishing chain of trust to a root trust anchor before transferring control. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-002 | The boot manager shall prevent boot continuation with unverified components and reject components with invalid, expired, revoked, or substituted signatures. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-003 | The boot manager shall verify component provenance through certificates and check component compatibility and version consistency. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-004 | The boot manager shall verify authenticity and integrity of update packages before installation and after network transfer. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-005 | The boot manager shall detect unauthorised firmware modifications using at least two distinct verification mechanisms; use software-based cryptography with protected storage when hardware security components are unavailable. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-006 | The boot manager shall maintain a configurable list of approved signatures. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-007 | The boot manager shall support multiple signature formats. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-008 | The boot manager shall require authentication before allowing verification bypass. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-009 | The boot manager shall prevent unauthorised modification between verification and execution. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-010 | The boot manager shall load components into protected memory before verification. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-011 | The boot manager shall execute verification checks atomically preventing TOCTOU vulnerabilities. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-012 | The boot manager shall protect sensitive configuration settings with authenticated encryption. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-013 | The boot manager shall restore secure defaults when configuration corruption is detected. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-014 | The boot manager shall prevent unauthorised runtime modification of boot code. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-015 | The boot manager shall authenticate network boot servers using cryptographic certificates. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-016 | The boot manager shall reject network boot connections with invalid, expired, or revoked server certificates. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-017 | The boot manager shall verify DHCP and PXE responses originate from authorised infrastructure. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-018 | The boot manager shall enforce rollback protection for firmware and security configuration by default. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-019 | The boot manager shall store anti-rollback counters in hardware-backed or tamper-evident storage and verify signed version metadata before accepting updates. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-020 | The boot manager shall support hierarchical trust with separate manufacturer and owner trust domains, owner-installable certificates, and certificate authority transitions during ownership changes. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-021 | The boot manager shall verify the entire certificate chain to a trusted root, including validity periods and revocation status. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-022 | The boot manager shall support revocation of compromised keys and certificates through a revocation database or configuration updates. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-023 | The boot manager shall use cryptographic algorithms, key sizes, and parameters listed in ECCG Agreed Cryptographic Mechanisms [2] or demonstrably equivalent state-of-the-art mechanisms.. | ● | ● | ● | ● | ● |
| RQ-INTEGRITY-024 | The boot manager shall support cryptographic algorithm updates through updateable trust anchors or multiple algorithm support. | ● | ● | ● | ● | ● |
| 5.7 — Data Minimisation | ||||||
| RQ-MINIMAL-001 | The boot manager shall minimise network disclosure by requesting only necessary files, negotiating only required protocol parameters, and exposing only MAC address and device class. | ● | ● | ● | ● | ● |
| RQ-MINIMAL-002 | The boot manager shall not disclose firmware version, hardware serial numbers, or internal configuration in network protocols, and shall not retain network credentials beyond use. | ● | ● | ● | ● | ● |
| RQ-MINIMAL-003 | The boot manager shall store only essential boot parameters, security policy settings, and boot device priorities in configuration storage. | ● | ● | ● | ● | ● |
| 5.8 — Availability and Resilience | ||||||
| RQ-AVAIL-001 | The boot manager shall support fallback to previous known-good configuration. | ● | ● | ● | ● | ● |
| RQ-AVAIL-002 | The boot manager shall automatically recover from corrupted configuration data. | ● | ● | ● | ● | ● |
| RQ-AVAIL-003 | The boot manager shall support redundant boot paths. | ● | ● | ● | ● | ● |
| RQ-AVAIL-004 | The boot manager shall indicate which boot image is currently active when multiple images are maintained. | ● | ● | ● | ● | ● |
| RQ-AVAIL-005 | The boot manager shall enforce timeouts for all operations including parsing and network operations, preventing indefinite hangs. | ● | ● | ● | ● | ● |
| RQ-AVAIL-006 | The boot manager shall limit retry attempts and resource consumption for signature verification and network operations. | ● | ● | ● | ● | ● |
| RQ-AVAIL-007 | The boot manager shall not allow security verification steps to be skipped. | ● | ● | ● | ● | ● |
| RQ-AVAIL-008 | The boot manager shall detect and correct errors in critical data. | ● | ● | ● | ● | ● |
| RQ-AVAIL-009 | The boot manager shall store essential boot code redundantly. | ● | ● | ● | ● | ● |
| RQ-AVAIL-010 | The boot manager shall verify critical structures through checksums. | ● | ● | ● | ● | ● |
| RQ-AVAIL-011 | The boot manager shall require authentication or physical presence for recovery mode. | ● | ● | ● | ● | ● |
| RQ-AVAIL-012 | The boot manager shall handle network boot failures by implementing timeouts with local fallback, exponential backoff retries, multiple server options, and maintain local boot capability under denial-of-service conditions. | ● | ● | ● | ● | ● |
| RQ-AVAIL-013 | The boot manager shall generate logs of security failure conditions protected against tampering through cryptographic binding, hardware security components, or write-once storage. | ● | ● | ● | ● | ● |
| RQ-AVAIL-014 | The boot manager shall use time representations for certificates, internal time, and timestamps that remain valid beyond 2038. | ● | ● | ● | ● | ● |
| RQ-AVAIL-015 | The boot manager shall protect recovery mechanisms from unauthorised modification or disablement. | ● | ● | ● | ● | ● |
| RQ-AVAIL-016 | The boot manager shall, on security or verification failure: halt boot, maintain integrity, prevent partial execution, and not attempt sensitive operations when cryptographic components are unavailable. | ● | ● | ● | ● | ● |
| RQ-AVAIL-017 | The boot manager shall enter recovery mode or reset on security violations and shall not bypass security controls on failure. | ● | ● | ● | ● | ● |
| RQ-AVAIL-018 | The boot manager shall indicate errors with sufficient detail to guide recovery actions. | ● | ● | ● | ● | ● |
| RQ-AVAIL-019 | The boot manager shall maintain recovery accessibility even with corrupted primary image and preserve recovery capability across updates. | ● | ● | ● | ● | ● |
| 5.9 — Impact Minimisation | ||||||
| RQ-IMPACT-001 | The boot manager shall avoid broadcast storms and network loops during network operations. | ● | ● | ● | ● | ● |
| 5.10 — Attack Surface Minimisation | ||||||
| RQ-SURFACE-001 | The boot manager shall exclude non-essential code from production builds including test code, debug instrumentation, coverage tools, experimental features, and unsupported platform code. | ● | ● | ● | ● | ● |
| RQ-SURFACE-002 | The boot manager shall disable debug interfaces, diagnostic consoles, test modes, and verbose logging in production configuration. | ● | ● | ● | ● | ● |
| RQ-SURFACE-003 | The boot manager shall disable unused hardware interfaces, legacy protocols, and non-essential network services. | ● | ● | ● | ● | ● |
| RQ-SURFACE-004 | The boot manager shall not expose debug shells, diagnostic consoles, or interactive command interfaces in production configuration. | ● | ● | ● | ● | ● |
| RQ-SURFACE-005 | The boot manager shall require authentication before activation of debug capabilities that cannot be disabled. | ● | ● | ● | ● | ● |
| RQ-SURFACE-006 | The boot manager shall validate all inputs with bounds checking and size limits, reject malformed or oversized data. | ● | ● | ● | ● | ● |
| RQ-SURFACE-007 | The boot manager shall perform verification checks using at least two independent mechanisms. | ● | ● | ● | ● | ● |
| RQ-SURFACE-008 | The boot manager shall validate structure and format of boot images, certificates, configuration, and cryptographic data before processing. | ● | ● | ● | ● | ● |
| RQ-SURFACE-009 | The boot manager shall detect errors in critical operations and reject non-compliant inputs; transition to error handling on faults. | ● | ● | ● | ● | ● |
| RQ-SURFACE-010 | The boot manager shall protect configuration by detecting unauthorised modifications, using checksums/hashes, and limiting configurable options to essential parameters. | ● | ● | ● | ● | ● |
| 5.11 — Logging and Monitoring | ||||||
| RQ-LOG-001 | The boot manager shall record measurements of boot components and security-critical configuration in tamper-resistant storage before execution or handoff. | ● | ● | ● | ● | ● |
| RQ-LOG-002 | The boot manager shall protect measurement records from unauthorised modification or deletion using cryptographic mechanisms, hardware-protected storage, or tamper-evident recording. | ● | ● | ● | ● | ● |
| RQ-LOG-003 | The boot manager shall provide measurement records in a format supporting remote attestation by external parties, with freshness mechanisms to prevent replay of stale measurements, including component hashes, register indices, event types, and version information. | ● | ● | ● | ● | ● |
| RQ-LOG-004 | The boot manager shall indicate security-relevant failures and state changes including verification failures, authentication failures, security policy violations, recovery mode activation, and execution of unsigned code. | ● | ● | ● | ● | ● |
| RQ-LOG-005 | The boot manager shall protect confidentiality of measurement records during transmission to external verifiers. | ● | ● | ● | ● | ● |
| 5.12 — Vulnerability Management | ||||||
| RQ-VULN-001 | The boot manager shall provide version information accessible to operating system or management systems. | ● | ● | ● | ● | ● |
| RQ-VULN-002 | The boot manager shall implement update mechanisms enabling vulnerability remediation where update capability exists. | ● | ● | ● | ● | ● |
| RQ-VULN-003 | The boot manager shall implement status indicators for available updates where user interfaces exist. | ● | ● | ● | ● | ● |
| RQ-VULN-004 | The boot manager shall support update availability checks when network capable. | ● | ● | ● | ● | ● |
| RQ-VULN-005 | The boot manager shall implement at least two distinct security mechanisms (e.g., memory protection and input validation, or hardware isolation and cryptographic verification). | ● | ● | ● | ● | ● |
| RQ-VULN-006 | The boot manager shall enable security policy updates through configuration, allow disabling features to address vulnerabilities, and maintain configuration update capability throughout product lifetime. | ● | ● | ● | ● | ● |
| RQ-VULN-007 | The boot manager shall verify updates before committing, accept updates only from authenticated sources, and store update verification keys in hardware security component where available. | ● | ● | ● | ● | ● |
| RQ-VULN-008 | The boot manager shall execute update operations atomically, maintain backup of previous version, and automatically rollback on update failure. | ● | ● | ● | ● | ● |
| RQ-VULN-009 | The boot manager shall isolate update logic from normal boot path, preventing update failures from affecting other components. | ● | ● | ● | ● | ● |
| RQ-VULN-010 | The boot manager shall receive updates over authenticated and encrypted communication channel and detect tampering during update process. | ● | ● | ● | ● | ● |
| 5.13 — Security Testing and Review | ||||||
● = required for that use case · — = not required. Use cases: UC-L1 Immutable embedded · UC-L2 Updateable IoT and consumer · UC-M1 Consumer and SMB computing · UC-M2 Enterprise managed · UC-H1 Critical systems.
5.2 — Security by Design
This subclause addresses CRA requirements for secure design, development, and production. Boot manager security architecture need to integrate protective measures from initial design through implementation, considering pre-OS constraints, limited resources, and critical boot integrity requirements. This clause implements the principle of security by design as defined in prEN 40000-1-2.
RQ-SBD-001 — The boot manager shall isolate boot components using memory protection, privilege separation, o…Clause 5.2
Requirement (verbatim from the interim draft)
The boot manager shall isolate boot components using memory protection, privilege separation, or hardware isolation mechanisms available on platform.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SBD-002 — The boot manager shall restrict access to cryptographic key material to authorised boot compone…Clause 5.2
Requirement (verbatim from the interim draft)
The boot manager shall restrict access to cryptographic key material to authorised boot components as defined by the boot manager's security policy.
Applicability
Applies to all boot managers with cryptographic keys.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SBD-003 — The boot manager shall, before boot target handoff: disable debug interfaces, revoke DMA-capabl…Clause 5.2
Requirement (verbatim from the interim draft)
The boot manager shall, before boot target handoff: disable debug interfaces, revoke DMA-capable device access, release hardware resources, free allocated memory, clear network buffers, and restrict memory regions to those required by the boot target.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SBD-004 — The boot manager shall enforce privilege boundaries preventing privilege escalation between boo…Clause 5.2
Requirement (verbatim from the interim draft)
The boot manager shall enforce privilege boundaries preventing privilege escalation between boot stages or across trust boundaries.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.3 — Secure by Default Configuration
This subclause addresses CRA requirements for secure default configuration. Boot managers shall be put on the market with security features enabled, no default credentials, and protection matching available hardware and software resources. This clause implements the principle of secure by default as defined in prEN 40000-1-2.
RQ-DEFAULT-001 — The boot manager shall enable cryptographic signature validation by default.Clause 5.3
Requirement (verbatim from the interim draft)
The boot manager shall enable cryptographic signature validation by default.
Applicability
Applies to all boot managers with verified boot.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-DEFAULT-002 — The boot manager shall not contain any default passwords, maintenance backdoors, or undocumente…Clause 5.3
Requirement (verbatim from the interim draft)
The boot manager shall not contain any default passwords, maintenance backdoors, or undocumented access methods.
Applicability
Applies to all boot managers.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-DEFAULT-003 — The boot manager shall require credentials to be established during initial deployment when usi…Clause 5.3
Requirement (verbatim from the interim draft)
The boot manager shall require credentials to be established during initial deployment when using password authentication.
Applicability
Applies to all boot managers with configuration capability using password authentication.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-DEFAULT-004 — The boot manager shall prevent automatic fallback to less secure boot modes.Clause 5.3
Requirement (verbatim from the interim draft)
The boot manager shall prevent automatic fallback to less secure boot modes.
Applicability
Applies to all boot managers with verified or measured boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-DEFAULT-005 — The boot manager shall provide user-visible indication when security is being reduced.Clause 5.3
Requirement (verbatim from the interim draft)
The boot manager shall provide user-visible indication when security is being reduced.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-DEFAULT-006 — The boot manager shall support restoration of secure defaults.Clause 5.3
Requirement (verbatim from the interim draft)
The boot manager shall support restoration of secure defaults.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
5.4 — Authentication and Authorisation
This subclause addresses CRA requirements for access control and authentication. Boot managers control code execution authorisation and configuration protection through cryptographic verification, physical presence detection, and hardware-based protections.
RQ-AUTH-001 — The boot manager shall require physical presence for changes to trusted keys, certificates, or…Clause 5.4
Requirement (verbatim from the interim draft)
The boot manager shall require physical presence for changes to trusted keys, certificates, or trust anchor databases.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level HIGH. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-AUTH-002 — The boot manager shall protect boot order and boot parameters from unauthorised modification.Clause 5.4
Requirement (verbatim from the interim draft)
The boot manager shall protect boot order and boot parameters from unauthorised modification.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-AUTH-003 — The boot manager shall require explicit user action and authentication before weakening secure…Clause 5.4
Requirement (verbatim from the interim draft)
The boot manager shall require explicit user action and authentication before weakening secure defaults, downgrading security settings, or modifying security-critical options.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-AUTH-004 — The boot manager shall limit authentication attempts with increasing delays between failed atte…Clause 5.4
Requirement (verbatim from the interim draft)
The boot manager shall limit authentication attempts with increasing delays between failed attempts where passwords are used.
Applicability
Applies to all boot managers with configuration capability using password authentication.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level MEDIUM. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-AUTH-005 — The boot manager shall verify digital signatures of boot security configuration policies before…Clause 5.4
Requirement (verbatim from the interim draft)
The boot manager shall verify digital signatures of boot security configuration policies before application.
Applicability
Applies to all boot managers with verified boot and configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level MEDIUM. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-AUTH-006 — The boot manager shall indicate when running with modified policies through persistent visual i…Clause 5.4
Requirement (verbatim from the interim draft)
The boot manager shall indicate when running with modified policies through persistent visual indication or logged events.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
5.5 — Confidentiality
This subclause addresses CRA requirements for data confidentiality. Boot managers shall protect cryptographic key material, credentials, and security policies in resource-constrained environments against persistent physical access threats.
RQ-CONFID-001 — The boot manager shall maintain separate key material for verification, encryption, and decrypt…Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall maintain separate key material for verification, encryption, and decryption operations.
Applicability
Applies to all boot managers with verified or measured boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-002 — The boot manager shall protect trusted certificate stores from unauthorised modification.Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall protect trusted certificate stores from unauthorised modification.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-003 — The boot manager shall exclude sensitive data from crash dumps and logs.Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall exclude sensitive data from crash dumps and logs.
Applicability
Applies to all boot managers with logging capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-004 — The boot manager shall hash stored credentials including user passwords and recovery keys.Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall hash stored credentials including user passwords and recovery keys.
Applicability
Applies to all boot managers with configuration and recovery capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level MEDIUM. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-CONFID-005 — The boot manager shall encrypt network boot parameters containing authentication information in…Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall encrypt network boot parameters containing authentication information in storage.
Applicability
Applies to all boot managers with configuration capability and network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-006 — The boot manager shall exclude cryptographic keys and mask partial key material or authenticati…Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall exclude cryptographic keys and mask partial key material or authentication tokens from all logs.
Applicability
Applies to all boot managers with logging capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-007 — The boot manager shall cryptographically erase all sensitive data and clear all user-enrolled k…Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall cryptographically erase all sensitive data and clear all user-enrolled keys and certificates during secure disposal.
Applicability
Applies to all boot managers with verified boot and configuration capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-008 — The boot manager shall indicate successful sanitisation completion when secure disposal is supp…Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall indicate successful sanitisation completion when secure disposal is supported.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-009 — The boot manager shall protect the confidentiality of boot configuration data transmitted over…Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall protect the confidentiality of boot configuration data transmitted over network.
Applicability
Applies to all boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-CONFID-010 — The boot manager shall overwrite sensitive data after use, clear temporary data structures and…Clause 5.5
Requirement (verbatim from the interim draft)
The boot manager shall overwrite sensitive data after use, clear temporary data structures and credentials before boot target handoff, and not persist authentication credentials or cryptographic material beyond the current boot cycle.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.6 — Integrity Protection
This subclause addresses CRA requirements for data and system integrity. Boot managers establish trust chains through cryptographic verification, measurement, and protection mechanisms that resist component substitution, rollback, and TOCTOU attacks.
RQ-INTEGRITY-001 — The boot manager shall verify integrity and authenticity of each boot stage using cryptographic…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall verify integrity and authenticity of each boot stage using cryptographic hashes and digital signatures, establishing chain of trust to a root trust anchor before transferring control.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-002 — The boot manager shall prevent boot continuation with unverified components and reject componen…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall prevent boot continuation with unverified components and reject components with invalid, expired, revoked, or substituted signatures.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-003 — The boot manager shall verify component provenance through certificates and check component com…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall verify component provenance through certificates and check component compatibility and version consistency.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-004 — The boot manager shall verify authenticity and integrity of update packages before installation…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall verify authenticity and integrity of update packages before installation and after network transfer.
Applicability
Applies to all boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-005 — The boot manager shall detect unauthorised firmware modifications using at least two distinct v…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall detect unauthorised firmware modifications using at least two distinct verification mechanisms; use software-based cryptography with protected storage when hardware security components are unavailable.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-006 — The boot manager shall maintain a configurable list of approved signatures.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall maintain a configurable list of approved signatures.
Applicability
Applies to all boot managers with verified boot and configuration capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-007 — The boot manager shall support multiple signature formats.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall support multiple signature formats.
Applicability
Applies to MEDIUM and HIGH risk boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-008 — The boot manager shall require authentication before allowing verification bypass.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall require authentication before allowing verification bypass.
Applicability
Applies to MEDIUM and HIGH risk boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-009 — The boot manager shall prevent unauthorised modification between verification and execution.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall prevent unauthorised modification between verification and execution.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-010 — The boot manager shall load components into protected memory before verification.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall load components into protected memory before verification.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-011 — The boot manager shall execute verification checks atomically preventing TOCTOU vulnerabilities.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall execute verification checks atomically preventing TOCTOU vulnerabilities.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-012 — The boot manager shall protect sensitive configuration settings with authenticated encryption.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall protect sensitive configuration settings with authenticated encryption.
Applicability
Applies to MEDIUM and HIGH risk boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level MEDIUM. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-INTEGRITY-013 — The boot manager shall restore secure defaults when configuration corruption is detected.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall restore secure defaults when configuration corruption is detected.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-INTEGRITY-014 — The boot manager shall prevent unauthorised runtime modification of boot code.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall prevent unauthorised runtime modification of boot code.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-015 — The boot manager shall authenticate network boot servers using cryptographic certificates.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall authenticate network boot servers using cryptographic certificates.
Applicability
Applies to MEDIUM and HIGH risk boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-016 — The boot manager shall reject network boot connections with invalid, expired, or revoked server…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall reject network boot connections with invalid, expired, or revoked server certificates.
Applicability
Applies to MEDIUM and HIGH risk boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-017 — The boot manager shall verify DHCP and PXE responses originate from authorised infrastructure.Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall verify DHCP and PXE responses originate from authorised infrastructure.
Applicability
Applies to all boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-018 — The boot manager shall enforce rollback protection for firmware and security configuration by d…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall enforce rollback protection for firmware and security configuration by default.
Applicability
Applies to MEDIUM and HIGH risk boot managers with update or configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level MEDIUM. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-INTEGRITY-019 — The boot manager shall store anti-rollback counters in hardware-backed or tamper-evident storag…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall store anti-rollback counters in hardware-backed or tamper-evident storage and verify signed version metadata before accepting updates.
Applicability
Applies to HIGH risk boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-020 — The boot manager shall support hierarchical trust with separate manufacturer and owner trust do…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall support hierarchical trust with separate manufacturer and owner trust domains, owner-installable certificates, and certificate authority transitions during ownership changes.
Applicability
Applies to MEDIUM and HIGH risk boot managers with verified boot and configuration capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-021 — The boot manager shall verify the entire certificate chain to a trusted root, including validit…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall verify the entire certificate chain to a trusted root, including validity periods and revocation status.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-022 — The boot manager shall support revocation of compromised keys and certificates through a revoca…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall support revocation of compromised keys and certificates through a revocation database or configuration updates.
Applicability
Applies to all boot managers with verified boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-023 — The boot manager shall use cryptographic algorithms, key sizes, and parameters listed in ECCG A…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall use cryptographic algorithms, key sizes, and parameters listed in ECCG Agreed Cryptographic Mechanisms [2] or demonstrably equivalent state-of-the-art mechanisms..
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-INTEGRITY-024 — The boot manager shall support cryptographic algorithm updates through updateable trust anchors…Clause 5.6
Requirement (verbatim from the interim draft)
The boot manager shall support cryptographic algorithm updates through updateable trust anchors or multiple algorithm support.
Applicability
Applies to MEDIUM and HIGH risk boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.7 — Data Minimisation
This subclause addresses CRA requirements for data minimisation. Boot managers shall process only data necessary for boot operations, security verification, and error indication, given memory and storage constraints.
RQ-MINIMAL-001 — The boot manager shall minimise network disclosure by requesting only necessary files, negotiat…Clause 5.7
Requirement (verbatim from the interim draft)
The boot manager shall minimise network disclosure by requesting only necessary files, negotiating only required protocol parameters, and exposing only MAC address and device class.
Applicability
Applies to all boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-MINIMAL-002 — The boot manager shall not disclose firmware version, hardware serial numbers, or internal conf…Clause 5.7
Requirement (verbatim from the interim draft)
The boot manager shall not disclose firmware version, hardware serial numbers, or internal configuration in network protocols, and shall not retain network credentials beyond use.
Applicability
Applies to all boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-MINIMAL-003 — The boot manager shall store only essential boot parameters, security policy settings, and boot…Clause 5.7
Requirement (verbatim from the interim draft)
The boot manager shall store only essential boot parameters, security policy settings, and boot device priorities in configuration storage.
Applicability
Applies to all boot managers with configuration capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.8 — Availability and Resilience
This subclause addresses CRA requirements for availability and resilience. Boot managers shall maintain availability during failures or attacks through recovery mechanisms, failsafe operations, and resistance to denial-of-service conditions.
NOTE: Where this subclause specifies limits without numeric values, the manufacturer shall document specific thresholds in security documentation per Annex C. Assessors verify defined and enforced limits.
RQ-AVAIL-001 — The boot manager shall support fallback to previous known-good configuration.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall support fallback to previous known-good configuration.
Applicability
Applies to all boot managers with configuration capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-002 — The boot manager shall automatically recover from corrupted configuration data.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall automatically recover from corrupted configuration data.
Applicability
Applies to all boot managers with configuration capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-003 — The boot manager shall support redundant boot paths.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall support redundant boot paths.
Applicability
Applies to MEDIUM and HIGH risk boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-004 — The boot manager shall indicate which boot image is currently active when multiple images are m…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall indicate which boot image is currently active when multiple images are maintained.
Applicability
Applies to MEDIUM and HIGH risk boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-005 — The boot manager shall enforce timeouts for all operations including parsing and network operat…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall enforce timeouts for all operations including parsing and network operations, preventing indefinite hangs.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-006 — The boot manager shall limit retry attempts and resource consumption for signature verification…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall limit retry attempts and resource consumption for signature verification and network operations.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-007 — The boot manager shall not allow security verification steps to be skipped.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall not allow security verification steps to be skipped.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-008 — The boot manager shall detect and correct errors in critical data.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall detect and correct errors in critical data.
Applicability
Applies to MEDIUM and HIGH risk boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-009 — The boot manager shall store essential boot code redundantly.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall store essential boot code redundantly.
Applicability
Applies to MEDIUM and HIGH risk boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-010 — The boot manager shall verify critical structures through checksums.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall verify critical structures through checksums.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-011 — The boot manager shall require authentication or physical presence for recovery mode.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall require authentication or physical presence for recovery mode.
Applicability
Applies to MEDIUM and HIGH risk boot managers with recovery capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-012 — The boot manager shall handle network boot failures by implementing timeouts with local fallbac…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall handle network boot failures by implementing timeouts with local fallback, exponential backoff retries, multiple server options, and maintain local boot capability under denial-of-service conditions.
Applicability
Applies to all boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-013 — The boot manager shall generate logs of security failure conditions protected against tampering…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall generate logs of security failure conditions protected against tampering through cryptographic binding, hardware security components, or write-once storage.
Applicability
Applies to MEDIUM and HIGH risk boot managers with verified boot or measured boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-014 — The boot manager shall use time representations for certificates, internal time, and timestamps…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall use time representations for certificates, internal time, and timestamps that remain valid beyond 2038.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-015 — The boot manager shall protect recovery mechanisms from unauthorised modification or disablemen…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall protect recovery mechanisms from unauthorised modification or disablement.
Applicability
Applies to all boot managers with recovery capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-016 — The boot manager shall, on security or verification failure: halt boot, maintain integrity, pre…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall, on security or verification failure: halt boot, maintain integrity, prevent partial execution, and not attempt sensitive operations when cryptographic components are unavailable.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-017 — The boot manager shall enter recovery mode or reset on security violations and shall not bypass…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall enter recovery mode or reset on security violations and shall not bypass security controls on failure.
Applicability
Applies to MEDIUM and HIGH risk boot managers with recovery capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-018 — The boot manager shall indicate errors with sufficient detail to guide recovery actions.Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall indicate errors with sufficient detail to guide recovery actions.
Applicability
Applies to all boot managers with recovery capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-AVAIL-019 — The boot manager shall maintain recovery accessibility even with corrupted primary image and pr…Clause 5.8
Requirement (verbatim from the interim draft)
The boot manager shall maintain recovery accessibility even with corrupted primary image and preserve recovery capability across updates.
Applicability
Applies to all boot managers with update and recovery capabilities.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.9 — Impact Minimisation
This subclause addresses CRA requirements for impact minimisation on other systems. Boot managers shall limit resource consumption, release hardware properly, and prevent cascading failures to connected devices or networks.
RQ-IMPACT-001 — The boot manager shall avoid broadcast storms and network loops during network operations.Clause 5.9
Requirement (verbatim from the interim draft)
The boot manager shall avoid broadcast storms and network loops during network operations.
Applicability
Applies to all boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.10 — Attack Surface Minimisation
This subclause addresses CRA requirements for attack surface minimisation. Boot managers shall implement minimal functionality, eliminate debug interfaces, and restrict all non-essential capabilities in production builds.
RQ-SURFACE-001 — The boot manager shall exclude non-essential code from production builds including test code, d…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall exclude non-essential code from production builds including test code, debug instrumentation, coverage tools, experimental features, and unsupported platform code.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SURFACE-002 — The boot manager shall disable debug interfaces, diagnostic consoles, test modes, and verbose l…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall disable debug interfaces, diagnostic consoles, test modes, and verbose logging in production configuration.
Applicability
Applies to all boot managers.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-SURFACE-003 — The boot manager shall disable unused hardware interfaces, legacy protocols, and non-essential…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall disable unused hardware interfaces, legacy protocols, and non-essential network services.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SURFACE-004 — The boot manager shall not expose debug shells, diagnostic consoles, or interactive command int…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall not expose debug shells, diagnostic consoles, or interactive command interfaces in production configuration.
Applicability
Applies to all boot managers with debug interface.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-SURFACE-005 — The boot manager shall require authentication before activation of debug capabilities that cann…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall require authentication before activation of debug capabilities that cannot be disabled.
Applicability
Applies to all boot managers.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-SURFACE-006 — The boot manager shall validate all inputs with bounds checking and size limits, reject malform…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall validate all inputs with bounds checking and size limits, reject malformed or oversized data.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SURFACE-007 — The boot manager shall perform verification checks using at least two independent mechanisms.Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall perform verification checks using at least two independent mechanisms.
Applicability
Applies to MEDIUM and HIGH risk boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SURFACE-008 — The boot manager shall validate structure and format of boot images, certificates, configuratio…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall validate structure and format of boot images, certificates, configuration, and cryptographic data before processing.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SURFACE-009 — The boot manager shall detect errors in critical operations and reject non-compliant inputs; tr…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall detect errors in critical operations and reject non-compliant inputs; transition to error handling on faults.
Applicability
Applies to all boot managers with network boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-SURFACE-010 — The boot manager shall protect configuration by detecting unauthorised modifications, using che…Clause 5.10
Requirement (verbatim from the interim draft)
The boot manager shall protect configuration by detecting unauthorised modifications, using checksums/hashes, and limiting configurable options to essential parameters.
Applicability
Applies to all boot managers with configuration capability.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level MEDIUM. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
5.11 — Logging and Monitoring
This subclause addresses CRA requirements for security monitoring. Boot managers shall provide visibility into boot processes through logs and attestation within pre-OS constraints of limited storage and no file systems.
RQ-LOG-001 — The boot manager shall record measurements of boot components and security-critical configurati…Clause 5.11
Requirement (verbatim from the interim draft)
The boot manager shall record measurements of boot components and security-critical configuration in tamper-resistant storage before execution or handoff.
Applicability
Applies to all boot managers with measured boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-LOG-002 — The boot manager shall protect measurement records from unauthorised modification or deletion u…Clause 5.11
Requirement (verbatim from the interim draft)
The boot manager shall protect measurement records from unauthorised modification or deletion using cryptographic mechanisms, hardware-protected storage, or tamper-evident recording.
Applicability
Applies to all boot managers with verified or measured boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-LOG-003 — The boot manager shall provide measurement records in a format supporting remote attestation by…Clause 5.11
Requirement (verbatim from the interim draft)
The boot manager shall provide measurement records in a format supporting remote attestation by external parties, with freshness mechanisms to prevent replay of stale measurements, including component hashes, register indices, event types, and version information.
Applicability
Applies to MEDIUM and HIGH risk boot managers with measured boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-LOG-004 — The boot manager shall indicate security-relevant failures and state changes including verifica…Clause 5.11
Requirement (verbatim from the interim draft)
The boot manager shall indicate security-relevant failures and state changes including verification failures, authentication failures, security policy violations, recovery mode activation, and execution of unsigned code.
Applicability
Applies to all boot managers.
Objective
Verify secure configuration management: secure defaults, authentication controls, debug interface protection, and policy integrity.
Preparation
- Device in factory-default state or reset per manufacturer procedure
- Manufacturer security documentation
- Valid and invalid credential sets
- Interface enumeration capability
- Serial/debug console access where applicable
Activities
6.2.5.1 Default state verification
Objective: Verify secure initial state without user configuration.
Activities (all tiers):
1. Review documentation for default security state
2. Confirm no default passwords or undocumented access declared
3. Verify secure defaults restorable
Verdict:
- PASS if secure defaults documented and restorable with no default credentials.
- FAIL if default passwords present, undocumented access exists, or defaults not restorable.
6.2.5.2 Configuration authentication
Applies: Procedure 6.1.7.2 to configuration interface access.
Scope: Boot security policy, boot order, security settings.
Verdict:
- PASS if configuration changes require authentication.
- FAIL if unauthenticated policy modification possible, boot order changeable without authentication, or security settings modifiable anonymously.
6.2.5.3 Debug interface restriction
Objective: Verify debug interfaces secured in production.
Activities (Basic):
1. Review documentation for debug interface state
2. Confirm debug disabled or authenticated in production
Activities (Elevated):
3. Attempt debug access; verify disabled or requires authentication
4. Verify manufacturing test modes disabled
Activities (Advanced):
5. Verify debug cannot be re-enabled without authentication
6. Verify debug authentication resists bypass
Verdict:
- PASS if debug interfaces disabled or authenticated in production.
- FAIL if debug accessible without authentication, test modes active, or debug re-enableable without authorisation.
6.2.5.4 Policy integrity
Applies: Procedure 6.1.7.3 to security policy storage.
Scope: Boot policies, security configuration, trust anchors.
Verdict:
- PASS if policy tampering detected and rejected.
- FAIL if modified policy accepted, tampering undetected, or policy rollback possible without detection.
6.2.5.5 Credential protection
Objective: Verify password/credential storage security.
Activities (Elevated):
1. Review documentation for credential storage
2. Verify passwords hashed, not stored plaintext
3. Verify salt used in password hashing
Activities (Advanced):
4. Verify credential storage protected from extraction
5. Verify secure credential comparison (timing-safe)
Verdict:
- PASS if credentials hashed with salt and protected from extraction.
- FAIL if plaintext storage, missing salt, or credentials extractable.
6.2.5.6 Physical presence
Objective: Verify critical operations require physical presence.
Activities (Advanced):
1. Review documentation for physical presence requirements
2. Attempt remote trust anchor modification; verify rejection
3. Verify physical presence mechanism documented
Verdict:
- PASS if trust anchor changes require physical presence.
- FAIL if remote trust anchor modification possible or physical presence bypassable.
6.2.5.7 Configuration logging
Applies: Procedure 6.1.7.1 to configuration events.
Scope: Policy changes, authentication attempts, security state transitions.
Verdict:
- PASS if configuration changes logged with actor and outcome.
- FAIL if changes unlogged, actor missing, or outcome not recorded.
Verdict
- PASS (LOW): All applicable Basic-tier activities pass.
- PASS (MEDIUM): All applicable Basic and Elevated-tier activities pass.
- PASS (HIGH): All applicable Basic, Elevated, and Advanced-tier activities pass.
- FAIL: Any required activity for the declared risk level fails.
Evidence the standard asks for
| Evidence | LOW | MEDIUM | HIGH |
|----------|-----|--------|------|
| Manufacturer documentation | X | X | X |
| Configuration logs | X | X | X |
| Debug interface test results | -- | X | X |
| Credential storage analysis | -- | X | X |
| Physical presence test results | -- | -- | X |
Guidance
NOTE (Vandorisk): EA-BM-CONFIG (clause 6.2) is a shared assessment profile: the draft assesses the requirements listed in its clause 6.2.1 reference table together, without per-requirement activities. The reference table assigns this requirement risk level LOW. Common assessment procedures (clause 6.1.7) apply where the activities reference them.
Applicability of activities per tier and capability (clause 6.2.3):
| Activity | Basic | Elevated | Advanced | Capability Condition |
|----------|-------|----------|----------|---------------------|
| 6.2.5.1 Default state | X | X | X | -- |
| 6.2.5.2 Configuration authentication | X | X | X | Configuration |
| 6.2.5.3 Debug interface restriction | X | X | X | -- |
| 6.2.5.4 Policy integrity | -- | X | X | Configuration |
| 6.2.5.5 Credential protection | -- | X | X | Password authentication |
| 6.2.5.6 Physical presence | -- | -- | X | Configuration |
| 6.2.5.7 Configuration logging | X | X | X | Configuration + logging |
RQ-LOG-005 — The boot manager shall protect confidentiality of measurement records during transmission to ex…Clause 5.11
Requirement (verbatim from the interim draft)
The boot manager shall protect confidentiality of measurement records during transmission to external verifiers.
Applicability
Applies to all boot managers with measured boot.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.12 — Vulnerability Management
This subclause addresses CRA requirements for vulnerability management. Boot managers shall support secure updates throughout product lifecycle, or clearly document limitations and compensating controls for non-updateable implementations.
RQ-VULN-001 — The boot manager shall provide version information accessible to operating system or management…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall provide version information accessible to operating system or management systems.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-002 — The boot manager shall implement update mechanisms enabling vulnerability remediation where upd…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall implement update mechanisms enabling vulnerability remediation where update capability exists.
Applicability
Applies to all boot managers.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-003 — The boot manager shall implement status indicators for available updates where user interfaces…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall implement status indicators for available updates where user interfaces exist.
Applicability
Applies to MEDIUM and HIGH risk boot managers with update and configuration capabilities.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-004 — The boot manager shall support update availability checks when network capable.Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall support update availability checks when network capable.
Applicability
Applies to MEDIUM and HIGH risk boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-005 — The boot manager shall implement at least two distinct security mechanisms (e.g., memory protec…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall implement at least two distinct security mechanisms (e.g., memory protection and input validation, or hardware isolation and cryptographic verification).
Applicability
Applies to all boot managers without update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-006 — The boot manager shall enable security policy updates through configuration, allow disabling fe…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall enable security policy updates through configuration, allow disabling features to address vulnerabilities, and maintain configuration update capability throughout product lifetime.
Applicability
Applies to all boot managers with configuration capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-007 — The boot manager shall verify updates before committing, accept updates only from authenticated…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall verify updates before committing, accept updates only from authenticated sources, and store update verification keys in hardware security component where available.
Applicability
Applies to all boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-008 — The boot manager shall execute update operations atomically, maintain backup of previous versio…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall execute update operations atomically, maintain backup of previous version, and automatically rollback on update failure.
Applicability
Applies to all boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-009 — The boot manager shall isolate update logic from normal boot path, preventing update failures f…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall isolate update logic from normal boot path, preventing update failures from affecting other components.
Applicability
Applies to all boot managers with update capability.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
RQ-VULN-010 — The boot manager shall receive updates over authenticated and encrypted communication channel a…Clause 5.12
Requirement (verbatim from the interim draft)
The boot manager shall receive updates over authenticated and encrypted communication channel and detect tampering during update process.
Applicability
Applies to MEDIUM and HIGH risk boot managers with network updates.
This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.
5.13 — Security Testing and Review
Security testing requirements are addressed through conformity assessment procedures in clause 6 and documentation requirements in Annex C.
Correspondence to the CRA
The draft’s own correspondence table: which of its clauses address which essential requirement of CRA Annex I. This is the draft’s claim, reproduced as it stands — not Vandorisk’s judgment of coverage, and (status block above) not a presumption of conformity.
| CRA provision | Draft clause(s) |
|---|---|
| Annex I, Part I, (1) | 4.7.7, 4.7.8, 5.1, 5.2 |
| Annex I, Part I, (2)(a) | 5.12.1, 5.12.2, 6.1 |
| Annex I, Part I, (2)(b) | 5.3 |
| Annex I, Part I, (2)(c) | 5.6.4, 5.12.2, 5.12.8 |
| Annex I, Part I, (2)(d) | 5.3.2, 5.4 |
| Annex I, Part I, (2)(e) | 5.5 |
| Annex I, Part I, (2)(f) | 5.6 |
| Annex I, Part I, (2)(g) | 5.7 |
| Annex I, Part I, (2)(h) | 5.8 |
| Annex I, Part I, (2)(i) | 5.9 |
| Annex I, Part I, (2)(j) | 5.10 |
| Annex I, Part I, (2)(k) | 5.2.3, 5.9 |
| Annex I, Part I, (2)(l) | 5.11 |
| Annex I, Part I, (2)(m) | 5.5.7, 5.5.8 |
| Annex I, Part II, (1) | 5.12.1, 6.1 |
| Annex I, Part II, (2) | 5.6.4, 5.12.2, 5.12.8 |
| Annex I, Part II, (3) | 6.1 |
| Annex I, Part II, (4) | 5.12.2 |
| Annex I, Part II, (5) | 5.12 |
| Annex I, Part II, (6) | 5.12.1, 5.12.2 |
| Annex I, Part II, (7) | 5.6.4, 5.12.7, 5.12.9, 5.12.10 |
| Annex I, Part II, (8) | 5.12.2 |
Where the table covers CRA Annex I Part 1 only, the Part 2 (vulnerability handling) obligations remain assessed through the horizontal CRA pack(II.1–II.8).
Threat catalogue
The 6 threats the draft derives its requirements against, verbatim:
T-INTEGRITY — Boot integrity attacks
Boot integrity attacks target the authenticity and trustworthiness of boot components, attempting to execute unauthorised code, weaken security policies, bypass verification mechanisms, or exploit parsing and input validation weaknesses.
T-PERSIST — Persistent firmware threats
Persistent firmware threats establish malware or compromise that survives operating system reinstallation, disk formatting, and traditional security remediation.
T-PHYS — Physical attacks
Physical attacks require direct hardware access to extract secrets, modify hardware, inject faults, or manipulate components. Physical security context determines attack feasibility more than boot manager capabilities.
T-SUPPLY — Supply chain attacks
Supply chain attacks compromise boot managers during manufacturing, development, distribution, or through systemic trust failures. These threats affect all products regardless of capabilities, though update mechanisms expand the attack surface.
T-NET — Network-based attacks
Network-based attacks exploit network connectivity during boot, update, or configuration processes, providing remote attack surface. These attacks occur before operating system security mechanisms are active.
T-AVAIL — Availability and resilience threats
Availability and resilience threats prevent successful boot completion, cause denial of service, or undermine recovery mechanisms that ensure operational continuity.
Draft gaps
Defects and holes we found in the interim draft while building this pack — recorded rather than papered over; they will be rechecked against each new draft. A standard under consultation is allowed to have holes. A pack that hides them is not.
- Clause 6 announces assessment profiles "Clauses 6.2-6.7" (clause 6.1.6) but this interim draft contains only one, EA-BM-CONFIG (clause 6.2). 78 of 98 requirements therefore have no assessment in the draft: RQ-SBD (4), RQ-DEFAULT (1), RQ-CONFID (9), RQ-INTEGRITY (21), RQ-MINIMAL (3), RQ-AVAIL (19), RQ-IMPACT (1), RQ-SURFACE (6), RQ-LOG (4), RQ-VULN (10).
- EA-BM-CONFIG is a profile-level assessment shared by the 20 requirements in its clause 6.2.1 reference table; the draft does not break its activities down per requirement. Each covered requirement carries the full profile verbatim, with the requirement's table-assigned risk level noted in the assessment guidance.
- Clause 6.1.6 ("Assessment tier derivation") carries an unresolved editor's note: "#FIXME discuss approach".
- Requirement applicability is prose over risk level (LOW/MEDIUM/HIGH per clause 4.7.8) and product capabilities (clause 4.3.3), not a per-use-case table. The per-use-case applicability maps are therefore empty and every requirement is treated as applicable until the user applies the stated condition.
- The risk-level determination machinery (risk factors in clause 4.7.8, capability and risk-factor tables in clauses 4.8.7-4.8.8) is not modelled by this pack: the use cases are informative deployment contexts and the pack cannot compute a product's risk level.
- Clause 5.13 (Security Testing and Review) defines no requirements; it delegates to clause 6 and Annex C.
How this pack is built, and corrections
The pack is produced by a deterministic parser over the vendored draft text pinned in the source card— no model writes or rewrites any requirement. When ETSI updates the draft, the pack is rebuilt from the new text, the draft gaps are rechecked, and the result ships as a new pack version — never a silent edit.
The interim draft and, once published, the standard itself are the authoritative texts — this pack reproduces and cites them, it does not replace them, and nothing on this page is legal advice. If you find an error — a mis-parsed requirement, an applicability entry that does not match the draft, a gap we missed — write to hello@vandorisk.com. The horizontal pack this one attaches alongside is published at /pack, with every tracked vertical standard listed there.