Training IEC 62304 SDLC training now available — structured learning, timed assessment & certificate

Cybersecurity Services

Cybersecurity by Design
for Medical Devices & Life Sciences

Threat Modelling · FDA Section 524B · IEC 81001-5-1 · EU MDR · EU AI Act · NIS2

A security weakness in a connected device or a GxP system is a patient safety and data integrity risk. We start with a threat model of your system, then build the security risk assessment, controls, testing and FDA and EU MDR documentation from it, and keep it current after release with SBOMs, vulnerability management and incident response.

How We Work
Threat Model First
Every control, test and document traces back to the threat model
Linked to Safety Risk
Security risks traced into your ISO 14971 risk management file
Ready for Review
Documentation shaped for Notified Body and FDA review
Maintained After Release
Vulnerability monitoring, disclosure and incident response
Where We Start

Threat Modelling Comes First

A threat model shows how your device or system could be attacked and what would happen if it were. FDA's premarket cybersecurity guidance and IEC 81001-5-1 both expect the security risk assessment, the controls and the testing to follow from it, so we build it first and keep it current for the life of the product.

Step 1
Model the System
Architecture and data-flow diagrams showing every component, interface, data store and trust boundary, including the cloud services, apps and hospital networks your device connects to.
Step 2
Identify the Threats
A systematic analysis using STRIDE and attack trees, extended for AI where the device uses it, with the assumptions behind each threat written down.
Step 3
Assess the Risks
Each threat rated for exploitability and for its impact on patient safety, data and device function, with criteria for deciding which risks are acceptable and which need controls.
Step 4
Trace to Controls and Tests
Each threat linked to the security controls that address it and the tests that prove them, with security risks that could affect safety carried into your ISO 14971 risk management file.
Step 5
Report
A threat model report and a security risk management report that show the residual risk and why it is acceptable, with a traceability matrix from threats to controls and tests, ready for your FDA submission and EU technical documentation.
Step 6
Maintain
A vulnerability management plan, which FDA calls the cybersecurity management plan, covering SBOM monitoring, vulnerability assessment, coordinated disclosure and patch timelines. The threat model is updated whenever the design, its components or the threat landscape change, and findings feed your post-market surveillance and periodic safety reports.
FDA Premarket Submissions

The Cybersecurity Deliverables FDA Expects

For cyber devices, section 524B of the FD&C Act and FDA's guidance Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions set out the documentation a 510(k), De Novo or PMA should contain. We prepare each item and map it to EU MDR expectations (MDCG 2019-16) and IEC 81001-5-1, so one set of evidence serves both markets.

SPDF
Secure product development framework
Evidence that security is managed across the whole product lifecycle within your quality system, for example by following IEC 81001-5-1.
Risk
Threat model and security risk management report
The threat model, a cybersecurity risk assessment that rates exploitability rather than probability, the risks that remain and why they are acceptable, and how security risk links to your safety risk management. Interoperability with other devices and systems is covered here too.
SBOM
Software bill of materials and third-party components
A machine-readable SBOM with each component's support level and end-of-support date, an assessment of known vulnerabilities in those components, and a security assessment of unresolved software anomalies.
Views
Security architecture views
The global system view, multi-patient harm view, updatability and patchability view, and security use case views, showing how the device, its connections and its updates are protected.
Controls
Security controls
How the design addresses authentication, authorisation, cryptography, code, data and execution integrity, confidentiality, event detection and logging, resiliency and recovery, and software and firmware updates.
Testing
Cybersecurity testing
Security requirements testing, threat mitigation testing, vulnerability testing (such as fuzzing, software composition analysis and static and dynamic analysis) and independent penetration testing, with the reports and how each finding was resolved.
Labelling
Cybersecurity information for users
Labelling that tells users and hospital IT teams how to operate and update the device securely, which security controls and logs are available, and where to find the SBOM and end-of-support information.
Plan
Cybersecurity management plan
The plan section 524B requires for monitoring, identifying and addressing post-market vulnerabilities and exploits, including coordinated vulnerability disclosure, patch timelines and the security metrics you will track.
Product Security

Across the Secure Product Lifecycle

For connected and software-based medical devices, IVDs and SaMD, we cover the full secure product lifecycle under IEC 81001-5-1, aligned with your IEC 62304 software process and ISO 14971 risk management.

ISO 14971 · AAMI SW96

Security Risk Management

A security risk management process that runs alongside your safety risk management, with clear rules for when a security risk becomes a safety risk.

IEC 81001-5-1

Secure Development Lifecycle

Security requirements, secure architecture and design, secure coding and code review, and security verification, built into your existing software development process rather than added on.

SBOM

SBOM & Vulnerability Management

