ETSI EN 304 627 Secure Boot Requirements: Can Passwords Protect a Router’s Root of Trust?

Looking at Trustworthy Boot Design for Routers and Switches through ETSI EN 304 627 AC-INTEGRITY-1-02

As the EU Cyber Resilience Act (CRA) gradually enters the technical standard implementation phase, manufacturers of routers, Internet-connected modems, and switches need to re-examine their designs for Secure Boot, Firmware Integrity, and Root of Trust.

ETSI is currently drafting EN 304 627, which serves as a candidate harmonized standard under the CRA applicable to routers, Internet-connected modems, and switches. Among its requirements, AC-INTEGRITY-1-02 focuses specifically on the product’s Secure Boot Chain and whether the first-stage trusted code is adequately protected.

Frequently Asked Client Question: Is having an admin account with a strong password good enough?

In actual technical assessments, manufacturers may have already implemented the following measures:

• Requiring admin account login before modifying the Bootloader;
• Setting admin password lengths to over 15 characters;
• Managing account credentials through internal company confidentiality procedures;
• Restricting operational privileges strictly to specific R&D or maintenance personnel.

While these measures certainly hold value, they primarily belong to Authentication and Administrative Controls, addressing the question:

Who is allowed to make modifications?

AC-INTEGRITY-1-02, however, goes a step further by focusing on:

Even if an attacker or a high-privilege account has entered the system, can the first-stage trusted code still be modified via software?

Although these two questions seem similar, they represent different levels of security controls.

“Restricting who can modify” is not equal to “preventing code modification”

Suppose a user must enter a strong password to access Recovery Mode or the maintenance interface.

If the first-stage U-Boot, code external to Boot ROM, or other Secure Boot Trust Anchors can still be rewritten after logging in, the account credentials merely raise the barrier to accessing the modification feature.

Once the account is compromised, privileges are escalated, or a vulnerability exists in the maintenance interface, an attacker could still modify the initial executed trusted code and subsequently bypass all downstream Secure Boot verifications.

Therefore, the Assessment Activities in Draft ETSI EN 304 627 require testing laboratories to attempt modifying the first-stage trusted code via software and confirm that the product rejects such modifications. The Pass Verdict also explicitly requires the product to prevent such software modifications.

To put it simply:

Passwords protect the entrance; the Root of Trust protects the entire chain of trust.

What technical designs better support compliance?

Manufacturers can consider protecting the first-stage trusted code through the following mechanisms:

• Storing the first-stage code in Mask ROM or immutable internal ROM;
• Using OTP (One-Time Programmable) memory or eFuses to lock boot and verification settings;
• Enabling hardware-level Flash Write Protection;
• Establishing an Immutable Root of Trust that cannot be altered via standard software paths;
• Protecting the Boot Verification Key via hardware mechanisms;
• Ensuring each stage only executes the next-stage code signed by an authorized vendor.

TPMs, Secure Elements, or security chips can also form part of the overall design—for instance, by protecting keys, storing measurement results, or supporting Attestation.

However, note that:

Having a TPM on the product does not automatically grant write protection to the first-stage Bootloader. Whether it complies still depends on how the TPM or Secure Element integrates with the SoC, Boot ROM, Flash Controller, Signing Key, and update mechanisms.

How do testing laboratories conduct assessments?

Testing laboratories do not arbitrarily add requirements beyond the standard. Instead, they issue judgments based on the Assessment Activities, Assessment Verdicts, and Assessment Evidence specified in the standard.

Typical assessment scope includes:

1. Reviewing the Boot Chain ArchitectureConfirming which boot stages the product includes, how each stage verifies the next, and where the first-stage trusted code is stored.
2. Attempting Modification via SoftwareTesting general Firmware Update interfaces, Recovery Mode, UART, Shell, remote management interfaces, and maintenance interfaces to check if any path exists to modify the first-stage trusted code.
3. Verifying Storage Protection MechanismsWhere physically feasible, checking Write Protection, Lock Bits, OTP, or eFuse status to ensure actual configurations align with product documentation.
4. Checking Failure Behavior and LoggingConfirming that when Secure Boot verification fails, the product refuses to execute unverified code, enters a predefined failure state, and logs the boot results once logging functionality becomes available.

The standard uses the phrase “where physically feasible,” meaning laboratories need to obtain reasonable and objective evidence, but it does not imply that every assessment requires desoldering, damaging the PCB, or depottings/decapping chips. When necessary, manufacturers can provide schematics, component datasheets, programming records, and hardware protection settings as supporting evidence.

How should manufacturers prepare?

Before submitting a product for formal assessment, manufacturers are advised to complete the following preparations:

• Define and map out the complete Secure Boot Chain;
• Clearly identify the first-stage trusted code;
• Explicitly distinguish trusted code, verification keys, and other trust materials;
• List all interfaces that could potentially modify the Bootloader;
• Prepare SoC, Flash, eFuse, OTP, and Write Protection evidence;
• Establish procedures for Signing Key management and Key Rotation;
• Verify that Recovery Mode cannot be used as a Secure Boot bypass path;
• Retain test logs for successful boots, verification failures, and recovery procedures.

Among these, the first-stage trusted code and trust materials need to be understood separately. The first-stage code should be protected against software modification; if the product allows replacing certain trust materials or verification keys through authorized means, additional authorization, integrity protection, and lifecycle management mechanisms must be established.

Conclusion

The core of Secure Boot is not just about requiring users to log in first, nor is it merely about having complex passwords.

The real question that needs answering is:

Can the code initially trusted by the product remain trustworthy when facing software attacks, privilege escalation, or abuse of maintenance interfaces?

Account passwords can mitigate unauthorized access risks, but the trust foundation of Secure Boot must still be built upon unalterable first-stage trusted code, protected verification mechanisms, Vendor Signing Key management, and a robust Secure Development Lifecycle (SDLC).

The One Lab assists router, modem, and switch manufacturers with Secure Boot architecture reviews, ETSI EN 304 627 gap analyses, test evidence planning, and pre-assessment technical preparation—ensuring product designs, documentation, and test evidence are effectively aligned before entering CRA compliance evaluation.