India CDSCO Medical Device Software Guidance 2026: MDR 2017 Map

India's Central Drugs Standard Control Organization (CDSCO) published its current Guidance Document on Medical Device Software on 21 July 2026. The 62-page document, numbered CDSCO/MD/GD/MDSW/01/2026, brings CDSCO's current approach to medical device software (MDSW), including in vitro diagnostic (IVD) software, into one operational reference under the Medical Devices Rules, 2017 (MDR 2017).

The status matters. CDSCO says the guidance reflects current practices under MDR 2017 and “should not be misconstrued as a new regulatory control.” It is guidance for public awareness, not a new regulation or a substitute for the Drugs and Cosmetics Act, MDR 2017, or later CDSCO clarifications. The practical change is therefore not a new software law; it is a much clearer map of how CDSCO expects the existing framework to be applied to software submissions, licensing, quality systems, changes, and post-market controls.

Read the official CDSCO medical-device notice page or open the full guidance PDF.

Which software is in scope

The guidance applies when software, by itself or in combination with another product, has a medical purpose and meets the medical-device definition under Indian law. CDSCO uses MDSW as an umbrella term that also includes IVD medical device software unless the document says otherwise.

The intended use is the dividing line. CDSCO excludes software used only for general wellness, healthy-lifestyle promotion, routine body-parameter tracking, or fitness provided that it is not intended for a medical purpose. A wellness label does not neutralize diagnostic, monitoring, prediction, treatment, or other medical claims. Manufacturers should therefore reconcile the intended-use statement across the product, submission, labeling, instructions for use, and promotional material before relying on the exclusion.

The document is relevant to more than standalone apps. Its examples and submission sections address software that operates independently, software that drives or influences hardware, cloud- or network-connected systems, AI/ML functions, and IVD software. It is written for manufacturers, importers, innovators, researchers, and other applicants seeking regulatory approvals.

Classification still starts with intended use

MDSW follows the four risk classes already used by MDR 2017:

CDSCO states that software classification is fundamentally based on intended use and the classification rules in the First Schedule to MDR 2017. When more than one rule applies, the strictest rule producing the higher class applies. The guidance supplies practical illustrations, but they do not replace a product-specific classification rationale.

For a software portfolio, the useful unit of analysis is therefore not the codebase or commercial platform. It is each regulated intended purpose and the harm that could follow from the information or control the function provides. Two modules sharing the same technical architecture may need different regulatory treatment if their medical purposes and risks differ.

The submission route and licensing authority

The guidance separates the online route by application type:

• Test licences: submit through India's National Single Window System.
• Other regulatory permissions, manufacturing or import licences, and registration for sale and distribution: submit through the Online System for Medical Devices.

Licensing responsibility also changes with the transaction and risk class. CDSCO's Table 5 assigns test licences and import licences to the Central Licensing Authority (CLA) for all classes. Manufacturing licences for Class A and B MDSW sit with the State Licensing Authority (SLA), while Class C and D manufacturing licences sit with the CLA. Class A non-sterile, non-measuring devices are exempt from licensing and require registration under Chapter IIIB of MDR 2017; that exemption should not be generalized to other Class A software configurations without checking the applicable conditions.

This division is operationally important for companies with both Indian manufacturing and imported products. “CDSCO submission” is not one undifferentiated route: the correct portal, form, authority, and dossier depend on what the applicant is asking permission to do.

What the dossier now maps in one place

Sections 12.1–12.5 and Annexure A organize the evidence expected across test licences, clinical investigations or IVD performance evaluations, investigational-device permissions, commercial manufacturing/import licences, and post-market obligations. Applicability still depends on the product and application, but the guidance makes the major evidence domains visible:

• intended use, indications, target users, use environment, inputs, outputs, contraindications, and limitations;
• device description, software architecture, versioning, interfaces, dependencies, and the relationship between software and any hardware;
• classification rationale and, when applicable, predicate comparison;
• software development lifecycle, requirements, design, verification, validation, configuration, defect, and change-management records;
• risk management covering clinical, usability, data, cybersecurity, interoperability, and AI-related risks where applicable;
• clinical or performance evidence appropriate to the software and pathway;
• labeling, electronic information, installation, maintenance, update, and version-traceability information;
• QMS evidence for domestic or overseas manufacturing sites; and
• post-market surveillance, vigilance, corrective action, recall, and software-specific field actions.

