Cyberattacks in India doubled from 1.4 million in FY2022 to 2.9 million in FY2026. The acceleration is not random: AI is reshaping the threat landscape asymmetrically. Attackers are using AI to discover vulnerabilities faster, generate exploits automatically, and evade detection systems at speeds that outpace human-operated defenses. India's Digital Threat Report 2025-26 identifies "AI Asymmetry" as the primary emerging cyber risk — AI-enabled attackers evolving faster than defensive and regulatory mechanisms.
CERT-In's Blueprint response to this asymmetry is operational, not theoretical. The 12-hour patch mandate is a direct acknowledgment that AI-assisted exploitation compresses the window between vulnerability disclosure and exploitation. A vulnerability that once took attackers days to weaponize now takes hours with AI-assisted exploit generation. The Blueprint restructures India's vulnerability remediation expectations around this new reality.
For India's banking sector — the most targeted industry for cyberattacks — the Blueprint creates governance obligations that sit at the intersection of cybersecurity and AI governance. Punjab National Bank's allocation of ₹7-8 billion to cybersecurity for FY27 reflects the scale of investment required. Governance infrastructure, not just technology investment, determines whether that investment translates into compliance and resilience.
CERT-In Remediation Timelines: What Banks Must Build
Known exploited vulnerabilities. Bank scope: customer-facing AI APIs, fraud detection endpoints, KYC AI systems, any AI accessible via external APIs or internet-facing infrastructure.
Not yet exploited but critical severity. External-facing AI model serving infrastructure, ML inference APIs, AI-integrated banking apps facing external networks.
Known exploited vulnerabilities on internal systems. Credit risk AI, regulatory reporting AI, AML transaction monitoring AI, internal analytics and decision models on bank networks.
AI models cannot be patched like traditional software. Patching an AI model may require retraining on cleaned data, revalidation against performance benchmarks, and staged production redeployment — a process that typically takes days or weeks under current practices. Banks that have not built emergency AI model rollback protocols, isolation procedures, and expedited revalidation paths will find CERT-In's 12-hour timeline operationally impossible for AI systems. This is not a compliance gap; it is an architectural gap requiring governance-level remediation.
Nine Core Defensive Principles: AI-Specific Requirements
Assume-Breach Operational Posture
Banks must operate assuming AI systems may already be compromised. Assume-breach for AI means: monitoring AI model outputs for behavioral anomalies consistent with model poisoning or backdoor activation; treating unexplained AI performance improvements with the same suspicion as unexplained performance degradation; and maintaining AI forensic replay capability so model behavior at any past point can be reconstructed for investigation.
Zero Trust with Continuous Verification
No implicit trust for AI inference requests or AI model outputs. Zero trust for AI means: every API call to an AI inference endpoint must be authenticated and authorized, regardless of internal network origin; AI model outputs must be verified before being used in downstream decisions (output validation, not just input validation); and AI-to-AI communication in multi-model pipelines must be authenticated at each hop, not trusted implicitly because it is internal.
Defense-in-Depth for AI Workflows
Layered controls at every stage of the AI lifecycle: input validation (prompt injection defense, data poisoning detection); inference monitoring (real-time output monitoring for anomalies, hallucination detection); output controls (AI output verification before downstream use); and access controls (least-privilege access to AI model weights, training data, and inference infrastructure). A single-layer AI security architecture — input filtering only, or output filtering only — fails defense-in-depth.
Continuous Exposure Management
Continuous vulnerability scanning of AI systems: model serving infrastructure (TensorFlow Serving, TorchServe, Triton Inference Server), AI model APIs, AI integrated application layers, and AI-adjacent data pipelines. Static annual vulnerability assessments are explicitly inadequate for AI systems in a threat environment where AI-assisted exploitation compresses exploitation timelines. Banks must move to continuous exposure management for their AI attack surface.
Secure-by-Design AI Integration
Security requirements built into AI system design rather than added after deployment. For banks: AI security requirements documented at the design stage of every new AI deployment; security architecture review mandatory before AI goes to production; threat modeling for AI-specific threats (prompt injection, model inversion, membership inference, adversarial examples) performed before deployment, not discovered post-incident.
xBOM for AI Supply Chain (AIBOM)
AI Bill of Materials: complete catalog of AI model provenance, training data sources, third-party frameworks (PyTorch, TensorFlow, ONNX, Hugging Face), hardware dependencies, and downstream AI dependencies. xBOM enables rapid impact assessment when a vulnerability is discovered in an AI component: instantly identify every AI system affected and prioritize remediation against CERT-In timelines. Intersects with RBI MRMF model inventory — AIBOM is a superset of MRMF's model inventory requirement.
Data Lifecycle Protection
Protection of training data, inference data, and model outputs across the full data lifecycle. For banks: training data used for credit scoring AI, fraud detection AI, and AML AI is sensitive financial data — its compromise during model training creates both security risk (poisoned model) and privacy risk (data exposure). Inference data (customer transaction data sent to AI inference endpoints) must be protected in transit and at rest, with same security standards as the underlying transaction data.
Formal AI Governance Mechanisms
CERT-In explicitly lists formal AI governance as a core defensive principle alongside technical security controls. This is significant: AI governance is not merely a regulatory compliance obligation under RBI MRMF — it is a cybersecurity control under CERT-In's Blueprint. A bank with strong AI governance (model inventory, validation, monitoring, explainability documentation) has a smaller AI attack surface than one without, because governed AI is better understood, better monitored, and faster to detect when compromised.
Mandatory Adversarial Testing
Regular adversarial testing of AI systems against AI-specific attack patterns: prompt injection (for LLM-based AI); model inversion (extracting training data from model outputs); membership inference (determining whether specific data was in the training set); adversarial examples (inputs engineered to fool the AI while appearing normal); and model poisoning detection (testing whether AI behavior has been modified by backdoor attacks). For banks, adversarial testing of credit AI, fraud AI, and customer-facing AI chatbots must be scheduled and documented. Results feed into RBI MRMF's model validation evidence requirements.
Where CERT-In AI Cybersecurity and RBI AI Governance Converge
CERT-In's Blueprint and RBI's MRMF are the two primary regulatory frameworks governing AI in Indian banking — and they are now explicitly convergent. CERT-In's ninth principle (formal AI governance) references the same AI governance constructs that RBI MRMF requires. Banks that build comprehensive AI governance under MRMF are simultaneously building CERT-In compliance — the governance layer is the same; only the regulatory authority differs.
- Model inventory — MRMF + xBOM: RBI MRMF requires every AI/ML model to be catalogued in a model inventory. CERT-In xBOM (AIBOM) requires the same inventory with additional supply chain depth (training data provenance, framework dependencies, hardware stack). A single comprehensive AIBOM satisfies both requirements simultaneously. Banks that maintain an AIBOM for CERT-In compliance get RBI MRMF model inventory compliance as a byproduct.
- Adversarial testing — MRMF validation + CERT-In testing mandate: RBI MRMF requires independent validation of AI models with documented test results. CERT-In's Blueprint requires adversarial testing of AI systems against AI-specific attacks. For customer-facing AI and fraud detection AI, adversarial testing results are both: MRMF validation evidence (demonstrating the model performs adequately under adversarial conditions) and CERT-In compliance evidence (demonstrating the bank has conducted required adversarial testing). The same testing program satisfies both requirements with appropriate documentation.
- Human oversight — MRMF kill switch + CERT-In assume-breach: RBI MRMF requires human override and kill-switch mechanisms for consequential AI. CERT-In's assume-breach posture requires that AI systems can be isolated and shut down when compromise is suspected. The MRMF kill switch is also the CERT-In isolation mechanism: a bank that can quickly disable a malfunctioning AI model (MRMF requirement) can also quickly isolate a potentially compromised AI model (CERT-In requirement). These are the same capability — designed once, meeting both standards.
- Incident reporting — CERT-In 6-hour window + MRMF incident management: CERT-In requires cybersecurity incident reporting within 6 hours. RBI MRMF requires AI incident documentation and remediation. An AI model compromise event is simultaneously a cybersecurity incident (CERT-In reporting) and an AI model failure event (MRMF incident management). Banks must have dual-channel reporting workflows: CERT-In notification within 6 hours of detection, plus MRMF-required documentation and risk committee escalation. Delayed CERT-In reporting is a separate compliance violation from inadequate MRMF incident management.