Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›CERT-In AI-Assisted Exploitation Blueprint
CERT-In · v1.0 · issued 25 May 2026

A practical guide to CERT-In's AI-exploitation blueprint.

CERT-In's Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation assumes attackers now use AI to find and exploit weaknesses faster than teams can patch them (§1, p.3). This page walks every control area and how to meet it, with the section and page for each.

Talk to our advisory team Read it on CERT-In
12core defensive principles (§5)
14technical control areas (§7)
12 hrsfastest fix window (§9, p.26)
6 hrsincident reporting to CERT-In (§10)
What changed

Static security can't keep up. The blueprint says so plainly.

Exploitation timelines are “reducing significantly,” attacks “will become increasingly autonomous,” and “traditional static security approaches would become insufficient” (§4.6, p.10). When an adversary chains reconnaissance, exploit development and lateral movement with AI, a quarterly scan and a ticket queue do not keep pace.

The blueprint's answer is continuous: organisations “can no longer rely solely on periodic assessments” (§2, p.5). The sections below are the practical version of that, control by control.

Defending against AI-assisted attacks

Find it before attackers do. Catch it if they try. Fix it fast.

The blueprint's threat model is an attacker using AI to move faster than you. The answer is to run the same loop on your own software, continuously.

1 · Find it first

Attack it the way an AI-assisted hacker would

An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build, before someone outside does the same with AI.

2 · Catch it live

Detect and block exploitation at runtime with eBPF

A kernel-level agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot, rather than taking down the whole host.

3 · Fix it automatically

Auto-patch what is reachable and exploitable

Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside the blueprint’s tight fix windows instead of sitting in a queue.

Maps to the blueprint's continuous-validation (§11), AI-aware security operations (§8) and risk-based remediation (§9) expectations.

Risk-based prioritisation · §9 C2

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that start the 12-hour clock.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Remediation timelines · §9, p.26

The clock by finding type

Indicative fix windows from the blueprint. Tightest where exposure and exploitation meet.

KEV · internet-facing / crown jewels12h
Critical · externally exposed1 day
KEV · internal systems1 day
Critical · internal high-value3 days
High severity5 days

Plus: report cyber incidents to CERT-In within 6 hours (§10, p.28).

EXPOSURE MANAGEMENT

How to run continuous exposure management

The blueprint treats exploitable exposure as something you measure and shrink on a continuous basis, not a quarterly audit. Continuous Exposure Management is named as a core principle (§5 Principle 4, p.11) and operationalised through asset visibility and attack surface management (§7 Control 1, p.17). The idea is simple: you cannot defend an asset you do not know exists, and attackers find shadow systems faster than most inventories update.

§5 Principle 4 · p.11§7 Control 1 · p.17§7 Control 7 · p.18-19
Build and continuously refresh an authoritative asset inventory that includes internet-facing systems, cloud resources, APIs, and dependencies, rather than a static spreadsheet (§7 Control 1, p.17).
Monitor your external attack surface for newly exposed services, and actively hunt for shadow IT and shadow AI that bypass procurement and security review (§7 Control 1, p.17).
Track software dependencies and maintain SBOM, QBOM, and CBOM inventories in line with CERT-In's Technical Guidelines on SBOM, QBOM and CBOM v2.0 (§7 Control 1, p.17).
Assess cloud posture continuously for exposed storage, over-permissioned identities, and management-plane misconfiguration (§7 Control 1, p.17; §7 Control 7, p.18-19).
Close the loop with remediation validation so reduced exposure is confirmed, not assumed (§5 Principle 4, p.11).
Where O3 helps

O3 helps on the dependency-visibility side: it generates CycloneDX SBOM, CBOM, QBOM, AIBOM and HBOM inventories so your dependency and crypto exposure is tracked the way the SBOM/QBOM/CBOM guidelines expect. Asset discovery, cloud posture and shadow-IT detection sit largely outside O3 and are best handled by a dedicated CSPM and external attack surface platform.

SECURE BY DESIGN

How to embed secure-by-design and SDLC security testing

The blueprint asks organisations to build security in from inception rather than bolt it on after release. Secure-by-Design and Secure-by-Default is a core principle (§5 Principle 5, p.12), and Application and API Security (§7 Control 6, p.18) spells out the testing expected across the development lifecycle. With AI now writing production code, §12 Area 11 (p.33) extends the same discipline to AI-assisted development.

§5 Principle 5 · p.12§7 Control 6 · p.18§12 Area 11 · p.33
Threat model new systems and features early, and ship hardened, secure-by-default configurations so safe settings are the baseline rather than an opt-in (§5 Principle 5, p.12).
Wire SAST, DAST and SCA into CI/CD so every change is tested for code flaws, runtime weaknesses and vulnerable dependencies before it merges (§7 Control 6, p.18).
Add dedicated API security testing and secrets management, since exposed keys and unauthenticated endpoints are common entry points (§7 Control 6, p.18).
Review AI-generated code and its pulled-in dependencies with the same SAST, DAST and dependency analysis you apply to human-written code, and secure the AI-assisted CI/CD path itself (§12 Area 11, p.33).
Align your application security programme with CERT-In's Guidelines for Secure Application Design, Development, Implementation and Operations (§7 Control 6, p.18).
Where O3 helps

