Most of the coverage of CERT-In's 2026 artificial-intelligence guidance collapsed into a single headline number: patch internet-facing critical vulnerabilities within twelve hours. It is a striking figure, and it is real. It is also, on its own, close to useless as guidance for a small Indian firm, because it has been lifted out of a document set that says several other things — some of them contradictory, one of them legally binding, and one of them genuinely valuable to a business with no security team at all.
What follows is a reading of the primary documents rather than the press summaries, because the gap between the two is where the practical advice lives.
Three Documents, Not One
CERT-In did not issue a single AI cybersecurity rulebook in 2026. It issued three connected instruments in seven weeks, and they carry different weight.
The first, on 26 April 2026, was an advisory titled Defending Against Frontier AI Driven Cyber Risks (reference CIAD-2026-0020). The second, on 25 May 2026, was the Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure — nine subject areas across fourteen sections, with a three-phase implementation roadmap. This is where the twelve-hour remediation expectation for internet-exposed critical vulnerabilities appears, alongside AI asset inventories, SBOM and AIBOM adoption, India-resident log retention, and the announcement of a new CERT-In AI Cyber Defence Centre. The third, dated 10 June 2026, is a set of guidelines aimed squarely at Original Equipment Manufacturers and technology providers, covering what vendors selling into India owe their Indian customers.
The distinction matters because only the third document names deliverables you can demand from someone else. The first two mostly describe work you are expected to do yourself.
The Twelve-Hour Number Is Advice. The Six-Hour Number Is Law.
The Blueprint's remediation expectation is framed as guidance, and the phrasing in the surrounding text is conditional — organisations should close internet-exposed critical exposure within twelve hours where feasible. There is no penalty clause attached to missing it. No small firm is going to be prosecuted in 2026 for taking three days to patch a public-facing server.
The obligation that does carry teeth is older and far less discussed in the AI coverage. CERT-In Directions No. 20(3)/2022-CERT-In, issued under Section 70B of the IT Act on 28 April 2022 and in force from 27 June 2022, require a reportable cyber incident to be notified to CERT-In within six hours of it being noticed. The same directions require 180 days of log retention and synchronisation of system clocks to Indian NTP servers. Non-compliance attracts action under Section 70B(7) of the IT Act, which extends to imprisonment of up to one year, a fine of up to one lakh rupees, or both.
The 10 June OEM guidelines explicitly restate the six-hour reporting requirement as a live obligation. So the honest priority order for an Indian MSME is the reverse of what the headlines implied. If you can only fix one thing this quarter, fix your ability to notice an incident and file a preliminary report inside six hours. That is a legal duty. The twelve-hour patch window is a performance target.
The initial report is not an investigation. It is roughly nine fields — incident category, detection timestamp, affected systems, estimated scope, a named point of contact, and whatever containment you have already attempted. Root cause and attribution are not expected at that stage. Firms miss the six-hour deadline not because the report is hard but because nobody owns it and nobody has written down where to send it.
The Arithmetic Nobody Has Named
Read the Blueprint and the OEM guidelines side by side and a structural problem appears that no summary I have seen has addressed.
Section 3.1 of the 10 June guidelines sets indicative timelines for how long a vendor may take to develop and release a patch. Those timelines are measured in days and weeks, not hours:
| Severity | AI-exploitable, IT systems | AI-exploitable, OT systems | Responsibly disclosed, IT systems |
|---|---|---|---|
| Critical (CVSS 9.0–10.0) | Emergency release | 7–15 days | 5 days |
| High (CVSS 7.0–8.9) | 7 days | 15–30 days | 15 days |
| Medium (CVSS 4.0–6.9) | 14 days | 30–60 days | 30 days |
A vendor may take five days to ship a fix for a critical, responsibly disclosed flaw in an IT product. The organisation running that product is told to close the exposure in twelve hours. For most of that window, the patch you are supposed to apply does not exist yet.
This is not an error in the documents. It is the point, and CERT-In says so directly: where immediate patch deployment is not feasible, the guidance calls for interim mitigation. But it means the twelve-hour clock is not really a patching instruction at all. It is an instruction to reduce exposure in twelve hours, by whatever means, and to keep reducing it until the vendor catches up. Firms that read it as “install the update faster” will spend the window waiting for something that has not been written.
What You Can Actually Do Inside Twelve Hours
The Blueprint and the OEM guidelines both list compensatory controls, and every one of them is available to a firm with no security staff and no budget. In descending order of how much exposure they remove per rupee spent:
Take it off the internet. Restriction of internet exposure is the first control CERT-In names, and it is free. A great many MSME breaches begin at a remote-desktop port, a database admin panel, or a legacy CCTV or router interface that was published to the public internet years ago by an installer who has since left. If a service does not need to be reachable from outside your office, close it. This single action resolves most twelve-hour situations outright.
Disable the vulnerable feature rather than the whole system. Advisories usually name a specific component — a file-upload module, an API endpoint, a plugin. Turning that one thing off buys you the days you need until the vendor ships.
Segment. Put accounts, production machinery and the guest or shop-floor network on separate segments so a compromise of one does not become a compromise of all three. On most small-business routers this is a VLAN configuration change, not a purchase.
Enforce multi-factor authentication. Phishing, including voice and SMS variants, was the most common initial attack vector in Indian breaches in 2026 at 19 per cent, according to IBM's Cost of a Data Breach Report 2026. MFA on email and on any remote-access account is the cheapest control with the largest measured effect.
Turn on logging, and keep it for 180 days. Not because it prevents anything, but because the 2022 directions require it and because without logs you cannot answer CERT-In's questions or your insurer's.
Firewall or IPS rules, virtual patching, application allow-listing and temporary configuration hardening round out CERT-In's own list. None of these require an AI strategy. They require somebody to have written down what you own.
The Leverage You Have Been Handed and Are Not Using
The most useful thing in the 2026 document set is not addressed to you at all, which is probably why almost nobody has told small firms about it.
The 10 June guidelines instruct OEMs and technology providers — software vendors, hardware manufacturers, cloud providers, managed service providers, system integrators — to supply their Indian customers with a Bill of Materials covering hardware, software, cryptography, AI components and quantum readiness, updated regularly. They are told to disclose any critical or high-severity vulnerability affecting deployed systems to affected organisations immediately upon discovery, with interim mitigation guidance and a remediation timeline. They are told to establish automated patch-notification mechanisms so customers hear about fixes as they are released. And CERT-In sets out five standing deliverables vendors should be able to produce on request, including a current security posture assessment, a documented remediation action plan with CVE identifiers and CVSS ratings, and a senior-management compliance commitment naming a cybersecurity liaison officer.
Section 8.1 then states that Indian organisations may conduct independent verification of vendor-supplied products and may request that documentation whenever required. It does not restrict that right to large enterprises.
For an MSME, that converts a vague anxiety into three concrete emails. Ask your billing or ERP vendor for their SBOM. Ask your cloud or hosting provider to name their cybersecurity liaison officer and confirm you are on their automated advisory list. Ask your system integrator for their current remediation plan for the products they installed at your premises. The answers — including silence — will tell you more about your actual risk than any threat report. CERT-In has published oem.security@cert-in.org.in for coordination on exactly these questions.
This is the shift worth acting on: for the first time, a substantial part of the compliance burden has been placed on the people who sold you the software, and you have been given standing to ask them about it. Our e-book Cyberthreat to Indian MSME 2026 works through the vendor-questioning process and the incident-reporting workflow in more operational detail than a single article allows.
What This Will Not Fix
An honest reading has to concede how much of this guidance will land nowhere.
Research compiled by CUTS International on cybersecurity challenges facing Indian MSMEs found that around 63 per cent of MSMEs have adopted no cybersecurity standard or framework at all, more than 40 per cent have never run any security awareness training for employees, and roughly a quarter cite the absence of internal IT security staff as their central obstacle. A twelve-hour remediation target and a five-deliverable vendor-assurance regime are not written for that firm. They are written for organisations that already have an asset inventory, and the firms most likely to be breached are precisely those that do not.
The financial asymmetry is widening rather than narrowing. IBM put the average cost of a data breach in India at a record 25.5 crore rupees in 2026, up 15.9 per cent from 22 crore the year before, with an average of 39,500 records exposed per incident. AI-generated attacks accounted for 26 per cent of malicious incidents. Organisations without AI-assisted security automation paid roughly 48 per cent more per breach than those with it — which describes almost every micro and small enterprise in the country. Meanwhile India's total information security spending is forecast at about 3.4 billion dollars in 2026, up 11.7 per cent, and very little of that is MSME money.
There is also no enforcement mechanism behind the advisory portions. The OEM guidelines use “should” throughout, not “shall”. A vendor that ignores a request for an SBOM faces no stated consequence. Whether Section 8.1 becomes a real customer right or a paragraph nobody invokes depends entirely on how many customers invoke it — which, for once, is something small firms can influence collectively at low cost.
And the operational technology timelines deserve attention from anyone running machinery. A critical, AI-exploitable flaw in an OT system carries an indicative patch-development window of seven to fifteen days, and thirty to sixty days for a responsibly disclosed medium-severity one. Small manufacturers with connected equipment should assume long exposure windows are structural, not exceptional, and plan segmentation accordingly.
The Practical Reading
Three things follow from the documents themselves rather than from the coverage of them.
Your binding obligation is the six-hour incident report under the 2022 directions, and it needs a named owner and a written procedure this month. Your twelve-hour target is an exposure-reduction exercise, not a patching exercise, and the controls that satisfy it are configuration changes you already have the ability to make. Your best available leverage is the vendor-disclosure regime in the 10 June guidelines, and it costs three emails to test.
The AI framing in these documents is accurate — attackers really have compressed reconnaissance and exploit development from weeks into hours. But nothing CERT-In recommends in response requires an Indian small business to buy artificial intelligence. It requires them to know what they own, close what does not need to be open, and hold their suppliers to a standard the government has now written down on their behalf.
Go deeper on MSME cyber risk
Cyberthreat to Indian MSME 2026 — the threat landscape, vendor due diligence and the CERT-In reporting workflow, written for firms without a security team.
Executive Cyber Crime & Digital Risk Report — a board-level view of digital risk exposure and response planning.
Sources
- CERT-In, Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure, 25 May 2026.
- CERT-In, Guidelines regarding AI-Accelerated Vulnerability Protection and Response Requirements for Original Equipment Manufacturers (OEMs) and Technology Providers, Version 1.0, 10 June 2026.
- CERT-In advisory, Defending Against Frontier AI Driven Cyber Risks, CIAD-2026-0020, 26 April 2026.
- CERT-In Directions No. 20(3)/2022-CERT-In under Section 70B of the Information Technology Act, 2000, dated 28 April 2022 (effective 27 June 2022) — six-hour incident reporting, 180-day log retention, NTP synchronisation; penalty under Section 70B(7).
- IBM, Cost of a Data Breach Report 2026 — India findings, released July 2026: average breach cost Rs 25.5 crore (up 15.9 per cent), 39,500 records per incident, phishing 19 per cent of initial vectors, AI-generated breaches 26 per cent of malicious incidents.
- Gartner forecast, reported August 2026: India end-user information security spending of USD 3.4 billion in 2026, an 11.7 per cent increase over 2025.
- CUTS International, briefing paper on cybersecurity challenges for Indian MSMEs — framework adoption, training and staffing gaps.
