No. ETSI EN 303 645 gives the example that a device using the manufacturer's public key to verify an update is not using a critical security parameter, so the key need not be unique per device. Shared symmetric keys are different and must be unique per device to avoid class-wide attacks.
What the standard says
Provision 5.4-4 of ETSI EN 303 645 requires that critical security parameters used for integrity and authenticity checks of software updates, and for protecting communication with associated services, be unique per device and produced with a mechanism that reduces the risk of automated attacks against classes of devices.
It then gives two examples. A different symmetric key deployed on every device of the same product class for generating and verifying message authentication codes for updates is cited as the problem case. The device using the manufacturer's public key to verify an update is not a critical security parameter and does not need to be unique per device.
Why the difference
With a symmetric key, whoever can verify an update can also create one. If one device is opened up and the key extracted, every device sharing that key accepts forged updates. The standard notes that disclosure of global critical security parameters can enable wide-scale attacks such as botnet creation.
With public key verification, the device holds only what is needed to check. Extracting it gives an attacker nothing to sign with.
| Design | Shared across devices? | Extracting it from one device lets an attacker |
|---|---|---|
| Symmetric MAC key | Must not be | Forge updates for every device that shares it |
| Manufacturer public key | Can be | Nothing useful, apart from learning the public key |
What should still be unique
Other secrets that protect a device or its cloud connection should be unique: device identity credentials, session keys and per-device passwords. Provision 5.4-3 also says hard-coded critical security parameters must not appear in device source code.
A short review
- List every key in the image and where it came from.
- Mark each as symmetric, public or private.
- Flag any symmetric key that is the same on all units.
- Check source and firmware strings for embedded credentials during review.
- Record the answer in your design documentation.
Keep in mind that uniqueness is only part of the story. Protecting the manufacturer private key and having a way to replace the public key matter just as much.
Where Safeguard fits
Safeguard supports compliance and evidence automation alongside SBOM and dependency scanning, so a record like this can be kept with your other evidence. Try the free scan at gold.safeguard.sh/scan on a repository you already own.
Quick check
Is the manufacturer public key secret?
No. The standard treats it as not a critical security parameter.
Is a shared symmetric update key ever acceptable?
The provision requires update integrity parameters to be unique per device and generated to reduce automated attacks, so a key shared across a product class is the example given of what to avoid.
Sources
Last reviewed: 19 October 2026.
