IVDR (2017/746)

IVDR (2017/746) represents the European Union's comprehensive regulatory framework governing in vitro diagnostic medical devices. This regulation, which replaced the previous In Vitro Diagnostic Directive (IVDD 98/79/EC), establishes stringent requirements for safety, performance, and quality management of diagnostic medical devices across member states. For DevSecOps leaders and security directors working on software-intensive medical devices, understanding IVDR (2017/746) becomes critical when managing software development lifecycles that intersect with healthcare technology. The regulation places particular emphasis on software as a medical device (SaMD), demanding rigorous documentation, traceability, and security measures throughout the product lifecycle.

The intersection of medical device regulation and software supply chain security creates unique challenges for development teams. Organizations building diagnostic software or integrated systems must demonstrate compliance with both technical requirements and regulatory expectations, making the collaboration between compliance teams, security professionals, and development leaders more critical than ever.

‍

What is IVDR (2017/746)?

The In Vitro Diagnostic Regulation (2017/746) is a European Union legal framework that came into full application on May 26, 2022. This regulation defines the rules for placing in vitro diagnostic medical devices on the EU market, covering everything from simple laboratory reagents to complex diagnostic software systems. The regulation's scope extends to any device, reagent, calibrator, or control material intended by the manufacturer for in vitro examination of specimens derived from the human body.

IVDR (2017/746) introduces a risk-based classification system that categorizes IVD devices into four classes: A (lowest risk), B, C, and D (highest risk). This classification determines the level of scrutiny required during conformity assessment. Software components that qualify as IVD medical devices fall under this classification scheme, with many diagnostic algorithms and clinical decision support systems landing in higher risk categories due to their potential impact on patient care decisions.

Definition of IVDR Scope and Applicability

The regulation applies to manufacturers, authorized representatives, importers, and distributors who place IVD medical devices on the European market. For software teams, this means any diagnostic application, algorithm, or system that processes patient data to generate clinical information falls under regulatory scrutiny. The definition extends to companion diagnostics, screening devices, and even some laboratory information management systems depending on their intended use.

Key aspects that define IVDR applicability include:

• Medical purpose or intended use as defined by the manufacturer
• Processing of specimens derived from the human body
• Generation of information about physiological or pathological states
• Prediction of disease susceptibility or predisposition
• Monitoring of therapeutic measures or disease progression

Explanation of Risk Classification Under IVDR

The risk-based classification system represents a significant departure from the previous directive. Class A devices require the least regulatory oversight, while Class D devices undergo the most rigorous conformity assessment procedures. Diagnostic software typically falls into Class B, C, or D depending on the clinical decision it influences. Software intended for screening, self-testing, or making critical treatment decisions generally receives higher classifications.

The classification rules consider several factors:

• Whether the device is for self-testing purposes
• The nature of the disease or condition being diagnosed
• Whether the device is used for screening populations
• The criticality of the diagnostic information for treatment decisions
• The potential harm if the device produces incorrect results

‍

How IVDR Impacts Software Development Lifecycle

For organizations developing diagnostic software, IVDR (2017/746) fundamentally changes how development teams approach their work. The regulation requires implementing quality management systems that align with ISO 13485 standards, maintaining comprehensive technical documentation, and establishing robust post-market surveillance mechanisms. These requirements intersect directly with DevSecOps practices, demanding integration of compliance considerations into continuous integration and continuous deployment pipelines.

Software bill of materials (SBOM) documentation becomes particularly relevant under IVDR. Development teams must maintain detailed records of all software components, including open-source libraries, third-party dependencies, and custom code modules. This traceability requirement aligns closely with modern software supply chain security practices, where understanding component provenance helps mitigate security risks and respond to vulnerabilities.

Quality Management System Requirements

IVDR mandates that manufacturers establish, document, implement, and maintain a quality management system that ensures compliance throughout the device lifecycle. For software development teams, this translates to implementing processes that demonstrate control over design, development, verification, validation, and maintenance activities. The quality system must address risk management according to ISO 14971, incorporating cybersecurity considerations into the risk assessment process.

The quality management system must include:

• Document and record control procedures
• Design and development controls with defined inputs, outputs, and verification stages
• Purchasing controls for software components and services
• Production and process controls covering build and deployment procedures
• Identification and traceability mechanisms for software versions
• Non-conformity handling and corrective action procedures
• Post-market surveillance and vigilance systems

Technical Documentation and Software Traceability

Technical documentation under IVDR goes far beyond simple user manuals. Manufacturers must compile comprehensive technical files that demonstrate conformity with all applicable requirements. For software-based IVDs, this documentation must detail the software development lifecycle, including architecture diagrams, design specifications, verification and validation protocols, and cybersecurity documentation.

