CERT-In published its “Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure” on 25 May 2026. Version 1.0, 38 pages, 14 sections. It is guidance, not regulation: across the whole document the words “mandatory”, “shall” and “must” appear zero times, and “indicative” appears 26 times. The headline doing the rounds, that CERT-In wants internet-facing vulnerabilities fixed within 12 hours, is wrong in scope. That timeline covers known exploited vulnerabilities on internet-facing and crown-jewel systems, and the sentence ends with the words “where feasible”.
Most of the coverage of this document so far has been written by law firms summarising it for compliance teams. That is useful if you need to know it exists. It is less useful if you are the engineer who has to decide what actually changes on Monday.
This is the practitioner read. Everything below is quoted or counted from the PDF itself, which you can download from CERT-In and check against what follows. If you want the source list it sits on the CERT-In guidelines page.
First, the number everyone is getting wrong
At least one outlet has run the headline “CERT-In Asks Organizations to Fix Internet-Facing Vulnerabilities Within 12 Hours.” If you only read the headline, you would conclude that every internet-facing finding in your last pentest is now on a twelve-hour clock.
Here is what page 26 actually contains. The table is titled Indicative Risk-Based Remediation Timelines, and the column heading is Indicative Remediation Expectation:
| Finding type | Indicative remediation expectation |
|---|---|
| Known exploited vulnerability affecting internet-facing and crown-jewel systems | Immediate containment; patch, mitigate, or remove exposure within 12 hours where feasible |
| Critical externally exposed vulnerability | Patch, mitigate, or remove exposure within 1 day |
| Known exploited vulnerability affecting internal systems | Patch or mitigate within 1 day unless compensating controls are implemented and documented |
| Critical internal vulnerability affecting high-value systems | Patch or mitigate within 3 days |
| High-severity vulnerability | Patch or mitigate within 5 days based on risk prioritisation |
| No patch available | Temporary mitigation such as isolation, access restriction, WAF or API protection, enhanced monitoring, or feature control |
Three things change once you read the row rather than the headline.
It is “known exploited”, not “critical”. The twelve-hour row is about vulnerabilities that are actually being exploited in the wild, on systems that are both internet-facing and crown jewels. That is a small, specific set. A critical externally exposed vulnerability with no known exploitation sits in the row below at one day.
The words “where feasible” are in the sentence. They are not a summariser’s hedge. They are CERT-In’s.
The whole table is indicative. So is every other control table in the document. This is the single most important thing to understand about the Blueprint, and it deserves its own section.
The word that governs the entire document
I counted. Across 38 pages:
- “mandatory”: 0
- “shall”: 0
- “must”: 0
- “required to”: 0
- “indicative”: 26
Every control table in the document is headed either Indicative Measures or Indicative Controls. Section 3 says the Blueprint “aims to provide organisations with a structured and implementation-oriented framework”. The closing line of the executive summary says it “has been developed to assist entities”.
That is advisory register from beginning to end. Anyone telling you the Blueprint imposes a new obligation has not opened it.
One thing genuinely is an obligation, and it is worth keeping separate. The Blueprint references reporting of cyber incidents within six hours. That is the existing requirement from CERT-In’s 2022 directions under Section 70B of the IT Act. It predates this document by four years. Do not confuse the six-hour reporting obligation, which is real and binding, with the twelve-hour remediation expectation, which is indicative. They are different numbers, from different instruments, doing different jobs.
What the Blueprint actually asks you to test
If you skip to one section, make it Section 11, “Security Validation, Assurance, and Continuous Testing”. It opens by saying organisations “should establish continuous and risk-based security validation mechanisms”, then lists nine validation areas. Four of them are directly about offensive testing:
| Validation area | Indicative measures |
|---|---|
| Vulnerability Assessment and Penetration Testing | Internal and external VAPT, API testing, cloud assessment, segmentation validation, remediation verification |
| Red Teaming and Adversarial Simulation | Multi-stage attack simulation, phishing simulation, cloud compromise testing, lateral movement assessment |
| AI System Security Testing | Prompt injection testing, AI API assessment, model integrity review, AI workflow validation |
| Supply-Chain and Third-Party Assurance | Vendor assessments, dependency review, software provenance assessment, third-party access review |
The remaining five cover continuous security assurance, security operations and monitoring validation, business continuity and recovery testing, tabletop exercises, and independent audits.
Two of these are worth pausing on.
“Remediation verification” is a retest. Section 9 makes the same point from the other direction, listing “Validation of Remediation Effectiveness” as a control area whose objective is to “validate that remediation actions effectively remove exploitable exposure”, with indicative measures of “rescanning, penetration testing, configuration validation”. A test that finds problems and a test that confirms they are gone are being treated as two separate activities. If your current arrangement with a vendor produces a report and nothing after it, that is the gap this names.
“Prompt injection testing” appears in a Government of India document. Section 12 returns to it, listing “Prompt Injection and Input Manipulation Risks” as an area whose key measures include restricting AI permissions and execution capability, and conducting adversarial testing and behavioural monitoring. If you have been trying to explain to a board why AI application security testing is a distinct discipline from your normal pentest, this is now a citable reference rather than a vendor claim.
The 60-day roadmap
Section 13 sets out three phases. This is the most directly usable part of the document, because it is sequenced rather than exhaustive:
Phase I, 0 to 7 days. Immediate risk reduction. Establish governance and accountability structures. Identify critical assets and internet-facing systems. Implement MFA for critical access. Conduct vulnerability assessments. Patch critical and known exploited vulnerabilities. Reduce unnecessary exposure. Establish incident reporting and escalation procedures. Enable security logging and baseline monitoring. Start workforce awareness for AI-assisted phishing and deepfake threats.
Phase II, 8 to 30 days. Operational strengthening. Strengthen SOC and monitoring. Integrate endpoint, cloud, identity and network telemetry. Establish continuous vulnerability and attack surface management. Implement behaviour-based detection and threat hunting. Establish AI governance and an AI system inventory. Conduct cloud and API security assessments. Strengthen third-party and supply-chain assurance. Run tabletop exercises and backup restoration testing.
Phase III, 31 to 60 days. Advanced resilience and adaptive security. Conduct red team exercises and adversarial simulations. Implement continuous control validation. Enhance security automation and orchestration. Conduct adversarial AI testing. Validate model integrity and AI orchestration security. Continuously reassess exposure and resilience posture.
Notice the ordering. Knowing what you have and what is exposed comes first, in week one. Red teaming is a Phase III activity, after governance, monitoring and asset inventory are in place. That sequencing is correct and it is the opposite of how most teams buy security, which is to start with the most advanced-sounding engagement and work backwards.
The empanelment sentence, read honestly
Section 11 closes with this:
Organisations should conduct Red Teaming & cybersecurity audits, security assessments, adversarial simulations, and resilience validation exercises… Where applicable, such assessments may be conducted through CERT-In empanelled Information Security Auditing Organisations in alignment with the Comprehensive Cyber Security Audit Policy Guidelines.
We are not a CERT-In empanelled organisation, so read the next two paragraphs with that in mind and check the wording yourself.
The operative words are “may” and “where applicable”. This sentence does not say assessments must be done by an empanelled auditor, and the Blueprint has no mandatory language anywhere in it to draw on. Empanelment matters in specific situations, usually when a regulator, a government contract, or a sector-specific rule names it explicitly. It is genuinely not required in many others.
If you are trying to work out which side of that line you are on, we have written it up in detail both ways: who actually needs a CERT-In empanelled pentest vendor and when you do not. The short version is that it depends on who is asking for the audit and why, and a vendor who tells you it is always required, or never required, is selling rather than answering.
AIBOM, and what it means in practice
The Blueprint asks for supply-chain visibility through SBOM, AIBOM, QBOM, CBOM and HBOM, and points to CERT-In’s own Technical Guidelines on those, Version 2.0.
AIBOM is an AI Bill of Materials: an inventory of the models, datasets, weights, and AI dependencies your product relies on, in the same way an SBOM inventories your software components. For most AI-first and API-first SaaS startups this is currently an undocumented list living in a few engineers’ heads. Writing it down is a Phase II activity and it is cheap compared to almost everything else in the document.
We do not produce AIBOMs as a service, and this is not a pitch for one. It is on the list because the document puts it there and because an inventory you can produce in an afternoon is a better use of week two than most alternatives.
What actually changes on Monday
If you run engineering at an Indian SaaS company, the honest answer is that nothing became compulsory. What changed is that a set of expectations you may have been arguing for internally now has a Government of India document behind it.
Three things worth doing this week, all from Phase I:
- List what is internet-facing. Not what you think is internet-facing. What actually answers on the public internet, including the staging environment somebody spun up in March. You can run a free external attack surface scan on your own domain to get a starting list, or use any tool you like. The point is the list, not the tool.
- Separate “known exploited” from “critical” in whatever your scanner last told you. The Blueprint’s fastest timeline applies to the first category and not the second, and most teams do not currently distinguish between them. CISA’s Known Exploited Vulnerabilities catalogue is the usual reference point.
- Check whether your last pentest was ever retested. Both Section 9 and Section 11 treat validation of remediation as separate from the original assessment. If nobody confirmed the fixes worked, the finding is still a finding.
For the compliance side of this, our audit and compliance readiness work covers how this maps into SOC 2 and ISO 27001 evidence. But you do not need us, or anyone, to do the three things above.
A note on sourcing
Every figure in this post comes from the PDF, not from coverage of it. The page count, section count, publication date and version are from the document’s own footer and table of contents. The word counts are counts. The remediation table and the Section 11 validation areas are reproduced from pages 26 and 29 to 30.
We wrote it this way because the twelve-hour claim is a good example of how a number travels. It is real, it is in the document, and the version most people have read is still wrong. If you are going to act on a regulator’s publication, read the regulator’s publication.
If you want a second opinion on how any of this applies to your stack, we do founder-led penetration testing for AI-first and API-first SaaS startups, and you are welcome to talk to us before you decide you need anything at all.
Want to see how we report AI findings? Our sample penetration test report is published in full, no email gate. For what an AI scope covers and where it stops, see AI and API penetration testing.