This is core O3 territory: code-property-graph SAST with interprocedural source-to-sink taint analysis, SCA against OSV, secret scanning, and agentic DAST covering 50+ vulnerability classes all run in CI/CD, and the same engines apply to AI-generated code. Threat modelling and the governance side of secure-by-default remain a human and process responsibility.

VULNERABILITY MANAGEMENT

How to prioritise vulnerabilities by real-world risk

The blueprint moves away from patching by raw CVSS score and toward remediating what is actually exploitable and actually exposed. Continuous Vulnerability Management (§9 Control 1, p.25) sets the cadence, and Risk-Based Prioritisation (§9 Control 2, p.25) defines the signals that should push a finding to the top of the queue. The goal is to spend remediation effort where an attacker is most likely to strike.

§9 Control 1 · p.25§9 Control 2 · p.25§9 Control 4 · p.26
Scan continuously across internet-facing systems, cloud and APIs rather than on a fixed annual schedule, and validate every remediation (§9 Control 1, p.25; §9 Control 4, p.26).
Prioritise findings on the CISA/CERT-In Known Exploited Vulnerabilities list first, since these are confirmed to be under active exploitation (§9 Control 2, p.25).
Use EPSS to estimate exploit likelihood and combine it with exploitability analysis, so probable-attack findings outrank theoretically-high ones (§9 Control 2, p.25).
Weight by business criticality and exposure so a medium flaw on a crown-jewel, internet-facing system beats a high flaw on an isolated internal host (§9 Control 2, p.25).
Feed threat intelligence into the prioritisation model so the queue reflects what adversaries are exploiting now (§9 Control 2, p.25).
Where O3 helps

O3 applies KEV and EPSS prioritisation directly, and adds function-level reachability that ranks whether a vulnerable dependency is actually called in your code, which removes a large share of unreachable noise before it reaches the remediation queue. Business-criticality weighting still depends on your own asset classification.

REMEDIATION CLOCK

How to meet the risk-based remediation timelines

The blueprint publishes indicative remediation timelines that turn prioritisation into a clock (§9 Timelines Table, p.26). The windows are tight at the exposed, exploited end and more forgiving as risk drops, and they assume you can tell which systems are crown jewels and which findings are KEV-listed. Knowing your exposure and exploitability is what makes these targets achievable.

§9 Timelines Table Rows 1-6 · p.26§9 Control 3 · p.25§9 Control 4 · p.26
Treat a known exploited vulnerability on an internet-facing or crown-jewel system as an emergency: contain immediately and patch, mitigate or remove exposure within 12 hours where feasible (§9 Timelines Table Row 1, p.26).
Remediate critical externally exposed vulnerabilities within 1 day, and KEV findings on internal systems within 1 day unless compensating controls are documented (§9 Timelines Table Rows 2-3, p.26).
Patch critical internal vulnerabilities on high-value systems within 3 days, and high-severity findings within 5 days based on risk prioritisation (§9 Timelines Table Rows 4-5, p.26).
When no patch exists, apply temporary mitigations such as isolation, access restriction, WAF or API protection, enhanced monitoring, or feature disablement until a fix is available (§9 Timelines Table Row 6, p.26).
Run controlled patch workflows with emergency, exception and tracking paths, then validate effectiveness by rescanning, penetration testing and configuration checks (§9 Control 3, p.25; §9 Control 4, p.26).
Where O3 helps

O3 supports the clock at both ends: KEV plus EPSS prioritisation flags the 12-hour and 1-day cases, autofix and auto-PR generation shorten time-to-patch, and rescanning confirms remediation under §9 Control 4. The patch-deployment workflow, change control and the WAF or network-isolation mitigations remain your operational responsibility.

SECURE CONFIGURATION

How to reduce exposure from insecure configuration

Misconfiguration is one of the most common roots of exploitable exposure, and the blueprint addresses it directly. Secure Configuration and Hardening (§7 Control 13, p.20) targets the drift and weak defaults that quietly widen attack surface over time, complementing the proactive secure-by-default principle with ongoing enforcement.

§7 Control 13 · p.20§5 Principle 5 · p.12
Define hardened baselines for operating systems, services, cloud resources and containers, drawing on recognised benchmarks (§7 Control 13, p.20).
Audit configurations against those baselines on a schedule rather than at deployment only (§7 Control 13, p.20).
Monitor for configuration drift so unauthorised or accidental changes are caught before they become exposure (§7 Control 13, p.20).
Lock down administrative interfaces and management planes with secure administrative controls (§7 Control 13, p.20).
Where O3 helps

Baseline definition, configuration auditing and drift monitoring are best served by dedicated hardening and CSPM tooling rather than O3; treat this cluster as neutral guidance and pair it with the asset-visibility work above so newly provisioned systems inherit a known-good baseline.

CONTINUOUS VALIDATION

How to validate that controls and fixes actually work

The blueprint repeatedly insists that security is proven, not assumed. Continuous Validation of Technical Controls (§7 Control 14, p.20) and the validation areas in §11 (p.29-30) ask you to test control effectiveness against evolving threats, and §9 Control 4 (p.26) ties this directly to confirming that remediation removed the exposure.

