This is the third in a five-part series on how agile methods, applied with hardware-ready tactics, deliver better outcomes for medical device companies. Executives face three consistent pressures: get products to market faster, remain fully compliant, and improve ROI. Traditional waterfall development slows innovation and increases risk; pure software agile doesn’t fit the regulated realities of devices.

The Modified Agile for Hardware Development (MAHD) Framework resolves this tension. By leveraging iterative learning cycles, cross-discipline alignment, and living traceability, MAHD helps organizations reduce risk, accelerate innovation, and stay compliance audit-ready.

In this third article, we focus on how agile methods can help companies effectively manage evolving cybersecurity and SBOM (software bill of materials) challenges. 

Security-by-Design Only Works When It Moves at the Speed of Engineering

As medical devices become more connected, software-driven, and data-intensive, cybersecurity is no longer a specialized concern but a core design responsibility. Teams are expected to demonstrate visibility into software components, awareness of potential threats, and proof that risks are addressed through design and testing. While security-by-design is widely accepted as the right goal, the challenge is making it real in a way that keeps pace with engineering progress.

Traditional development models often treat cybersecurity as a parallel track. Threat models may be created early and then sit largely unchanged. Meanwhile, feature development moves quickly, especially when software teams adopt Scrum or similar methods. SBOM discipline, dependency tracking, and security testing often fall behind until late in development, when they suddenly become urgent. The result is familiar: late surprises, reactive fixes, and a scramble to meet market-driven cybersecurity expectations.

An iterative learning and execution approach, such as the MAHD Framework, adapts agile tactics to offer a more practical path for hardware and hybrid systems. By integrating SBOM visibility, threat thinking, and security validation into each development cycle, security becomes part of how the solution evolves rather than something layered on at the end.

A Simple Example to Ground the Discussion

To visualize the challenge, consider a connected health monitoring platform: a wearable sensor that streams patient data to a mobile app, which then sends information to cloud-based analytics and a clinician dashboard.

Even in this simplified case, cybersecurity must address multiple concerns at once, including protecting patient data, securing wireless communication, managing authentication, controlling software updates, and maintaining visibility into third-party components. This example reflects the types of realities most modern devices face. Connectivity introduces both value and exposure with every design decision—such as how data moves, how systems connect, and what software is reused—having security implications.

How Traditional Development Handles Security

In traditional waterfall development models, the early focus is on defining requirements before building and testing core functionality. A high-level threat assessment is typically completed early, with foundational choices made, such as encrypting sensitive data or requiring authentication. As development progresses, engineering teams concentrate on integrating components and refining the system. Security is recognized as important, but it is seldom properly addressed after the initial assumptions have been baked into thinking. Security discussions may happen periodically, but real scrutiny and formal updates are limited.

Then, late in the process, the focus shifts sharply. Teams assemble an SBOM by gathering information from multiple sources. Vulnerability scanning and penetration testing accelerate. Gaps appear. Some libraries must be replaced. Assumptions about access control or data handling may need revision. Documentation must be reconstructed from earlier decisions.

This model can work, but it concentrates effort and uncovers new risks near the end of development that are often detrimental to project success. In the health monitoring example, a new third-party library added midstream might not be fully tracked until late, or evolving authentication needs for clinician access may not be fully reflected in earlier threat assumptions. By the time gaps are discovered, parts of the architecture may already be locked, making change more disruptive.

How an Iterative Learning Approach Changes the Picture

An iterative, agile-for-hardware approach treats cybersecurity as something that evolves alongside the solution. It becomes a set of activities and questions tracked in a swim lane. 

Instead of addressing it once and then validating at the end or through gate-review scrambles, teams revisit it in small, structured increments tied directly to execution and learning.

Teams still begin with an initial view of potential threats based on early architecture and use scenarios as part of project initiation (the on-ramp, as the MAHD Framework calls it). The difference is this view becomes a living part of development. Each time a new interface, feature, or data pathway is introduced, teams briefly reassess whether new exposure has been created and whether the current execution and learning plan properly addresses those changes.

