What Information FDA is Expecting for Cyber Devices?


In an era where medical devices are increasingly interconnected and reliant on software, cybersecurity has become a critical component of healthcare. The FDA recognizes the importance of cybersecurity in protecting public health and ensuring the safety and effectiveness of medical devices. To address these concerns, the FDA has outlined specific cybersecurity information needs for medical device manufacturers in Final guidance Cybersecurity in Medical Devices (September 26, 2023).

Understanding the FDA’s Role in Cybersecurity

The FDA is responsible for regulating medical devices to ensure they are safe and effective for use. With the growing integration of digital technologies in medical devices, the FDA’s oversight was expanded to include cybersecurity. This includes assessing the cybersecurity risks of devices during the premarket review process to determine if the manufacturer has provided a reasonable assurance that cybersecurity concerns have been adequately addressed, and monitoring for vulnerabilities post-market will be in place.

Here are the critical components manufacturers must address:

1. Architecture Security Views
Global System View

Manufacturers must provide a comprehensive overview of the device’s architecture, including how it interacts with other systems. This global system view should highlight:

  • Network interfaces and communication pathways.
  • Data flow between components and external systems.
  • Potential entry points for cyber threats.
Multi-Patient Harm View

The multi-patient harm view focuses on the potential impact of cybersecurity threats on multiple patients. This includes:

  • Assessing scenarios where a single cyber incident could affect multiple patients.
  • Identifying critical vulnerabilities that could lead to widespread harm.
  • Implementing safeguards to mitigate such risks.
Updatability and Patchability View

This view addresses the device’s capability to be updated and patched throughout its lifecycle. Manufacturers should detail:

  • The process for delivering updates and patches.
  • Mechanisms to ensure updates do not compromise device functionality.
  • Strategies to minimize downtime and disruption during updates.
Additional Security Views

Other security views may include:

  • Access Control View: Describing how access to the device and its data is controlled and monitored.
  • Data Integrity View: Ensuring that data stored, processed, and transmitted by the device remains accurate and unaltered.
2. Threat Modeling
Data Flow Diagrams

Threat modeling involves identifying potential threats to the device by mapping out data flows. Data flow diagrams should:

  • Illustrate how data moves through the system.
  • Highlight points where data may be vulnerable to unauthorized access or modification.
  • Serve as a basis for identifying and mitigating threats.
3. Threat Analysis
Non-probabilistic Scoring

The Common Vulnerability Scoring System (CVSS) or similar, is used to evaluate the severity of vulnerabilities. Manufacturers should:

  • Assign non-probabilistic scores to identified vulnerabilities.
  • Prioritize mitigation efforts based on the severity of these scores.
  • Continuously reassess vulnerabilities as new threats emerge.

Effective mitigation strategies are essential for addressing identified vulnerabilities. This includes:

  • Implementing technical controls, such as encryption and authentication.
  • Developing response plans for potential cybersecurity incidents.
  • Regularly updating security measures based on new threat information.
4. Management Plans
Device Update

Manufacturers must have a robust update management plan that ensures:

  • Timely deployment of security patches and updates.
  • Clear communication with users about the importance of updates.
  • Procedures to verify the successful application of updates.
Response to incidents

A well-defined response plan is crucial for addressing cybersecurity incidents. This plan should include:

  • Steps for identifying and assessing incidents.
  • Procedures for containing and mitigating the impact of incidents.
  • Communication protocols with stakeholders, including the FDA and affected users.
5. Testing Results
Penetration Testing

Penetration testing involves simulating cyber attacks to identify vulnerabilities. Manufacturers should:

  • Conduct regular penetration tests.
  • Document the findings and remediation efforts.
  • Use the results to strengthen security measures.
Fuzz Testing

Fuzz testing involves inputting random data to find vulnerabilities. Key aspects include:

  • Identifying potential points of failure.
  • Evaluating the device’s response to unexpected inputs.
  • Using the results to improve the device’s robustness.