§7 Control 14 · p.20§11 Validation Area 2 · p.29§9 Control 4 · p.26
Run regular vulnerability assessments and penetration tests across internal and external environments, APIs and cloud, and verify remediation as part of the engagement (§7 Control 14, p.20; §11 Validation Area 2, p.29).
Use adversarial simulation and exposure validation to confirm that deployed controls block the techniques attackers actually use (§7 Control 14, p.20; §11 Validation Area 3, p.29).
Rescan and retest after every fix so closed findings stay closed and patches do not regress (§9 Control 4, p.26).
Include AI-assisted vulnerability assessment in the validation mix, as the blueprint explicitly anticipates both internal and external AI-assisted testing (§7 Control 14, p.20).
Where O3 helps

O3's agentic pentest engine and SAST/SCA/DAST stack provide the AI-assisted vulnerability assessment the blueprint anticipates, and automated rescanning closes the §9 Control 4 validation loop after each fix. Independent third-party audits and red-team engagements remain valuable as an outside check.

SUPPLY-CHAIN TRUST

How to build supply-chain trust and software provenance

The blueprint treats third-party software, open-source dependencies, and AI models as a single trust problem. Principle 10 asks you to reduce risk from anything you did not write yourself by knowing where it came from and proving it has not been tampered with (§5 Principle 10, p.12). Validation Area 5 then makes that posture something you must test on a recurring basis, not assert once at procurement (§11 Validation Area 5, p.29).

§5 P10 · p.12§11 Validation Area 5 · p.29§7 Control 1 · p.17
Run vendor security assessments before integration and re-review on a schedule, covering the vendor's own development security, breach history, and patch responsiveness.
Validate software provenance: verify signed artifacts, check build origin, and reject unsigned or unverifiable components from your build and deployment pipelines.
Maintain a live dependency inventory so every transitive package, container base image, and external service is tracked and attributable to a source.
Govern third-party access with least privilege and time-boxed credentials, and review which vendors and integrations still hold access each quarter.
Re-test supply-chain posture continuously through dependency review and provenance assessment rather than relying on a one-time onboarding check (§11 Validation Area 5, p.29).
Where O3 helps

O3 reads SLSA provenance and cosign signatures directly off container images so you can confirm an artifact's build origin during provenance validation, and its dependency scanning keeps the live inventory the blueprint expects.

MALICIOUS DEPENDENCIES

How to detect malicious dependencies and reduce dependency exposure

Attackers increasingly compromise the package rather than the perimeter, through typosquats, poisoned post-install scripts, and hijacked maintainer accounts. The blueprint requires dependency tracking and review as part of attack surface management (§7 Control 1, p.17) and pairs it with SAST, DAST, and software composition analysis under Application and API Security (§7 Control 6, p.18). Dependency review also appears explicitly in supply-chain assurance testing (§11 Validation Area 5, p.29).

§7 Control 1 · p.17§7 Control 6 · p.18§9 Control 2 · p.25§11 Validation Area 5 · p.29
Run software composition analysis against a vulnerability database such as OSV on every build, and fail the build on known-exploitable components.
Screen new and updated dependencies for malicious behaviour, including typosquatted names, suspicious install scripts, and recently changed maintainership, before they reach production.
Pin and lock versions, and prefer signed packages and verified registries so an upstream compromise cannot silently land in your tree.
Prioritise dependency findings by real exposure using KEV and EPSS rather than treating every CVE equally (§9 Control 2, p.25).
Use function-level reachability to confirm whether a vulnerable dependency path is actually invoked before spending a remediation window on it.
Where O3 helps

O3 covers this end to end: SCA against OSV, dedicated malicious-dependency detection for typosquats, malicious post-install scripts and compromised maintainers, plus function-level reachability and EPSS/KEV ranking so teams remediate the dependencies that are genuinely reachable and exploitable.

XBOM AND AI ASSET INVENTORY

How to maintain an xBOM and AI bill of materials

You cannot govern what you cannot see. The blueprint anchors asset visibility to CERT-In's own Technical Guidelines on SBOM, QBOM, CBOM, AIBOM and HBOM v2.0, and calls for shadow IT and shadow AI detection alongside dependency tracking (§7 Control 1, p.17). On the AI side it requires a maintained inventory of every AI system, integration, API, plugin, and third-party AI dependency, including unauthorised usage (§12 Area 2, p.31).

§7 Control 1 · p.17§12 Area 2 · p.31§13 Phase II · p.36
Generate a machine-readable SBOM in CycloneDX for every application and link it to VEX so consumers know which listed vulnerabilities actually affect the build.
Extend the bill of materials beyond software: a CBOM for cryptographic assets, a QBOM for quantum-readiness scoring, an AIBOM for models and datasets, and an HBOM for hardware, per CERT-In SBOM/QBOM/CBOM/AIBOM/HBOM v2.0 (§7 Control 1, p.17).
Build and continuously update an AI asset inventory that records models, inference endpoints, agents, plugins, and the third-party AI APIs your applications call (§12 Area 2, p.31).
Hunt for shadow AI: monitor egress and API usage to surface unsanctioned AI services and unauthorised model access (§12 Area 2, p.31).
Treat AI governance and AI system inventory as Phase II work to stand up within 8 to 30 days (§13 Phase II, p.36).
Where O3 helps

