Begin with architecture and assets
Security work needs a credible system boundary, architecture, external-interface inventory, data flows, trust boundaries, assets and operating assumptions. Threat modelling without this foundation tends to become generic.
- Identify safety-relevant and sensitive assets.
- Show every external interface and trust transition.
- Consider service, update, manufacturing and decommissioning paths—not only normal use.
Translate threats into controls
Threats and vulnerabilities should produce explicit security requirements. Each control then needs an architectural allocation, implementation evidence, verification method and residual-risk conclusion.
- Authentication and authorisation
- Data protection at rest, in transit and, where necessary, in use
- Secure update and rollback controls
- Logging, detection and recovery
- Availability and resilience
- Least privilege and attack-surface reduction
Plan for the supported lifetime
A secure release is only a starting point. Manufacturers need vulnerability intake, monitoring, assessment, coordinated disclosure, SBOM maintenance, update capability and clear support policies throughout the device lifetime.
Key takeaways
- Security architecture should precede detailed threat analysis.
- Every significant security control needs traceable verification evidence.
- Post-market vulnerability handling is part of the product, not an afterthought.
This article provides general educational information. Applicable requirements depend on the device, jurisdiction, lifecycle stage and current regulatory position.