Other testing as appropriate.

6. Software Bill of Materials (SBOM)

Software bill of materials for all software that is part of the medical device.  These SBOM’s should be machine readable and follow a standard format.

Vulnerability Analysis

Vulnerabilities in third-party software components should be analyzed:

  • Determine impact on the medical device and provide any necessary mitigation.
  • Ensure third-party vendors provide timely security updates.
Support Expectation for Third-Party

Manufacturers must outline their expectations for third-party software support, including:

  • Commitments from vendors to provide updates and patches.
  • Processes for integrating third-party updates into the device.
  • Contingency plans for unsupported third-party components.
7. Monitoring and Incident Reporting
Analysis of Incidents

Continuous monitoring and analysis of cybersecurity incidents are vital. This involves:

  • Collecting and analyzing data on security incidents.
  • Identifying trends and patterns in incidents.
  • Using insights to improve device security.
Metrics to gauge effectiveness

Developing metrics to measure the effectiveness of cybersecurity efforts is crucial. Key metrics might include:

  • Number and severity of identified vulnerabilities.
  • Time taken to deploy updates and patches.
  • Frequency and impact of cybersecurity incidents.
Product Update Cycles

Manufacturers should establish regular product update cycles, ensuring:

  • Consistent and timely updates to address new threats.
  • Communication with users about upcoming updates.
  • Minimization of disruption during the update process.
The Implications for Manufacturers and Healthcare Providers

Adhering to the FDA’s cybersecurity information needs is crucial for manufacturers to ensure their devices are secure and compliant with regulatory requirements. By integrating cybersecurity into the entire lifecycle of a medical device, manufacturers can protect patient safety, maintain trust, and reduce the risk of costly recalls and legal issues.


As medical devices become more interconnected and reliant on digital technologies, cybersecurity will continue to be a top priority for the FDA and the healthcare industry. By addressing the FDA’s cybersecurity information needs, manufacturers can ensure their devices are secure, effective, and capable of protecting patient health in an increasingly digital world.

Bold Type is here to help whether you need a secure software development partner or just a consultant to help ensure your system is secure and will meet FDA’s latest requirements. Reach out at [email protected] to set up a quick chat.


Ensuring Secure Software Updates for Medical Devices


While remote software updates for medical devices have traditionally been seen as a convenient feature, the FDA now emphasizes their crucial role in safeguarding against discovered cybersecurity vulnerabilities. However, it’s imperative that these updates themselves are secure; otherwise, they become potential avenues for cyber attacks.

Differentiating Secure from Insecure Software Updates:

The journey towards a secure update begins with a fundamental capability known as ‘secure boot’. This hardware-based feature ensures that only authorized software runs during device startup. It’s paramount that no mechanism, whether in hardware or software, undermines this process. Despite processor manufacturers often including ‘back door’ access for development purposes, these must be disabled in production for genuine security. The software executed during boot-up is typically stored internally within the processor, safeguarding it against modifications. While it’s feasible to store boot software externally, verifying its authenticity poses challenges in smaller systems. The selection of cryptographic authentication methods is pivotal and may hinge on available hardware and software.

By combining secure boot hardware with trusted boot software, a cryptographic root of trust is established on the processor. This setup guarantees that the device powers up securely each time, allowing validation of the main software application before execution.

Steps for Secure Updates:

  1. Downloading from a Trusted Source: Initiating an update process begins with downloading the update from a trusted remote source. Authentication of this source is critical and can be achieved through cryptographic means, utilizing pre-provisioned information and identity details from the source. Commonly, X509 certificates are utilized to provide attestation information.
  2. Verification of the Update: Upon downloading, the update undergoes cryptographic verification to ensure its trustworthiness. This involves computing a cryptographic hash of the update and validating it against a provided cryptographic signature from the software builder, ensuring it was produced by a trusted source.
  3. Application of the Update: Once verified, the trusted update is applied to the device, either replacing the existing software or patching it. The new software is treated to ensure trustworthiness in subsequent power-up cycles, often involving the computation of a cryptographic hash and secure storage of this hash for future verification.