Traceability requirements demand that teams can track every component from requirements through deployment. This includes maintaining records of code commits, build processes, testing results, and deployment activities. Modern DevSecOps practices like infrastructure as code and automated testing help teams meet these documentation requirements while maintaining development velocity. Tools that automatically generate software composition analysis reports and dependency graphs become valuable compliance assets.

‍

Cybersecurity and Software Supply Chain Security Under IVDR

While IVDR doesn't explicitly mandate specific cybersecurity standards, Article 10 requires that devices are designed to minimize risks related to software defects and IT security vulnerabilities. The regulation recognizes that connected diagnostic devices face cyber threats that could compromise patient safety or data integrity. This recognition creates explicit obligations for manufacturers to address security throughout the product lifecycle.

The software supply chain represents a critical attack surface for diagnostic devices. Compromised dependencies, vulnerable open-source components, or malicious code injection during the build process could undermine device safety and performance. Security teams must implement controls that verify component integrity, scan for known vulnerabilities, and maintain visibility into the complete software supply chain.

Implementing Security Controls for IVDR Compliance

Security controls for IVDR compliance should address multiple layers of the software stack. Development teams need to implement secure coding practices, conduct regular security assessments, and maintain vulnerability management programs. The regulation requires that manufacturers establish procedures for updating software to address security vulnerabilities, including mechanisms for deploying patches without disrupting device functionality.

Key security controls include:

• Secure software development lifecycle practices including threat modeling
• Code review and static application security testing integration
• Dependency scanning and software composition analysis
• Container and infrastructure security for cloud-based diagnostics
• Access controls and authentication mechanisms
• Encryption for data at rest and in transit
• Security testing and penetration testing procedures
• Incident response and vulnerability disclosure processes

Software Bill of Materials for Medical Device Security

Maintaining an accurate software bill of materials has become a regulatory expectation and a security best practice. An SBOM provides transparency into the components that comprise a diagnostic application, enabling rapid response when vulnerabilities are discovered in upstream dependencies. For teams building medical device software, the SBOM serves dual purposes: meeting regulatory traceability requirements and supporting vulnerability management.

The level of detail required in medical device SBOMs exceeds typical software projects. Teams must document not just direct dependencies but also transitive dependencies, including the specific versions used in production builds. Automated SBOM generation integrated into the CI/CD pipeline helps teams maintain this documentation without creating excessive manual burden. The ability to quickly identify affected devices when a new vulnerability emerges in a common library can significantly reduce response time and patient risk.

‍

DevSecOps Practices for IVDR Compliance

Achieving IVDR compliance while maintaining agile development practices requires rethinking traditional approaches to both regulation and software delivery. DevSecOps methodologies that integrate security and compliance checks into automated pipelines provide a path forward. Rather than treating compliance as a gate at the end of development, teams can build continuous compliance into their daily workflows.

The key lies in automating evidence collection and compliance verification wherever possible. Every code commit, build, test run, and deployment generates data that contributes to the regulatory documentation package. By capturing this information systematically, teams reduce the compliance burden while improving the accuracy and completeness of technical documentation.

Continuous Compliance in CI/CD Pipelines

Integrating compliance checks into continuous integration pipelines transforms regulatory requirements from periodic obstacles into ongoing process improvements. Automated checks can verify that code changes include appropriate documentation, that security scans pass defined thresholds, and that changes receive required reviews before merging. These automated gates help teams catch compliance issues early when they're easier and cheaper to fix.

Pipeline stages for IVDR-compliant development might include:

• Commit stage: Automated unit tests, static analysis, and code quality checks
• Build stage: SBOM generation, dependency vulnerability scanning, license compliance checks
• Test stage: Integration tests, security testing, verification against requirements
• Release stage: Validation testing, documentation completeness checks, approval workflows
• Deployment stage: Traceability recording, release notes generation, change documentation

Documentation Automation and Traceability

Modern development tools generate vast amounts of data that can serve as regulatory evidence. Issue tracking systems capture requirements and design decisions, version control systems document code changes and reviews, and testing platforms record verification activities. The challenge becomes extracting this information in formats suitable for regulatory submission.

Documentation automation tools can bridge this gap by pulling information from development systems and generating formatted compliance documentation. Teams can maintain a single source of truth for requirements, with automated links showing how each requirement connects to design specifications, test cases, and implemented features. This approach reduces duplication and keeps documentation synchronized with actual development artifacts.

‍

Post-Market Surveillance and Incident Response