O3's xBOM suite emits CycloneDX SBOM (with deps.dev enrichment and VEX), CBOM, QBOM and AIBOM, and its AIBOM inventories AI models and datasets, which directly supports both the v2.0 BOM guidelines and the AI asset inventory the blueprint requires.

AI IN DEVELOPMENT

How to secure AI-assisted software development and DevSecOps

AI coding assistants accelerate delivery but introduce code and dependencies no human chose deliberately. The blueprint requires you to review AI-generated code and the dependencies it pulls in, run SAST, DAST and dependency analysis over it, and secure AI-assisted CI/CD workflows (§12 Area 11, p.33). This sits on top of the Secure-by-Design principle that pushes threat modelling and CI/CD security testing to the start of the lifecycle (§5 Principle 5, p.12).

§12 Area 11 · p.33§7 Control 6 · p.18§5 P5 · p.12§12 Area 10 · p.33
Treat AI-generated code as untrusted input: require human review, and scan it with SAST for source-to-sink flaws and SCA for the dependencies it introduces (§12 Area 11, p.33).
Validate every dependency an assistant suggests against a real package registry, since LLMs routinely hallucinate plausible-but-nonexistent package names that attackers then register.
Embed security gates in the pipeline: SAST, DAST, dependency analysis, and secrets scanning on each merge, with secure handling of the credentials the AI tooling itself uses (§7 Control 6, p.18).
Threat-model AI-assisted CI/CD: restrict what build agents and AI tools can read, write, and deploy, and keep audit trails of automated changes (§5 Principle 8, p.12).
Keep a human in the loop for high-impact merges and releases rather than allowing fully autonomous promotion to production (§12 Area 10, p.33).
Where O3 helps

O3 applies directly to AI-generated code: interprocedural code-property-graph SAST for source-to-sink taint, SCA with malicious-dependency detection to catch hallucinated or poisoned packages, Gitleaks secret scanning, and autofix/auto-PR generation to remediate findings inside the pipeline.

AI GOVERNANCE

How to govern third-party AI providers and model integrity

The blueprint extends supply-chain trust to the AI you consume and the models you run. It requires assessing third-party AI providers' security posture, contractual and data-handling obligations, and contingency plans for critical dependencies (§12 Area 8, p.33), and separately demands you validate model provenance, integrity and versioning to prevent unauthorised modification (§12 Area 12, p.34). Public AI platforms get their own guardrail against leaking regulated data (§12 Area 4, p.32).

§12 Area 8 · p.33§12 Area 12 · p.34§12 Area 4 · p.32§12 Area 1 · p.31§12 Area 15 · p.34
Assess each external AI model, API, and platform for security posture, data residency, and resilience before adoption, and keep a fallback for any provider you cannot afford to lose (§12 Area 8, p.33).
Establish acceptable-use policies for public AI services that block upload of sensitive or regulated information, backed by awareness and approval-based governance (§12 Area 4, p.32).
Validate model provenance and integrity, version-control models, and protect them from unauthorised modification across the training and inference pipeline (§12 Area 12, p.34).
Define AI usage policies, accountability owners, and approval and review gates for new AI integrations as the governance backbone (§12 Area 1, p.31).
Reassess AI risk, architecture, and provider posture periodically as part of adaptive governance rather than at onboarding only (§12 Area 15, p.34).
Where O3 helps

AI governance, contractual review, and acceptable-use policy are organisational controls O3 does not provide; teams should run these through their procurement and risk functions. O3's AIBOM does help on one piece by inventorying the AI models and datasets in use, which feeds the third-party AI dependency and model-integrity tracking the blueprint asks for.

ASSUME BREACH

How to detect attacks at runtime with behavioural analytics

The blueprint's first core principle is Assume Breach (§5 Principle 1, p.11): build for rapid detection, containment, and recovery rather than assuming prevention will hold. It pairs this with Detection Engineering and Behavioural Analytics in security operations (§8 Controls 3 and 4, p.22), which call for behaviour-based detection, anomaly detection, and monitoring of privilege escalation and suspicious activity. The point is that AI-assisted attacks adapt faster than static signatures, so detection has to watch how systems and identities actually behave, not just match known indicators.

§5 Principle 1 · p.11§7 Control 3 · p.18§7 Control 10 · p.19§8 Control 1 · p.21§8 Control 3 · p.22§8 Control 4 · p.22§8 Control 13 · p.24
Build behavioural baselines for users, service accounts, hosts, and APIs so deviations (off-hours privilege use, unusual API call volumes, new process lineage) surface as alerts rather than noise (§8 Control 4, p.22).
Deploy EDR/XDR on endpoints and servers with behavioural monitoring, not just signature AV, and tune detection rules continuously as adversary tactics shift (§7 Control 3, p.18; §8 Control 3, p.22).
Instrument the kernel and process layer to capture process trees, syscalls, and execution chains so post-exploitation activity is visible even when the initial payload is novel.
Centralise endpoint, identity, network, cloud, and AI telemetry into a SIEM and correlate it, prioritising alerts on critical and internet-facing systems (§7 Control 10, p.19; §8 Control 1, p.21).
Continuously review detection coverage, assess telemetry gaps, and feed incident learnings back into rule tuning (§8 Control 13, p.24).
Where O3 helps

