The earliest technical decisions in connected medical devices can either pave the way for success or create roadblocks you’ll be navigating for the rest of the project. Choices like which chip to use, how manufacturing will be supported, or what security infrastructure is needed can have far-reaching implications. In regulated industries, these decisions directly affect a product’s ability to meet safety requirements, pass audits, scale in production, and reach the market on time.
With so much pressure to deliver working functionality, it’s easy to jump straight into implementation. That’s the exciting part—building features, testing devices, getting systems to talk to each other. But without early alignment on architecture, test strategy, and security, teams can unintentionally bake in risk that’s difficult and costly to unwind later.
To avoid that, this article highlights four areas where upfront embedded firmware planning, especially for connected medical devices, pays off in the long run:
- Chip selection – how the microcontroller you choose influences system architecture, development efficiency, and long-term supply
- Manufacturing – how early conversations around production timelines, testing needs, and provisioning shape software decisions
- Testing strategy – how test coverage and timing affect architecture, tooling, and product quality
- Security – how to design security as a core part of the system from the beginning—not as an afterthought
Drawing from our work on regulated, connected devices, we’ll share patterns, pitfalls, and decision points that can help set up your development process for long-term success.
1. Chip Selection
Chip selection is one of the most foundational decisions at the start of the embedded development process. To make the right choice, it’s critical to understand your system’s use cases. Embedded systems are typically built for focused applications, not general-purpose use, so it’s important to pick the chip that’s best suited for the product you’re building.
Don’t Overbuy on Features
While it may be tempting to select a microcontroller that can do it all, paying for unused features often comes at the cost of performance or efficiency in areas that matter more. You could argue that extra features leave room for future product iterations, but unless there’s a clear, near-term roadmap, that’s usually not reason enough. That said, it’s also not worth sacrificing essentials like on-chip storage or memory. Anyone who’s had to cut features late in development because they didn’t fit knows how painful and costly that can be.
Align with Product Priorities
Your chip selection should be guided by your specific needs around security, power management, connectivity, and processing power. For example, if you’re designing a rechargeable hearing aid, audio performance and digital signal processing (DSP) capabilities will likely be more critical than maximizing battery life. In that case, something like the STM32F4 series—with its high performance and DSP support—may be more appropriate than the ultra-low-power nRF54L series, which prioritizes energy efficiency and wireless connectivity.
Plan for Longevity and Supply Chain Risks
In addition to ensuring the chip you select is the right one for the job, it’s essential to consider long-term availability and supply chain risks. Take into account your project timeline, expected product life, and supply chain risks:
- Project timeline: Will the chip you choose be mature enough to minimize risk to development time? When do you expect to release your product? Will the chip you choose be the best choice at the time of release?
- Expected product life: How long do you expect to manufacture, distribute, and support fielded devices?
- Supply chain risks: Are the chips abundantly available now? Are there other chips or modules that are pin-compatible and could be used in its place? While there are always supply chain risks present, many of which are out of our control (e.g. environmental, economic), have there been challenges in the past with a particular supplier?
Although not all-inclusive, these questions can help you identify any major concerns and narrow down your decision.
Consider Team Familiarity and Development Efficiency
Perhaps not as obviously impactful as some of these other factors, the engineering team’s familiarity and preferences with the various platforms should be considered in chip selection. It is completely reasonable to expect the team to learn new tools, but the team could face inefficiencies during development, such as the need to fight persistent pain points with the use of specific tools, lack of SDK support, and the like.
This is not to say you should select a chip solely based on the team’s familiarity with specific tools, but you should take the tradeoffs into consideration as part of your decision. If you have an aggressive timeline for your project or you’re very budget-contrained, for example, you will want to consider the path of least resistance to set your team up for success from the start.
2. Manufacturing
It’s easy to get excited about architecture and features and delay conversations about manufacturing until later in the development process. After all, you need a product before you can manufacture it, right?
In reality, thinking about manufacturing early can shape everything from milestone planning and hardware acquisition to how you design your software.
Manufacturing Affects Milestone Planning
Even if development starts on evaluation boards or early prototypes, it’s critical to know when you’ll need production-ready units and how many. This gives structure to your timeline and helps you plan backward from key delivery milestones. From there, you can work backwards to inform your timeline.
A few important questions to consider:
- When do you plan to integrate your software with the real hardware?
- How much time do you need to perform verification testing?
- How quickly can you manufacture units?
- What type of manufacturing tests need to be performed? Do you need to develop additional tools to facilitate manufacturing tests?
Whether you’re building in-house or working with a manufacturing partner, early alignment on capabilities, quality expectations, and timeline is key, especially when working with a new partner. Delays or miscommunications at this stage can easily ripple into major project risks.
Software Needs a Manufacturing Mode
From a software perspective, embedded devices often require a dedicated manufacturing mode. Depending on your product, this can range from simple (e.g., blinking LEDs or writing a serial number) to complex (e.g., executing self-tests, logging results, and provisioning secure keys).
For regulated industries like medical or aviation, a robust manufacturing mode is often non-negotiable. But regardless of industry, designing this functionality from the outset leads to cleaner code, better integration, and fewer late-stage bugs.
Some design questions to guide your manufacturing mode implementation:
- Which components need to be exercised in manufacturing mode?
- How should the device respond to the detection of a failing component or a failed self-test?
- How do manufacturing use cases differ from typical user interactions? Are there any features that would be useful in manufacturing but need to be disabled before the device leaves the factory?
- Is there a need to enforce security at some level during the manufacturing process?
- How will security provisioning be applied? Where do the security keys live?
- What triggers the device to exit manufacturing mode?
Build It In Early
Designing manufacturing mode into your software from the get-go will result in a cleaner software design and implementation, reducing the risk that a bug is introduced when a feature is more of an afterthought than intentionally designed, as we software engineers have seen all too often.
3. Test Approach
Like manufacturing, testing is often deprioritized in the early stages of embedded software development. It’s easy to assume that testing won’t meaningfully impact early progress, but your test approach can have far-reaching effects on your development schedule, architecture, and team workflows.
Your approach to testing may be influenced by FDA guidance, dictated entirely by your internal quality standards, or somewhere in between, where the stringent end of this spectrum might require modified condition/decision coverage (MC/DC) and the lax end may only require ad hoc testing. But no matter the context, defining your approach early helps set realistic expectations and reduces rework later.
Levels of Testing in Embedded Systems
When we think about the verification of embedded systems, we often categorize the levels of testing into:
- Unit testing: testing of individual units or modules
- Integration testing: testing the interaction between 2 or more units or modules
- System testing: testing the system as a whole meets the requirements
- Acceptance testing: testing against user needs and business requirements
Each level serves a different purpose and carries different implications for timing, tooling, and team effort. If you’re unsure which types of testing are appropriate for your product, this guide on choosing the right testing strategy can help you decide based on your context, risk level, and development goals.
Aligning Testing with the Development Timeline
The chosen level of testing will affect the development schedule and timeline, as each type of testing will require time to bring up testing infrastructure and may provide more or less value at different stages of development. For example, if unit testing is required, it will provide the most value when developed alongside feature implementation rather than done retrospectively, so it would be wise to account for time to bring up unit testing tools and infrastructure early.
System tests, on the other hand, will likely require changes as requirements change. As such, the amount of effort to stand up system testing infrastructure and implement tests should certainly be accounted for in the project timeline, but writing these tests too early in development may prove to be difficult and can result in maintenance overhead as requirements change.
Impact on Architecture and Development Process
Your test strategy doesn’t just influence what gets tested—it can shape how your software is written.
Software development practices, such as code reviews, will be influenced by the type of test coverage you are looking for. In the case of MC/DC testing, for example, it is probably most valuable and efficient for unit tests to be developed alongside the software, so it would be reasonable to enforce the development and maintenance of unit tests as part of the code review process. The need for unit testing will also influence the modularity of the software architecture. The more modular the design and implementation of the software, the easier it will be to unit test.
A strong test approach will also influence development practices, especially peer reviews, CI/CD workflows, and decisions about tooling and frameworks.
Plan Enough to Stay on Track
While your test approach does not need to be written in stone early in the development of your embedded system, it is certainly advantageous to have enough of an understanding of your testing needs to inform the project schedule, software development process, and software design.
4. Security
Security is a critical part of software system design, especially in connected systems, and it should be considered from the very beginning of development. It’s not a separate concern or a final checklist item; it touches every other aspect of the product.
In fact, security considerations intersect with all of the early decisions discussed so far:
- The chip must support the required security capabilities.
- The manufacturing process must accommodate secure provisioning and key injection.
- The test strategy must validate security mechanisms and behaviors.
More Connectivity, More Risk
The benefits of connectivity, like enabling a doctor to monitor a patient’s heart remotely, are unsurprisingly coupled with increased risk. Providing a means for an embedded system to connect to another device or a network inevitably increases the means through which it can be exploited.
This is especially true in connected medical devices, where security failures can have severe consequences. An attacker gaining access to protected health information (PHI) would violate HIPAA regulations, while interference with device functionality could directly impact patient safety. That’s why security isn’t just a nice-to-have—it’s a non-negotiable requirement in regulated industries.
OTA Updates Are the Norm—And a Risk Vector
When designing a connected system, over-the-air (OTA) updates are a baseline expectation of users. After all, we live in a world where our phones, smart watches, and video doorbells are silently updated over-the-air while we sleep.
Beyond pleasantly surprising their users with new features, OTA updates serve as a way for companies to quickly patch vulnerabilities and fix bugs in their products. They enable medical devices to follow the FDA guidance that devices should be “capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product’s lifecycle.”
Implementing OTA securely requires early embedded firmware planning and infrastructure across both firmware and cloud components. At minimum, consider the following:
- Authentication: How are devices within the system able to identify themselves and each other? How do they know which devices to trust?
- Secure bootloader: Can the bootloader detect and reject invalid or unsigned firmware images? What type of key is used to sign images and how secure is it?
- Encryption: Does data being sent over the air need to be encrypted? What are the consequences of an attacker intercepting this data? Does flash memory need to be encrypted?
Security Starts Early—or Becomes a Headache Later
The level of security your system needs will depend on its use case and industry, but every connected product requires some baseline level of security. Designing for security from the start makes it far easier to build the right infrastructure and avoid painful compromises later.
Security can’t be bolted on at the end. When it’s treated as an afterthought, it often leads to:
- Costly rework of core system components
- Increased likelihood of introducing bugs
- Difficult tradeoffs due to earlier design constraints
To build a secure, reliable system, security must be treated as a core design input, not a final check.
Planning Ahead to Build Smarter
Developing an embedded system for a connected medical device is a complex process, and while not every decision needs to be made upfront, establishing an early understanding of key factors—chip selection, manufacturing, testing, and security—can significantly impact the success of your product. These considerations shape everything from system reliability to cost efficiency, reducing the likelihood of encountering the setbacks that come with late-stage discovery.
Of course, there’s a balance to strike; some unknowns will only become clear as development unfolds, so don’t allow progress to stall in pursuit of perfection. However, taking the time to think through these critical elements early, aligning with stakeholders, and making informed decisions will reduce risk and minimize costly rework down the line.
Still, even with the best planning, unexpected challenges are inevitable. Whether it’s navigating supply chain and manufacturing constraints or architecting a system with an effective security strategy, the right expertise at the right time can mean the difference between a smooth development process and costly setbacks. If you need a partner who understands the nuances of building connected medical devices, we can help you get it right from the start.