A software bill of materials for every release, continuous monitoring of third-party components for new vulnerabilities, and a documented process to assess, fix and release patches.

Planned & Managed

Penetration Testing

We define the scope and test plan, engage and manage an independent penetration tester, and turn the findings into risk controls, fixes and records for your technical documentation.

EU MDR · IVDR

EU Technical Documentation

Cybersecurity content for EU MDR and IVDR technical documentation that meets Annex I and MDCG 2019-16, built from the same evidence as your FDA submission.

Post-Market

Incident Response & Disclosure

Coordinated vulnerability disclosure, incident triage and response playbooks linked to your vigilance process, and MDS2 security disclosures for hospital customers.

Beyond the Device

Security Across Your Products and Organisation

The same discipline applies to AI, to the systems that run your quality and manufacturing operations, and to your organisation as a whole.

EU AI Act Article 15

AI Security

Threat modelling for AI-enabled devices and AI systems, covering data poisoning, model manipulation, adversarial inputs and data leakage, and evidence for the AI Act's cybersecurity and robustness requirements.

ISO/IEC 27001 · NIS2

Information Security & NIS2

ISO/IEC 27001 gap assessments, readiness and internal audits, and support with NIS2, which applies to many medium and large manufacturers of medicines and medical devices.

EU GMP Annex 11 · GAMP 5

GxP Computerised Systems

Security controls for GxP computerised systems, including access, audit trails, backup and supplier oversight, so that security supports data integrity under Annex 11, 21 CFR Part 11 and GAMP 5.

IEC 82304-1

Health Software

Security for health and wellness apps and software built in-house by health institutions, under IEC 82304-1 and IEC 81001-5-1.

Requirements

Which Rules Apply to You?

Cybersecurity requirements now come from several directions at once. We help you work out which apply and meet them with one set of evidence rather than several.

EU MDR
IVDR
EU medical device and IVD regulations
Annex I requires software to be developed with information security in mind, protection against unauthorised access, and minimum IT security requirements in the instructions for use. MDCG 2019-16 explains what Notified Bodies expect, and IEC 81001-5-1 is the lifecycle standard most used to meet it.
FDA
US premarket and postmarket cybersecurity
Section 524B of the FD&C Act requires manufacturers of cyber devices to submit a plan for monitoring and addressing vulnerabilities, an SBOM and evidence of secure design, as set out in FDA's premarket cybersecurity guidance.
EU
AI Act
AI systems
Article 15 requires high-risk AI systems, including many AI-enabled medical devices, to be resilient against attempts to exploit their vulnerabilities, such as data poisoning and adversarial examples.
NIS2
CRA
Organisational security and other connected products
NIS2 sets cybersecurity risk management and incident reporting duties for many health-sector organisations, including manufacturers of pharmaceuticals and medical devices. The Cyber Resilience Act covers other products with digital elements; devices regulated under the MDR and IVDR are excluded from it, but your accessories, apps or non-medical products may not be.
GMP
Pharma and biotech systems
EU GMP Annex 11 and 21 CFR Part 11 expect computerised systems to be protected against unauthorised access and change, so that GxP data stays complete and accurate. The draft revision of Annex 11 expands these security expectations.
How an Engagement Works

From Gap Assessment to Ongoing Security

Step 1

Assess

A gap assessment of your products, processes and documentation against the requirements that apply to you.

Step 2

Plan

A prioritised plan, with procedures and templates adapted to your quality system.

Step 3

Build the Evidence

Threat models, risk assessments, SBOMs, test plans and the documentation for your submission or audit.

Step 4

Maintain

Vulnerability monitoring, patch assessment, incident response and periodic review, as a service or handed over to your team.

Our Experience

Security Grounded in Regulation and Engineering

Reviewer's View

Notified Body Experience

Four years as a Notified Body technical reviewer and site auditor, so we know what reviewers look for in a technical file.

Standards

Standards Development

Expert membership of IEC TC62, which develops the medical device software and health software standards, and chair of the NSAI committee that mirrors this work in Ireland.

Engineering & Teaching

Built and Taught

We follow IEC 81001-5-1 in our own software development, and lecture on healthcare software engineering and security at MSc level at Dundalk Institute of Technology.

Toolkit

Cybersecurity SOPs & Templates

Building the process in-house? Our Cybersecurity & Security SOPs Pack has nine documents: a cybersecurity policy, a STRIDE threat model template, an SBOM management plan and work instruction, a penetration testing work instruction, an incident response playbook and triage work instruction, a coordinated vulnerability disclosure template and an MDS2 security disclosure template.

Let's Work Together

Is Your Cybersecurity Ready for Review?

Tell us about your product or system, your markets and your timeline, and we will suggest where to start: a gap assessment, a threat model, or a plan for your next submission or audit.