With each iteration, risk understanding and mitigation become grounded in real design decisions rather than early assumptions and late testing. In the health monitoring example, this could mean revisiting risks when Bluetooth pairing is introduced, reassessing exposure when cloud analytics expand, or strengthening authentication when remote clinician access is added. Security evolves with the system instead of lagging behind it.

Maintaining SBOM Visibility as the System Evolves

Modern devices rely on a mix of internally developed software and third-party components. Each adds capability, but also potential exposure. In a traditional model, a full SBOM is often assembled late, requiring teams to reconstruct what was added, changed, or replaced over time. 

In an iterative model, SBOM visibility grows naturally with the system, as traceability and digital tracking become an essential enabling capability of the project. Instead of reviewing these dependencies only at major milestones, iterative teams apply a simple, repeatable discipline. When a new dependency is introduced, they confirm its origin, version, and whether known vulnerabilities exist. These become part of the day-to-day engineering conversation instead of a last-minute documentation exercise or relegated to a disconnected, project manager-owned spreadsheet. 

For our connected monitoring system, this might include tracking mobile libraries, wireless stacks, and cloud services as they are integrated. If a vulnerability is discovered later, teams already know where the component lives and how it is used. 

Treating Security Testing as Part of Completion

Another shift happens in how teams think about “done.” When a feature is completed, the question is not just whether it works, but whether it behaves securely at its current level of maturity. Early in development, checks may be simple. As the system matures, validation becomes deeper and more structured as testing is increasingly integrated into iteration milestones and outcomes.

For example, when secure pairing is introduced for the connected monitoring platform, teams can verify early that data transmission is encrypted and access pathways are controlled. They don’t wait until final system testing to discover assumptions were incomplete. This steady layering of validation helps catch weaknesses earlier, when they are easier and less disruptive to address.

Managing Dependencies, Evidence, and Readiness Together

At the same time, one of the biggest challenges in premarket cybersecurity is demonstrating what has been done. Teams must show how risks were identified, what controls were implemented, what testing occurred, and how software components are tracked. In traditional models, much of this evidence is gathered late, often reconstructed from scattered records.

In an iterative model, that evidence builds naturally alongside the work. Each development cycle produces small but meaningful artifacts: updated threat considerations, SBOM updates, validation results, and documented decisions tied to real engineering progress. By the time the product approaches submission, the cybersecurity story already exists and reflects the actual evolution of the system rather than a retrospective reconstruction.

Conclusion

As connectivity increases, cybersecurity becomes tightly linked to patient safety, system reliability, and trust. Yet one of the most persistent challenges in product development is not just implementing the right controls; it is clearly demonstrating what has been done, how risks were addressed, and how decisions evolved. In traditional models, this evidence is often assembled late and reconstructed from scattered records, creating gaps, uncertainty, and added pressure near submission.

An iterative learning and execution approach changes this dynamic. Threats are identified early and refined continuously. Software components and dependencies remain visible as they are introduced and updated. Security validation becomes part of normal development rather than a late-stage hurdle. At the same time, evidence builds naturally alongside the work: updated threat considerations, SBOM revisions, test results, and documented decisions tied directly to engineering progress.

By the time the product approaches submission, the cybersecurity story already exists and reflects the true evolution of the system, not a retrospective reconstruction. The result is more than better documentation or smoother regulatory preparation. It leads to a more resilient product, a more informed team, and a development process where security is embedded into everyday engineering work instead of being treated as a final checkpoint.

MORE FROM THIS AUTHOR—DHF by Design: How Synchronous Capture Delivers Better Results

Dorian Simpson is an innovation, product management, and agile consultant, trainer, and speaker. He is the author of The Savvy Corporate Innovator and co-founder of the Modified Agile for Hardware Development (MAHD) Framework. He helps startups to Fortune 500 technology leaders build skills to improve their ability to identify, evaluate, plan, and develop innovative products. The MAHD Framework is a purpose-built agile approach for physical product innovation. MAHD combines agile principles with hardware-ready methods: On-Ramps to set strategic intent, IPAC Iterations to integrate and learn quickly, Aligned Backlogs to connect work across disciplines, and hardware-aligned roles that empower technical leaders. Organizations adopting MAHD report faster time-to-market, improved compliance confidence, and higher ROI—without sacrificing safety or quality. Learn more at www.MAHDFramework.com.