CDSCO Registration for Software as a Medical Device (SaMD) & AI Diagnostic Tools in India (2026)

The Central Drugs Standard Control Organisation (CDSCO) — India's national regulatory authority for medical devices, operating under the Directorate General of Health Services, Ministry of Health & Family Welfare — has historically regulated medical devices through rules written primarily with hardware in mind. That gap closed substantially on 21 October 2025, when CDSCO released its draft Guidance Document on Medical Device Software, giving Software as a Medical Device (SaMD) — including AI-powered diagnostic tools, clinical decision support systems, and remote monitoring platforms — a clear classification framework for the first time.

For digital health startups, AI diagnostics companies, and telemedicine platforms building products with a medical purpose, this guidance is the difference between assuming your software falls outside CDSCO's reach and discovering — often after launch — that it doesn't. This guide explains what qualifies as SaMD, how CDSCO's existing risk-based classification applies to software, and what registration actually involves. If your SaMD is likely to sit at the lower end of the risk scale, our CDSCO registration guide for Class A medical devices covers that pathway in more depth.

What is Software as a Medical Device (SaMD), and does CDSCO regulate it?

Software as a Medical Device (SaMD) is standalone software that independently performs a medical purpose — such as diagnosis, monitoring, or clinical decision support — without being embedded in a physical hardware device, and CDSCO regulates it under the Medical Devices Rules, 2017 (MDR 2017) once its intended use qualifies as a medical function. This covers AI-powered radiology and imaging analysis tools, computer-aided detection software, disease-monitoring apps, and clinical decision-support platforms — even where the software is offered free or bundled with a broader digital health platform.

CDSCO's October 2025 guidance draws a clear line between SaMD and Software in a Medical Device (SiMD) — firmware or embedded software that is inseparable from a physical device, such as the operating software inside an IVD analyser or the firmware controlling a pacemaker. SiMD inherits the risk classification of its parent hardware device and does not require separate classification. SaMD, by contrast, must be classified independently based on its own intended use and clinical impact, regardless of what platform or device it runs on.

How does CDSCO classify SaMD into risk classes?

CDSCO applies the same four-tier risk classification used for hardware devices — Class A (low risk) through Class D (high risk) — to SaMD, based on the software's medical purpose, the significance of the information it provides for clinical decision-making, and the severity of the condition it addresses. A retrospective data analysis tool with no direct bearing on an individual patient's treatment sits at the low-risk end of this scale, while an AI tool that independently detects a life-threatening condition and drives immediate clinical action sits at the high-risk end.

Foreign SaMD companies import their software into the Indian market under MD-14/MD-15 import licensing rather than the manufacturing forms above, and — as with hardware devices — must appoint an Indian Authorised Agent to hold the licence. Classification is based on what the software is currently validated to do, not what it may theoretically be capable of after a future update, which matters a great deal for AI/ML tools that evolve after deployment.

Is your app a wellness tool or a regulated SaMD?

A general wellness app becomes a regulated SaMD the moment it makes a diagnostic, monitoring, or treatment claim tied to a specific medical condition, rather than supporting general fitness or lifestyle goals. A step-counting or sleep-tracking app that makes no medical claim generally sits outside CDSCO's SaMD scope; the same app claiming to "detect signs of sleep apnea" or "flag irregular heart rhythms requiring medical attention" has crossed into SaMD territory, regardless of how the product is marketed commercially.

This distinction trips up more digital health founders than any other part of the framework, because the underlying technology can be identical — the same sensor data and algorithm can power both a wellness feature and a diagnostic one, depending purely on the claim attached to it. Clinical decision support software aimed at healthcare professionals faces a similar test: tools that simply display or organise information for a clinician to interpret generally carry lower regulatory weight than tools designed to be relied upon as the primary basis for a clinical decision. If your product roadmap includes adding a diagnostic or monitoring claim to an existing wellness feature, that update is the point at which a fresh classification review is worth doing — not after the feature has already shipped.

Who does the SaMD classification framework apply to?

The SaMD framework applies to any company placing standalone medical-purpose software on the Indian market, regardless of whether that company builds hardware devices, operates purely as a software business, or is based outside India. This includes AI diagnostics startups building imaging-analysis tools, telemedicine platforms adding symptom-checking or triage features, hospital-software vendors building clinical decision support modules, and wearable-device companies whose companion apps make health claims beyond basic activity tracking.

It also applies to foreign SaMD companies entering India through a distributor or local partner — holding a CE mark or FDA clearance does not exempt a company from filing a separate CDSCO application, and the Indian Authorised Agent requirement applies to software importers in the same way it applies to hardware. Companies building software as one component of a larger connected-device ecosystem should map each software module individually against the SiMD/SaMD distinction, since a single product can contain both embedded SiMD components and a standalone SaMD companion app that each carry different regulatory obligations.

What software validation and verification does CDSCO expect for SaMD?