This framework guarantees that only trusted software is executed, ensuring the system remains secure throughout the update process. While additional considerations such as fallback mechanisms and encryption methods are important, they build upon the robust foundation established here.

At BoldType, we have decades of experience in developing and deploying secure remote software update mechanisms. Let us assist you in implementing a secure update mechanism for your next product, ensuring all software updates are executed safely and securely.


New Cybersecurity Regulations Make Remote Software Updates Practically Mandatory


A startup recently shared with us that they were considering incorporating remote software updates into their medical device. They knew this feature would add a lot of value, but were leaning against it for fear it would create barriers to FDA approval due to cybersecurity concerns. This is a natural concern, especially given the major changes around cybersecurity that have happened at FDA in the last year. We would argue, however, that remote software updates are no longer optional precisely because of FDA’s increased scrutiny on cybersecurity. 

First, a quick history. FDA has recognized the importance of cybersecurity for more than a decade. In 2014 and 2016, they finalized guidance documents on cybersecurity information in pre-market submissions and post market management of cybersecurity. While FDA technically did not have statutory authority to require cybersecurity information, they understandably argued that cybersecurity is key to device safety, and therefore in their purview. Medical device manufacturers were expected to include a cybersecurity file with basic risk analyses, but the bar was not particularly high; especially for low risk devices. 

Everything changed in 2023, however, when the Food and Drug Omnibus Reform Act (FDORA) codified new statutory authority for the FDA to require cybersecurity information and post-market monitoring for cybersecurity vulnerabilities. Section 524B of the Federal Food, Drug and Cosmetic (FD&C) Act now requires specific cybersecurity information for all “cyber devices” and detailed plans on how vulnerabilities will be handled post-market. Now you might be thinking, “yeah, but my device is not a cyber device.” Think again. 

Here is how the FD&C Act defines a cyber device: 

DEFINITION.—In this section, the term ‘cyber device’ means a device that—

(1) includes software validated, installed, or authorized by the sponsor as a device or in a device;

(2) has the ability to connect to the internet; and

