Introduction
Software as a Medical Device, usually shortened to SaMD, covers software intended for a medical purpose that is not itself part of a hardware device: an algorithm that flags a likely arrhythmia from ECG data, a clinical decision support tool, a digital therapeutic that delivers a treatment intervention through an app. This category has existed conceptually for years, but the volume of products moving through it, and the regulatory complexity each one carries, has grown enough to create a genuinely distinct hiring lane within device regulatory affairs. This article looks at what is driving that demand, what the work actually involves, and what it takes to position yourself for it.
Why SaMD Is a Distinct Regulatory Category
Traditional device regulatory affairs assumes a physical product with a fixed design that goes through design controls, verification and validation, and a defined submission before it changes. Software does not behave that way. It is built iteratively, often on short release cycles, and increasingly incorporates machine learning models that can shift in behavior as they encounter new data. Regulators have had to build frameworks that account for that difference. The FDA's guidance on mobile medical applications, its evolving approach to Predetermined Change Control Plans for AI/ML-enabled devices, and the IMDRF's SaMD risk categorization framework all exist because standalone software genuinely does not fit cleanly into the regulatory logic built for physical devices. The EU MDR reflects the same shift through Rule 11, which classifies standalone software based on the significance of the information it provides and the criticality of the healthcare situation it addresses, generally pushing more software products into higher device classes than earlier EU rules did.
What Is Actually Driving the Hiring Demand
Several forces are compounding at once. Digital health and diagnostics companies built primarily around software products need regulatory affairs professionals from the start, not as an afterthought bolted onto a hardware-focused team. Traditional device manufacturers are increasingly shipping software components, companion apps, connected sensors, cloud-based analytics, alongside their physical products, which means regulatory teams that have never had to think about software lifecycle requirements now do. Cybersecurity has become a mandatory, non-negotiable part of device submissions following FDA's premarket cybersecurity guidance, adding a technical review dimension that most legacy device regulatory teams were not built to handle. And AI/ML-enabled SaMD introduces an entirely new regulatory concept, the Predetermined Change Control Plan, that lets a product's algorithm evolve within a pre-authorized scope without triggering a new submission for every update, which requires regulatory professionals who understand both the technology and the framework well enough to write a defensible plan.
What the Work Actually Looks Like
Regulatory roles in this space tend to be more hybrid than traditional device regulatory affairs. A SaMD regulatory professional works closely and continuously with software engineers and data scientists, not just at submission time but throughout development, which means understanding enough about agile development practices, software design controls under IEC 62304, and risk management under ISO 14971 to have a genuinely useful conversation with the engineering team rather than translating requirements after the fact. Submissions for SaMD products increasingly require documentation of algorithm training data, validation methodology, and performance across relevant subgroups, which is a different kind of technical writing than a traditional device submission demands. Post-market surveillance looks different too, since software updates happen far more frequently than hardware changes, requiring a more continuous regulatory review process rather than periodic submissions tied to discrete design changes.
Skills That Are in Real Demand
Fluency in IEC 62304, the software lifecycle standard, and ISO 14971 for risk management is close to a baseline expectation now for SaMD-focused roles. Familiarity with FDA's cybersecurity guidance and the documentation it requires, a cybersecurity bill of materials, threat modeling, and vulnerability management planning, has become a genuinely differentiating skill, since relatively few regulatory professionals with traditional device backgrounds have deep exposure to it yet. Understanding how AI/ML models are developed, validated, and monitored, enough to meaningfully evaluate a Predetermined Change Control Plan or a performance monitoring strategy, is increasingly valuable, particularly as more products in this space incorporate adaptive algorithms. None of this requires being able to write code yourself, but it does require enough technical fluency to ask sharp questions of engineering colleagues and recognize when a proposed approach will not hold up under regulatory scrutiny.
Where the Roles Sit
Digital health startups building diagnostic or therapeutic software products are an obvious source of these roles, often needing regulatory hires earlier in the company's life than a hardware-focused device company would. Diagnostics companies incorporating AI-based interpretation into imaging or lab workflows are another growing source. Traditional device manufacturers building software and connectivity capabilities alongside established hardware lines are increasingly building out dedicated software regulatory functions rather than folding this work into a generalist device regulatory team. Health systems and provider organizations building or deploying their own clinical AI tools represent a newer, smaller, but growing source of similar roles, often framed around regulatory and compliance oversight of internally developed tools rather than commercial submissions.
How to Position Yourself for This Lane
For regulatory professionals already working in traditional device regulatory affairs, the most direct path is deliberately building exposure to software-specific frameworks: working through IEC 62304 and ISO 14971 in enough depth to speak to them confidently, following FDA's published guidance on AI/ML-enabled devices and cybersecurity as it evolves, and seeking out any internal project involving a software or connected component even if it is a small piece of a larger hardware submission. RAPS and other professional bodies have expanded their course offerings to cover digital health and software-specific regulatory topics, which is a reasonably efficient way to build structured knowledge without years of on-the-job exposure. For people coming from a more technical background, software engineering, data science, or biomedical engineering with a software focus, regulatory affairs roles in this space can be a genuinely strong fit, since the technical fluency that traditional regulatory professionals have to build deliberately, this group often already has.
What This Means for the Broader Device Regulatory Field
SaMD is not replacing traditional device regulatory affairs, and most device regulatory roles will continue to center on physical products for the foreseeable future. What is happening instead is the emergence of a genuinely distinct specialization within the broader device regulatory field, similar in scope to how CMC or nonclinical regulatory work carved out their own specialized tracks within pharmaceutical regulatory affairs. Regulatory professionals who build real expertise here early are positioning themselves in a specialization that is still relatively thin on experienced talent relative to the demand building behind it.
Common Misconceptions About SaMD Regulatory Work
One common misconception is that SaMD regulatory roles require a background in software engineering to be credible. In practice, most successful SaMD regulatory professionals come from traditional device or clinical regulatory backgrounds and build software-specific fluency deliberately over time, rather than starting as engineers. A second misconception is that SaMD regulation is uniformly lighter-touch than hardware device regulation because software feels less physically risky; the opposite is often true, since a flawed diagnostic algorithm can affect a very large number of patients quickly, and regulators have responded by treating higher-risk SaMD categories with real rigor. A third misconception, common among candidates newer to the field, is that AI/ML-enabled products all move faster through regulatory pathways than traditional devices; in practice, the added scrutiny around training data, validation methodology, and change control planning for adaptive algorithms can make these submissions more demanding to prepare, not less.
International Considerations Beyond the US and EU
While FDA and EU MDR frameworks tend to dominate discussion of SaMD regulation, other markets are developing their own approaches worth understanding for companies operating globally. Health Canada has issued specific guidance addressing software as a medical device within its broader device regulations, and several other national regulators have adopted or referenced the IMDRF's SaMD risk categorization framework as a common starting point, even where their specific submission requirements differ. For a regulatory professional building a career in this space, understanding that the underlying risk-based logic is reasonably consistent across major markets, even as the specific submission mechanics vary, is a useful mental model, and it is generally a more efficient use of time than trying to memorize every jurisdiction's requirements in equal depth before having a reason to work in a specific one.
Building Relevant Experience When Your Current Role Is Traditional Device Work
Regulatory professionals working at companies that have not yet built a dedicated SaMD function still have practical ways to build relevant experience before a formal transition. Volunteering for any project touching a companion app, a connected sensor, or a cloud-based data platform, even as a secondary contributor rather than the lead, provides real exposure to how software components move through a submission differently than hardware. Reading FDA's published guidance documents on AI/ML-enabled devices and cybersecurity closely, including the specific questions and expectations they lay out for a submission, builds a working vocabulary that shows up naturally in an interview. Some professionals also find it useful to sit in on internal engineering design reviews for a software component, purely to build familiarity with how that team thinks about iterative development and risk, even without a formal regulatory role in that specific project. None of this requires a job change to start, and it meaningfully strengthens a resume or interview conversation when a genuine SaMD-focused opportunity does come up.
Conclusion
Software as a Medical Device has moved from a regulatory edge case to a substantial and fast-growing category, and the regulatory affairs skill set it demands, software lifecycle fluency, cybersecurity literacy, and comfort with adaptive algorithm oversight, is different enough from traditional device regulatory work to constitute its own hiring lane. For regulatory professionals willing to build that specific fluency now, it is one of the more clearly growing specializations in device regulatory affairs.