Server room with a brain scan, the cloud and a hospital linked

The cybersecurity file for connected medical devices.

Device software that can connect to the internet makes the device a cyber device under section 524B of the FD&C Act, and the EU MDR requires software devices to be designed for information security (Annex I, 17.2, 17.4 and 18.8). Silurus Software writes the threat model (threat modeling in US usage), the security requirements and their verification, the SBOM (software bill of materials, the list of every software component in the build) and the vulnerability process under IEC 81001-5-1, for the EU MDR technical documentation and the FDA premarket submission. The regulatory responsibility and the release decision stay with the client, as the legal manufacturer.

Book a 30 minute call Write to us

Standard: IEC 81001-5-1
FDA: Premarket cybersecurity
SBOM: CycloneDX · SPDX · VEX statements
Process: IEC 62304 · ISO 13485 · ISO 14971

What we cover

Security across the whole device

Threat modelling

One threat model covers the whole system, each threat rated for its exploitability and its effect on the patient, linked to the ISO 14971 risk file where it can lead to harm, with a control or a documented risk acceptance for each.

Security architecture

Identity, encryption, secure boot, logging and segregation are designed into the architecture from the start.

Security requirements and tests

Every control becomes a requirement, verified by a test, an analysis or a review and traced in the same matrix as the functional tests, with its residual risk.

Verification and validation →

SBOM and SOUP

The SBOM is generated from every build in CycloneDX or SPDX, checked against the released artefact, and shares its identifiers with the SOUP list (software of unknown provenance, meaning third party code used in the device), including the support status and end of support of each component.

Vulnerability management after release

New vulnerabilities are matched against the SBOM and triaged for this device in a documented record, shared as a VEX statement where customers need it, and fixes go through change control.

Secure updates

Signed updates with signature verification, anti-rollback protection and a controlled recovery path, analysed in the risk file and the threat model.

Embedded and firmware development →

Connected interfaces

Each interface is analysed for its threats and protected, the hospital network side included.

Regulatory file and hospital questions

Our regulatory specialists and FDA consultants prepare the security content of the submission and the answers to procurement questionnaires.

Regulatory consulting →

In practice

Situations we are asked to solve

Situation

A connected device going to the FDA

A connected device is heading for an FDA submission and has to meet the premarket cybersecurity requirements of section 524B.

How we approach it

We write the threat model and the security architecture views, the cybersecurity risk assessment, the SBOM with the assessment of its known vulnerabilities, and the cybersecurity management plan for after release. Our engineers run the security tests, penetration testing included, and the results are traced to the controls. The records are assembled for the eSTAR submission.

Situation

A device on the market without a security file

A connected device is on the market, and a hospital or the notified body (the independent organisation that certifies a device under the EU MDR) asks for its security documentation.

How we approach it

We start from the architecture and the code as they are, write the threat model and the SBOM, test the controls and answer the questions, including hospital procurement forms such as MDS2.

How it runs

From the architecture to the vulnerability process

Step 1

Architecture

Data flows, interfaces and trust boundaries of the whole system.

Step 2

Threat model

Each threat rated for exploitability and harm, with a control or a documented risk acceptance for each.

Step 3

Requirements and tests

Every control written as a requirement and verified by a test, an analysis or a review.

Step 4

SBOM and after release

An SBOM from every build, checked against each release, and new vulnerabilities triaged and recorded.

What you receive

The cybersecurity file

D-01

Threat model and security architecture views

The architecture views the FDA guidance names (global system, multi-patient harm, updatability and patchability, security use cases), with trust boundaries and every threat with its control, verification and residual risk.

Sample STRIDE threat table →

D-02

Cybersecurity risk assessment and testing

Each threat assessed for exploitability and linked to harm in the ISO 14971 file, each control a requirement traced to design and verification, the security test report and the security assessment of unresolved anomalies.

D-03

SBOM and VEX

The SBOM generated from the build, and the analysis of each known vulnerability against the device.

Sample SBOM excerpt →

D-04

Cybersecurity management plan

Monitoring, coordinated disclosure, the patch process under your change control, and the security information for the labeling and the secure configuration in the hospital network.

EU and US

One evidence base, two submissions

European Union

EU MDR

The security evidence mapped to MDR Annex I (17.2, 17.4 and 18.8) for the technical documentation, prepared with our regulatory specialists.

