From SaMD/SiMD to MDSW: What the New CDSCO Guidance 2026 Means for Your Medical Device
CDSCO has issued the final Guidance Document on Medical Device Software, replacing the draft published for comment in October 2025. The most significant change is terminological. The separate categories of Software as a Medical Device and Software in a Medical Device have been withdrawn and replaced by a single term, Medical Device Software (MDSW), which covers standalone software, software embedded in hardware, software that drives or influences a device, and software interfaced with other devices or general purpose software.
The document has also been restructured. The draft placed all content under a single guidance section, while the final guidance is organised into twelve sections across 62 pages, supported by an annexure of document checklists. The additional content concentrates on artificial intelligence, cybersecurity and alignment with India’s digital health infrastructure. The sections below set out what has been added, what has been revised and what has been withdrawn, with the corresponding reference in the final document.
| Aspect | Draft, 21 October 2025 | Final, 21 July 2026 |
|---|---|---|
| Terminology | SiMD and SaMD defined separately | Single term, MDSW (Section 4.11) |
| Structure | Single guidance section, 4.1 to 4.13 | Twelve sections, 62 pages, plus Annexure A |
| Stated audience | Manufacturers and importers | Expanded to manufacturers, importers and innovators/researchers |
What’s New in the Final CDSCO MDSW Guidance (2026)
The following provisions have no equivalent in the draft.
| Area | New incorporation |
|---|---|
| Definitions | New definitions of change management, cybersecurity, medical purposes now anchored to the statutory list, medical device software, product lifecycle, real world data, real world evidence and software bill of materials (Sections 4.2, 4.6, 4.9 and 4.10, 4.11, and 4.14 to 4.17) |
| General wellness carve out | Wellness, healthy lifestyle and fitness tracking software explicitly excluded from MDR-2017, with notes on permissible claims and the clarification that software measuring physiological values for clinical purposes is not wellness software. The draft had no wellness exclusion at all (Sections 2.0 and 5.2) |
| New covered examples | Embedded software or firmware intended to regulate or control a medical device, software integrated into an IVD analyzer or instrument, software that connects via Bluetooth to obtain readings, computer-aided detection (CAD)-based software intended to provide information, digital platforms utilizing Internet of Things (IoT) technology for use with connected devices, digital therapeutics platforms, and software designed for veterinary medical purposes are all included within the scope. (Section 5.1, examples 5, 9, 10 and 11) |
| New excluded examples | ERP and quality system software, and software solely for medical teaching or training, plus a note that HIS, CIS, LIS and IMS become medical devices if they add a medical function (Section 5.2) |
| Intended use | Manufacturers should clearly define the clinical role of the MDSW in the intended use statement, specifying whether it functions as decision support software, drives a medical device, provides definitive diagnosis or treatment recommendations, or serves another intended clinical purpose (Section 6) |
| Embedded software licensing | Firmware sold separately from the hardware requires its own licence. Supplied with the parent device, it may be registered as a component or accessory (Section 5.0, notes i and ii) |
| COTS and non-device functions | The manufacturer should submit justification on the role and impact of COTS software within the MDSW framework, and clarification on the impact of non-device functions on safety and effectiveness (Section 5.0, notes iii and iv) |
| Digital health ecosystem | New sub-section and table covering interoperability, consent driven data access compliant with the DPDP Act 2023, secure health information exchange, privacy across the AI lifecycle and auditable digital traceability (Section 9.0 and Table 4) |
| ABDM alignment | Software handling patient health information should align with ABDM building blocks, namely ABHA, the Health Facility Registry and the Healthcare Professionals Registry, and should support compliant record generation and traceability of diagnostic outputs (Sections 9.0 and 12.4.2(E)) |
| SaaS and cloud hosting | Disclosure of whether SaaS is hosted on a MeitY empanelled cloud server, baseline security controls for hosted environments, and case by case risk assessment for on premises deployments (Section 12.1, notes iii to v) |
| QMS expansion | Explicit QMS objectives a to g. Documentation must cover software architecture, SRS, SDS, source code management, version control and release management. Bill of materials and SBOM maintenance with vulnerability monitoring, continuous performance assurance, encryption in transit and at rest, access controls and audit trails. Manufacturers are required to implement documented procedures for post-deployment performance monitoring, including the identification and management of clinically significant performance degradation, algorithm drift, cybersecurity vulnerabilities, and unintended outcomes. They must also evaluate device performance across relevant populations, healthcare settings, and operational environments to support safe and equitable use within the Indian healthcare ecosystem. In addition, the QMS plan should include compliance with applicable cybersecurity standards for MDSW. Digital Health Ecosystem Requirements: MDSW should be designed and deployed to support India's evolving digital health ecosystem. Developers, implementers, healthcare providers, and procuring agencies should ensure that MDSW, including AI-based systems, aligns with these ecosystem requirements. (Section 9.0) |
| Secure by design | Formal threat modelling at design stage, secure default configurations with unnecessary ports and debug functions disabled, design for safe operation during cyber incidents, and a security focused architecture review covering attack surfaces, trust boundaries and APIs (Section 12.4.2(E)) |
| India specific AI and validation | Disclosure of dataset composition covering demographic, geographic and clinical diversity, justification of applicability for models trained outside India, evidence on bias, generalisability and robustness across Indian sub-populations, and declaration of whether training data is real world or synthetic (Sections 12.4.2(G) and 12.4.2(H)) |
| Usability and human factors | Usability validation should reflect Indian clinical workflows, language and interface accessibility, variability in operator training, and infrastructure constraints (Section 12.4.2(A), item j) |
| Substantial equivalence | Structured requirements B.1 to B.4 plus a table of minimum comparative parameters, with scientific justification required where differences exist. The draft only asked for a general tabular comparison (Section 12.4.2(B) and Table 6) |
| Risk documentation | New checklist covering hazard identification, severity and probability, cybersecurity risks, AI bias risks, misuse scenarios, mitigation controls and residual risk, plus a risk domain mapping table that names model drift and hallucination. Software intended to drive or influence the use of a hardware medical device should be classified in the same risk class as the associated hardware device (e.g., medical device operation software or image output generation and processing software). The documentation should also include technical design details demonstrating how the software design implements all Software Requirements Specification (SRS) requirements and maintains traceability to the SRS in terms of intended use, functionality, safety, and effectiveness. (Section 12.4.2(D) and Table 7) |
| Software Design Specifications | The documentation should include technical design details demonstrating how the software design implements all Software Requirements Specification (SRS) requirements and maintains traceability to the SRS in terms of intended use, functionality, safety, and effectiveness. (Section 12.4.2(G)) |
| Versioning | New requirement for a documented history of tested software versions with date, version number and description of changes (Section 12.4.2(F)) |
| Labelling | Explicit software label content list a to i covering device name, MDSW name, version or build number, manufacturer, licence number, release date, intended use, storage conditions and Rule 44 particulars. Electronic IFU terminology introduced (Section 12.4.2(I)) |
| Post market surveillance | PMS plan proportionate to risk class, a defined activity set, AI monitoring of model drift, error rates, clinical safety signals and user feedback, real world evidence collection from Indian healthcare settings, a PMS expectations table including hallucination detection, and an explicit MvPI reporting route (Section 12.5.3 and Table 8) |
| Post approval changes | New major change triggers including a new clinical claim or a new data input type, and version changes affecting intended use, safety, effectiveness or risk controls. New minor change categories including performance re-tuning within validated ranges (Section 12.5.2) |
| Standards table | Added IS/ISO/IEC 27001, IS/ISO 15223-1 and 15223-2, and IS/ISO/TR 24971, plus a catch all row covering IS/ISO/TS 82304-2, ISO/TR 62366-2, ISO 20417 and IS 18376/ISO/TR 20416. BIS website reference added (Section 8.0, Table 3) |
| Practical aids | Links to the CDSCO risk classification lists, a formal route to apply through the MD Online portal for classification of unlisted MDSW, and a full Information and Resources section (Section 7.1 and the Information and Resources list) |
Which AI Requirements Are Mandatory
The AI provisions mix obligation levels, and the distinction decides where your budget goes.
| Requirement | How it is worded |
|---|---|
| Disclose dataset composition used for training, validation and testing, including demographic distribution, geographic origin and clinical diversity (Section 12.4.2(G)) | shall |
| Provide justification for applicability to Indian clinical environments where models are trained or validated in non-Indian settings (Section 12.4.2(G)) | shall |
| Provide evidence addressing model bias, generalisability and robustness across sub-populations relevant to India (Section 12.4.2(G)) | shall |
| State whether training datasets are real world data or artificially generated synthetic data (Section 12.4.2(G), note) | required to mention |
| Demonstrate that performance has been evaluated in at risk populations and representative operational environments (Section 12.4.2(H)) | should |
| Supplement performance evidence generated outside India with validation in representative Indian populations (Section 12.4.2(H)) | may |
One further provision is worth reading before assuming Indian clinical data is unavoidable. The note at Section 12.2 points to the clinical investigation exemptions in Chapter VII of MDR-2017, available where the Central Licensing Authority is satisfied on safety, performance and materiovigilance, and there is no evidence or theoretical possibility of a difference in the behaviour and performance of the applied software in the Indian population.
Key Changes from the Draft to the Final Guidance
The following provisions existed in the draft and have been revised.
| Item | Draft | Final |
|---|---|---|
| Medical purposes | Open ended list including diagnosis, prevention, monitoring, mitigation, prediction and treatment | Anchored to the six statutory purposes in the medical device definition, with mitigation, prediction and alleviation retained only as a note (Sections 4.9 and 4.10) |
| Test licence quantity | Applicant may state number of installations, copies or downloads as quantity | Downloads replaced with intended deployments, the quantity must be properly justified, and the application may run in parallel with a clinical investigation application (Section 12.1, notes i and ii) |
| Clinical investigation exemptions | Not discussed | New note allowing exemptions under Chapter VII where the CLA is satisfied and no difference in behaviour is expected in the Indian population (Section 12.2, note) |
| IVD intended use elements | Five elements, with diagnostic levels ending at prognosis | Monitoring added to diagnostic levels, plus two new elements on assessment of analytical procedure performance and on self testing or near patient testing (Section 6.0, item i) |
| Licensing table | Last row titled Special Code | Renamed Special Code, Neutral Code and Risk Classification (Section 11.0, Table 5) |
| Risk management output | Update details added to the risk management plan | Update and correction details added to the risk management report, with ISO 82304 added to the compliance list (Sections 12.4.2(D) and 8.0) |
| Indirect harm | Mentioned but undefined | Now formally defined as injury from erroneous, delayed or misleading software information, or reduced effectiveness, rather than direct physical failure (Section 12.4.2(D), note) |
Requirements Removed Before Final Publication
| Removed item | Where it was in the draft | Status in the final |
|---|---|---|
| SiMD and SaMD categories and definitions | Sections 4.2.1 and 4.2.2, including firmware and middleware explanations | Replaced by the unified MDSW definition at Section 4.11 |
| Medical device grouping definition | Draft definition 4.1.8 | No standalone definition in Section 4.0. The concept survives only as a checklist item in Annexure A |
| Endorsement licence note, required where an update significantly changed indications or intended use with a risk class increase | Note under post approval change notification | Not carried over. Such changes now fall under the general major change and post approval change provisions at Section 12.5.2 |
| Standards IS/ISO/TR 80002-2 and IS/IEC/TR 80002-3 | Draft standards list under 4.5 | Dropped from the named list and partly absorbed by the catch all row at Section 8.0, Table 3 |
| Prior to implementation wording in the ACP change note | Draft note stating that ACP based changes need approval or notification prior to implementation | The approval and notification requirement remains, the phrase does not, at Section 12.5.2, note |
What to Do About It
Each item below is an obligation the final guidance states, with the section to check.
- Replace SaMD and SiMD wording with MDSW across your dossier, device master file, SOPs and labelling.
- Confirm whether your embedded software is sold separately. That decides whether it needs its own licence.
- If you rely on the wellness exclusion, test your intended use statement and promotional material against both limits.
- Re-check your risk class, especially where non-clinical users operate in a serious situation, which may be treated as critical. If unlisted, apply through the MD Online portal.
- Extend your QMS documentation to architecture, SRS, SDS, source code management, version control and release management, and maintain an SBOM with vulnerability monitoring.
- For AI products, treat the three “shall” items as mandatory. If you intend to avoid Indian clinical data, build your case against the Chapter VII exemption route.
- Rebuild your predicate comparison into the Table 6 format, with justification for every difference.
- State your hosting position If SaaS/cloud-hosted, state your hosting position including MeitY empanelment status and document baseline security controls. If on-premises, separately assess and document risks to local infrastructure, network security, maintenance, access controls, backup/recovery, and software updates.
- Update your software label against the a to i list, including Rule 44 particulars, and keep a version history.
- Revise your PMS plan to cover patch tracking, AI drift, hallucination detection and Indian real world evidence.
- Where an Annexure A checklist item does not apply, submit a justification with rationale rather than leaving it blank (Annexure A).
How NexorTest can help
At NexorTest, we help medical device and software manufacturers meet the CDSCO MDSW Guidance 2026 end to end: MDSW classification and risk-class determination, QMS and SBOM documentation, secure-by-design and cybersecurity evidence, AI dataset and bias documentation aligned to the Indian sub-population requirements, substantial-equivalence rebuilds into the Table 6 format, labelling and PMS plans, and full CDSCO submission through the MD Online portal. Our regulatory team also covers ISO 13485 QMS, SaMD, DPDP Act compliance and Indian Authorized Agent representation, so your software clears review the first time and stays compliant after approval.
Preparing an MDSW dossier or updating an existing SaMD/SiMD registration to the new guidance? Talk to our NexorTest regulatory team and align your submission with the final CDSCO guidance with confidence.
Meet Our Regulatory Expert
Dr. Pabbisetty PBS Kumar
Chief Compliance Officer at NexorTest Technologies
Newsletter
Sign up our newsletter to get update information, promotion or insight.