O3's eBPF runtime agent observes attacks at the kernel level, reconstructing per-process trees from syscalls, Kprobes, Tracepoints, and LSM hooks to flag multi-step attack chains with no sidecars, and it can apply dynamic per-PID enforcement. Centralised SIEM correlation, alert prioritisation, and the broader SOC workflow remain the responsibility of your security operations stack.

DATA EXFILTRATION

How to detect and stop data exfiltration on egress

Defence-in-Depth and Data-Centric Security (§5 Principles 3 and 9, p.11-12) expect controls that protect data throughout its lifecycle and catch leakage, while Behavioural Analytics calls out suspicious API activity and operational anomalies (§8 Control 4, p.22). Exfiltration is often the moment a breach becomes a reportable incident, so watching what leaves the network is as important as watching what comes in. AI-assisted attacks increasingly stage data over encrypted channels and DNS, which is exactly where egress monitoring earns its keep.

§5 Principle 3 · p.11§5 Principle 9 · p.12§7 Control 4 · p.18§7 Control 8 · p.19§8 Control 4 · p.22§8 Control 10 · p.23§10 · p.28
Classify sensitive and regulated data first so you know what an exfiltration alert is actually protecting, then enforce encryption, access governance, and retention controls around it (§7 Control 8, p.19; §5 Principle 9, p.12).
Establish an egress baseline of normal outbound destinations, volumes, and protocols, then alert on deviations such as large transfers to new endpoints or anomalous DNS query patterns that indicate tunnelling.
Inspect encrypted traffic at the endpoint where you can see plaintext, rather than relying only on perimeter taps that go blind on TLS, so you catch staged exfiltration before it leaves.
Deploy Data Loss Prevention and network/DNS protections as layered controls, and monitor cloud and API egress paths specifically since modern exfiltration often rides cloud storage and API calls (§7 Control 4, p.18; §7 Control 8, p.19; §8 Control 4, p.22).
Wire exfiltration detections into automated response (endpoint isolation, blocking) with approval gates for high-impact actions, and confirm reportable incidents are escalated to CERT-In within 6 hours (§8 Control 10, p.23; §10 closing requirement, p.28).
Where O3 helps

O3's eBPF L7 deep packet inspection captures TLS plaintext on the host, learns an egress baseline, and detects DNS-tunnel and exfiltration patterns in under two seconds, and its runtime agent can enforce per-PID. Data classification, DLP policy, and SIEM-driven response orchestration sit outside O3 and should be handled by dedicated tooling.

THREAT-INFORMED DEFENCE

How to align defences with real adversary behaviour

Threat-Informed Defence (§5 Principle 6, p.12) asks you to align controls with evolving adversarial tactics through threat intelligence, threat hunting, detection engineering, and red/purple teaming. The security operations section reinforces this with Threat Intelligence Integration and Threat Hunting (§8 Controls 2 and 6, p.21-22), including explicit monitoring of AI-assisted attack trends. Validation closes the loop with red teaming and adversarial simulation (§11 Validation Area 3, p.29). The goal is a defence that is shaped by how attackers actually operate, then tested against it.

§5 Principle 6 · p.12§7 Control 14 · p.20§8 Control 2 · p.21-22§8 Control 6 · p.22§8 Control 13 · p.24§9 Control 2 · p.25§9 Control 4 · p.26§11 Validation Area 3 · p.29
Integrate threat intelligence feeds and correlate IOCs across your telemetry, tracking AI-assisted attack trends and sector-specific threats so detections reflect current adversary behaviour (§8 Control 2, p.21-22).
Run proactive threat hunts for stealthy activity (suspicious identity use, lateral movement, cloud and AI misuse) instead of waiting for alerts to fire (§8 Control 6, p.22).
Use exploit-likelihood signals such as KEV and EPSS to prioritise which exposures attackers are most likely to weaponise, and validate that remediation actually closed them (§9 Control 2, p.25; §9 Control 4, p.26).
Exercise the defence with multi-stage attack simulation, phishing simulation, cloud compromise testing, and lateral movement assessment, then feed findings back into detection rules (§11 Validation Area 3, p.29; §8 Control 13, p.24).
Continuously validate technical controls with internal and external AI-assisted vulnerability assessments and adversarial simulations so coverage keeps pace with new tactics (§7 Control 14, p.20).
Where O3 helps

O3 supports the offensive-validation side with an agentic pentest engine covering 50+ vulnerability classes via a browser agent, and it prioritises findings using EPSS and KEV plus function-level reachability so teams focus on what is genuinely exploitable. Threat intelligence integration, hunting workflows, and purple-team program management remain SOC functions outside O3's scope.

CONTINUOUS VALIDATION & ASSURANCE

How to prove your security controls actually work, continuously

The blueprint treats security as something you measure, not something you assume. Principle 11 (§5, p.13) and Control 14 (§7, p.20) both call for continuous testing of control effectiveness rather than point-in-time checks, and §11 Validation Area 1 (p.29) frames this as ongoing security assurance covering exposure, monitoring, privileged access, cloud and AI. The point is simple: a control you deployed last quarter is only worth what it can do against today's threats.

