How banks can modernize their security infrastructure with Zero Trust

On June 30, 2025, the Reserve Bank of India in its Financial Security Report urged financial organizations to adopt the Zero Trust framework and an AI-aware cybersecurity approach towards combating financial cyberattacks. As a precursor to this report, on May 8, the Indian Finance Ministry issued an alert to banks and non-banking financial companies of impending cyberattacks that aimed to destabilize Indian financial infrastructure.

Besides India, the United Kingdom's Digital Operational Resilience Act (DORA), which came into effect in January 2025, also directed bank organizations to incorporate Zero Trust into their security defenses. These directives are coming during a time when cyberattacks are rapidly achieving progress in terms of sophistication and scale, thanks to the proliferation of generative AI tools.

Being a highly critical component of a nation's financial infrastructure and in a sector that contains sensitive information, right from PII and Social Security numbers to transaction details, it is a matter of national concern for banking institutions to protect themselves as best they can against data breaches and cyberattacks.

What is Zero Trust, and why is it important for the BFSI sector?

Introduced by John Kindervag, the Zero Trust security framework adopts a "never trust, always verify" approach to every user action taking place in an organizational network. These actions may range from a user attempting to access a folder to a privileged user changing group permissions. A Zero Trust program aims to eliminate the idea of implicit trust given to employees and adopts the following security fundamentals to secure assets:

• Continuous verification: Before performing a critical action, the user's identity will be confirmed using multi-factor authentication (MFA).
• Microsegmentation: The assets stored within the network will be classified and segmented based on their sensitivity. By isolating workloads based on their vulnerability to risk, microsegmentation makes breach containment effective for administrative and security teams.
• Continuous monitoring: User activity is tracked and audited in a Zero Trust environment to ensure that anomalous behavior is promptly recorded and notified.

At the back end of Zero Trust's operations are three components: policy engine, policy administrator, and policy enforcement point.

Policy engine

The policy engine is the decision-making component of a Zero Trust architecture. It evaluates every access request against defined policies and risk factors to decide whether to grant, deny, or challenge the request.

Key functions of the policy engine:

• Risk evaluation: Considers multiple parameters such as user identity, device posture, geolocation, time of access, behavioral patterns, and data sensitivity.
• Policy application: Uses organizational security policies, regulatory requirements, and risk scores to make real-time access decisions.
• Integration with threat intelligence: Centrally evaluates data from multiple sources, such as SIEM, UEBA, and threat feeds, to assess if the access request poses any known or suspected risk.
• Dynamic decision-making: Continuously re-evaluates access during a session, enforcing adaptive authentication or revoking access if the risk context changes.

Policy administrator

The policy administrator acts as the execution arm of the policy engine. Once the policy engine decides on an access request, the policy administrator communicates this decision to the enforcement mechanism, issuing commands to allow or terminate the session.

Key functions of the policy administrator:

• Command execution: Converts policy decisions into actionable commands for the policy enforcement point (e.g., granting a secure tunnel, applying microsegmentation, or terminating access).
• Session setup and teardown: Establishes secure sessions (like encrypted tunnels or token-based access) when access is granted and tears them down upon session expiry or policy violations.
• Logging and auditing: Maintains a record of every decision executed for compliance, audits, and incident response.
• Coordination with identity systems: Ensures that identity governance tools, IAM solutions, and privilege policies are enforced consistently across endpoints.

Policy enforcement point

The policy enforcement point is where the access control decision is actually enforced on the endpoint. It sits in the data path between the user and the resource, ensuring that only authorized, authenticated, and continuously verified traffic reaches sensitive applications or data.

Key functions of the policy enforcement point:

• Traffic interception: Monitors and controls all requests to protected resources, acting as a gatekeeper.
• Access enforcement: Applies the allow, deny, or challenge decision received from the policy administrator.
• Continuous verification: Revalidates user and device posture during the session, terminating access if anomalies or policy violations are detected.
• Microsegmentation enforcement: Ensures the user or device only communicates with resources permitted by their role and policy, reducing lateral movement.

Together, these components ensure adaptive, risk-aware, and continuously enforced access controls—ideal for protecting financial systems where trust can never be assumed.

How to use Zero Trust to secure a bank's IT ecosystem

Much like how it takes layers of security checks for an individual to enter into a bank's vault, Zero Trust ensures that employees undergo multiple checkpoints of authentication, authorization, and monitoring to perform an action, regardless of its sensitivity.

For example, consider a scenario where a bad actor tries to gain unauthorized access into a bank's support portal by impersonating an employee's credentials. Zero Trust thwarts attacks by performing the following steps:

