The Financial Sector Under Siege: Why ZTNA Is No Longer Optional

The financial services sector is the most attacked industry on earth – and the gap is widening. Cyber incidents targeting financial institutions more than doubled between 2024 and 2025, surging from 864 to 1,858 reported events, representing approximately 18–19% of all cyberattacks worldwide. In the United States alone, data compromises in financial services jumped from 138 in 2020 to 744 in 2023 – a 439% increase in three years.

The financial damage is equally severe. The average cost of a data breach in the financial sector reached $6.08 million in 2024 – 22% higher than the global cross-industry average of $4.88 million. Financial institutions take an average of 258 days to identify and contain a breach. And the downstream impact extends far beyond direct costs: 38% of customers say they would switch financial institutions after a breach, and stock prices of affected companies drop an average of 7.5% following disclosure.

Ransomware has hit record levels. The financial services industry experienced a 65% ransomware attack rate in 2024 – the highest since tracking began. Nearly two out of three finance companies were attacked. In 49% of those attacks, data was successfully encrypted before the organization could respond. Financial services also accounts for 27.7% of all phishing attempts globally, making it the single most phished industry.

Against this threat landscape, the traditional VPN-based access model is not just inadequate – it is actively dangerous. VPNs grant broad network access after a single authentication, create discoverable attack surfaces, and provide no protection against lateral movement once an attacker is inside. Zero Trust Network Access (ZTNA) addresses every one of these failures. But not all ZTNA solutions meet the specific demands of banking and financial services – where regulatory scrutiny, third-party complexity, legacy system dependencies, and nation-state threat actors create requirements that standard enterprise ZTNA cannot satisfy.

This guide provides a practical evaluation framework for financial services CISOs selecting ZTNA – covering regulatory mapping, architectural requirements, vendor assessment, and deployment strategy.

The Regulatory Pressure Driving ZTNA Adoption in Financial Services

Financial services operates under the most complex regulatory environment of any industry. Every major financial regulator now explicitly or implicitly requires Zero Trust principles. Understanding how ZTNA maps to these requirements is the foundation of any compliant deployment.

DORA – Digital Operational Resilience Act (EU)

DORA became enforceable on January 17, 2025, and applies to all EU financial entities: banks, insurers, investment firms, payment providers, and crypto-asset service providers. DORA requires a comprehensive ICT risk management framework with continuous assessment, major ICT incident classification and reporting within hours, regular digital operational resilience testing including penetration testing, continuous oversight of third-party ICT providers with documented risk assessments, and a register of all contractual arrangements with ICT service providers.

Non-compliance penalties reach up to 2% of global annual turnover for financial entities and up to €5 million for critical ICT providers.

ZTNA directly addresses DORA requirements by providing continuous access verification (ICT risk management), granular audit trails for every session (incident classification and reporting), access controls that can be tested against defined policies (resilience testing), and documented, policy-based controls over third-party access (third-party risk management). Critically, the ZTNA vendor itself is an ICT third-party provider subject to DORA oversight – meaning the ZTNA contract must include DORA-compliant provisions for incident reporting, audit rights, and exit planning.

PCI DSS 4.0.1

All PCI DSS 4.0.1 requirements became mandatory on March 31, 2025. The standard significantly tightened access control requirements relevant to ZTNA: Requirement 7 mandates restricting access to cardholder data by business need to know, Requirement 8 mandates identifying and authenticating all access to system components with phishing-resistant MFA, and Requirement 10 mandates logging and monitoring all access to network resources and cardholder data.

ZTNA enforces these requirements natively through per-application access policies (Req. 7), integrated MFA with device posture verification (Req. 8), and comprehensive session audit logs (Req. 10).

NYDFS Part 500 (23 NYCRR Part 500)

The Second Amendment to the NYDFS Cybersecurity Regulation entered full enforcement through 2025. As of 2026, all requirements are active and NYDFS has moved to enforcement mode. Key provisions include universal multi-factor authentication for all systems, access privilege management based on least-privilege principles, comprehensive audit trails for all users, and formal oversight of third-party service providers.

Part 500 applies to any firm operating under New York banking, insurance, or financial services law – which encompasses most financial services firms operating in the United States.

