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. 


Why ISO 13485 Certification Matters in Product Development

Bold Type achieved ISO 13485 certification this year. And if you’re a medical device company looking for a product development partner, that certification can mean the difference between a successful 510K submission and a rejected one.

As I explained to Paul Enderle of BayCross Capital,  ISO 13485 certification means that we have a full quality management system in place, compliant with both FDA and CE mark requirements.

It means that we’re documenting our design inputs, outputs, design verification and validation testing in accordance with the requirements, and that we’re storing and maintaining those documents appropriately.

This greatly reduces risk for manufacturers, especially when the FDA auditors come around and find the design history file and all other associated documentation is just as it should be.


How Venture Debt Can Benefit Your Company’s Cash Flow

Most startup entrepreneurs know about venture capital. But venture debt? Not so much.

As an entrepreneur, it’s something you need to be aware of, regardless of where it fits in your financial plan.

Venture debt can be a great strategic financing tool, but you have to know what you’re doing to get it and – more importantly – to get the right terms.

My friend Paul Enderle from BayCross Capital is an expert and took a few minutes to explain venture debt – what it is, who can get it, what typical terms are like, and when is the most strategic time to pursue it.