• Identity verification: A login attempt from an unusual country triggers risk-based MFA, asking for biometric verification in addition to a password.
• Policy engine decision: Since the device is unrecognized and the behavior deviates from normal patterns (large transfer volume and non-standard hours), the policy engine flags the attempt as high risk.
• Conditional access enforcement: The policy administrator instructs the system to deny transaction privileges until the identity is reverified by the security team.
• Microsegmentation containment: Even if partial access is granted, the attacker is restricted to low-level data views, preventing access to the payment processing network.
• Real-time alerting: Security operations receive an alert and can investigate or disable the compromised account immediately, preventing fraudulent transfers and minimizing potential loss.

Challenges in implementing Zero Trust in bank ecosystems

Implementing a Zero Trust framework in a banking institution, albeit rewarding, is a complex process. Banks cannot afford downtime or operational disruptions when overhauling their cybersecurity infrastructure. Transitioning from traditional perimeter-based defenses to Zero Trust introduces technical, organizational, and regulatory challenges that must be carefully addressed.

Incompatibility with legacy infrastructure

A 2023 Deloitte poll on Zero Trust adoption revealed that 44.6% of respondents cited legacy systems as the primary barrier to adopting Zero Trust. Many banks still rely on mainframes, core banking systems, and decades-old applications that lack support for modern authentication standards, granular access controls, or continuous monitoring. These systems often depend on flat network architectures with implicit trust models, making microsegmentation and identity-based access enforcement difficult to implement without breaking critical banking functions.

How to overcome it:

• Conduct a comprehensive asset inventory to identify legacy systems and their security dependencies.
• Deploy Zero Trust gateways or brokers to enforce identity-based controls in front of legacy applications.
• Phase out or modernize unsupported systems through application refactoring or virtualization.
• Use API-based connectors or middleware to bridge legacy apps with modern IAM platforms.

Managing high volumes of identities and access privileges

Banks handle millions of identities—employees, contractors, customers, vendors, and machine identities like APIs and service accounts. Overprovisioned and orphaned accounts are common, increasing the attack surface. Implementing Zero Trust across such a vast identity landscape is challenging, as it requires real-time visibility, strong authentication, and least privilege enforcement across all entities without disrupting services.

How to overcome it:

• Implement a centralized identity governance and administration (IGA) platform to automate provisioning and deprovisioning.
• Enforce risk-based MFA and conditional access policies for all high-value applications.
• Regularly conduct access reviews and certifications to eliminate excessive privileges.
• Use user and entity behavior analytics (UEBA) to detect compromised accounts early.

Balancing security with a seamless customer experience

Banks must protect transactions without degrading the user experience. Introducing Zero Trust measures, such as continuous authentication or strict session monitoring, can add latency, additional login prompts, or blocked access during false positives, potentially frustrating customers and increasing churn.

How to overcome it:

• Use risk-adaptive authentication, challenging only high-risk actions (e.g., unusual location or large transfers).
• Deploy frictionless MFA methods, such as biometrics or device-based authentication.
• Continuously monitor behavioral patterns to minimize unnecessary verification prompts.
• Pilot Zero Trust controls with internal teams and small customer segments before full-scale rollout.

Complex vendor and third-party access management

Banks depend on a wide ecosystem of FinTech partners, consultants, cloud providers, and software vendors. Third-party connections often have high privileges and weak security controls, making them prime targets for attackers. Enforcing Zero Trust for external entities is challenging due to inconsistent identity management practices and limited visibility into their security posture.

How to overcome it:

• Require vendors to adopt federated identity management with strong MFA before granting access.
• Apply just-in-time (JIT) access for third parties, expiring privileges after tasks are completed.
• Segregate vendor access using microsegmentation and network zoning to limit lateral movement.
• Continuously monitor third-party sessions and enforce strict logging and alerting.

Skill gaps and operational complexity

Zero Trust is not a single tool but an architectural shift requiring expertise in IAM, network segmentation, encryption, analytics, and security orchestration. Many banking institutions lack internal expertise or face resource constraints, making it difficult to design, implement, and operate Zero Trust policies without disrupting critical services.

How to overcome it:

• Invest in specialized training for security teams on Zero Trust principles and technologies.
• Partner with experienced system integrators or managed security service providers for implementation.
• Use orchestration platforms that centralize policy creation and enforcement across all environments.
• Start with high-risk assets, adopting a phased approach instead of a full-scale rollout.

Regulatory and compliance considerations

Banks operate under strict regulations (e.g., the PCI DSS, SOX, the PSD2, the GDPR, and the RBI Cybersecurity Framework). While Zero Trust enhances security, it requires major changes to access control models, data flow monitoring, and incident reporting, which can conflict with existing compliance frameworks or legacy audit requirements.

How to overcome it:

• Map Zero Trust controls to existing regulatory requirements to ensure alignment.
• Maintain comprehensive logging and audit trails to meet compliance obligations.
• Engage with regulatory bodies early to validate the Zero Trust implementation roadmap.
• Adopt continuous compliance monitoring tools to ensure ongoing adherence during and after the transition.

