What you will learn
By the end of this topic, you should be able to define the cybersecurity engineer’s product responsibilities; identify assets, trust boundaries and threat scenarios; shape secure architecture; derive and verify security requirements; manage third-party dependencies and software bills of materials; connect security and safety; establish release evidence; and support coordinated vulnerability management throughout the product lifetime.
The cybersecurity engineer’s role
Cybersecurity engineers help the organisation build and sustain a device that remains acceptably secure in its intended environment. They translate adversarial behaviour and dependency risk into product requirements, architecture, verification and operational controls. Security is not a final penetration test and is not confined to software; it includes hardware, communications, identity, data, update infrastructure, manufacturing, service and external services.
Threat analyst
Model assets, actors, attack paths, trust boundaries and foreseeable misuse.
Control designer
Turn security objectives into architecture and testable requirements.
Assurance specialist
Plan reviews, analysis and testing that demonstrate control effectiveness.
Lifecycle responder
Monitor vulnerabilities and support assessment, remediation and communication.
Define the complete security scope
Identify the device, software functions, accessories, mobile applications, cloud services, update systems, service tools, manufacturing systems and external interfaces that can affect security. Record deployment models, users, administrators, operators, data flows, trust assumptions and shared-responsibility boundaries. An omitted service or update pathway can invalidate an otherwise strong product threat model.
Use MTL-121 — Data, Connectivity and Interoperability and MTL-112 — Systems Engineering, Architecture and Interfaces.
Threat-model the system and its use
- Identify safety, operational, privacy and security-relevant assets.
- Map entities, data flows, entry points and trust boundaries.
- Describe attacker capabilities, plausible abuse cases and attack chains.
- Assess exploitability, impact, detectability and uncertainty using a defined method.
- Consider local, remote, supply-chain, insider and maintenance threats.
- Update the model when architecture, dependencies, use environment or threats change.
Threat modelling should produce decisions and requirements. A diagram or STRIDE list without disposition, ownership and traceability is unfinished work.
Shape a security architecture that contains failure
Define security domains, identities, privileges, trust relationships, protected assets, communication paths, key management, logging, update mechanisms and recovery. Apply least privilege, defence in depth, secure defaults, separation of duties and minimised attack surface. Show how compromise of one component is detected or contained and which dependencies remain critical.
Coordinate consequential structural decisions with MTL-214 — System Architects in Medical-device Development.
Derive testable cybersecurity requirements
Include logging, time, alerting, lockout, backup, rollback and secure decommissioning where applicable. Each control needs implementation and effectiveness evidence.
Control third-party components and the software bill of materials
Record component identity, version, supplier, licence, source, intended use, known vulnerabilities, support status and transitive dependencies. The SBOM is an inventory, not the complete vulnerability assessment. Define how new vulnerability information is matched to deployed configurations, assessed for exploitability and safety impact, and communicated across affected products.
Build layered security evidence
Combine architecture and code review, static and dynamic analysis, composition analysis, interface testing, abuse-case testing, fuzzing where appropriate, penetration testing and update/recovery testing. Test the supported configuration and realistic threat paths. Independence should reflect risk, and findings need documented disposition and regression evidence.
Coordinate formal evidence with MTL-106 — Verification and Validation.
Connect cybersecurity risk to safety risk
A security compromise may create or contribute to hazardous situations by changing therapy, delaying information, denying service or corrupting data. Cybersecurity risk assessment should identify these safety impacts and feed relevant sequences and controls into the product risk-management file. Not every security harm is a safety harm, but both analyses must share architecture, assumptions and evidence.
Use MTL-105 — Medical-device Risk Management for the safety-risk process.
Define cybersecurity release readiness
Confirm the threat model and architecture reflect the released system; critical controls are verified; vulnerabilities and anomalies are assessed; the SBOM is accurate; production and signing assets are protected; security configuration and user information are complete; and monitoring, disclosure, update and recovery capabilities are operational. Residual cybersecurity risk should be explicit and approved.
Sustain security after release
Monitor vulnerability sources, supplier notices, threat intelligence, complaints and field signals. Triage reports, reproduce issues, assess exploitability and safety impact, coordinate disclosure, create and verify remediations, and communicate deployment instructions. Track unsupported components and define end-of-support arrangements before the product becomes unmaintainable.
Connect the operating model to MTL-111 — Post-market Support and lifecycle change to MTL-127 — Configuration and Change Management.
Common misconceptions
“Cybersecurity is the IT team’s responsibility.”
Enterprise IT contributes controls, but product security needs device-specific engineering and lifecycle ownership.
“A penetration test proves the device is secure.”
Testing samples attack paths at a point in time; architecture, process, monitoring and update capability provide lifecycle assurance.
“Encryption solves cybersecurity.”
Encryption addresses selected confidentiality and integrity needs, not identity, authorisation, availability, updateability or unsafe system behaviour.
Authoritative starting points
Medical-device cybersecurity is a sustained product capability—not a test performed before submission
Threat-informed architecture, verified controls, dependency knowledge and an effective vulnerability-response system must remain connected throughout the device lifetime.