Annexure A turns those domains into application checklists. It also says that when a listed document is not applicable, the applicant should provide a detailed justification rather than silently omit it.

QMS, standards, cybersecurity, and software changes

CDSCO places software lifecycle controls inside the quality management system. Domestic manufacturers must establish and maintain QMS procedures and records and submit the MDR 2017 Fifth Schedule compliance undertaking with a manufacturing-licence application. For imports, the overseas manufacturer must support the import-licence application with the QMS evidence described by the guidance.

The standards section preserves the MDR 2017 hierarchy: applicable BIS or notified Indian standards first, then ISO, IEC, or other stated international standards when an Indian standard is unavailable, and validated manufacturer standards when none of those is specified. Its illustrative MDSW table includes ISO 13485, ISO 14971, IEC 62304, IEC 82304-1, and IEC 81001-5-1, among others. The table says standards “may be applicable”; it is not a declaration that every listed standard applies identically to every product.

For lifecycle security, CDSCO says manufacturers should maintain and periodically update a bill of materials, including a software bill of materials (SBOM), covering third-party, open-source, and commercial components as appropriate. The guidance connects the SBOM to monitoring, assessing, and mitigating known vulnerabilities. It also calls for documented monitoring of post-deployment performance, including clinically significant degradation, algorithm drift, cybersecurity vulnerabilities, and unintended outcomes.

The wording around AI change planning requires care. The guidance says an Algorithm Change Protocol (ACP) may be devised, wherever applicable, based on the nature and risks of the MDSW. An ACP is therefore not presented as a mandatory artifact for every software device. Where used, it should describe procedures intended to ensure that changes do not compromise safety or intended use, including relevant data, validation, risk, monitoring, and rollback controls.

Post-market obligations are risk- and pathway-dependent

Commercial approval does not end the software lifecycle. The guidance connects licence conditions, adverse-event reporting, field safety corrective action, recalls, updates, and version traceability to the existing MDR 2017 post-market framework. For software, a recall can include halting distribution, uninstalling, or decommissioning the product from channels, networks, or hardware.

The Periodic Safety Update Report (PSUR) statement is narrower than a blanket rule for all MDSW. CDSCO specifically says MDSW approved for marketing after clinical investigations—such as a device without a predicate—should be closely monitored and that the manufacturer or importer must furnish PSURs under the conditions laid out in MDR 2017. Teams should map the exact post-market obligation to the approval route and licence conditions rather than copy a universal cadence from another product.

What manufacturers and importers should do now

Pure Global's view is that the most useful response is a controlled gap assessment, not a wholesale redesign based on the word “guidance.”

1. Replace the draft in the regulatory intelligence file. Record the 21 July 2026 document number and archive the issued guidance as the current reference.
2. Reconcile intended use and classification. Confirm that product claims, module boundaries, classification rules, and the highest-applicable-rule analysis agree.
3. Confirm the transaction-specific route. Separate test, manufacturing, import, investigational, and commercial-registration activities and map each to the correct portal, form, and licensing authority.
4. Crosswalk the dossier to Sections 12 and Annexure A. Identify missing evidence and document why a checklist item is not applicable.
5. Test the QMS against software reality. Confirm lifecycle, risk, configuration, verification/validation, vulnerability, SBOM, monitoring, and change records exist as controlled evidence rather than engineering artifacts outside the QMS.
6. Define the change boundary before the next release. Determine which changes require validation, documentation, and regulatory assessment, and whether an ACP is useful for the particular AI/ML function.
7. Align post-market data with versions. Complaints, adverse events, performance drift, vulnerabilities, corrections, and recalls must remain traceable to the software version actually deployed.

For the broader Indian registration pathway, see Pure Global's India medical device market-access guide. For a cross-market view of how AI-enabled software is classified and maintained, see AI as a Medical Device: The Global Map of Regulation, Registration, and Market Access.

The central takeaway is precise: CDSCO has not announced a separate new software regime. It has issued the clearest consolidated account yet of how medical device software fits inside India's existing MDR 2017 system. The compliance value comes from using that map to expose inconsistencies before they appear in a licence application, software release, or post-market event.