Additional Frameworks

Framework	Key Access Requirements	How ZTNA Addresses
GLBA / Reg S-P	Safeguard customer financial information	Identity-based access, encryption, session monitoring
SOX Section 404	Internal controls over financial reporting	Segregation of duties, approval workflows, privilege management
FFIEC Guidance	Risk-based access, continuous monitoring, third-party risk	Risk-scored policies, continuous validation, vendor audit trails
MAS TRM (Singapore)	Access controls for critical systems, data sovereignty	On-premises deployment, granular access, comprehensive audit
RBI Guidelines (India)	Zero Trust adoption, continuous verification	Continuous authentication, identity-based segmentation
FCA (UK)	Operational resilience, third-party oversight	Session recording, vendor access governance, resilience testing

Eight Requirements That Make Banking ZTNA Different

Standard enterprise ZTNA evaluation criteria are insufficient for financial services. The following eight requirements address the specific constraints that banking environments impose.

1. Examiner-Grade Audit Trails

General ZTNA provides access logs. Banking ZTNA must provide audit trails deep enough to satisfy direct examiner scrutiny from OCC, FDIC, FFIEC, NYDFS, ECB, BaFin, MAS, and RBI. This means logging every access request – granted and denied – with user identity, device posture at time of access, application accessed, specific actions performed within the session, session duration, and the policy that authorized or denied the request. Audit data must be immutable, exportable, and retainable for five to seven years.

The critical question: does the ZTNA solution generate complete, self-contained audit records per session natively, or does it require SIEM integration to assemble complete records from partial logs? Native completeness reduces compliance team workload and audit gap risk.

2. Third-Party and Vendor Access Governance

Banks depend on extensive vendor ecosystems – core banking providers, payment processors, ATM operators, compliance vendors, auditors, and outsourced development teams. Each vendor relationship is an access pathway that must be individually controlled, monitored, and auditable.

The risk is not theoretical. The 2024 Bank of America breach occurred through a third-party SaaS provider (Infosys McCamish Systems), exposing data of 57,000 customers. The bank was not notified for three weeks. Santander and DBS Bank suffered major breaches in 2024–2025 through supply chain attacks where their own systems were never directly compromised.

Banking ZTNA must support agentless access for vendors who cannot install software, time-bounded sessions that automatically expire, per-vendor policies scoped to specific applications, session recording for all vendor sessions, and automatic access revocation synchronized with contract lifecycle.

3. Integrated Microsegmentation

Banking infrastructure is inherently tiered: customer-facing channels (web, mobile, ATM), middleware (API gateways, payment switches), core banking (account processing, ledger, transaction engines), and data stores (customer databases, transaction logs). A breach in the customer-facing tier must not propagate to core banking.

ZTNA controls north-south traffic – who reaches which application. Microsegmentation controls east-west traffic – how applications communicate with each other. For banking environments, both are essential. A ZTNA solution that secures user access to a payment application but does not prevent that application from being exploited to reach the core banking database leaves the most critical gap unaddressed.

Evaluate whether the ZTNA vendor offers integrated microsegmentation on the same platform or requires a separate product. Separate products create integration complexity and policy drift between the two control planes.

4. On-Premises and Hybrid Deployment

Core banking platforms, payment switches, and transaction engines typically run on premises in private data centers. Regulatory requirements in multiple jurisdictions – MAS TRM, RBI directives, NYDFS, national data sovereignty laws – restrict where financial data can be processed and stored.

A ZTNA solution that operates exclusively as a cloud service routes all access traffic through the vendor’s cloud infrastructure. For banks subject to data sovereignty requirements, this may be disqualifying – particularly when the ZTNA broker decrypts and re-encrypts session traffic, meaning unencrypted data temporarily resides in the vendor’s environment.

Financial services CISOs should evaluate whether the ZTNA solution can be deployed entirely on premises – within the bank’s own infrastructure – without dependency on external cloud services.

5. Network Invisibility and Attack Surface Elimination

Banks are permanent, high-value targets for nation-state actors, organized crime, and hacktivists. Any internet-exposed service is a target for vulnerability scanning, DDoS, and zero-day exploitation.