(3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

Now you might be thinking, “Cool, so long as my device doesn’t connect to the internet, it’s not a cyber device.” Not so fast. FDA probably heard this once or twice and decided to provide some additional clarification in their March 2024 draft guidance Select Updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act. Here it their clarification verbatim: 

FDA considers devices that include any of the following features to have the ability to connect to the internet. The list below is illustrative, not exhaustive:

  • Wi-Fi or cellular;
  • Network, server, or Cloud Service Provider connections;
  • Bluetooth or Bluetooth Low Energy;
  • Radiofrequency communications;
  • Inductive communications; and
  • Hardware connectors capable of connecting to the internet (e.g., USB, ethernet, serial port).

Did you pick up on that last line? FDA is saying, if you incorporate any means of wireless or wired communication in your device, it’s a cyber device!

So what does that have to do with remote software updates? Well, section 524(b)(1) of the FD&C Act requires plans that describe “the timeline, with associated justifications, to develop and release required updates and patches.” Again, verbatim from the guidance: 

  • Section 524B(b)(2)(A) of the FD&C Act requires manufacturers of cyber devices to make updates and patches for known unacceptable vulnerabilities available on a reasonably justified regular cycle.
  • Section 524B(b)(2)(B) of the FD&C Act requires manufacturers of cyber devices to make available updates and patches to the device and related systems to address as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks.

Now you tell me: how are you going to “make updates and patches” to your cyber device without remote software updates? Will you execute a physical device recall? Is the plan to send a technician around with a thumb drive? Putting aside the cost and reputational damage to either of these approaches, it probably won’t fly with FDA anyway. Notice the language: “the FD&C Act requires manufacturers of cyber devices to make available updates and patches to the device and related systems to address as soon as possible out of cycle..” 

The bottom line is that FDA just raised the cybersecurity bar substantially when it comes to medical devices that incorporate software and any conceivable means of external access. You’re not going to be able to get away with simple rationales of why your device is low risk or why it is not a cyber device. Chances are that (a) your device is a cyber device, (b) you need to make sure cyber security risks are managed, and (c) you need a means to update it remotely once fielded. 

Now here is the good news: First, ensuring the cybersecurity of your device is not just a good idea because FDA is forcing you to; it’s the right thing to do and it’s the smart thing to do. Second, it’s not just a cybersecurity issue. You may find a software anomaly that impacts your device’s safety and be forced to issue a recall if you don’t have remote software update capabilities. Third, data is gold. Avoiding cloud connectivity out of cybersecurity fear robs you of the tremendous value that comes from generating and accessing all sorts of data that increase your enterprise value.  And finally, implementing secure remote software updates (and cloud connectivity in general) is challenging, but it’s not rocket science. You just have to make sure it is truly secure. In our next blog, we’ll explain precisely how to do that. 

Bold Type is here to help whether you need a secure software development partner or just a consultant to help ensure your system is secure and will meet FDA’s latest requirements. Reach out at [email protected] to set up a quick chat.


6 pitfalls to avoid when developing mobile apps for medical devices


In the bustling healthcare landscape, the mHealth market—estimated between $50 billion and $110 billion USD in 2022—is more than just a promising niche. Given the roaring momentum, you’d expect the roadmap for the mHealth App development to be very well defined by now. But the reality is a bit murkier than that. As evidenced in the significant differences in market estimates, defining even what is an mHealth system remains a debate. A bird’s-eye view of the challenges facing the mHealth industry as it moves toward maturity:

Sky-high user expectations: Mainstream consumer apps developed by very large companies with equally large budgets have set the bar extremely high. Companies entering the mHealth space must be deliberate in managing these expectations with all stakeholders, both internal and external.

Consumer app startup culture: Consumer-app style rapid development is enabled by small teams quickly assembled together and leveraging large collections of off-the-shelf software libraries. They operate in a market where failure costs little, you learn from the failure, and iterate. The culture that fits consumer-apps however lacks the processes and systems required to ensure the quality, safety, and security required for mHealth applications.

Regulatory catch-up: Healthcare regulators are grappling to define standards for an industry that’s evolving faster than they can staff and skill up. Regulators understand that mHealth has enormous potential to transform healthcare by reducing cost and bringing care closer to the patient, but they are rushing to prevent the industry from practices that pose risks to the delivery of care.

These three industry-wide challenges translate into common mistakes made by companies as they develop new mHealth solutions. If you’re charting the course for your organization’s mHealth foray, here are a few pitfalls you might want to sidestep:

1. Compliance isn’t a last-minute job: It’s a common misstep to design an mHealth app and then scramble to wrap it in a cloak of compliance. A well-crafted app starts with a foundation of solid design controls and risk management practices from the outset. Retrofitting these crucial aspects as an afterthought can result in software that’s shaky at best, with issues that can’t merely be patched up later.

2. Premature implementation: While the startup world champions the “build fast and iterate” mantra, the mHealth realm demands more caution. Rushing to code can often lead to costly detours and rework. Instead, invest time in proof of concept prototypes that validate your technical approach. Then invest in formative tests with cost-efficient mockups rather than code implementations. These preliminary steps, although seemingly slow, can fast-track the latter stages of development and ensure a smoother rollout.

3. Ambiguous regulatory strategy: Venturing into mHealth without a regulatory compass can lead to directionless development. A well-defined regulatory strategy not only ensures compliance but also streamlines your app’s focus. It delineates the boundaries, ensuring you don’t inadvertently overstep or underdeliver which often leads to failed regulatory submissions.

4. Conflating features: In the bid to offer a comprehensive solution, there’s a temptation to pack an app with myriad features, medical and otherwise. However, blurring these lines can complicate the regulatory process and muddy the app’s core value proposition. Instead, strategically segment medical device functions from non-medical ones, ensuring clarity and minimizing red tape.

5. Settling for mediocre content: User experience is paramount. Lackluster images or poorly crafted content can diminish the perceived value of your app. Remember, in the digital realm, presentation matters immensely. Whether it’s a crisp infographic, a compelling video, or a well-written user guide, quality content can elevate the overall user experience and enhance engagement.

6. Beware of feature overload: While it’s natural to want your app to be a one-stop solution, it’s essential to discern between what’s necessary and what’s superfluous. Prioritize features that align with your app’s core objectives, and resist the allure of adding bells and whistles that don’t directly enhance its value. Overcomplicating the app not only strains development resources but can also confuse and deter users.

Developing a stellar mHealth app isn’t just about coding—it demands a strategic blend of technology, regulatory insight, and market understanding. At Bold Type, we’ve honed our expertise to guide product managers and executives like you through this intricate terrain. Instead of shortcuts, we offer smart cuts. If you’re ready to embark on your mHealth journey with a partner that gets it, let’s connect. Together, we can define the future of mHealth.


You don’t need a full QMS: Leverage your development partner and contract manufacturer



In today’s competitive and fast-paced market, efficiency and lean operations are essential. For startups and small businesses, setting up a full-fledged Quality Management System (QMS) can be an overwhelming endeavor in terms of cost, time, and resources. However, the good news is that you don’t always need to. By leveraging your development partner and contract manufacturer, you can streamline quality without the overhead of a full QMS. Let’s delve into how.

Understanding the QMS Landscape

At its core, a QMS is an organized framework that outlines the processes, procedures, and responsibilities needed to achieve and uphold a company’s quality goals. It’s designed to synergize a company’s operations to not only meet customer and regulatory requirements but also to drive ongoing improvements in quality and efficiency. While traditional approaches to a QMS might paint a picture of a comprehensive, intricate system, the modern landscape is evolving. With the rise of partnerships and collaborative business models, companies now have more flexible options. They can integrate established systems from experienced partners rather than constructing an entire infrastructure from the ground up.

The Power of Partnership 

Startups and smaller enterprises can sidestep the complexities of a full QMS by forging strong partnerships with the right development partners and contract manufacturers.  Here’s why:

  • Share Resources and Knowledge: Established development partners and contract manufacturers often already have a robust QMS in place and commonly their QMS is certified to meet applicable standards and requirements.  By collaborating with them, startups can tap into these resources, avoiding the redundancy of creating a system from scratch.
  • Compliance and Standards: Regulatory compliance can be a maze. By leveraging a partner with expertise in regulatory standards, businesses can ensure their products meet required guidelines without the need to invest in internal training and infrastructure.
  • Continuous Improvement: Seasoned development partners and contract manufacturers bring with them years of experience and iterative improvements. This allows startups to benefit from best practices and process optimizations right from the start.

Selecting the Right Partner

Of course, the efficiency of this approach hinges on choosing the right partner. Here are some factors to consider:

  • Reputation and References: Ensure that the chosen partner has a solid reputation in the industry and positive feedback from previous collaborations. 
  • Alignment of Values: Both parties should share a common vision and values, especially concerning quality, communication, and customer satisfaction.
  • Flexibility: As needs change, it’s essential to have a partner willing to adapt and adjust to support evolving business requirements.

Maintaining a Hybrid Approach

For some businesses, a blend of internal processes with the resources of an external partner can be the best approach. This hybrid strategy is gaining traction because it allows companies to maintain some autonomy by retaining elements of a QMS in-house, while relying on the expertise and infrastructure of a development partner for more complex components. This can be especially pertinent for unique processes or trade secrets that differentiate a business in the market. Additionally, the experience and proven methodologies of a development partner can significantly accelerate implementation of refined processes. Moreover, this symbiotic relationship often leads to the cross-pollination of best practices, fostering innovation and continuous improvement, a key component of a successful quality management system. 


While having a comprehensive QMS can be a hallmark of mature businesses, it’s not always the best or most efficient route for all, especially for small startups and smaller enterprises.  Leveraging strengths and resources of development partners and contact manufacturers can be a strategic move. It offers the dual benefit of maintaining high quality without the daunting investment. As with all business decisions, the key lies in selecting the right partners and continuously monitoring and refining the collaborative approach to quality management. 

For tailored advice and expertise on quality management solutions, contact Bold Type and benefit from our wealth of experience to integrate quality processes into your business model. 


What’s the simplest QMS your medical device startup can implement and still be compliant?


quality level

Implementing a Quality Management System (QMS) for a medical device startup is not just an exercise in regulatory compliance; it’s a foundational step to ensure the safety, efficacy, and consistency of your product.  Startups, with their innate agility and resource constraints, face the unique challenge of needing to establish a robust QMS without the luxury of large teams or budgets.  However, there is an effective way to bridge this gap; implement only the necessary elements of a QMS in-house, while relying on the expertise and infrastructure of development and contract manufacturing partners for more complex components. This approach not only balances the need for a robust system against the constraints of a young company but also represents a simplified mechanism toward establishing a QMS that remains compliant.  Here’s a basic outline of the simplest QMS your medical device startup can implement to achieve compliance:

Quality Agreement

A quality agreement is a crucial document between you and your development or contract manufacturing partner. This document outlines the roles and responsibilities of each party concerning quality and regulatory compliance.  A well-crafted Quality Agreement helps ensure product safety, efficacy, and compliance with relevant authorities by defining the organizational roles and responsibilities for things like which QMS is used and how, audit support, change control policy, and regulatory compliance.  

Document Control

Every QMS starts with proper documentation. Ensure that you have a system in place to:

  • Create and approve documents.
  • Revise and review documents when necessary.
  • Control the distribution of documents to prevent outdated or unauthorized usage.

Quality Manual, Quality Policy, and Objectives

A Quality Manual is a formalized document that describes your company’s quality management system and outlines your approach to quality assurance and process improvement.  It acts as a roadmap for how your company produces your medical device to ensure that it meets consistent quality standards.  It also may serve to identify which elements of the ISO 13485 standard your organization is subject to versus those you outsource to your development or contact manufacturing partners.  As part of your quality manual, it will be important for you to draft a clear quality policy reflecting your commitment to compliance, safety, and efficacy.  This policy should be supported by measurable quality objectives. 

Management Review

Your QMS should incorporate regulatory management review meetings to assess the suitability, adequacy, and effectiveness of your QMS.  These reviews are intended to ensure continuous improvement and alignment with regulatory changes and should be formally documented.  

Risk Management

Medical devices must undergo risk assessment to ensure patient safety.  Implementing a simple risk management process to identify, evaluate, control, and monitor risks associated with your device throughout its lifecycle is necessary to demonstrate that your QMS incorporates a risk-based approach. 

Supplier Controls

Your QMS should ensure that any components, materials, or services used in the development or manufacturing of your product are from verified suppliers.  By qualifying your development and manufacturing partners, you may leverage their supplier evaluation, selection, and monitoring process.  This could simplify (but not remove) your supplier qualification process, saving both time and money.  


Maintaining a system for training your employees to be aware of their roles and responsibilities in the QMS is required.  Your procedure should define training requirements needed to ensure that your employees are equipped to follow procedures correctly to maintain the effectiveness of your QMS.  Training records are needed to demonstrate that employees have been properly trained to carry out their assigned tasks. 

Nonconformance and CAPA (Corrective and Preventive Action)

A process to identify, document, and address nonconformities is required.  This process should tie into your CAPA system that corrects these issues and prevents their recurrence.  

Internal Audits

Even a simple QMS requires periodic internal audits to ensure processes are followed and to identify areas for improvement.  It is important that your internal audit be conducted by someone who is not directly responsible for the area being audited.  In a small organization, this can be difficult.  But with a reasonable Supplier Control process in place, your organization should be able to identify and qualify a third-party auditing agency to conduct an independent review of your QMS. 

Feedback and Complaint Handling

Once your product has hit the market, having an established and streamlined process for collecting feedback and handling complaints is a must to ensure that customer satisfaction is maintained and to address potential safety concerns promptly.  Certain types of reported events have reporting timelines associated with them.  Understanding these requirements and having an effective process to manage these activities at the ready is the key to success in this area.  


It is essential to remember that, while the above outlines a basic QMS, “simplicity” should not compromise effectiveness or compliance.  As your startup grows, the QMS should evolve to meet your company’s changing needs.  Collaboration with experienced quality and regulatory consultants or professionals can also provide guidance tailored to your specific device and marketing, ensuring that even the simplest system is both compliant and effective. 


5 reasons FDA will refuse your 510(k) application due to cybersecurity deficiencies

Over the past decade, the FDA has steadily increased the degree of scrutiny applied to cybersecurity aspects of submissions.  From the guidance issued on this topic in 2014, followed by extensive additions on the 2018 guidance and most recently the 2022 guidance, the FDA has made it clear that cybersecurity management needs to be carefully considered within 510(k) applications.  In the latest update that has become effective as of March 29, 2023, the FDA now reserves the right to refuse your 510(k) application due to cybersecurity deficiencies under certain circumstances.

Refusal Reasons:

#1 : The application does not include an adequate plan to address post market cyber security vulnerabilities in a reasonable time.  A plan like this would include how such vulnerabilities are identified, monitored and disclosed.

#2: The application does not contain evidence that the medical device design and development has followed processes and procedures that provide reasonable assurance that the device is cyber secure.

#3: The medical device within the application does not have the means to be updated postmarket to address discovered cyber security threats.  These updates would be required either on a reasonably justified regular cycle or possibly out of cycle to address a critical vulnerability.

#4: The application does not contain an appropriate software bill of materials that includes any open source software as well as commercial software used within the medical device.

#5: The application does not comply with any additional requirements that the FDA may impose through regulation to demonstrate with reasonable assurance that the medical device is cybersecure.


Ultimately, if your medical device has software and has connectivity to the Internet, it has now become a prime target for outright refusal of a 510(k) submission for lack of adherence to the rapidly evolving FDA regulations in this area.  Driven mainly by new laws as a result of the Consolidated Appropriations Act of 2023, specifically section 3305 titled “Ensuring Cybersecurity of Medical Devices” and subsequent amendments to the Federal Food, Drug and Cosmetic Act (FD&C Act) section 524B, these new cybersecurity regulations need to be seriously considered in any 510(k) submission to avoid costly delays.

At Bold Type we have always taken cyber security concerns seriously and incorporated extensive measures to address these concerns as part of our ISO 13485 compliant processes and procedures.  We have been prepared for the inevitable and well deserved increase in 510(k) scrutiny over cybersecurity threats, fundamentally addressing such concerns in our software architectures as well as within our 510(k) submissions.  For us, cybersecurity of connected Medical devices is foundational which is why we make sure we are well positioned to comply with the evolving FDA regulations in this space.

When it comes to safeguarding your connected Medical Devices to ensure a smooth FDA submission and avoid costly mistakes, Bold Type is the team to rely on.  Contact us today.

Reference: Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems UnderSection 524B of the FD&C Act, March 30, 2023


Why avoiding Q-subs (presubmissions) to FDA is a terrible idea

In the realm of medical device development, ensuring the safety, effectiveness, and regulatory compliance of products is paramount. The United States Food and Drug Administration (FDA) serves as the gatekeeper, evaluating and approving medical devices before they reach the market. One crucial step in this process is the presubmission, which allows manufacturers to seek valuable feedback and guidance from the FDA. However, there is a concerning trend among some companies who opt to bypass this essential step in an attempt to expedite their product development. In this blog, we will delve into why avoiding FDA presubmissions for medical devices is not only ill-advised but also poses significant risks to patients and businesses alike.

Patient Safety as the Foremost Priority

Medical devices directly impact the lives of patients. Without engaging in FDA presubmissions, manufacturers risk overlooking crucial safety considerations and potential risks associated with their devices. Patient safety should always be the primary concern in the development and commercialization of medical devices. By bypassing presubmissions, companies increase the likelihood of introducing devices with unaddressed safety concerns, potentially endangering patients’ well-being and undermining public trust in the medical device industry.

Ensuring Regulatory Compliance

Adhering to FDA regulations is a fundamental requirement for medical device manufacturers. Presubmissions provide a crucial opportunity for companies to seek regulatory guidance and clarification, ensuring that their devices meet the necessary standards for market approval. Skipping this step significantly heightens the risk of non-compliance, which can result in delays, costly remediation efforts, and even the rejection of a product altogether. By actively participating in presubmissions, manufacturers can address regulatory concerns early on, thereby increasing their chances of successful product development and market entry.

Accelerating Product Development

Presubmissions foster a collaborative environment between manufacturers and regulatory experts. Seeking early feedback from the FDA allows companies to identify potential roadblocks, refine their development plans, and streamline the path to market approval. Engaging in presubmissions can help accelerate product development by addressing potential issues upfront, optimizing designs, and making informed decisions based on expert insights. By avoiding this critical step, companies risk encountering unforeseen obstacles, delays, and costly iterations later in the development process.

Building Market Confidence

Successfully navigating the FDA regulatory pathway enhances market confidence and increases the likelihood of product adoption. By actively participating in presubmissions, manufacturers demonstrate their commitment to quality, safety, and regulatory compliance. This engagement instills trust among healthcare providers, patients, and investors, who rely on the FDA’s rigorous evaluation process as an assurance of a device’s reliability and efficacy. Companies that choose to forgo presubmissions may face skepticism from stakeholders, impeding market acceptance and hindering potential reimbursement efforts.


The decision to avoid FDA presubmissions for medical devices has far-reaching consequences that extend beyond short-term expediency. By recognizing the importance of this topic, we understand that patient safety, regulatory compliance, and long-term business success are at stake. Engaging in presubmissions allows manufacturers to leverage valuable regulatory guidance, identify and mitigate risks, accelerate product development, and build market confidence. Prioritizing these aspects should be the cornerstone of any responsible and successful medical device development endeavor.


Edwin Armstrong’s Impact on Connected Medical Devices

My doctoral work was on the design of ultra-low power circuits and systems for medical devices.

If you’re suffering from insomnia and want to geek out on some math, here’s your chance:

During that time, I came across the work of Edwin Armstrong, who is an engineering hero of mine.

You’re probably wondering exactly who Edwin is but the funny thing is, he’s had a dramatically bigger impact in your life than you know.

Edwin Armstrong was a true genius of the 20th century. He invented wireless communications techniques and architectures that are used to this day – think frequency modulation (FM) and the superheterodyne receiver. He also invented a type of receiver called a “super-regenerative amplifier” (SRA), which is a lot less common these days.

I decided to design an SRA and went down the theoretical rabbit hole to develop a mathematical model that would explain its frequency response.

This was tricky because most systems are linear, time invariant and employ negative feedback. The SRA is nonlinear, time variant, and employs positive feedback, taking advantage of the huge amplification that happens when a system becomes unstable.

It’s fricking genius and one of the reasons I admire Armstrong so much.