RSU: How to handle FACTORY_IMAGE signing and trust validation?

Great question — this is a common point of confusion in secure RSU designs. Let me walk through how signing and authentication work in the RSU context.

Short answer: Yes, you can use a signed/authenticated factory image in RSU. The key is that the signing workflow operates on the .rbf file, not the .sof, and quartus_pfg accepts .rbf as input for RSU image generation as well as .sof.

The correct flow:

1. Compile your factory design in Quartus Prime Pro to produce the .sof. You must use Quartus Prime Pro Edition software to compile the hardware projects you use for remote system update. Intel Agilex™® 7 Hard Processor System Remote System Update User Guide



2. Convert the .sof to a .rbf first, then sign the .rbf. You can run a command to generate a .rbf file from a factory or application image file (.sof). Agilex™ 7 Configuration User Guide Once you have the .rbf, you apply quartus_sign to it to produce a signed .rbf.



3. Feed the signed .rbf into quartus_pfg to build the initial RSU flash image. On the Input Files tab, click Add Bitstream, select the factory image .rbf file and click Open. Repeat this step for the application image .rbf. Agilex™ 7 Configuration User Guide So quartus_pfg does accept .rbf inputs for RSU — the .sof-only path is the generic/non-RSU path.

How authentication is enforced at runtime:

During the configuration state, the SDM authenticates the Altera-generated configuration firmware and configuration bitstream, ensuring that the configuration bitstream is from a trusted source. All Agilex 7 devices support authentication. Agilex™ 7 Configuration User Guide

Upon receiving configuration data, the SDM performs authentication, decryption, and decompression. Agilex™ 7 Configuration User Guide This applies to every image the SDM loads — including the factory image — so a properly signed factory .rbf will be authenticated by the SDM before it is allowed to configure the device.

Authentication is fundamental to Agilex 7 security in that any other Agilex 7 security features cannot be enabled without first enabling owner authentication. AN 886: Agilex™ 7 Device Design Guidelines

One important caveat to be aware of:

Due to a bug in Quartus Prime Pro Edition Software version 25.3.1 or earlier, when using Agilex 5 or Agilex 7 devices, you may see an error when examining a JIC file that has been generated where the Direct Factory Image Fallback flag has been enabled on a signed BOOT_INFO .rbf image. This error occurs because this setting needs to be applied before the image is signed. A future update of the quartus_pfg flow will include a method to generate .rbf files with the Direct Factory Image Fallback flag set to a user-desired value before encryption and signing. Error(22650): File .jic is corrupted. DCIO/Main section data information is not found So if you are using the Direct Factory Image Fallback feature together with signing, be aware of this known issue and plan accordingly.

Summary recommendation: The correct secure RSU flow is: compile → generate .rbf → sign the .rbf with quartus_sign → use the signed .rbf as input to quartus_pfg for RSU image generation. The SDM will then authenticate the factory image at load time, giving you the integrity and authenticity guarantees you need.