IVDR (2017/746) places significant emphasis on post-market surveillance, requiring manufacturers to actively monitor device performance after market release. For software-based diagnostics, this includes monitoring for security vulnerabilities, software defects, and performance issues that could impact safety or accuracy. The regulation requires establishing systematic processes for collecting and analyzing post-market data.

Security incident response becomes part of the regulatory framework under IVDR. When a cybersecurity vulnerability is discovered that could impact device safety, manufacturers must assess the risk, develop mitigations, and potentially notify regulatory authorities and customers. The speed and quality of incident response directly impacts patient safety and regulatory compliance.

Vulnerability Management for Medical Device Software

Managing vulnerabilities in medical device software presents unique challenges compared to conventional IT systems. Software updates require validation to confirm they don't introduce new risks, and deployment may require regulatory notification or approval depending on the significance of the change. Teams need processes that balance the urgency of security patching with regulatory requirements for change control.

A structured vulnerability management program should include:

• Continuous monitoring for new vulnerabilities in device components
• Risk assessment procedures that evaluate vulnerability exploitability and impact
• Prioritization criteria that consider both security risk and regulatory requirements
• Change control processes that determine whether updates require regulatory notification
• Testing and validation procedures appropriate to the change severity
• Deployment mechanisms that can reach all deployed devices
• Communication protocols for notifying stakeholders about security updates

Coordinated Vulnerability Disclosure

Medical device manufacturers must establish vulnerability disclosure policies that enable security researchers to report issues responsibly. IVDR's emphasis on safety requires that manufacturers take security reports seriously and respond appropriately. A well-structured disclosure program provides clear channels for reporting, defined response timelines, and transparent communication about remediation efforts.

The coordination becomes more complex when vulnerabilities affect third-party components used across multiple devices. Manufacturers may learn about vulnerabilities through public disclosures, vendor notifications, or direct reports. Regardless of the source, teams need processes to quickly assess impact, determine appropriate response, and implement fixes within timeframes that consider both security urgency and regulatory requirements.

‍

Securing Your Medical Device Software Supply Chain

Organizations developing diagnostic software under IVDR face the dual challenge of meeting regulatory requirements while defending against evolving cyber threats. The software supply chain connects these challenges, as vulnerable or compromised components could undermine both compliance and security. Building secure, compliant medical device software requires visibility into every component, control over the build process, and the ability to respond quickly when issues arise.

Kusari provides purpose-built tools for securing software supply chains in regulated environments. Our platform helps medical device manufacturers maintain the comprehensive traceability required by IVDR while implementing modern DevSecOps practices. From automated SBOM generation to continuous vulnerability monitoring and compliance reporting, Kusari integrates security and compliance into your development workflow. Schedule a demo to see how Kusari can help your team build secure, compliant diagnostic software.

‍

What Are the Key Requirements of IVDR (2017/746) for Software Developers?

The key requirements of IVDR (2017/746) for software developers center on establishing comprehensive quality management systems, maintaining detailed technical documentation, and implementing robust risk management processes. Software developers working on in vitro diagnostic devices must demonstrate that their development processes meet medical device quality standards, typically aligned with ISO 13485. This includes documented procedures for design controls, verification and validation activities, and change management processes that track every modification to the software throughout its lifecycle.

Risk management under IVDR (2017/746) requires developers to identify potential hazards associated with their software, including cybersecurity risks, and implement appropriate mitigations. The risk management process must continue throughout the product lifecycle, incorporating information from post-market surveillance to identify emerging risks. Software updates, whether for feature enhancements or security patches, must undergo risk assessment to determine whether they introduce new hazards or affect the device's safety profile.

Traceability represents another critical requirement under IVDR (2017/746) for software teams. Developers must maintain records that link requirements through design, implementation, testing, and deployment. This traceability enables manufacturers to demonstrate that the finished device meets its specifications and allows for impact analysis when changes are proposed. Modern development tools and practices can help teams meet these traceability requirements by automatically capturing relationships between requirements, code, and tests.

How Does IVDR (2017/746) Address Cybersecurity for Diagnostic Devices?

IVDR (2017/746) addresses cybersecurity through general safety requirements that obligate manufacturers to minimize risks related to IT security vulnerabilities and software defects. The regulation recognizes that connected diagnostic devices face cybersecurity threats that could compromise patient safety or data integrity. Article 10 specifically requires that devices incorporate features that reduce these risks to acceptable levels, considering the generally acknowledged state of the art in cybersecurity.

