On 4 November 2026 CERT-In published its Artificial Intelligence (AI) Security Auditing Guidelines v1.0, a 107-page framework with four risk tiers and nine core audit domains. The domains include adversarial resilience and incident reporting, human oversight, and AI supply-chain assurance. Most coverage has focused on chatbots and banking models. The part that matters for connected devices is easier to miss: a supplementary section for what CERT-In calls Autonomous and Cyber-Physical AI.
That section is the closest the guidelines come to an IoT security rule. The MediaNama summary lists the category but does not spell out what it requires. The primary document does.
What the guidelines say about devices
The guidelines do not regulate devices as products. They are an audit framework for organisations that develop, procure, deploy or operate AI. Within that scope, a table of covered system types includes "Embedded AI": AI built into hardware devices, operational technology and IoT endpoints, with examples such as smart sensors, autonomous drones and connected vehicles. A separate category, Autonomous and Cyber-Physical AI, covers systems that affect physical processes with little or no continuous human intervention. The examples given are robotics, industrial-control AI, AI-enabled medical devices and smart-grid systems.
Section 9.10 sets controls for this category. Operators must define operating boundaries and detect spoofed or contradictory sensor inputs. Safety interlocks should work independently of the AI model where practicable. Systems must fall back to a safe state when inputs fail, allow manual takeover, and have an independent emergency shutdown. Model, firmware and software updates must be authenticated, tested, approved and capable of rollback. Higher-tier systems need simulation and hardware-in-the-loop fault testing before material changes go into production.
These are sensible engineering requirements. Authenticated, reversible updates and sensor-integrity checks are what a security engineer would ask of any connected device, and they are proportionate because the guidelines tie audit depth to risk tier. They sit alongside the guidelines' wider security domain, which MediaNama reports includes a six-hour incident-reporting window to CERT-In.
The strongest case for tighter rules
Advocates of a binding IoT law make a fair argument. Voluntary or audit-based guidance reaches organisations that choose to be audited. It does not stop a manufacturer from shipping a camera with a hardcoded password, and consumers cannot audit firmware. A statute would set a floor for every device sold, give regulators clear enforcement powers, and end the doubt over which agency is responsible. India has no single binding IoT security law, so that doubt is real.
What India has instead
India has two device regimes, and neither connects to the new guidelines.
The first covers surveillance cameras. TheNewsMinute reports that from 1 April 2026 internet-enabled CCTV sold in India must comply with certification under the STQC framework. Requirements include disclosing where key components such as chipsets come from and testing for vulnerabilities that allow unauthorised remote access. The same report says more than 500 camera models were already certified. STQC runs an IoT System Certification Scheme that tests devices at assurance levels, with vulnerability assessment and bill-of-materials checks for NVR/DVR-class products. Its own notice says earlier IoTSCS certificates are not valid for the cameras covered by the MeitY gazette notification of 6 March 2024 unless the products are validated against that notification's Essential Requirements. The result is a regime with two overlapping certificates, and manufacturers cannot assume that one satisfies the other.
The second regime is telecom equipment certification. The Department of Telecommunications describes MTCTE as testing against Essential Requirements, with security requirements issued as Indian Telecom Security Assurance Requirements. A 2021 UL Solutions summary of the early phases listed smart cameras, smart electricity meters, tracking devices with embedded SIMs and IoT gateways. That describes the early phases, so check current product lists before relying on it.
A connected device can therefore face MeitY/STQC rules, TEC/MTCTE rules, and now an AI audit that its deployer may owe to CERT-In. Nothing says how one maps to another.
Why a crosswalk beats a new statute
The case for a new omnibus IoT law is weaker than it looks. Technical standards for connected devices change faster than statutes can. India has just built two certification regimes that took years to reach manufacturers, and a third layer would restart that learning curve, with compliance costs that fall hardest on small hardware makers and startups.
CERT-In's guidelines offer a better route. They already require auditors to map applicable CERT-In requirements, sector obligations and contractual security requirements into the audit criteria and a Statement of Applicability. That mechanism could take in device certifications as evidence. A device holding a valid STQC or MTCTE certificate should be able to count toward the supply-chain and security domains without being re-tested from scratch.
Three changes would help:
- Publish a crosswalk. CERT-In, MeitY and DoT should show which Essential Requirements satisfy which section 9.10 controls, so that one test report serves several regimes.
- Clarify the device category. The guidelines should say plainly whether a consumer smart camera with on-device AI counts as Embedded AI, and at which tier. Auditors and manufacturers should not have to guess.
- Fix the certificate overlap. STQC should state which IoTSCS evidence carries over to the CCTV Essential Requirements, rather than leaving each manufacturer to find out through rejection.
What to watch
The guidelines are v1.0, and the test will be how auditors apply them to devices in practice. If they are read narrowly, enterprise operators of industrial and medical systems will bear the cost while consumer devices stay in the older regimes. If they are read broadly, small device makers could face audit obligations designed for banks. Either outcome would be avoidable with a short clarifying note and a published mapping. India does not need a new IoT statute to secure connected devices. It needs its existing rules to refer to one another.