United States

FDA

The cybersecurity content of the premarket submission, prepared with our FDA consultants.

Technologies and standards

What we work with

Technologies and tools

SonarQubeCoverityPolyspacePC-lintclang-tidyCodeQLSemgrepOWASP Dependency-CheckSyftGrypeDependency-TrackANSI/AAMI SW96:2023

Standards, regulations and practices

MISRA CIEC 81001-5-1FDA section 524BFDA premarket cybersecurity guidanceMDCG 2019-16 rev.1EU MDREU MDR Annex IISO 14971AAMI TIR57IEC 62304ISO 13485Threat modellingSTRIDECybersecurity risk assessmentSecurity architecture viewsSBOMCycloneDXSPDXVEXPenetration testingCoordinated vulnerability disclosureeSTARMDS2

Silurus Software

Silurus Software, founded in 2017, offices in Budapest, Hungary, and Singapore
More than 40 engineers, EU MDR regulatory specialists and FDA consultants
Work inside the client's ISO 13485 quality management system, with the split of tasks written down before the work starts. Where the client has no documented software process yet, we bring IEC 62304 templates for the client to adopt into its own system
Multi-year engineering partner of a European MedTech manufacturer
Founder and CTO Péter Török, in medical technology software since 1999, formerly software development director at Siemens Healthcare (syngo.via) and head of R&D at Mediso Medical Imaging Systems
ISO 9001:2015 (NQA, certificate 171041, valid until March 2027) and ISO/IEC 27001:2022 (NQA, certificate 728872, valid until August 2029)
Awarded AAA, Highest Creditworthiness, by Dun & Bradstreet in 2025
Research partner of ELTE Eötvös Loránd University, Budapest
Industrial partner of the University of Bologna, the University of Pisa, the University of Amsterdam and Masaryk University, Brno, in the EU Horizon Europe project LOGOS from 2027
Female Business Leader of the Year 2025 and The Pioneer Award 2026, awarded to CEO Dr. Linda Szántó

How we work →Quality and standards →Sample deliverables →Case studies →

Related work and pages.

Sample deliverables Regulatory consulting, EU MDR and FDA Verification and validation Embedded and firmware development Retrospective IEC 62304 documentation

FAQ

Frequently asked questions

Which SBOM format do you deliver?

CycloneDX or SPDX, generated from every build and checked against the released artefact, so the SBOM of a release matches the shipped software.

Our device is already on the market. Can you build the file after the fact?

Yes. We start from the architecture and the code as they are, then write the threat model, the SBOM and the missing requirements and tests. Records written after the fact describe the device as it is, and missing controls are implemented in the software and then documented.

How are the security tests traced?

In the same matrix as the functional tests, each test linked to the control it verifies.

Do you work in our QMS and templates?

Yes. The records are written in your templates and under your document control.

Can the same work serve the EU MDR and the FDA?

Yes, as one evidence base. The threat model, the tests and the SBOM are shared, and the FDA submission content and the MDR Annex I mapping are prepared for each route by our regulatory specialists and FDA consultants.

Who is responsible for the cybersecurity file?

You as the manufacturer. You approve the records and own the release decision and the regulatory responsibility, and we write and verify the file under your QMS.

Do you run penetration tests?

Yes. Our engineers run penetration tests and other security tests on the device, its interfaces and the cloud part, and the findings go into the risk assessment and the change control.

Which FDA cybersecurity documents do you prepare?

The threat model and security architecture views, the cybersecurity risk assessment, the SBOM with its vulnerability assessment, the security test reports and the cybersecurity management plan.

How long does a cybersecurity file take?

It depends on the architecture and on what exists. A gap analysis (a review of what is missing against the standard) of the current state comes first and sizes the work.

How does the FDA QMSR affect the cybersecurity work?

The FDA Quality Management System Regulation (QMSR, 21 CFR 820), in force since 2 February 2026, incorporates ISO 13485 by reference. The threat model, the risk assessment and the security tests are kept as design records under that quality system. The EU MDR technical documentation draws on the same ISO 13485 records, so one evidence base serves section 524B and the EU MDR.

Talk to us

Tell us about the device.

The device, its connections and the market. We reply with what the file needs and where to start.

Book a 30 minute technical call