Embedded and IoT security engineering
Decide which device threats the hardware and software design must resist in the field
A connected product is approaching design freeze, or a fielded device needs a security position. The decision is which device threats the hardware and software design must resist in the field. The work starts from physical access, debug interfaces, storage, radio surfaces and what a single compromised device reveals about the rest of the fleet and ends with a device security design with a stated attacker model and fleet-level consequences. It is most relevant to embedded engineering leads and product security owners. A useful result states what was examined, what remains uncertain and which decision the evidence can support.
Decide which device threats the hardware and software design must resist in the field
- Attacker class
The starting condition this work depends on.
- Debug surface
Where the consequence actually arises.
- Fleet consequence
The finding and its open dependencies.
Decision
Frame the decision before scoping the work
Questions and the evidence each one needs
- Attacker class
- Inspect hardware block diagrams and component datasheets.
- Debug surface
- Inspect the device software stack and its update path.
- Fleet consequence
- Inspect provisioning and manufacturing process descriptions.
The decision is which device threats the hardware and software design must resist in the field. This matters to embedded engineering leads and product security owners when a connected product is approaching design freeze, or a fielded device needs a security position. Name the affected product, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.
The specific failure hypothesis is that the design assumes an attacker who is remote, while the real attacker can open the enclosure. It stays a hypothesis until it is examined in your own case. Existing design records, tests or operating evidence may already resolve it, so identify the uncovered question before commissioning further work.
Mechanism
Follow the relationship that carries the consequence
Where the boundary is actually crossed
- Attacker class
- The condition the design assumes.
- Debug surface
- Where authority or information changes hands.
- Fleet consequence
- The effect the owner must answer for.
What this specialty examines
Embedded and IoT security engineering rests on physical access, debug interfaces, storage, radio surfaces and what a single compromised device reveals about the rest of the fleet. Work from the configuration that will actually ship rather than from the reference design, and record where the two differ.
The examination draws on hardware block diagrams and component datasheets; the device software stack and its update path; and provisioning and manufacturing process descriptions. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.
The tradeoff to make explicit
The tradeoff here is unit cost and manufacturing simplicity against per-device secrets and tamper resistance. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.
Preparation
Connect the inputs to the boundary examined
Preparation record for the engagement
Illustrative working format
- Hardware block diagrams and component datasheets
- Bounds the context.
- The device software stack and its update path
- Supplies the material examined.
- Provisioning and manufacturing process descriptions
- Exposes conditions that qualify a result.
Start with hardware block diagrams and component datasheets; the device software stack and its update path; and provisioning and manufacturing process descriptions. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.
The scope also needs embedded engineering leads and product security owners with the authority to inspect the relevant boundary, and agreement on what evidence would distinguish the failure in which the design assumes an attacker who is remote, while the real attacker can open the enclosure from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.
Working sequence
Carry the question through to an accountable finding
From scoped material to a decision record
- Model the device attacker
Set the conditions assumed.
- Examine the hardware-software seam
Apply the scoped check.
- Decide the fleet consequences
Record evidence and the next decision.
Model the device attacker
Distinguish remote, local-network, proximate-radio and physical-possession attackers, and state which the product intends to resist. Record what is deliberately excluded.
Examine the hardware-software seam
Inspect debug and test interfaces, external storage, secure elements, provisioning secrets and the boundary between privileged and application code. Keep an unreproducible observation in the record with its reason.
Decide the fleet consequences
Establish what a single extracted secret would reach, and design per-device identity, segmentation and revocation accordingly. Hand the result over with its open dependencies attached.
Indicative artefact
Make the artefact usable by the person who owns the decision
A device security design with a stated attacker model and fleet-level consequences
Illustrative working format
- The attacker classes the product resists
- What was examined, and under which assumptions.
- Hardware and software boundary findings
- Each observation, linked to evidence.
- Per-device identity, segmentation and revocation decisions
- The next decision, and its limits.
The proposed decision artefact is a device security design with a stated attacker model and fleet-level consequences. Depending on the agreed scope, the pack may include:
-
The attacker classes the product resists. Basis: the definitions, boundaries and assumptions another reviewer would need.
-
Hardware and software boundary findings. Observation: the findings and their interpretation, preserving adverse results and disagreement.
-
Per-device identity, segmentation and revocation decisions. Decision: what the owner could do next, and what change would justify revisiting it.
Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.
Illustrative scenario
Examine the question through a constructed case
A constructed case and its decision paths
Illustrative scenario
- Attacker class
A connected sensor family shares one firmware-signing arrangement and one network credential across the fleet.
- Debug surface
What does extracting that credential from one unit give an attacker across every other unit?
- Fleet consequence
Introduce per-device identity before volume manufacture, while the provisioning process can still change.
Consider an illustrative situation: a connected sensor family shares one firmware-signing arrangement and one network credential across the fleet. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.
The question to examine is what does extracting that credential from one unit give an attacker across every other unit. A reasonable next action would be to introduce per-device identity before volume manufacture, while the provisioning process can still change. The decision record should state which configuration was accepted and which limitations came with it.
Scope and next action
Keep the conclusion inside the agreed boundary
Confirm fit before the next commitment
- Attacker class
- Limited to the agreed scope and configuration.
- Hardware block diagrams and component datasheets
- The owner confirms access and conditions.
- Fleet consequence
- A design review is not hardware penetration testing. Physical attack resistance is established by qualified laboratory testing under a separate scope.
A design review is not hardware penetration testing. Physical attack resistance is established by qualified laboratory testing under a separate scope. Any engagement depends on an agreed scope, a qualified team and authorised access.
Bring the affected product or workflow, its current configuration and the evidence you already hold. The scope question follows from the situation in which a connected product is approaching design freeze, or a fielded device needs a security position. Confirm which missing observation would change the owner’s next action.