Standard ZTNA achieves partial invisibility – applications hide behind a broker, but the broker and connector endpoints are reachable. Reverse-access architecture goes further: the application-side components initiate outbound-only connections, the firewall stays in permanent deny-all for inbound traffic, and there are no listening services, open ports, or discoverable IP addresses. The infrastructure is invisible – there is nothing to scan, exploit, or DDoS.

For banks where the threat model includes nation-state reconnaissance, this architectural distinction is not an incremental improvement – it is a category change in security posture.

6. Legacy Protocol Support

Banking environments depend on protocols that many ZTNA solutions do not support. Core banking via thick clients uses proprietary protocols. Payment system integration uses SFTP and MFT. Internal file sharing runs on SMB. Mainframe access uses TN3270. Analytics platforms use native database protocols.

A ZTNA solution that supports only HTTP/S-based web applications covers a fraction of the banking portfolio. Everything else falls back to VPN, perpetuating the attack surface ZTNA was intended to eliminate.

7. Privileged Access to Core Banking Systems

DBAs, core platform engineers, payment switch operators, and IT auditors require privileged access to the most sensitive systems. Banking ZTNA should integrate with or provide privileged access management: just-in-time access provisioning (no standing admin privileges), session recording with keystroke logging, credential vaulting with automatic rotation, and approval workflows for elevated access.

8. DDoS Resilience

Financial institutions face DDoS at disproportionate rates – finance and telecom account for a combined 60% of all DDoS targets. In 2025, attack volumes reached 31.4 Tbps globally. DDoS against banks is frequently a smokescreen masking concurrent intrusion attempts.

Cloud-native ZTNA platforms inherit DDoS protection from their global edge networks. On-premises ZTNA with reverse-access architecture approaches resilience differently – with no externally reachable endpoint, there is nothing to target. Evaluate DDoS resilience at every access path in the deployment.

How Leading ZTNA Vendors Address Banking Requirements

Cloud-Native SSE Platforms (Zscaler, Palo Alto Prisma, Cloudflare, Netskope)

These vendors deliver ZTNA as part of broader Security Service Edge platforms with extensive global PoP networks. They excel at securing cloud-hosted applications for distributed workforces and consolidating security functions (SWG, CASB, DLP, ZTNA) under one vendor.

Where they fit in banking: Securing SaaS and cloud applications for remote employees. CASB and DLP capabilities control data movement. Zscaler and Palo Alto offer the strongest application segmentation among cloud-native vendors. Netskope provides the strongest DLP integration for data-centric compliance.

Where they fall short: None offer fully on-premises deployment – all route traffic through vendor cloud infrastructure, raising data sovereignty concerns for banks under MAS, RBI, or strict NYDFS interpretation. Microsegmentation is unavailable or requires a separate product. Integrated PAM is not available – privileged banking access requires a third-party solution. SMB and legacy protocol support varies; Cloudflare’s non-web support is the least mature.

Fortinet Universal ZTNA

Fortinet delivers ZTNA through existing FortiGate appliances with zero additional licensing.

Where it fits: On-premises deployment via FortiGate. Full protocol support. Smooth VPN migration for Fortinet-standardized banks. Lowest-cost activation for existing Fortinet shops.

Where it falls short: Microsegmentation requires separate FortiGate policies – not integrated into ZTNA. Cloud-native capabilities less mature. Vendor ecosystem lock-in limits flexibility.

TerraZone truePass

TerraZone delivers ZTNA through a unified Zero Trust platform that natively integrates secure application access, microsegmentation, identity isolation, privileged access management, and secure data exchange.

Where it fits in banking: Patented reverse-access architecture provides zero inbound exposure – the firewall remains in permanent deny-all, with no open ports or discoverable infrastructure. This eliminates the attack surface that nation-state and organized crime groups exploit for banking reconnaissance. Full on-premises, cloud, and hybrid deployment supports banks with data sovereignty constraints. Integrated microsegmentation enforces east-west traffic controls between banking application tiers from the same platform – no separate product, no policy gaps. Built-in PAM capabilities address privileged access to core banking systems. Full protocol support including HTTP/S, RDP, SSH, SFTP, and SMB via the Heimdall protocol (which adds identity-based segmentation controls to file sharing natively). AES-256 encryption with comprehensive audit trails mapped to DORA, PCI DSS, NYDFS, and GLBA.

