A ventilator that clears every electrical safety and EMC test can still stall at submission in 2026 if its software cannot be shown to be secure. As devices add wireless connectivity, mobile apps, cloud dashboards, and hospital-network integration, their software has become a safety surface in its own right. For Indian manufacturers, this is no longer a future concern. Cybersecurity has moved into the regulatory file, and testing evidence is now part of how a connected device earns approval.
Why Connectivity Redefined the Compliance Question
A connected device is exposed through interfaces that older standalone equipment never had: network ports, APIs, firmware update channels, and third-party software libraries. Each of these is a potential entry point. A vulnerability here is not only a data-privacy issue. It can alter device behaviour, corrupt readings, or interrupt therapy, which makes it a patient-safety issue. Regulators have responded by treating software security as inseparable from device safety, and manufacturers are now expected to prove that they have identified and controlled these risks before market entry.
What CDSCO Now Expects from Medical Device Software
The Central Drugs Standard Control Organisation released its final Guidance Document on Medical Device Software on 23 July 2026, building on an earlier draft and operating within the Medical Devices Rules, 2017. It applies a risk-based classification to Software as a Medical Device and Software in a Medical Device across Classes A to D, and raises clear expectations for software-driven products.
Three points matter most for manufacturers. First, a Software Bill of Materials is now expected, giving regulators and manufacturers a traceable inventory of every software component so that known vulnerabilities can be tracked. Second, cybersecurity risk must sit inside the risk management file under ISO 14971, not in a separate annex. Third, submissions are expected to include security testing evidence, commonly vulnerability assessment and penetration testing, along with a post-market plan that covers cybersecurity incident reporting. CDSCO does not mandate a single method, so the burden is on the manufacturer to demonstrate that vulnerabilities were found and mitigated credibly.
IEC 81001-5-1 and the Secure Development Lifecycle
The standard the wider industry is converging on is IEC 81001-5-1:2021, which governs security activities across the health-software lifecycle. It is worth understanding two things about it. It is process-based rather than a product certification, meaning it evaluates how securely a manufacturer designs, builds, and maintains software rather than certifying a finished unit. And it is structurally derived from the industrial standard IEC 62443-4-1, then adapted so that it supplements IEC 62304 for the software lifecycle and integrates with ISO 14971 for risk management. An interpretation sheet issued in 2025 has since clarified several requirements. Because a single secure lifecycle can support an entire product portfolio, manufacturers who adopt it early tend to move faster through multiple markets.
The Testing and Evidence That Supports Approval
In practice, demonstrating security readiness draws on a combination of activities: penetration testing across web interfaces, APIs, cloud back-ends, and device integrations; software composition analysis tied to the SBOM; threat modelling; vulnerability assessment; and verification that secure-design principles were actually implemented. The value of this work is not only the test result. It is the documented, defensible evidence trail that a reviewer can follow from identified threat to applied control, which is precisely what shortens technical review and reduces the risk of a submission being held.
Aligning Indian Approval with Export Markets
Manufacturers targeting more than one geography benefit from the overlap between frameworks. The United States now treats cybersecurity as a statutory premarket requirement, with FDA guidance built around a secure product development framework and an SBOM. The European Union recognises the harmonised version of IEC 81001-5-1. Building the security process once, around a recognised standard, means the same core evidence can serve Indian, US, and EU expectations rather than being rebuilt for each.
How Astute Labs Supports Manufacturers
As a NABL, BIS, and CDSCO-recognised medical device testing laboratory, Astute Labs helps manufacturers see how software security fits alongside the safety and EMC evidence already required for approval. For teams navigating the new software guidance, that means clarity on where testing and documentation obligations sit, how the risk file should reflect cybersecurity, and how to prepare a submission that a reviewer can trust. Our focus is helping manufacturers assemble complete, standards-aligned evidence rather than discovering gaps late in the process.
Connected devices raise the compliance bar, but they do not have to slow a launch when the testing and documentation strategy is planned early. To discuss how your device software and connected features map to current Medical Device Testing and compliance expectations, Contact us.