§5 P11 · p.13§7 Control 14 · p.20§11 Validation Area 1 · p.29§9 Control 4 · p.26§13 Phase III · p.36
Define a recurring validation cadence per control family (identity, endpoint, network, cloud, AI) instead of a single annual review, mapping each to §7 Controls 1–14 so coverage is explicit.
Validate that controls produce the outcome they promise: confirm segmentation actually blocks lateral movement, that EDR alerts fire, and that monitoring captures the event, per §11 Validation Area 1 (p.29).
Close the loop after every remediation. §9 Control 4 (p.26) requires rescanning, penetration testing, and configuration validation to confirm the exposure is truly gone, not just ticketed.
Track control drift over time and feed validation results back into prioritisation, aligning with Phase III activity 'implement continuous control validation' (§13, p.36).
Keep validation evidence in a form an independent auditor can replay, supporting §11 Validation Area 9 (p.30).
Where O3 helps

O3 supports the technical-control validation loop: continuous SAST, SCA against the OSV database, and secret scanning re-run on every change, with function-level reachability ranking whether a flagged vulnerability is actually exploitable in your code so validation focuses on real exposure. It does not cover identity, segmentation, or governance validation, which need dedicated tooling and process.

PENTEST & ADVERSARIAL SIMULATION

How to run penetration testing and adversarial simulation against AI-assisted threats

Scanning tells you what might be wrong; adversarial testing tells you what an attacker can actually do. The blueprint asks for both. §11 Validation Area 2 (p.29) covers internal and external VAPT, while Validation Area 3 (p.29) adds red teaming and multi-stage attack simulation, and Validation Area 4 (p.29) extends testing to AI systems through prompt-injection and model-integrity testing. Phase III (§13, p.36) sequences red team exercises, continuous control validation, and adversarial AI testing as the maturity end-state.

§11 Validation Area 2 · p.29§11 Validation Area 3 · p.29§11 Validation Area 4 · p.29§12 Area 16 · p.35§13 Phase III · p.36
Run VAPT across internal and external surfaces, APIs, and cloud, and validate segmentation, per §11 Validation Area 2 (p.29).
Move beyond isolated findings to multi-stage simulations that chain phishing, cloud compromise, and lateral movement the way a real adversary would, per §11 Validation Area 3 (p.29).
Test your AI systems as attack surface: prompt injection, AI API assessment, model integrity, and AI workflow validation, per §11 Validation Area 4 (p.29) and §12 Area 16 (p.35).
Align scenarios with current adversary tradecraft and threat intelligence so simulations stay threat-informed, per §5 Principle 6 (p.12).
Verify remediation by re-testing the exploited path, not just rescanning, closing §9 Control 4 (p.26).
Where O3 helps

O3's agentic DAST (pulsar-agno) drives a browser agent across 50+ vulnerability classes for application and API testing, and its taint-based SAST traces source-to-sink exploitability to support pre-deployment validation. Full multi-stage red teaming and human-led social engineering remain a specialist exercise that should sit alongside automated testing.

EVIDENCE & AUDIT READINESS

How to keep evidence and stay audit-ready with automation under human oversight

Validation only counts if you can show it. The blueprint pairs Principle 8, Security Automation with Human Oversight (§5, p.12), with Independent Audits and Assurance Reviews (§11 Validation Area 9, p.30), so automation accelerates the work while a human stays accountable for high-impact decisions and the audit trail proves it. For AI-assisted decisions specifically, §12 Area 10 (p.33) requires you to validate outputs, restrict fully autonomous critical actions, and maintain approval and auditability mechanisms.

§5 P8 · p.12§11 Validation Area 9 · p.30§12 Area 10 · p.33§9 Timelines · p.26§10 · p.28
Automate the repetitive validation work (scanning, triage, correlation) but require human approval for critical actions and record every decision in an audit trail, per §5 Principle 8 (p.12) and §8 Control 10 (p.23).
Maintain immutable, time-stamped evidence of assessments, remediations, and re-tests so an independent reviewer can verify control effectiveness, supporting §11 Validation Area 9 (p.30).
Log AI-assisted defensive actions and AI-generated outputs, and keep records of who validated them, per §12 Area 10 (p.33) and §12 Area 9 (p.33).
Tie evidence to the remediation timelines so auditors can confirm, for example, that known exploited internet-facing vulnerabilities were contained within the indicative windows in §9 (p.26).
Be ready to report cyber incidents to CERT-In within 6 hours (§10, p.28) and to participate in CERT-In drills and tabletop exercises (§11 Validation Area 8, p.30).
Where O3 helps

O3 generates machine-readable evidence as a by-product of scanning: CycloneDX SBOM, CBOM, QBOM, AIBOM and HBOM inventories, EPSS and KEV prioritisation on findings, and reachability-ranked results, all of which give auditors a verifiable, replayable trail. The human-approval workflows, sign-off accountability, and formal audit process itself stay with your governance team.

The whole document

Every control area, and how teams meet it.

All 71principle and control areas across the blueprint's 38 pages, each with the section, page, and a vendor-neutral note on how to satisfy it.