Implementing Zero Trust in phases: A step-by-step workflow

Like every major technological transition, Zero Trust must be implemented in a phased manner as opposed to an overnight one. This will help organizations avoid makeshift changes and unwanted disruptions that may potentially affect banking services and cost millions.

Phase 0: Establish your baseline and scope

Begin with a concise, risk‑driven assessment. Inventory users (workforce, third parties, and service accounts), devices, apps, data stores, and network flows. Map crown jewels (e.g., finance and HR systems); current identity providers; and where passwords, keys, and tokens live. Identify quick wins (high risk or low effort) and dependencies (e.g., legacy authorization). Define measurable outcomes: reduction in standing privileges, mean time to revoke access, and policy coverage. This phase produces an architecture blueprint, a prioritized backlog, and a change management plan that aligns Zero Trust with business continuity and compliance obligations.

Phase 1: Build the identity foundation (IGA + life cycle)

Make identity the control plane. Deploy or modernize IGA with centralized policies spanning cloud and on‑premises environments. Standardize joiner-mover-leaver workflows for identity life cycle management: Automatically provision least‑privilege entitlements at hire, adjust on role change, and revoke on exit across all systems—human and non‑human. Normalize roles and attributes using role-based access control (RBAC) and attribute-based access control (ABAC) and eliminate duplicate or orphaned accounts. Integrate HR information or contractor systems as the authoritative source. Success here shrinks the attack surface and makes later phases faster and safer.

Phase 2: Upgrade authentication with adaptive MFA and SSO

Replace password‑centric logins with adaptive MFA and phishing‑resistant factors (e.g., FIDO2, WebAuthn, or platform biometrics). Pair with single sign‑on (SSO) to reduce password sprawl and enforce consistent session policies. Make MFA risk‑aware: Step it up only when context changes (like a new device, atypical geolocation, or high‑value action) to preserve the user experience. Harden recovery flows (no SMS fallback for admins), enforce device posture checks, and protect machine‑to‑machine paths with mutual TLS and workload identities. Track outcomes: MFA coverage, factor assurance levels, and blocked takeover attempts.

Phase 3: Enforce least privilege with JIT access

Reduce standing entitlements. Move admins, developers, and vendors to JIT access with time‑bound elevation and approval workflows. Replace static keys with short‑lived credentials and brokered sessions; rotate secrets automatically. Apply ABAC and RBAC consistently so access decisions reflect the role, the sensitivity of the resource, device health, and transaction context. For non‑human identities (e.g., APIs, bots, or CI/CD pipelines), scope each token to the smallest set of actions and rotate frequently. Measure reductions in always‑on privileges and median elevation duration.

Phase 4: Segment applications and data, not just networks

Assume breach and constrain blast radius. Implement microsegmentation at the policy enforcement point (e.g., identity‑aware proxies, gateways, or SDP or ZTNA) so access is granted per app or dataset—not per subnet. Put sensitive data behind strong policies (like attribute‑based rules or continuous re‑authorization for high‑value actions). Gate east-west traffic with identity and posture checks, and prefer private application access over VPNs. For legacy apps, front them with a broker that adds SSO, MFA, and a per‑request policy before you refactor or retire.

Phase 5: Add continuous monitoring and UBA

Visibility is the feedback loop. Enable continuous monitoring of identity events across sign‑in, elevation, policy decisions, and data access. Use user behavior analytics (UBA) and device analytics to learn normal patterns and flag anomalies like privilege misuse, atypical data pulls, impossible travel, or service accounts acting like humans. Tie detections to automated responses: Prompt adaptive MFA, revoke tokens, quarantine devices, and open cases with evidence attached. Track mean time to detect and respond for identity‑driven incidents and false‑positive rates to tune models.

Phase 6: Build resilience, testing, and governance

Operationalize Zero Trust. Institute periodic access recertifications for high‑risk apps and privileged roles, and enforce break‑glass procedures with audited controls. Run threat‑led exercises (e.g., simulating token theft or OAuth consent abuse) and purple team validations of policy coverage. Ensure backups include an identity state (e.g., directory, policy store, or key vault) and practice restoration with integrity checks to avoid privilege drift after recovery. Establish a governance forum (including security, IT, risk, and audits) to review metrics, exceptions, and roadmap progress each quarter.

Phase 7: Extend Zero Trust to third parties and workloads

Apply the same standards to vendors, contractors, and workloads. Federate identities where possible; otherwise, provision least‑privilege roles with JIT access and strong factors. Require device posture for partner access and isolate their sessions via dedicated enforcement points. For workloads, adopt workload identities and short‑lived tokens; validate service‑to‑service calls with policies based on app identity and environment. Continuously attest third‑party controls and terminate access automatically when contracts end.

Related solutions