CDSCO's guidance expects SaMD software to be developed and tested under a documented software lifecycle process — most commonly aligned with IEC 62304, the internationally harmonised standard for medical device software — covering planning, requirements, design, verification, and post-release maintenance. IEC 62304 applies to both SaMD and SiMD, and CDSCO's alignment with IMDRF and global frameworks means Indian reviewers increasingly expect the same lifecycle discipline that FDA and EU MDR reviewers already require, even though IEC 62304 itself isn't yet formally mandated by name under Indian law.

Verification and validation are frequently used interchangeably by non-specialists, but CDSCO reviewers treat them as distinct evidence requirements. Verification confirms that the software was built correctly against its own design specification — does the code do what the design document says it should — typically demonstrated through unit testing, integration testing, and code review records. Validation confirms that the software does what it needs to do in the real clinical context it's intended for — does the finished product actually diagnose, monitor, or support the clinical decision it claims to, when used the way a real clinician or patient will use it. A SaMD dossier that only submits verification test results without clinical validation data is one of the more common reasons CDSCO raises a deficiency query on software submissions.

IEC 62304 also introduces its own software safety classification — Class A (no injury possible), Class B (non-serious injury possible), and Class C (death or serious injury possible) — which runs alongside, but isn't identical to, CDSCO's device-level Class A–D system. A CDSCO Class C device, for instance, may contain software components that IEC 62304 would classify at its own Class B or C depending on the specific failure mode, and the depth of documentation, testing, and risk control expected scales with the higher of the two classifications that applies. In practice, the software safety class — not just the overall device class — determines how rigorous your test coverage, code review, and problem-resolution records need to be.

A complete software lifecycle file typically includes a software development plan, requirements specification, design specification, a traceability matrix linking requirements to design, test cases, and identified risks, verification and validation test reports, a software risk management file aligned with ISO 14971, and a maintenance plan covering how defects, updates, and cybersecurity patches are handled after release. For AI/ML-based SaMD specifically, validation needs to additionally cover training and test dataset composition, performance metrics (sensitivity, specificity, and similar measures appropriate to the clinical claim), and — under the Algorithm Change Protocol discussed above — a defined process for re-validating the model after retraining without necessarily triggering a full new licence application each time.

Cybersecurity evidence is increasingly folded directly into this same risk management file rather than treated as a separate checkbox — reviewers expect software risk analysis to explicitly consider failure modes introduced by data breaches, unauthorised access, or manipulated inputs, alongside the more traditional clinical failure modes. Companies that build their traceability matrix and risk file incrementally during development, rather than reconstructing it retroactively to satisfy a CDSCO submission, generally find the dossier preparation stage considerably faster and less prone to gaps that trigger review queries.

Documents required for CDSCO SaMD registration

A complete SaMD application needs the same core technical dossier structure as hardware devices, adapted for software — algorithm documentation, validation data, and cybersecurity evidence are the parts most first-time applicants underprepare.

How to register SaMD with CDSCO: step-by-step

CDSCO SaMD registration follows the same six-stage MDR 2017 pathway used for hardware devices, adapted to software-specific evidence at each stage.

What does CDSCO registration cost for SaMD companies?

CDSCO registration cost for SaMD depends on risk classification, the depth of clinical validation required, and whether existing FDA or CE evidence can be reused — Class A/B software with straightforward validation costs meaningfully less than a Class C/D AI diagnostic tool needing dedicated clinical performance studies. Government fees follow the same MD form structure as hardware devices; the larger cost variable for software is usually clinical validation and, increasingly, cybersecurity assessment, rather than the licence fee itself.

Consultant fees are typically quoted separately and vary significantly based on whether the software already holds FDA clearance or a CE mark — since that documentation can support, though not substitute for, the CDSCO technical dossier — versus a first-time regulatory submission built from scratch. Get a written, itemised quote after a consultant has reviewed your specific software's classification and existing regulatory history, since two SaMD products with similar functions can have very different validation costs depending on what evidence already exists.

Common pitfalls in SaMD regulatory compliance

Most SaMD compliance failures in India trace back to founders assuming their software falls outside CDSCO's scope — this remains the single largest risk given how recently the classification framework was clarified.

How MRDX REGULATORY supports CDSCO registration for SaMD, end-to-end

MRDX REGULATORY provides CDSCO medical device registration support covering classification, technical dossier preparation, and licensing for both hardware medical devices and standalone SaMD — the same regulatory groundwork behind categories we cover elsewhere, including CDSCO cosmetic import registration (COS-1/COS-2). If you're comparing consultants for a broader CDSCO project, see our Top 20 CDSCO Licensing Consultants in India roundup or the shorter Top 5 CDSCO Consultants in India guide.

CDSCO's October 2025 guidance has done what years of regulatory ambiguity hadn't — given digital health companies a concrete framework for understanding whether, and how, their software needs to be licensed in India. Even as a draft, it signals clearly where enforcement is heading, and companies building AI diagnostics, clinical decision support tools, or remote monitoring platforms should treat SaMD classification as a day-one product decision, not a post-launch cleanup task. Getting classification, algorithm documentation, and your Algorithm Change Protocol right early is what will let your product scale in India without a compliance gap surfacing later.