Where it falls short: Smaller global PoP footprint than Zscaler, Cloudflare, or Palo Alto – banks with 50,000+ globally distributed users should validate latency. No native CASB or secure web gateway – banks needing full SSE consolidation must pair TerraZone with a SWG/CASB solution. Less brand recognition than major SASE vendors, which may require additional internal justification. Pricing requires direct engagement.

Appgate SDP

Appgate delivers software-defined perimeter access with dynamic trust models for regulated industries.

Where it fits: Strong compliance audit capabilities. Dynamic risk-based policies. Built-in microsegmentation. On-premises deployment. Established in regulated financial services.

Where it falls short: Smaller market presence. Agentless options more limited. Implementation requires dedicated security engineering. Steeper policy design learning curve.

Banking ZTNA Capability Matrix

Banking Requirement	Zscaler ZPA	Palo Alto Prisma	Cloudflare	Netskope	Fortinet	TerraZone truePass	Appgate SDP
Examiner-grade audit trail	SIEM-dependent	SIEM-dependent	SIEM-dependent	SIEM-dependent	FortiAnalyzer	Native	Native
Agentless vendor access	Yes	Yes	Yes	Yes	Yes	Yes	Limited
Integrated microsegmentation	No	No	No	No	No	Yes	Yes
Full on-premises deployment	No	No	No	No	Yes	Yes	Yes
SMB/legacy protocols	Limited	Yes	Limited	Limited	Yes	Yes (Heimdall)	Yes
Zero inbound ports	Partial (inside-out)	No	No	No	No	Yes (patented)	Yes (SDP)
Integrated PAM	No	No	No	No	Add-on	Yes	No
DDoS resilience	Cloud edge (strong)	Cloud edge (strong)	Cloud edge (strongest)	Cloud edge	On-prem dependent	No target exists	On-prem dependent
CASB/SWG/DLP bundling	Yes	Yes	Yes	Yes	Yes	No	No

Decision Framework for Banking CISOs

If your bank is cloud-first with predominantly SaaS applications and your priority is SASE consolidation, evaluate Zscaler, Palo Alto Prisma, or Netskope. These platforms bundle ZTNA with SWG, CASB, and DLP for unified cloud-delivered security.

If your bank runs on Fortinet infrastructure and needs the fastest, lowest-cost ZTNA activation, Fortinet Universal ZTNA is built into your existing FortiGate appliances at no additional cost.

If your bank operates core systems on premises with data sovereignty constraints, evaluate solutions with full on-premises deployment: TerraZone truePass, Fortinet, or Appgate SDP. Cloud-only ZTNA vendors cannot meet data residency requirements in multiple jurisdictions.

If eliminating the internet-facing attack surface is the top priority – particularly for banks facing nation-state or organized crime reconnaissance – TerraZone’s patented reverse-access architecture provides zero inbound exposure. No ports, no services, no discoverable infrastructure.

If you need unified ZTNA + microsegmentation to protect banking application tiers without integrating separate products, TerraZone truePass or Appgate SDP provide both natively.

If data protection and DLP drive the security strategy, Netskope Private Access offers the strongest DLP integration among ZTNA vendors.

If the primary need is third-party access governance with strong vendor lifecycle management, evaluate all vendors’ agentless access, session recording, and time-bounded access capabilities – these differentiate more than ZTNA architecture for this use case.

Deployment Roadmap for Banking ZTNA

Phase 1: Start with Third-Party Access (Weeks 1–6)

The fastest ZTNA value in banking comes from replacing VPN-based vendor access. Third-party access is the highest-risk, most audited, and most compliance-relevant access pathway – and has the smallest user population for a controlled pilot.

Deploy ZTNA for 50–100 vendor users accessing a defined application set. Validate audit trail completeness against your most recent regulatory examination findings. Verify session recording and time-bounded access policies. Use pilot results to build the internal business case.

Phase 2: Extend to Remote Employee Access (Weeks 7–14)

