Zero Trust Is Now an RBI Mandate.
But Who's Actually Testing It?

On April 14, 2026, the Reserve Bank of India's circular on Technology Risk and Cybersecurity Framework formally came into effect — and buried inside the 47-page document was language that sent every CISO in Indian banking into an emergency board presentation: regulated entities must adopt Zero Trust Architecture principles across their network, identity, and data layers, with documented evidence of validation.

The mandate did not arrive without warning. The groundwork was laid in 2023 via the Master Directions on IT Governance, Risk, Controls, and Assurance Practices. By 2025, the writing was unmistakably on the wall. Still, when the final circular dropped, most Indian banks discovered the same uncomfortable truth: they had been implementing Zero Trust. Almost none of them had been testing it.

What ZTA Means in Practice for Indian Banks

Zero Trust is not a product you buy. It is an architectural philosophy that rejects the old "castle-and-moat" assumption — that once you are inside the network perimeter, you can be trusted. In a Zero Trust model, every request for access is treated as potentially hostile, regardless of whether it originates from inside or outside the network.

For Indian banks operating across branches, data centres, cloud workloads, and thousands of endpoints, ZTA translates into three interlocking imperatives. Identity-first access: every user, service, and device must authenticate continuously. Multi-factor authentication, device posture checks, and short-lived credentials are baseline expectations. Microsegmentation: network segments must be broken into granular zones so a compromise in the ATM network cannot propagate to the core banking system. Continuous authorisation: access rights must be evaluated dynamically at the time of each request based on user context, device health, and behavioural signals.

Implementation vs Validation — The Critical Gap

Across the Indian banking sector, the story is broadly the same: organisations deployed Microsoft Entra ID for identity, rolled out microsegmentation, implemented SIEM dashboards, and ticked the compliance checklist. The architecture diagrams look correct. The policy documents are thorough. The board presentations are reassuring.

But here is what almost none of them did: they did not pay someone to try to break it.

Real-world attackers do not read your architecture diagrams. They probe endpoints, test policy exceptions, exploit trust relationships between systems that your segmentation missed, and abuse legitimate credentials to move laterally inside environments that are theoretically microsegmented. Consider a common failure mode: a bank deploys microsegmentation across its production environment but forgets to apply the same policies to a staging cluster that shares an Active Directory domain. An attacker who compromises a developer's credentials gains access to staging. From staging, they leverage domain trust relationships to move into production. The ZTA was implemented. It just was not tested in a way that would have caught this exact path.

Five ZTA Assumptions That Fail Under Real Attack Conditions

"Our MFA prevents credential abuse." MFA is bypassed via real-time phishing proxies, SIM swapping, and MFA fatigue attacks. Static MFA deployment without anomaly detection on authentication patterns is insufficient against modern adversaries.

"Our microsegmentation blocks lateral movement." Microsegmentation policies are often applied to production environments but miss development, staging, or legacy systems sharing the same Active Directory forest. Attackers find and exploit these gaps reliably.

"Our SIEM would detect an attacker in our network." Most SIEM detections are tuned for signature-based alerts. Slow, low-and-slow lateral movement using legitimate tools — PsExec, WMI, Remote Desktop — generates minimal alerts and often goes undetected for weeks.

"Our service accounts are locked down." Service accounts are the most abused vector in enterprise environments. Overprivileged service accounts with non-expiring passwords and no behavioural monitoring are a direct path to domain compromise in over 60 percent of red team exercises.

"We passed our audit, so we are secure." Compliance is a point-in-time attestation. Security is a continuous adversarial condition. Passing a checklist-based audit tells you your documentation is correct. It tells you nothing about whether your controls hold under real attack pressure.

How Arxiis Tests ZTA Environments

Arxiis by Vryxa is built specifically for the Indian BFSI context. Our autonomous red team platform simulates the full attack lifecycle inside your environment — from initial access through to lateral movement and domain-level compromise — continuously and at scale.

For Zero Trust validation, the platform executes three categories of adversarial testing that standard penetration testing and compliance audits do not cover: ZTA Policy Gap Analysis that maps your documented Zero Trust policies against the actual enforced controls in your identity provider, network segmentation layer, and endpoint management platform; Continuous Lateral Movement Simulation that attempts privilege escalation and maps trust relationships continuously, not as a one-time annual exercise; and RBI-Aligned Reporting that maps every finding to the relevant RBI Technology Risk Framework clause, giving your CISO and board a direct line between red team output and regulatory obligation.

The question is not whether your bank has Zero Trust. Every bank does now, at least on paper. The question is whether it holds. That is a different question, and it requires a different kind of answer — one that only comes from adversarial testing.