12§5
Core principles
14§7
Technical controls
13§8
Security operations
5§9
Vuln management
9§11
Validation
16§12
AI governance
Control area
Assume Breach§5 P1 · p.11Continuous monitoring, segmentation, breach simulations
Zero Trust Security§5 P2 · p.11MFA, PAM, micro-segmentation, conditional access
Defence-in-Depth§5 P3 · p.11Layered endpoint, DLP, hardening, backups
Continuous Exposure Management§5 P4 · p.11Attack-surface monitoring, vuln scanning, remediation validation
Secure-by-Design / Secure-by-Default§5 P5 · p.12Threat modelling, secure coding, CI/CD security testing
Threat-Informed Defence§5 P6 · p.12Threat intel, hunting, red/purple teaming
Resilience-Centric Security§5 P7 · p.12BCP/DR, immutable backups, crisis comms
Security Automation with Human Oversight§5 P8 · p.12SOAR with human approval, audit trails
Data-Centric Security§5 P9 · p.12Classification, encryption, DLP, access governance
Supply-Chain Trust & Verifiability§5 P10 · p.12Vendor reviews, SBOM/xBOM, provenance validation
Continuous Validation, Audits & Assurance§5 P11 · p.13VAPT, adversarial simulation, independent audits
Proportional, Risk-Based Implementation§5 P12 · p.13Prioritise critical systems, privileged identities, OT
Asset Visibility & Attack Surface Mgmt§7 C1 · p.17Asset inventory, shadow IT/AI detection, dependency tracking
Identity & Access Security§7 C2 · p.17MFA, PAM, least privilege, access reviews
Endpoint & Server Security§7 C3 · p.18EDR/XDR, hardening, patching, application control
Network Security & Segmentation§7 C4 · p.18Segmentation, IDS/IPS, secure remote access
Email, Messaging & Collaboration Security§7 C5 · p.18Anti-phishing, SPF/DKIM/DMARC, executive verification
Application & API Security§7 C6 · p.18Secure SDLC, SAST/DAST/SCA, secrets management
Cloud Security§7 C7 · p.18-19Secure config, IAM controls, continuous cloud monitoring
Data Protection & Information Security§7 C8 · p.19Classification, encryption, DLP, AI data controls
AI System Security§7 C9 · p.19Prompt-injection protection, AI access control, model monitoring
Security Logging, Monitoring & Telemetry§7 C10 · p.19Centralised logging, SIEM, anomaly detection
Backup, Recovery & Resilience§7 C11 · p.19Immutable backups, restoration testing, recovery objectives
OT & Critical Infrastructure Security§7 C12 · p.19-20IT/OT segregation, air-gap, data diodes
Secure Configuration & Hardening§7 C13 · p.20Hardened baselines, config audits, drift monitoring
Continuous Validation of Technical Controls§7 C14 · p.20VA, pentesting, AI-assisted exposure validation
Security Operations Modernisation (Agentic SOC)§8 C1 · p.21Centralised monitoring, telemetry correlation, alert prioritisation
Threat Intelligence Integration§8 C2 · p.21-22IOC correlation, sector threat tracking
Detection Engineering§8 C3 · p.22Behavioural detection rules, tuning, privilege-escalation monitoring
Behavioural Analytics & Anomaly Detection§8 C4 · p.22User/cloud anomaly, suspicious API analysis
Continuous Security Monitoring§8 C5 · p.22Endpoint, identity, network, cloud, AI logging
Threat Hunting§8 C6 · p.22Proactive hunts, cloud/AI misuse detection
AI-Assisted Defensive Operations§8 C7 · p.23Automated triage, enrichment, investigation support
Monitoring of AI Systems & Usage§8 C8 · p.23Monitor AI access, prompts, inference, API
Incident Correlation & Contextual Analysis§8 C9 · p.23Cross-domain correlation, attack-path analysis
Security Automation & Orchestration§8 C10 · p.23Automated workflows, endpoint isolation, approval gates
Deepfake & Impersonation Detection Readiness§8 C11 · p.23-24Verification procedures, deepfake awareness, escalation
SOC Workforce Readiness & Skills§8 C12 · p.24Detection, AI-threat, investigation training
Continuous Improvement & Operational Adaptation§8 C13 · p.24Detection review, telemetry gaps, incident learnings
Continuous Vulnerability Management§9 C1 · p.25Scanning, cloud/API assessment, remediation validation
Risk-Based Prioritisation§9 C2 · p.25KEV + EPSS, exploitability, business criticality
Patch & Remediation Management§9 C3 · p.25Patch workflows, emergency remediation, exception handling
Validation of Remediation Effectiveness§9 C4 · p.26Rescanning, pentesting, configuration validation
Risk-Based Remediation Timelines§9 Table · p.2612h KEV crown-jewels; 1d critical; 3-5d high
Continuous Security Assurance§11 A1 · p.29Exposure, monitoring, privileged-access, cloud/AI review
Vulnerability Assessment & Penetration Testing§11 A2 · p.29Internal/external VAPT, API, segmentation validation
Red Teaming & Adversarial Simulation§11 A3 · p.29Multi-stage simulation, phishing, lateral-movement testing
AI System Security Testing§11 A4 · p.29Prompt-injection testing, model integrity, workflow validation
Supply-Chain & Third-Party Assurance§11 A5 · p.29Vendor, dependency, provenance, access review
Security Operations & Monitoring Validation§11 A6 · p.30Detection testing, SIEM, alert-quality review
Business Continuity & Recovery Testing§11 A7 · p.30Backup restoration, DR exercises, continuity drills
Tabletop Exercises & Crisis Simulations§11 A8 · p.30Tabletops, ransomware sims, crisis comms
Independent Audits & Assurance Reviews§11 A9 · p.30Cyber audits, resilience, architecture reviews
6-Hour Incident Reporting to CERT-In§10 · p.28Report incidents to CERT-In within 6 hours
AI Governance & Oversight§12 A1 · p.31AI usage policies, approval and audit obligations
Inventory & Visibility of AI Systems§12 A2 · p.31AIBOM, AI API/plugin tracking, shadow-AI detection
Risk Assessment for AI Deployments§12 A3 · p.32Pre-deployment data, integration, dependency risk review
Secure Use of Public AI Platforms§12 A4 · p.32Restrict sensitive uploads, acceptable-use policy
AI System Security Controls§12 A5 · p.32AI access control, secure APIs, audit logs
Prompt Injection & Input Manipulation§12 A6 · p.32Input sanitisation, restricted permissions, adversarial testing
Data Protection & Privacy in AI§12 A7 · p.32Classify data, retention/deletion, monitor AI data flow
Third-Party AI Provider & Supply-Chain Risk§12 A8 · p.33Provider posture, contracts, contingency mechanisms
AI System Monitoring & Logging§12 A9 · p.33Monitor model access, correlate AI telemetry
Human Oversight & Decision Governance§12 A10 · p.33Validate AI outputs, restrict autonomous critical actions
AI in Software Development & DevSecOps§12 A11 · p.33Review AI code, SAST/DAST/SCA, secure CI/CD
AI Model Integrity & Trustworthiness§12 A12 · p.34Validate provenance, version control, inference validation
AI Usage Awareness & Workforce Preparedness§12 A13 · p.34Phishing/deepfake awareness, secure-AI training
Governance of Autonomous & Agentic AI§12 A14 · p.34Operational boundaries, monitoring, emergency shutdown
Continuous Review & Adaptive Governance§12 A15 · p.34Reassess AI risks, update governance regularly
AI Security Assessment & Assurance§12 A16 · p.35Classical + AI/ML vuln testing, red teaming
Implementation Roadmap (3 phases)§13 · p.35-370-7d risk reduction, 8-30d strengthening, 31-60d resilience