Expand ZTNA to remote employees accessing customer-facing applications and internal tools. Run in parallel with VPN – allow fallback while ZTNA coverage expands. Begin migrating application-by-application, starting with the highest-risk systems.

Phase 3: Deploy Microsegmentation for Core Banking (Weeks 15–24)

Implement east-west controls between banking application tiers. Isolate customer-facing systems from middleware, middleware from core banking, and core banking from data stores. If the ZTNA vendor provides integrated microsegmentation, deploy from the same policy framework. If not, deploy a parallel microsegmentation solution and ensure policy consistency.

Phase 4: Implement PAM for Privileged Banking Access (Weeks 25–32)

Deploy just-in-time privileged access for database administrators, core banking engineers, and payment switch operators. Enable session recording for all privileged sessions. Implement credential rotation. If the ZTNA platform includes PAM natively, configure from the existing policy engine. If not, integrate with CyberArk or BeyondTrust.

Phase 5: Decommission VPN and Validate (Weeks 33–40)

Narrow VPN access to maintenance-only use cases. Conduct penetration testing specifically targeting ZTNA bypass scenarios. Validate compliance posture against DORA, PCI DSS, NYDFS, and applicable framework requirements. Document the ZTNA architecture for regulatory examination readiness.

Phase 6: Continuous Operations (Ongoing)

Conduct quarterly access reviews to identify privilege drift. Run annual ZTNA-focused penetration tests. Update vendor access policies as contracts change. Re-evaluate ZTNA vendor capabilities against evolving regulatory requirements – particularly as DORA enforcement matures and NYDFS issues new guidance.

Common Mistakes in Banking ZTNA Deployments

Deploying ZTNA without microsegmentation. ZTNA controls who reaches the application. Without east-west controls, a compromised session can pivot laterally across the same network segment. In banking, this means a breach in customer-facing systems can cascade to core banking – exactly the scenario ZTNA was supposed to prevent.

Covering only web applications. If ZTNA handles web apps but forces VPN fallback for RDP, SSH, or SMB, the bank operates two parallel access systems. Management overhead doubles, and the VPN attack surface remains intact.

Ignoring the ZTNA vendor as a DORA third-party provider. For EU-regulated banks, the ZTNA vendor is itself an ICT third-party subject to DORA oversight. Contracts must include incident reporting, audit rights, subcontracting transparency, and exit provisions. On-premises deployment may reduce this regulatory burden.

Underestimating data sovereignty implications. Cloud-only ZTNA decrypts traffic in the vendor’s infrastructure. Confirm where session data is processed and stored before signing – a jurisdiction mismatch may disqualify the vendor under MAS TRM, RBI guidelines, or NYDFS interpretation.

Selecting based on analyst rankings instead of architectural fit. The largest ZTNA vendors optimize for cloud-first SASE consolidation. Banks with on-premises core systems, legacy protocols, and data sovereignty requirements may find that the highest-ranked vendors cannot meet their most critical needs.

Conclusion

Selecting the best ZTNA solution for banking and financial services is not the same exercise as selecting ZTNA for a general enterprise. The $6.08 million average breach cost, 65% ransomware attack rate, DORA enforcement, PCI DSS 4.0.1 mandates, and NYDFS full-enforcement mode create a regulatory and threat environment that demands capabilities most cloud-first ZTNA platforms were not designed to deliver.

Cloud-native SSE platforms provide strong ZTNA for cloud-hosted banking applications and distributed workforces – and their CASB and DLP capabilities address important data protection requirements. However, banks with on-premises core systems, data sovereignty constraints, or requirements for integrated microsegmentation and privileged access management need solutions architecturally designed for these constraints.

The eight banking-specific requirements outlined in this guide – examiner-grade audit trails, third-party governance, integrated microsegmentation, on-premises deployment, network invisibility, legacy protocol support, privileged access management, and DDoS resilience – provide the evaluation framework that separates ZTNA solutions that work in banking from solutions that work elsewhere.

Financial services CISOs should evaluate ZTNA through the lens of their specific regulatory obligations, infrastructure reality, and threat model. The vendor that satisfies the most analyst criteria is not necessarily the vendor that satisfies the bank’s most critical security requirements. Architecture, deployment flexibility, and regulatory alignment determine the right choice – not market share.