← Back to the learning library
Before you begin: Basic trust-boundary concepts and TFA-105 for update terminology.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Learning objectives
By the end of this module, you should be able to:
- Identify assets, trust boundaries and realistic device attack paths.
- Select proportionate identity, access and cryptographic controls.
- Plan secure provisioning, secrets handling and decommissioning.
- Balance cybersecurity with safety, performance and updateability.
Lesson 1
1. Begin with the device in its system
Threat modelling starts with assets and trust boundaries, not a catalogue of attacks. Consider control authority, safety-related parameters, measurements, credentials, intellectual property, update capability and service interfaces. Map physical ports, radios, debug access, manufacturing tools, companion applications and cloud connections.
A constrained device may delegate some controls, but it cannot delegate responsibility for validating commands and protecting the authority it holds.
Lesson 2
2. Establish device identity and protect secrets
Shared fleet credentials make one compromise a fleet compromise. Prefer per-device identities provisioned through a controlled manufacturing process. Protect long-term keys using hardware facilities where available and minimise exposure in RAM, logs and diagnostic interfaces.
Plan generation, injection, activation, rotation, revocation, replacement and secure disposal. A cryptographic algorithm choice without this lifecycle is not a key-management design.
Lesson 3
3. Apply controls within constraints
Use well-reviewed protocols and libraries rather than inventing lightweight cryptography. Authenticate peers and messages, enforce least privilege, protect sensitive data in transit and at rest where justified, and limit repeated attempts. Freshness values or sequence numbers may be needed to prevent replay.
When memory or energy prevents a desired control, record the trade-off, compensating controls and residual risk rather than silently weakening the design.
Lesson 4
4. Make security maintainable
Products need secure update, vulnerability intake, component inventory, logging appropriate to incident investigation and a supported way to identify installed versions. Disable or strongly control debug and manufacturing functions before release. Decommissioning should remove credentials and sensitive data without preventing legitimate disposal or refurbishment.
Lesson 5
5. Allocate resource budgets to hostile traffic
A parser must remain bounded before it trusts the sender. Limit frame length, nested structures, outstanding requests, handshake state and expensive operations. Reserve resources for essential control so a valid but excessive request stream cannot exhaust all queues or CPU time.
Rate limits should act at the correct boundary. Limiting only authenticated application requests may leave an unauthenticated handshake path unbounded. Define the minimum service required during overload and measure it under realistic radio or bus saturation. Security controls themselves consume RAM, energy and time, so include them in normal and worst-case budgets.
Cryptography needs trustworthy entropy, not merely a random-looking counter. Determine where random data originates during early boot, how failure is detected and whether keys or nonces are ever reused after reset. Follow the selected protocol and library requirements rather than constructing an ad hoc replacement.
Lesson 6
6. Specify the command authority model
Authentication establishes an identity; authorisation decides what that identity may do. A service technician might be allowed to read diagnostics and install approved firmware but not alter factory calibration outside a controlled process. Validate command parameters even for authorised peers.
Freshness requires a replay design suited to resets, power loss and offline use. A sequence counter held only in RAM can restart from an old value. A timestamp may be meaningless before clock synchronisation. Agree counter persistence, session establishment or another protocol-supported approach and define the receiver’s response to duplicates.
| Operation | Authority question | Safety / availability question |
|---|---|---|
| Update | Who may request it and which signature is accepted? | Can a running operation be interrupted? |
| Calibration | Who may write and approve a value? | Can invalid values reach active control? |
| Diagnostics | Which records may this role access? | Can logging or export delay essential work? |
Lesson 7
7. Build provisioning and retirement into the product
Manufacturing is part of the security boundary. Control who can create identities, inject credentials, change debug state and record device-to-certificate mappings. A locked debug port with an uncontrolled factory key process does not establish device trust.
Prepare for ownership change, repair, replacement and decommissioning. Erasing a user configuration should not accidentally erase the boot trust anchor; retaining a device certificate should not retain a former owner’s access. Specify separate lifecycles for product trust, device identity and customer credentials.
When a component vulnerability is reported, establish whether the affected code exists in the released build, is reachable and can violate a product security property. Record the reasoning, required mitigation and retest scope. A severity score alone cannot describe safety or fleet impact.
Decision guide
How should a constrained device authenticate commands?
| Pattern | Appropriate when | Key concern |
|---|---|---|
| Mutually authenticated secure channel | Both endpoints support a session protocol. | Certificate/key lifecycle and session recovery. |
| Message authentication code | Small messages and pre-established symmetric trust. | Unique keys, replay protection and fleet compromise. |
| Signed command/package | Offline or store-and-forward authorisation. | Signer authority, freshness and revocation. |
Worked example
Worked example — BLE-enabled actuator
A low-power actuator accepts configuration from a mobile application and cannot maintain a permanent cloud connection.
Each device receives a unique manufacturing identity. Pairing requires physical possession and a time-limited device action. The app and device establish an authenticated encrypted session; commands contain roles and monotonic sequence values. Sensitive service commands require a separately authorised service credential. Rate limits and lockout avoid battery-drain attacks without permanently denying legitimate recovery.
The radio link is not treated as trusted, fleet-wide secrets are avoided and service authority is distinct from ordinary user control.
Engineering evidence
What should the work produce?
Threat model
Records assets, boundaries, attack paths and assumptions.
Security requirements
Defines device capabilities and verification criteria.
Provisioning and key-management plan
Controls identity and secrets throughout life.
Security test report
Covers authentication, replay, abuse, debug and update paths.
Common failure patterns
What goes wrong?
- One hard-coded credential across all devices.
- Encrypted communication without authenticating the endpoint.
- Leaving production debug access enabled.
- Adding security that prevents a safety-critical recovery action.
Applied exercise · approximately 25 minutes
Threat-model a battery-powered service interface
A device accepts wireless diagnostics and local firmware updates. It has 64 KiB RAM, an intermittent network connection and a requirement to continue essential control during servicing.
- Identify three assets and two trust boundaries, including manufacturing.
- Define bounded behaviour for repeated authentication failures and oversized messages.
- Explain how replay and revoked service access behave while the device is offline.
Review a suggested approach
Assets include control authority, device credentials and installed-code integrity. Boundaries include provisioning-to-device and service-peer-to-command parser. Reject oversized frames before allocation, cap concurrent authentication state and reserve execution time for essential control. Test power use and latency as well as rejection counts.
Offline revocation cannot be assumed instantaneous. Define an authorised offline-access lifetime or a synchronisation prerequisite for sensitive actions, with an explicit safety and service trade-off. Use the protocol’s session and freshness mechanisms; retain enough state or re-establish trust after reset to avoid accepting old commands. Document what happens when credentials expire during essential operation.
Completion criteria
- Controls address both untrusted and authenticated overload.
- Offline trust limitations are explicit.
- Verification observes essential control alongside security outcomes.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Are all control and service entry points included in the threat model?
- Does each production device have appropriately unique identity?
- Are replay and resource-exhaustion attacks considered?
- Can credentials be revoked or replaced?
- Are security controls tested alongside safety and availability behaviour?
Constrained security is the disciplined allocation of trust, authority and limited resources across the complete lifecycle.
References and further reading
- RFC 7228 — Terminology for Constrained-Node Networks
- NISTIR 8259A — Device Cybersecurity Capability Core Baseline
- OWASP Internet of Things project
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.