By Vikrant Rana and Ananyaa Banerjee
Introduction
Cybersecurity regulation in India has, until now, largely spoken to the entity that suffers the breach. The 2022 CERT-In Directions issued under Section 70B of the Information Technology Act, 2000 fixed a six-hour reporting clock on the organisation that detects an incident. The new Guidelines flip the lens onto the entity upstream of that breach, the OEM or technology provider that built the product in the first place. For the first time, vendors supplying software, firmware, cloud platforms, or APIs into India carry direct, time-bound, and independently verifiable obligations of their own and not obligations that are merely passed through a customer contract, but obligations CERT-In itself may enforce.
The trigger is squarely artificial intelligence. AI has made vulnerability discovery, exploit generation, and attack execution dramatically faster on both sides of the fight, that is, for defenders and attackers alike. CERT-In has responded by building a regulatory framework where compliance timelines compress sharply the moment a vulnerability is assessed as AI-exploitable, rather than waiting for a fixed, one-size-fits-all patch cycle.
Background: How We Got Here
The Guidelines are the third instalment in a fast-moving regulatory sequence:
- 26 April 2026 — CERT-In advisory, “Defending Against Frontier AI Driven Cyber Risks,” flagging AI-generated malware, automated reconnaissance, and deepfake-enabled social engineering as emerging threat categories.[1]
- 25 May 2026 — the Blueprint for Reducing Exposure and Defending Against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure, a detailed technical playbook that the new Guidelines repeatedly cross-refer to (notably its Chapter 12, on guardrails for AI-enabled tools).[2]
- 10 June 2026 — the Guidelines reviewed here, which convert that advisory posture into concrete, dated obligations sitting on OEMs and technology providers.[3]
Read together, the three documents tell a consistent story: CERT-In sees AI as both a threat vector to be defended against and a compliance subject in its own right, and it is building supervisory infrastructure that includes inventories, certifications, audit rights for vendors to build their internal processes in alignment with.
Who Does This Apply To?
The net is deliberately wide. “Technology Provider” is defined to include software vendors, hardware manufacturers, cloud service providers, managed service providers, system integrators, technology partners, and digital service providers — covering, in effect, almost anyone supplying a product, platform, API, or managed service to an organisation in India, whether the vendor itself is based in India or abroad.
The Six Compliance Obligations, Decoded
-
Continuous Vulnerability Assessment
OEMs and technology providers should setup continuous vulnerability assessment mechanism on deployed products and platforms.
-
Immediate Disclosure of Critical and High-Severity Vulnerabilities
Any Critical (CVSS 9.0–10.0) or High (CVSS 7.0–8.9) vulnerability must be reported to CERT-In and to every affected Indian customer immediately upon discovery or confirmation along with interim mitigation guidance remediation timelines and not just baseline details about the vulnerability.
-
The Zero-Day Vulnerability Protocol
OEMs and technology providers should immediately notify CERT-In on becoming aware of any Zero-day vulnerability, active exploitation, and AI-assisted exploitation affecting deployed products of services. Furthermore, interim safeguards, temporary mitigation measures, indicators or compromise (IOCs), detection guidance, and recommended containment procedures should also be provided without delay.
-
AI-Assisted Security Testing Certification
OEMs and technology providers should maintain evidence and periodic certification confirming that security assessments including AI-assisted code analysis, automated vulnerability discovery mechanisms, security token scanning, and dependency analysis have been carried out.
Risk-Tiered, AI-Calibrated Patch Timelines
This is the Guidelines’ most operationally significant feature: patch deadlines now depend on whether AI could plausibly be used to exploit the vulnerability, not merely on its CVSS score. A Critical, AI-exploitable IT vulnerability calls for an Emergency Release; the same severity, if surfaced only through responsible disclosure with no AI-exploitation angle, gets 15–30 days.
Severity AI-Exploitable (IT) AI-Exploitable (OT) Standard Disclosure (IT) Standard Disclosure (OT) Critical (CVSS 9.0–10.0) Emergency Release 7–15 Days 5 Days 15–30 Days High (CVSS 7.0–8.9) 7 Days 15–30 Days 15 Days 30–60 Days Medium (CVSS 4.0–6.9) 14 Days 30–60 Days 30 Days 60–90 Days Indicative patch and remediation timelines under the Guidelines (Section 3.1)
Where an immediate patch is not feasible, the Guidelines expect interim compensating controls like virtual patching, disabling the vulnerable feature, network micro-segmentation, IPS rules, MFA enforcement, application allow-listing, and configuration hardening be deployed while the permanent fix is built.
-
Secure Development Lifecycle (SDL) and Bill of Materials
Security must be designed in, not bolted on: secure architecture review, threat modelling, dependency validation, and secrets management across the development lifecycle, with products free of hardcoded credentials, insecure defaults, exposed admin interfaces, or unsupported libraries. Underpinning all of this is a live Software/Hardware/Cryptography/AI Bill of Materials, shared with Indian customers and CERT-In and kept current — closing off the familiar defence of disclaiming responsibility for a vulnerable component buried three layers deep in a dependency tree.
-
Incident Response and Customer-Facing Transparency
The 2022 six-hour reporting rule already binds the entity that notices a breach. The new Guidelines layer a vendor-side duty on top: OEMs and technology providers must notify affected Indian customers directly, preserve logs and forensic evidence, and keep providing status updates until remediation is complete — particularly where the incident involves ransomware, credential exposure, supply-chain compromise, or AI-assisted exploitation.
The Five Deliverables CERT-In Can Ask to See
Beyond day-to-day compliance, the Guidelines require vendors to keep five documents audit-ready at all times. These are not annual filings — CERT-In and Indian customers may ask for them at any point:
- Current Security Posture Assessment — inventories, known vulnerabilities, patch status, and AI-related exposure.
- Vulnerability Remediation Action Plan — CVEs, CVSS ratings, mitigation steps, deployment timelines, rollback procedures.
- Enhanced Security Compliance Commitment — a signed statement from senior management, plus a named cybersecurity liaison officer for CERT-In and customer escalations.
- Continuous Security Assessment and Assurance Report — VAPT, Breach and Attack Simulation results, configuration reviews, and an updated SBOM.
- SDL Compliance Certification — evidence that secure coding, dependency management, and secure release practices were followed.
- Appointing a named cybersecurity liaison
Conclusion
These Guidelines are best read as CERT-In closing a structural gap rather than adding a new formality. Indian organisations have long carried breach-reporting duties under the 2022 Directions, while the vendors whose products actually contained the underlying flaw faced no comparable direct obligation to CERT-In. That imbalance is now corrected — and calibrated specifically to a threat environment where AI can compress the gap between vulnerability discovery and exploitation from months to hours.
For technology vendors, the practical shift is from cybersecurity-as-incident-response to cybersecurity-as-continuous-operations, with defined timelines and standing documentation that can be demanded, not merely referenced, at any time. For Indian buyers of technology, the Guidelines hand a ready-made checklist for procurement and vendor-risk teams — SBOM delivery, SDL certification, and audit rights are no longer aspirational contract asks; they now have a clear regulatory basis behind them. We expect vendor contracts, RFPs, and technology due-diligence checklists across India to begin reflecting this framework well before enforcement activity formally begins.
[1] https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0020
[2] https://www.cert-in.org.in/s2cMainServlet?pageid=GUIDLNVIEW02&refcode=CISG-2026-02
[3] https://www.cert-in.org.in/s2cMainServlet?pageid=GUIDLNVIEW02&refcode=CISG-2026-03