Before you design a chip or module into a product, ask the supplier ten questions: how secure boot starts, how debug access is locked, where keys live, how updates are verified, how long fixes will come, and whether they provide an SBOM. The answers decide what your own product can promise.
Boot and debug
- How is the first stage verified, and what is the root of trust? ETSI EN 303 645 says devices should verify software using secure boot and describes a hardware root of trust as one route to it.
- Can debug access be permanently or conditionally locked, and how? ETSI provision 5.6-4 says physically accessible debug interfaces shall be disabled in software. Ask what the silicon offers beyond that.
- Which physical interfaces are exposed by default on the module? Provision 5.6-3 asks that hardware not unnecessarily expose physical interfaces.
Keys and identity
- Where can we store keys, and can they be used without being read out? ETSI 5.4-1 names TEEs, secure elements and hardware backed storage.
- Do you provision per device identities, and how is that process protected? Provision 5.4-2 asks that hard-coded unique identities resist tampering.
- Does the SDK or reference firmware contain default or shared credentials? ETSI says hard-coded critical security parameters shall not be used in source code.
Updates
- What does your update mechanism verify, and does it support rollback protection? ETSI gives an anti-rollback policy based on version checking as an example measure.
- How long will you provide security fixes for this part and its SDK? You cannot promise customers more than your supplier gives you. Get it in writing.
Transparency
- Do you publish an SBOM for the SDK and any binary blobs? Formats such as SPDX can describe the components. If the answer is no, ask what you can get under an agreement.
- How do we report a vulnerability to you, and how do you notify us? A contact route and a disclosure policy matter before you need them.
How to use the answers
Put them in a table with a row per question and a column per candidate supplier. Mark gaps as risks you will cover yourself or reasons to choose someone else. Do not assume marketing material answers a specific question. Ask for a datasheet reference or a written reply.
Keep the record
Store the replies with your design documents. When a customer questionnaire asks how your device protects keys or verifies updates, the record lets you answer from evidence. It also shows what changed if a supplier revises its position later.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a single advisory is tied to the components and owners it affects, the same link you want from a supplier's SBOM.
Quick check
Can a supplier SBOM replace our own?
No. It covers their part. You still need to record your own code, configuration and other dependencies.
Which of these questions matters most?
It depends on your threat model, but support duration and key storage are hard to fix after the hardware is chosen.
Where Safeguard fits
Safeguard covers the software supply chain side of this work: SBOM and dependency scanning, policies and gates, and compliance and evidence automation. It does not replace hardware security features. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
