CERT-In's OEM guidelines: five deliverables, and a named right to test your supplier

CERT-In has published Guidelines regarding AI-Accelerated Vulnerability Protection and Response Requirements for Original Equipment Manufacturers (OEMs), and Technology Providers, version 1.0, dated 10 June 2026. Twelve pages, eight sections, five named deliverables.

Most coverage of a CERT-In document asks what it obliges a supplier to do. The more useful question here is what it hands the buyer, because one section is addressed to Indian organisations rather than to their vendors.

Read the modal verbs first

This document advises. Section 2 opens with "All OEMs and technology providers are advised to establish and maintain comprehensive cybersecurity governance, vulnerability management, and secure product development practices". Every deliverable is worded with "should". The patch table is headed Indicative Timelines.

One part is different, and the document says so itself. Section 6 points at CERT-In Directions No. 20(3)/2022-CERT-In of 28 April 2022, issued under section 70B of the Information Technology Act, and restates their effect: cyber incidents "are required to be reported to CERT-In within 6 hours of noticing such incidents or being informed about them".

That sentence is pointing at a separate instrument. The rest of the guidelines sit alongside it as recommended practice. Anyone writing a supplier clause should reflect that difference rather than flatten it.

Who it is addressed to, which is wider than "OEM" suggests

Section 1 defines the population as global and domestic OEMs and technology providers, then opens a bracket that runs to software vendors, hardware manufacturers, cloud service providers, managed service providers, system integrators, technology partners and digital service providers. What they supply is drawn just as wide: products, software, firmware, platforms, cloud services, applications, APIs or managed services, to organisations operating in India.

A systems integrator delivering an API into an Indian bank is in scope on that reading. So is a SaaS vendor with Indian customers and no Indian entity.

The five deliverables, as a procurement ask-list

Section 7 is the part to lift straight into a vendor questionnaire.

#	Deliverable	What it asks for
1	Current Security Posture Assessment	Deployed products, software inventories, known vulnerabilities, CVSS scores, patch status, exposed attack surfaces, AI-related risks, plus AI-assisted testing readiness, SDL compliance status and credential hygiene verification
2	Vulnerability Remediation Action Plan	CVE identifiers, CVSS ratings, affected versions, exploitation prerequisites, patch availability, interim mitigations, testing requirements, deployment timelines, rollback procedures
3	Enhanced Security Compliance Commitment	A formal commitment from senior management, plus named cybersecurity liaison officers and escalation contacts
4	Continuous Security Assessment and Assurance Report	VAPT, Breach and Attack Simulation, configuration reviews and independent security audits, with reports covering remediation progress, penetration testing observations, unresolved risks and updated SBOM
5	SDL Compliance Certification	Evidence of code review, penetration testing, dependency management, security token management, patch validation, supply chain controls and secure release management

Deliverables 4 and 5 are the two that name testing outright. Deliverable 4 asks for vulnerability assessment and penetration testing, breach and attack simulation, configuration reviews and independent security audits. Deliverable 5 asks for evidence of code review, penetration testing and dependency management, alongside the rest of the secure development chain.

Three of the five are documents a mature supplier already has. Deliverable 3 is the one that tends to stall, because it needs a signature from someone senior enough to mean something.

Section 8.1, and why it is the part worth reading twice

Section 8.1 is headed "Organization Verification Rights", and it is written to the buyer:

"Indian organizations including CERT-In, may conduct independent security assessments, vulnerability verification, patch validation, penetration testing, configuration reviews, and compliance verification activities for OEM / technology providers - supplied products, software, services, APIs, and infrastructure."

And the next clause matters just as much:

"Indian organizations including CERT-In, may also engage independent security testing agencies or third-party auditors to validate OEM security controls, patch effectiveness, vulnerability remediation status, and compliance posture."

So the buyer may test the product it bought, and may bring in a third party to do the testing. The same section lets Indian organisations request documentation, security evidence, remediation status reports, incident response records, audit reports, SDL compliance documentation and SBOM details "whenever required".

Where a vendor contract leaves testing to be agreed case by case, this is a reference to bring to the renewal conversation. The practical move is to convert it into a contract clause, with a scope and a frequency, rather than to rely on citing guidance at the moment you want to run a test.

The patch table, and the IT and OT split

Section 3.1 sets indicative timelines on two axes at once. The first is how the vulnerability surfaced: one it judges "could likely be exploited using AI", or one identified or reported through responsible disclosure. The second is the environment, Information Technology or Operational Technology. That second split is the detail most summaries drop.

Severity	IT, AI-exploitable	OT, AI-exploitable	IT, responsibly disclosed	OT, responsibly disclosed
Critical, CVSS 9.0 to 10.0	Emergency release	7 to 15 days	5 days	15 to 30 days
High, CVSS 7.0 to 8.9	7 days	15 to 30 days	15 days	30 to 60 days
Medium, CVSS 4.0 to 6.9	14 days	30 to 60 days	30 days	60 to 90 days

Every numeric OT figure is at least double its IT counterpart, and the document explains why: remediation is to be implemented "in conjunction with appropriate validation, testing, change management, and deployment procedures" so that it does not harm "the security, stability, safety, or operational continuity" of either environment.

Where a patch cannot be deployed in time, section 3.1 lists the interim measures a supplier is advised to provide: virtual patching and compensatory controls, disabling vulnerable services or features, network and micro-segmentation, firewall or IPS rules, restricting internet exposure, enhanced logging and monitoring, multi-factor authentication, application allow-listing, and temporary configuration hardening.

The Bill of Material ask is broader than SBOM

Section 2 asks suppliers to keep inventories and adds that "The Bill of Material for hardware / software / cryptography / AI / quantum should also be provided to the Indian customers including CERT-In, and updated on a regular basis."

Five bills of material, not one. A supplier that has an SBOM and nothing else has a quarter of that ask covered. Section 4 repeats the SBOM point separately for products and software components.

Disclosure clocks a buyer should expect

Section 2.1(b) asks that any Critical (CVSS 9.0 to 10.0) or High (CVSS 7.0 to 8.9) vulnerability affecting deployed systems be communicated to affected organisations and to CERT-In "immediately upon discovery or confirmation", with interim mitigation guidance and recommended remediation timelines attached.

Section 2.1(c) sets a zero-day protocol: on becoming aware of a zero-day, active exploitation, or exploitation through AI-assisted techniques, the supplier notifies affected organisations including CERT-In immediately, and provides interim safeguards, indicators of compromise, detection guidance and containment procedures.

Section 3.3 asks for automated notification, so that advisories, mitigations and patches reach CERT-In and affected Indian organisations as soon as they exist rather than on the next newsletter cycle.

Where to start

Put deliverables 1, 2, 4 and 5 into the vendor questionnaire. They are documents rather than projects, and a supplier that cannot produce them has told you something.

Write section 8.1 into the contract. A right to test that lives in guidance is worth less than the same right with a named scope and frequency in a schedule.

Ask for all five bills of material. Hardware, software, cryptography, AI and quantum. The last two are the ones a supplier is least likely to have started.

Separate the 6-hour clock from the rest. It comes from the CERT-In Directions of 28 April 2022 and applies to your own organisation as well as to your supplier.

Security Brigade has been CERT-In empanelled since 2008 and runs the testing this guidance names: VAPT across applications, APIs and infrastructure, configuration review, source code review, and independent third-party assessment of supplier-delivered products.