CERT-In OEM Guidelines: Turn ‘Should’ Into Contract Clauses
CERT-In’s June 2026 guidelines for OEMs and technology providers include a table of indicative patch timelines, from 5 days for a critical IT flaw reported through responsible disclosure to 60–90 days for a medium-severity OT flaw. The table does not say when the clock starts or where it stops, and the sentence around it is written as “should”.[1] A buyer who wants those numbers to mean something has to write them into the contract, with a start event, an end event and a remedy.
The document is CISG-2026-03, Version 1.0, dated 10 June 2026.[1][3] It is addressed to OEMs and to technology providers broadly, including software vendors, hardware manufacturers, cloud and managed service providers and system integrators that supply organisations in India.[1] For a city, SPV or building owner, that covers most of what sits in a control room. This article turns the provisions into tender clauses and evidence requests.
Disclosure: Trisim Global Solutions, which supports this site, works on control room solutions. This article makes no claims about Trisim projects. It is analysis, not legal advice.
The patch table is indicative, and neither end of its clock is defined
Section 3.1 of the guidelines is headed “Patch Development and Compensatory Controls Indicative Timelines”. The table splits vulnerabilities by CVSS band, by whether they sit in IT or operational technology (OT), and by how they surfaced: either they “could likely be exploited using AI”, or they were identified or reported through responsible vulnerability disclosure.[1]
| Severity (CVSS) | Likely AI-exploitable: IT | Likely AI-exploitable: OT | Reported via disclosure: IT | Reported via disclosure: OT |
|---|---|---|---|---|
| Critical (9.0–10.0) | Emergency release | 7–15 days | 5 days | 15–30 days |
| High (7.0–8.9) | 7 days | 15–30 days | 15 days | 30–60 days |
| Medium (4.0–6.9) | 14 days | 30–60 days | 30 days | 60–90 days |
Two things stand out. The heading refers to patch development, which suggests the vendor’s side of the job, yet the text adds that the timelines should be applied “in conjunction with appropriate validation, testing, change management, and deployment procedures”.[1] Whether the days end at release or at go-live is therefore open. We also found no sentence that defines day 0. The nearest wording says vendors should start technical validation “immediately upon identification or confirmation” of a vulnerability, which is a duty to begin work, not a definition of when the count begins.[1]
The longer OT windows have a stated reason: the same paragraph asks that remediation not harm “security, stability, safety, or operational continuity”. That is sensible for a plant or a building system. It also means a buyer should ask the vendor which column each product belongs in, because a vendor can claim the longer window for anything with an OT label.
Nine provisions turn into a bidder’s evidence pack
The table below sets provisions we found testable against the evidence a bidder could be asked to supply. The right-hand column is our suggestion for a tender, indicative and not drawn from the guidelines. Pages are the document’s own page numbers.[1]
| Clause | What the CERT-In guidelines say | Evidence a bidder could be asked for (ours) |
|---|---|---|
| Bill of material | A BOM for hardware, software, cryptography, AI and quantum should be provided to Indian customers including CERT-In, and updated regularly (p.3). SBOM is advised for software components (p.7). | Machine-readable SBOM with every release and a dated update log. CERT-In’s separate SBOM guideline covers the format.[5] |
| Critical and High disclosure | Critical (CVSS 9.0–10.0) and High (7.0–8.9) flaws should be communicated to affected organisations and CERT-In “immediately upon discovery or confirmation”, with interim mitigation guidance (p.4). | A named notification channel, and a clause that turns “immediately” into a number of hours chosen by the buyer. |
| Zero-days and active exploitation | Affected organisations and CERT-In should be notified immediately, with interim safeguards, indicators of compromise and containment guidance (p.4). | The vendor’s written zero-day procedure, with the contact who will call you. |
| AI-assisted testing | Vendors should keep evidence and periodic certification that AI-assisted code analysis, dependency analysis and similar testing has been carried out (p.4). | Dated certificate or report naming tools, scope and findings counts. |
| Patch timelines | The indicative table in section 3.1 (p.5). | A committed number of days per severity and environment, with start and end events defined. |
| Interim controls | Where patching is not feasible, vendors should provide mitigations such as virtual patching, disabling services, segmentation, firewall or IPS rules and MFA (pp.5–6). | A written interim-mitigation note for each open Critical or High flaw, inside the committed window. |
| Patch deployment support | Documentation, testing guidance, rollback procedures, validation mechanisms and technical support during deployment (p.6). | Release notes, rollback steps and integrity checks for every patch, plus support hours. |
| Secure development and credentials | Products free of hardcoded credentials and insecure defaults (p.6); MFA, role-based access, privileged access management and time-bound administrative access (p.7). | SDL certification, a written statement of no default or hardcoded credentials, and time-bound vendor remote access. |
| Incident notification | Preliminary notice to affected Indian organisations with a copy to CERT-In, and regular status updates in listed cases; relevant logs preserved (pp.8–9). | A named liaison officer, a notification clock in hours and a log-retention commitment. |
Five deliverables in the guidelines already read as a tender checklist
Section 7 of the guidelines lists five “actionable deliverables” that OEMs and technology providers should maintain. They are the closest thing in the document to a bid checklist.[1]
- A current security posture assessment, covering deployed products, software inventories, known vulnerabilities, CVSS scores, patch status and exposed attack surfaces (p.9).
- A vulnerability remediation action plan with CVE identifiers, affected versions, interim measures, deployment timelines and rollback procedures (pp.9–10).
- A security compliance commitment from senior management, with designated cybersecurity liaison officers and escalation contacts (p.10).
- A continuous security assessment and assurance report, including VAPT, breach and attack simulation, independent audits and updated SBOM documentation (p.10).
- SDL compliance certification and evidence, including code review, penetration testing, dependency management and patch validation (p.10).
A buyer can ask for all five at bid stage and again at each annual review. We would ask for the third item first, because a named liaison officer is what makes the other four reachable in an emergency.
The guidelines address OEMs, so enforcement has to sit in your contract
Section 8 is headed “Compliance Verification and Enforcement”, but the text under it lists verification rights: Indian organisations including CERT-In “may” run independent assessments, patch validation and penetration tests, request audit reports and SBOM details, and engage third-party auditors.[1] We found no penalty for an OEM that ignores the guidelines. Binding duties come from elsewhere: the 2022 Directions, issued under section 70B(6) of the IT Act, require incident reporting to CERT-In within 6 hours, and the OEM guidelines cite them for that rule.[1][2]
Whether a foreign OEM or a local integrator is bound by any of this in a particular contract, and what remedy follows, is a matter for counsel. The guidelines also lean on a companion document: for AI-related guardrails they send readers to chapter 12 of the CERT-In Blueprint on AI-assisted exploitation.[1][4]
Because the guidelines name no consequence, the remedy has to come from the commercial terms. Options a buyer could consider are listed below. They are our suggestions only.
- Service credits or a payment holdback for each missed patch or notification date.
- A right for the buyer to engage an independent tester at the vendor’s cost when a Critical or High flaw stays open past its committed window.
- Termination or exit rights, with data and configuration hand-back, after repeated misses.
For the supplier landscape, our guide to cyber security OEMs matched to the layer lists who sells what. For why OT patching windows deserve separate treatment, see our piece on control room BMS design that plans for failure, and for another recent CERT-In alert that touches vendors, CERT-In’s AI agent alert and smart buildings.
Planning or upgrading a command and control centre? Talk to Trisim Global Solutions.
Sources
- CERT-In (MeitY), Guidelines regarding AI-Accelerated Vulnerability Protection and Response Requirements for OEMs and Technology Providers, CISG-2026-03, V1.0 (12 pp.), 10 Jun 2026, accessed 26 Oct 2026
- CERT-In (MeitY), Directions No. 20(3)/2022-CERT-In under section 70B(6) of the IT Act, 2000, 28 Apr 2022, accessed 26 Oct 2026
- CERT-In (MeitY), Security Guidelines index, entries CISG-2026-03 and CISG-2026-02, accessed 26 Oct 2026
- CERT-In (MeitY), Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure, V1.0, 25 May 2026, accessed 26 Oct 2026
- CERT-In (MeitY), Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, dated 9 July 2025, accessed 26 Oct 2026