Software as a Medical Device & Cybersecurity
Medical device software operates under a regulatory framework that most software companies did not build their processes for. Classification is not always obvious. IEC 62304 requires lifecycle documentation that agile teams rarely produce by default. Cybersecurity under IEC 81001-5-1 adds threat modelling, secure design evidence, and post-market monitoring obligations. And from August 2027, the EU AI Act introduces a parallel conformity assessment layer for AI-powered devices. We ensure your software development process produces the documentation, traceability, and evidence that regulators and Notified Bodies expect, without forcing you to abandon the development methodology that works for your team.
Examples of How We Support
These are just examples to illustrate the kind of work we do day to day. The fastest way is usually a short call to understand your situation and discuss how we can help.
CDSS qualification
You have developed a clinical decision support tool and need to determine whether it qualifies as a medical device under MDR. The MDCG 2019-11 decision steps are not always straightforward, particularly for software that provides recommendations rather than direct diagnostic outputs. You need a defensible classification with documented rationale before you invest in the wrong regulatory pathway.
IEC 62304 remediation
You are a device manufacturer with embedded software and your Notified Body has flagged gaps in your IEC 62304 compliance during the last audit cycle. Your development team writes code and runs tests, but the lifecycle documentation, traceability matrices, and SOUP management don't meet the standard. You need a gap analysis, a remediation plan, and someone to help restructure the documentation without halting development.
MDR and AI Act overlap
You are developing an AI-based diagnostic tool that analyses medical images. The MDR classification is clear (Class IIb), but you need to understand how the EU AI Act overlaps with MDR, what additional obligations it creates, and how to handle algorithm updates after CE marking without triggering a full new conformity assessment every time you retrain the model.
DiGA Fast-Track
You are a startup building a digital health application for the German market and want to pursue DiGA listing through the BfArM Fast-Track. You need regulatory classification, Class I or IIa under MDR, a clinical evidence strategy that satisfies BfArM's positive healthcare effects requirement, data protection compliance, and interoperability readiness, all before you apply.
Device cybersecurity questions
Your Notified Body has raised cybersecurity-related questions during the technical documentation review. You need to demonstrate compliance with IEC 81001-5-1, including a documented threat model, secure design review evidence, security test reports, and a vulnerability management plan. The questions need answering within the NB review timeline.
Understanding Software as a Medical Device & Cybersecurity
This page covers the regulatory and compliance requirements specific to medical device software: classification, IEC 62304 software lifecycle compliance, IEC 81001-5-1 cybersecurity, EU AI Act obligations, and DiGA/DiPA pathways. Our role is to ensure your development process meets regulatory expectations and that the resulting documentation satisfies Notified Bodies and authorities.
A note on terminology: the EU MDR uses the term "medical device software" (MDSW), while the international IMDRF framework and much of the industry use "Software as a Medical Device" (SaMD). The concepts overlap but are not identical. MDSW under MDR covers both standalone software and software that is a component of a device. SaMD, as defined by IMDRF (and used by the FDA), refers specifically to software intended to be used for medical purposes without being part of a hardware device. On this page we use both terms: MDSW when referring to EU MDR/IVDR scope, and SaMD when the context is international or when discussing classification under MDCG 2019-11, which itself uses both terms. The regulatory requirements we cover apply regardless of which label fits your product.
We do not develop software. For companies that need development support alongside regulatory compliance, we connect them with trusted partners experienced in medical device software and DiGA development. These partners deliver development projects that meet IEC 62304, IEC 81001-5-1, and MDR requirements. Through our device team, we also provide contract development for medical device software including AI-based solutions where regulatory and development expertise need to be tightly integrated.
For the broader device regulatory pathway (CE marking, technical documentation compilation, Notified Body coordination), see Medical Device Regulatory Services. For ISO 14971 risk management as it applies to software, see Risk Management & Human Factors. For clinical validation of digital health products, see Clinical Development. For organisational data protection and GDPR compliance (as distinct from device cybersecurity), see Data Privacy & Security.
What We Do
Software regulatory work spans classification, process compliance, documentation, and ongoing lifecycle management. Here is what we deliver in practice.
Our Workstreams
We structure our software regulatory work into defined workstreams. Most engagements combine classification with at least one process compliance workstream.
Classification & Regulatory Pathway
SaMD/MDSW qualification using MDCG 2019-11 decision steps. MDR/IVDR risk classification for standalone and embedded software. Qualification vs. classification decisions for borderline products (wellness app vs. medical device). Pathway mapping including Notified Body involvement requirements. Documentation of classification rationale.
IEC 62304 Lifecycle Compliance
Gap analysis against IEC 62304 requirements. Software safety classification (Class A, B, C). Process design and documentation framework for software planning, requirements, architecture, implementation, verification, release, and maintenance. SOUP and OTS component management: identification, risk assessment, and update monitoring. Traceability framework linking requirements to design, implementation, verification, and risk controls. Change management procedures for post-market software updates.
Cybersecurity (IEC 81001-5-1)
Threat modelling and security risk assessment. Secure design requirements definition and design review support. Security verification and testing plans. Vulnerability disclosure and management procedures. Post-market cybersecurity monitoring plan. Incident response planning. Cybersecurity file compilation for the technical documentation. Alignment with MDCG 2019-16 Rev.1 cybersecurity guidance.
AI/ML Regulatory Compliance
EU AI Act high-risk classification assessment for AI-powered medical devices. Mapping of AI Act requirements against existing MDR/IVDR conformity framework (per MDCG 2025-6). Algorithm change management: determining when model retraining or updates require regulatory action. Data governance and bias assessment documentation. Transparency and human oversight requirements. Post-market AI performance monitoring plan.
DiGA & Digital Health Pathways
BfArM Fast-Track regulatory strategy: provisional vs. permanent listing assessment. Clinical evidence planning for positive healthcare effects (pVE) demonstration. Data protection compliance (DiGAV, BSI TR-03161). Interoperability requirements (FHIR, MIO profiles). Reimbursement pathway alignment with GKV-SV negotiation. Application package preparation and BfArM assessment management.
Where This Fits in the Development Journey
Software regulatory requirements apply from the earliest classification decision through post-market lifecycle management. The heaviest workload falls during Design & Development.
Discovery & Concept
Determine whether the software is a medical device. Classify under MDR/IVDR. Assess the regulatory implications for the development approach and the level of lifecycle documentation required.
Design & Development
Implement IEC 62304 lifecycle processes. Integrate cybersecurity per IEC 81001-5-1. Build the documentation framework. Manage SOUP components. This is where the bulk of the compliance work happens.
Clinical
For digital therapeutics and DiGA: generate the clinical evidence required for regulatory approval or BfArM listing. Clinical validation study design sits with the Clinical Development team.
Regulatory Submission & Approval
Software lifecycle documentation integrated into the technical file for NB submission. AI Act conformity assessment where applicable. DiGA Fast-Track submission to BfArM.
Post-Market & Lifecycle Management
Post-market cybersecurity monitoring. Algorithm performance surveillance. Software update impact assessment and regulatory notification decisions. Vulnerability management.
Product Type Considerations
The regulatory requirements differ substantially by software type. Classification, lifecycle documentation depth, and cybersecurity expectations all depend on the software's intended purpose and risk profile.
Standalone SaMD (Class IIa)
Most common classification for clinical decision support and monitoring software. IEC 62304 software safety classification (typically Class B) determines the documentation depth. Cybersecurity file required. NB involvement for conformity assessment.
Embedded Software
Software as a component of a hardware device. IEC 62304 applies to the software; the overall device risk management (ISO 14971) addresses integration risks. Software updates may or may not require new conformity assessment depending on significance.
DiGA / Digital Therapeutics
German-specific pathway through BfArM. Must be Class I or IIa under MDR. Clinical evidence requirements (positive healthcare effects) differ from standard MDR conformity. Data protection (DiGAV, BSI TR-03161) and interoperability are assessed alongside clinical evidence. Reimbursement is tied to BfArM listing.
Standalone SaMD (Class IIb/III)
Higher-risk diagnostic or therapeutic software. Software safety classification typically Class C, requiring the most rigorous lifecycle documentation. Clinical investigation may be required. Full NB involvement with intensive TD review.
AI/ML-Based Devices
Algorithm change management is the central regulatory challenge. EU AI Act high-risk classification creates parallel obligations from August 2027. Continuous learning algorithms face particular scrutiny: each model update must be assessed for regulatory impact. MDCG 2025-6 provides current guidance on the MDR/AI Act intersection.
IVD Software
Classification under IVDR (may fall into Class A through D depending on function). Performance evaluation requirements for software-based IVDs include analytical and clinical performance validation. Common specifications may apply for certain IVD software categories.
Sample Deliverables
The outputs depend on whether the engagement focuses on classification, process compliance, cybersecurity, AI, or DiGA. These are typical deliverables.
SaMD classification rationale document with MDCG 2019-11 decision pathway, intended purpose analysis, and supporting evidence. 
IEC 62304 gap analysis report with finding-by-finding assessment, software safety classification determination, and prioritised remediation plan. 
Software lifecycle documentation framework: procedure templates, artifact specifications, and traceability matrix structure tailored to the client's development methodology. 
Cybersecurity file per IEC 81001-5-1: threat model, security risk assessment, secure design review records, security test reports, vulnerability management plan, and post-market monitoring plan. 
EU AI Act compliance assessment: high-risk classification determination, gap analysis against AI Act requirements mapped to existing MDR documentation, and remediation recommendations. 
Algorithm change management procedure: decision framework for determining when software updates require notification, new conformity assessment, or documentation updates only. DiGA Fast-Track application package: classification documentation, clinical evidence summary, data protection and interoperability checklists, and BfArM submission documentation. Example Projects
Illustrative Example
Clinical Decision Support SaMD: From Classification to CE Marking
A health technology company developed a clinical decision support tool for risk stratification in cardiology. We classified the software as Class IIa SaMD under MDR, conducted an IEC 62304 gap analysis of their agile development process, designed a compliant lifecycle documentation framework that preserved their sprint-based workflow, built the cybersecurity file per IEC 81001-5-1, and compiled the software-specific sections of the technical documentation. The Notified Body accepted the software documentation without major findings.
Illustrative Example
AI-Based Diagnostic Imaging: Navigating MDR and EU AI Act
A medical AI company developing an image analysis tool for pathology needed to understand the combined regulatory obligations under MDR (Class IIb) and the EU AI Act (high-risk). We assessed the AI Act requirements against their existing MDR conformity framework, developed an algorithm change management procedure to handle model retraining without triggering full re-certification, and created a post-market AI performance monitoring plan. The regulatory framework was accepted by the NB and the company's internal development team adopted the change management procedure for ongoing use.
Illustrative Example
DiGA Startup: BfArM Fast-Track from Concept to Listing
A startup developing a mental health digital therapeutic for the German market needed end-to-end regulatory support. We confirmed the MDR Class I classification, designed the clinical evidence strategy (randomised controlled trial for permanent listing), prepared the data protection and interoperability documentation, and managed the BfArM Fast-Track application. We connected the team with a development partner for the technical build. The application achieved provisional listing within the standard 3-month BfArM assessment timeline.
Developing Medical Device Software, Navigating SaMD Classification, or Preparing for IEC 62304 Compliance?
Tell us about your software and where you are in development, and we'll outline how we can help.
Speak with an ExpertKey Regulations & Guidance
These are the standards, regulations, and guidance documents that most directly shape our software regulatory work:
Frequently Asked Questions (FAQ)
How do I know if my software is a medical device under MDR?
The determination follows a two-step process defined in MDCG 2019-11. First, you assess whether the software meets the definition of a medical device (does it have a medical intended purpose?). Second, if it does, you apply the MDR classification rules to determine the risk class. Software that performs calculations or analyses on patient data to inform clinical decisions typically qualifies. Software that only stores, archives, communicates, or provides search functionality typically does not. The boundary is often less clear than it sounds, particularly for clinical decision support tools where the output could be interpreted as either information or a recommendation.
Can we use agile development and still comply with IEC 62304?
Yes. IEC 62304 does not prescribe a development methodology. It requires specific activities and documentation outputs (requirements, architecture, verification, traceability) but not a specific sequence or process model. Agile, V-model, and hybrid approaches all work. The challenge is mapping your agile artifacts (user stories, sprint reviews, automated test results) to the lifecycle documentation IEC 62304 expects. We design documentation frameworks that translate agile workflows into compliant lifecycle records without forcing your team into a waterfall process.
What does cybersecurity compliance look like for medical device software?
IEC 81001-5-1 requires you to integrate security activities into the software lifecycle: threat modelling during design, secure coding practices during implementation, security testing during verification, and vulnerability management and monitoring after release. The output is a cybersecurity file that becomes part of the technical documentation. Notified Bodies increasingly review this file as a core element of the TD.
How does the EU AI Act affect my AI-based medical device?
Under the EU AI Act (Regulation (EU) 2024/1689), most AI-powered medical devices that require third-party conformity assessment under MDR or IVDR are classified as high-risk AI systems. For AI embedded in regulated medical devices, the full high-risk obligations apply from August 2027. These include risk management for AI-specific risks (bias, robustness, data quality), data governance requirements, transparency and human oversight obligations, and post-market AI performance monitoring. MDCG 2025-6 provides guidance on how MDR/IVDR and AI Act requirements interact.
What happens when we update our algorithm after CE marking?
Every software update must be assessed for its impact on the device's safety, performance, and regulatory status. Not every update triggers a new conformity assessment. Minor bug fixes and UI changes typically require documentation only. Significant algorithm changes (new training data, changed model architecture, expanded intended use) may require Notified Body notification or a new conformity assessment. We design change management procedures that define clear criteria for categorising updates and determining the appropriate regulatory action.
Do you develop the software, or only handle the regulatory side?
Our core role is regulatory compliance and process alignment: classification, IEC 62304 process design, cybersecurity integration, documentation, and regulatory submissions. For companies that need software development, we connect them with trusted development partners. Through our device team, we also provide contract development for medical device software including AI-based solutions where tight integration between regulatory and development expertise is needed.
What is a DiGA and how does the BfArM Fast-Track work?
A DiGA (Digitale Gesundheitsanwendung) is a CE-marked medical device software application (Class I–IIb) that in most cases supports patients in managing or treating diseases. The BfArM Fast-Track is a 3-month assessment process that, if successful, lists the DiGA in the official DiGA Directory, making it prescribable by physicians and reimbursable by German statutory health insurance. Listing can be provisional (based on preliminary evidence, valid for 12 months, extendable to 24) or permanent (based on demonstrated positive healthcare effects through comparative studies).
How is IVD software classified under IVDR?
IVD software follows the IVDR classification rules in Annex VIII, which assign risk classes A through D based on the intended purpose and the consequences of incorrect results. Software that analyses patient samples or interprets diagnostic data may be classified as Class C or D, requiring Notified Body involvement and performance evaluation (analytical and clinical performance). Class D IVD software may also require EU Reference Laboratory opinions.