The cybersecurity expectations under IVDR (2017/746) align with guidance from regulatory bodies like the FDA and international standards such as IEC 62443. Manufacturers must demonstrate that they've conducted threat modeling to identify potential attack vectors, implemented appropriate security controls, and established processes for monitoring and responding to security vulnerabilities. The security documentation must explain design choices and justify why selected controls provide adequate protection given the device's risk classification and intended use environment.

Post-market cybersecurity obligations represent a significant aspect of how IVDR (2017/746) addresses security. Manufacturers must maintain vigilance systems that monitor for newly discovered vulnerabilities affecting their devices or the components they contain. When security issues are identified, manufacturers must assess whether they constitute reportable incidents, develop appropriate mitigations, and deploy updates to affected devices. The regulation's emphasis on continuous monitoring and improvement reflects the reality that cybersecurity threats evolve constantly.

What Documentation Must Be Maintained for IVDR (2017/746) Compliance?

Documentation requirements for IVDR (2017/746) compliance are comprehensive and cover the entire product lifecycle from initial design through post-market monitoring. The technical documentation must include a device description with intended purpose and risk classification, information about design and manufacturing including software architecture and development methodologies, verification and validation protocols and results, and instructions for use. For software-based diagnostics, the documentation must detail the software development lifecycle, including version control practices and configuration management procedures.

Quality management system documentation required for IVDR (2017/746) includes procedures for all processes that affect product quality. This encompasses design controls, purchasing procedures for components and services, production and process controls, and post-market surveillance systems. Software teams must document their development methodologies, coding standards, review processes, and testing strategies. The documentation should demonstrate that these processes provide adequate control to consistently produce safe, effective devices.

Risk management documentation forms another critical component of IVDR (2017/746) compliance documentation. Manufacturers must maintain risk management files that identify hazards, estimate and evaluate risks, implement and verify risk control measures, and monitor information about risks throughout the lifecycle. For software, this includes cybersecurity threat models, vulnerability assessments, and documentation of security controls. The risk management file must show that residual risks are acceptable and that benefits outweigh remaining risks.

How Do DevSecOps Practices Support IVDR (2017/746) Compliance?

DevSecOps practices support IVDR (2017/746) compliance by integrating security and quality controls directly into the software development lifecycle. Rather than treating compliance as a separate activity, DevSecOps embeds regulatory requirements into daily development workflows through automation and continuous monitoring. This approach helps teams maintain the comprehensive documentation and traceability required by IVDR (2017/746) while preserving development agility and enabling rapid response to security issues.

Automated testing and verification practices central to DevSecOps directly address IVDR (2017/746) requirements for software verification and validation. Continuous integration pipelines can execute test suites with every code change, generating documented evidence that requirements remain satisfied. Static analysis tools identify potential defects and security vulnerabilities early in development when they're easier to resolve. These automated checks provide the systematic verification evidence required in technical documentation while catching issues before they reach later development stages.

The transparency and traceability inherent in modern DevSecOps toolchains supports IVDR (2017/746) documentation requirements naturally. Version control systems maintain complete histories of code changes with associated context and rationale. Issue tracking platforms link requirements to implementation tasks and test cases. Build systems generate reproducible artifacts with complete component manifests. By leveraging these tools effectively, teams can extract regulatory documentation from their normal development activities rather than maintaining separate compliance documentation that risks falling out of sync with actual development artifacts, meeting IVDR (2017/746) requirements more efficiently.

Meeting Regulatory Demands While Building Secure Software

IVDR (2017/746) represents a significant regulatory framework that shapes how organizations develop diagnostic software for the European market. The regulation's emphasis on safety, performance, and quality management creates substantial obligations for manufacturers while ultimately serving to protect patients and healthcare systems. For DevSecOps leaders and security directors, understanding IVDR requirements enables building development processes that efficiently meet regulatory expectations while maintaining security and agility.

The intersection of IVDR compliance and software supply chain security creates both challenges and opportunities. The detailed traceability and documentation requirements align naturally with modern supply chain security practices like SBOM generation and dependency tracking. Organizations that invest in comprehensive software supply chain visibility gain both regulatory compliance benefits and improved security posture. The regulatory focus on cybersecurity and post-market surveillance reinforces the importance of continuous monitoring and rapid vulnerability response that characterizes mature DevSecOps programs.

Success with IVDR (2017/746) requires viewing compliance not as a constraint but as a driver for engineering excellence. The regulation's requirements for systematic design controls, comprehensive testing, and continuous improvement push teams toward practices that produce higher quality, more secure software. Organizations that embrace these principles and integrate compliance into their development culture will find themselves better positioned to deliver innovative diagnostic solutions that meet both regulatory standards and market needs, ensuring that IVDR (2017/746) considerations are woven throughout their software development lifecycle.

‍