Author: Brandon Miller

Why Cybersecurity Has Become a Regulatory Priority

As combination products increasingly rely on software, connectivity, and digital interfaces, cybersecurity has moved from a secondary concern to a core regulatory expectation. What was once viewed as an IT or infrastructure issue is now clearly framed by regulators as a patient safety risk.

Vulnerabilities that go unaddressed during development can expose patient data, disrupt device performance, or create pathways into broader healthcare networks. FDA scrutiny has followed this reality—with expectations now focused on how cybersecurity risks are identified and controlled across the entire product lifecycle.

When Software Expands the Regulatory Scope

Once software plays a role in device operation, data handling, or clinical functionality, it introduces a new regulatory dimension. IEC 62304 establishes expectations for managing medical device software throughout its lifecycle, and FDA increasingly looks for evidence that these principles are embedded into development practices.

This includes clearly defining software architecture, understanding how different components interact, and documenting how risks are assessed and mitigated. Software complexity, especially when multiple operating systems, programming languages, or third-party components are involved, increases the likelihood that vulnerabilities exist. Regulators expect sponsors to demonstrate awareness of that complexity and control over its impact.

Secure by Design Starts at the Requirements Level

One of the most common contributors to cybersecurity weaknesses is poor design planning. When security requirements are vague, incomplete, or added late in development, vulnerabilities are often baked into the product.

FDA expectations increasingly reflect a “secure by design” mindset. The strongest cybersecurity controls are those that eliminate or reduce vulnerabilities through planned architecture and clear requirements. Protective mechanisms that detect and respond to threats are the next layer of defense.

Effective cybersecurity requires giving security considerations a formal seat at the design table, supported by subject matter expertise and documented decision-making. Otherwise, designers run the risk of relying primarily on labeling, instructions, or user warnings for security—which are considered the weakest mechanisms available.

Software Changes Are Lifecycle Events, Not IT Tasks

As vulnerabilities evolve, software must be maintained through updates and patches. These activities are not routine maintenance tasks. Each change has the potential to affect safety, performance, and compliance.

FDA expects organizations to assess software changes through a quality and risk lens, not an IT convenience lens. Updates tied to cybersecurity posture or device behavior typically require formal change control, risk evaluation, and verification. Organizations that lack clear criteria for distinguishing between design-controlled changes and minor maintenance should expect to struggle when questioned during inspections.

Cybersecurity Documentation FDA Now Expects

Cybersecurity reviews increasingly include specific deliverables that demonstrate transparency and control. One example is the Software Bill of Materials, which identifies third-party software components and dependencies. This allows regulators to assess supply chain risk and vulnerability exposure.

Threat modeling documentation is also becoming more common, showing how potential attack scenarios were identified and addressed. Additional artifacts may include secure development lifecycle procedures, vulnerability management processes, and post-market monitoring strategies that demonstrate ongoing accountability rather than one-time compliance.

Integrating Cybersecurity Into a Streamlined QMS

For combination products, cybersecurity controls can be integrated into an existing pharmaceutical quality system through the streamlined approach allowed under 21 CFR Part 4. This avoids duplicative systems while ensuring software and cybersecurity risks are appropriately governed.

Successful integration depends on alignment between software development, Design Controls, risk management, and quality oversight. When cybersecurity is embedded into the QMS and the D&D file for the device rather than bolted on after the fact, inspection readiness improves significantly.

How RCA Supports Software and Cybersecurity Readiness

Regulatory Compliance Associates® (RCA) helps life sciences organizations build inspection-ready software and cybersecurity frameworks tailored to combination products.

From TIR57 and ISO 14971 compliance and cybersecurity documentation to inspection preparation and training, RCA partners with teams to navigate this complex and rapidly evolving regulatory landscape with confidence.

Ready to streamline your QMS for combination product success?
Contact RCA today to schedule a consultation and take the first step toward regulatory readiness and market leadership.

Why Design Controls Are the Biggest Leap for Drug Teams

For pharmaceutical and biologic organizations entering the combination product space, few regulatory requirements cause as much friction as design controls under FDA QMSR. Unlike traditional pharmaceutical Quality Risk Management (QRM), design controls require a structured and documented history of how the device portion of a product was conceived, designed, verified, validated, and transferred into production.

For many drug teams, this represents a fundamental shift from the line of thinking they are accustomed to. Quality is no longer focused solely on batch release, clinical outcomes, or GMP compliance. Instead, regulators expect a living design narrative that demonstrates intentional engineering decisions and risk-based controls throughout the product lifecycle.

Why Pharmaceutical Risk Management Is Not Device Risk Management

Pharmaceutical QRM, often aligned with ICH Q9, is typically focused on patient safety, process variability, and manufacturing controls. Device risk management, however, is governed by ISO 14971 and embedded directly into design controls.

The key distinction is timing and intent.

Pharma risk management often evaluates risk after formulation and process decisions are made. Device risk management is proactive and iterative, requiring teams to identify hazards, estimate and evaluate risks, implement controls, and reassess residual risk throughout design and development.

For combination products, the FDA expects risk management to be tightly linked to design inputs, outputs, verification, and validation. A standalone risk assessment or FMEA is not sufficient if it is not clearly integrated into the design history.

The Circular Nature of Design Inputs and Outputs

One of the most misunderstood aspects of design controls is that design is not linear. Design inputs inform outputs, but outputs frequently expose gaps, ambiguities, or risks that require refinement of inputs. This circular relationship is not a weakness. It is an expected and documented part of compliant device development.

Design inputs define what the device must do, including performance requirements, safety considerations, usability needs, and regulatory constraints. Design outputs translate those requirements into drawings, specifications, software code, and manufacturing instructions.

FDA investigators routinely look for evidence that inputs and outputs were revisited as new information emerged. Static inputs that never evolve raise red flags during inspection.

Why Clinical Trials Do Not Equal Design Validation

A common misconception among drug-focused organizations is that clinical trials satisfy device design validation requirements. While clinical data may support aspects of performance or safety, FDA does not consider clinical trials alone to be sufficient design validation for the device component.

Design validation under QMSR and ISO 13485 requires documented evidence that the device meets user needs and intended uses under actual or simulated use conditions. This includes usability testing, human factors engineering, and validation of device performance independent of clinical efficacy endpoints.

In short, proving the therapy works does not automatically prove the device was designed correctly.

Design Transfer Is Where Many Programs Fail

Design transfer is often treated as an administrative milestone. In reality, it is a critical control point where FDA scrutiny increases significantly.

Design transfer ensures that the device design is correctly translated into production specifications and manufacturing processes. Regulators expect clear evidence that manufacturing can consistently produce devices that meet approved design requirements.

Weak design transfer frequently results in downstream CAPAs, nonconformances, and delayed approvals. Strong design transfer, on the other hand, creates alignment between R&D, quality, and manufacturing and significantly reduces lifecycle risk.

Building Design Controls Without Rebuilding Your QMS

For combination products, design controls do not require a full medical device QMS. Under the streamlined approach, organizations can integrate design control elements into an existing pharmaceutical system while maintaining compliance with 21 CFR Part 4.

The key is intentional integration, not duplication. Design controls must be documented, traceable, and inspection-ready, but they can coexist with pharmaceutical processes when structured correctly.

How RCA Helps Drug Teams Navigate Design Controls

Design controls are challenging because they force organizations to think differently about development. Regulatory Compliance Associates® (RCA) helps pharmaceutical and biologic companies implement right-sized design control frameworks that meet FDA expectations without unnecessary complexity.

Ready to streamline your QMS for combination product success?

Contact RCA today to schedule a consultation and take the first step toward regulatory readiness and market leadership.