Device Lifecycle — States and Transitions
Overview
A secure device does not behave the same way throughout its life. Its capabilities, permissions, and accessible interfaces depend on its lifecycle state — a hardware‑anchored configuration that determines:
- who can program the device
- whether debug is allowed
- whether keys can be injected or replaced
- whether secure boot is enforced
- whether firmware updates require OEM signatures
- whether the device can be repaired or decommissioned
Lifecycle states are enforced by OTP fuses, secure boot ROM logic, and HSM policies. Transitions between states are one‑way to prevent attackers from rolling a device back into a permissive mode.
Lifecycle State Machine — High‑Level Diagram
Key properties of this state machine
- Transitions are irreversible (Manufacturing → OEM → User → EoL)
- RMA is a controlled side‑path, not a rollback
- Debug access shrinks at every step
- Keys become immutable after OEM state
- EoL wipes secrets and permanently disables sensitive functions
1. Manufacturing State
This is the initial state after silicon fabrication.
Characteristics
- debug interfaces open (JTAG/SWD)
- no cryptographic secrets yet
- secure boot disabled
- device is fully programmable
- used for bring‑up and testing
Risks
If an attacker forces a device back into this state, they can:
- extract firmware
- bypass secure boot
- inject malicious keys
- clone the device
Transition
Manufacturing → OEM Irreversible once fuses are blown.
2. OEM State
This is the provisioning state where the device receives its permanent identity.
Characteristics
- keys injected or derived (PUF enrollment)
- certificates programmed
- secure boot enabled
- debug access restricted or authenticated
- lifecycle fuses programmed
- anti‑rollback counters initialized
Security Guarantees
- only OEM‑authorized tools can program keys
- provisioning interfaces are authenticated
- all injected secrets become immutable
Transition
OEM → User Irreversible.
3. User / Field State
This is the normal operational state of the device.
Characteristics
- keys cannot be replaced
- secure boot enforces firmware integrity
- firmware updates require OEM signatures
- debug is disabled or requires secure authentication
- provisioning interfaces are permanently locked
Security Guarantees
- device identity is fixed
- firmware cannot be downgraded without detection
- no new secrets can be injected
Transition
User → RMA (optional, controlled) User → Decommissioned (irreversible)
4. RMA (Return Material Authorization) State
A special state for controlled diagnostics or repair.
Characteristics
- requires OEM‑signed authorization token
- may wipe sensitive data before enabling debug
- allows limited re‑provisioning or diagnostics
- cannot be entered without cryptographic proof
Security Guarantees
- prevents unauthorized rollback to Manufacturing
- ensures debug access is temporary and controlled
- protects user data during repair
Transition
RMA → User (optional, if allowed) RMA → Decommissioned (irreversible)
5. Decommissioned / End‑of‑Life State
The final state of the device.
Characteristics
- keys erased or invalidated
- secure boot disabled
- debug permanently disabled
- device cannot return to any previous state
- user data wiped
Purpose
- prevent reuse or repurposing
- ensure no secrets survive
- comply with security and privacy requirements
Transition
None — terminal state.
Threats to Lifecycle Security
| Threat | Description |
|---|---|
| Unauthorized lifecycle rollback | Forcing device back to Manufacturing or OEM |
| Debug re‑enable attacks | Attempting to bypass debug lockdown |
| Fault injection | Glitching lifecycle fuses or state checks |
| Supply‑chain compromise | Malicious provisioning or unauthorized state changes |
| Weak lifecycle enforcement | Allowing reversible transitions |
| Insecure RMA process | Unauthorized access to debug or keys |
Mitigation Techniques
- OTP‑based irreversible transitions
- secure boot ROM enforcement
- HSM‑controlled lifecycle policies
- authenticated debug (challenge/response)
- tamper detection and zeroization
- anti‑rollback counters
- OEM‑signed RMA tokens
- secure audit logs
Relationship with Keys and Provisioning
Lifecycle is inseparable from keys and provisioning:
- Keys define identity
- Provisioning installs identity
- Lifecycle protects identity
If lifecycle is weak:
- keys can be replaced
- provisioning can be repeated
- debug can be reopened
- secure boot can be bypassed
Lifecycle is the guardrail that ensures the device remains trustworthy throughout its entire existence.