See it mapped to your own estate

Our advisory team walks the blueprint with you, scopes the controls that apply, and shows the exact evidence for each. Book a slot below or reach out directly.

Read the blueprint on CERT-In.org.in
FAQ

Blueprint
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • The Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation (Version 1.0, 25.05.2026) is a defensive framework rather than a standalone regulation. However, it ties into CERT-In's existing directions, including the mandatory 6-hour cyber-incident reporting requirement (§10, p.28). Treat its 12 principles and controls as the expected baseline for regulated and critical-infrastructure entities in India.
  • The §9 risk-based timelines table (p.26) sets indicative expectations: known exploited vulnerabilities on internet-facing or crown-jewel systems within 12 hours; critical externally exposed within 1 day; known-exploited internal within 1 day; critical internal high-value within 3 days; high-severity within 5 days. Where no patch exists, apply isolation, WAF/API protection, or feature disablement until remediation is available.
  • Follow the §13 roadmap (p.35-37): Phase I (0-7 days) covers governance, asset identification, MFA, vulnerability assessment, and logging; Phase II (8-30 days) strengthens SOC, exposure management, and AI governance; Phase III (31-60 days) adds red teaming, control validation, and adversarial AI testing. Map each of the 12 §5 principles and §7 controls to existing tooling, then close gaps.
  • §7 Control 9 (p.19) and the 16 AI-governance areas in §12 (p.31-35) require an AI asset inventory (AIBOM), access controls, prompt-injection protection, input sanitisation, model provenance and integrity validation, AI activity logging, human oversight for critical actions, and adversarial AI testing. Shadow or unauthorised AI usage must also be identified and governed (§12 Area 2, p.31).
  • Yes. §7 Control 1 (p.17) requires dependency tracking and adherence to CERT-In's Technical Guidelines on SBOM, QBOM, CBOM, AIBOM and HBOM v2.0. Supply-chain trust (§5 Principle 10, p.12) and §11 Area 5 (p.29) call for SBOM/xBOM and software provenance validation. Tools that generate CycloneDX SBOM, CBOM, QBOM, AIBOM and HBOM, like O3's xBOM suite, support this directly.
  • §9 Control 2 (p.25) requires risk-based prioritisation using Known Exploited Vulnerabilities (KEV) lists and the Exploit Prediction Scoring System (EPSS) for exploit-likelihood, combined with exploitability analysis and business-criticality assessment. Pairing KEV/EPSS scoring with function-level reachability, as O3 Security does, helps focus remediation on vulnerabilities that are both exploitable and reachable in the codebase.
  • §5 Principle 5 (p.12) requires embedding security into systems, applications, and AI workflows from inception via threat modelling, secure coding, CI/CD security testing, and hardened configurations. §7 Control 6 (p.18) extends this to application and API security with SAST, DAST, SCA, secrets management, and penetration testing aligned to CERT-In's Secure Application Design guidelines.
  • Yes. §5 Principle 10 (p.12), §11 Area 5 (p.29), and §12 Area 8 (p.33) require vendor security assessments, dependency review, software provenance validation, and contingency mechanisms for critical AI providers. Detecting malicious or typosquatted dependencies and reading SLSA/cosign provenance off container images, as O3 does, helps satisfy the verifiability expectations across these sections.

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.