TLDR
Regional banks face a critical paradox: legacy systems built for stability create exploitable attack surfaces, but modernization introduces new vulnerabilities faster than security teams can assess them. The collision happens when banks modernize piecemeal: connecting decades-old core banking platforms to cloud APIs and mobile apps without understanding how these integration points become attacker highways between old and new infrastructure.
The Integration Point Problem
Starting in December 2020, attackers exploited multiple zero-day vulnerabilities in Accellion’s 20-year-old legacy File Transfer Appliance (FTA) to steal data from major financial institutions, including Flagstar Bank and Morgan Stanley (through a third-party vendor) [1,2]. The legacy file transfer solution was scheduled to be retired on April 30, 2021, just four months after the attacks began [3].
Here’s the collision: Accellion had been actively phasing out the FTA and encouraging clients to migrate to its newly developed Kiteworks platform [4], but banks were caught in the transition. One victim, Washington State’s Auditor’s Office, had finished its migration to the new platform and was preparing to shut off its FTA when the breach occurred [5]. They did everything right, except they couldn’t complete the migration fast enough.
This is what happens when modernization meets reality: organizations running a legacy system (that everyone knows needs replacement) alongside its modern replacement (that isn’t fully deployed yet), and the old system becomes the entry point. Flagstar’s Accellion breach compromised nearly 1.5 million customers’ sensitive data including Social Security numbers [6].
Three Technical Realities Auditors Miss
Authentication Translation Layers
Legacy systems use authentication models that predate modern token-based security. Many legacy systems rely on proprietary or outdated protocols, and modern IAM tools require middleware to communicate with older systems. These translation layers often make security decisions using business logic rather than cryptographic validation [7].
For legacy systems that struggle with modern authentication standards, adding an API gateway or middleware layer acts as a “translator” between older platforms and cloud services [8]. The problem: these middleware solutions create an additional entry point in the technology stack, increasing the probability of a security breach [9].
Compromise the translator and you’ve gained authenticated access to systems that trust the legacy side implicitly. Legacy systems were not designed with modern security standards in mind, making them vulnerable to data breaches and unauthorized access during the integration process [10]. When middleware assumes “if it got this far, it must be authorized,” the entire security model collapses.
Data Format Conversion Points
Core banking systems use fixed-field formats (EBCDIC on mainframes, fixed-width records) that date back to the 1970s and 1980s. Modern APIs use JSON, XML, or Protocol Buffers. Conversion happens in middleware that must parse, validate, and transform data, and each transformation is a potential injection point [11,12].
New and relatively simple transaction systems have to connect with ancient system architectures that have been continually patched to meet changing business needs. Some older platforms use File Transfer Protocol (FTP) to move data from front-end servers to middleware platforms, while modern systems use web services [11].
What auditors test: API input validation. What attackers test: whether the legacy system validates data that already passed through the API layer, or if the middleware is the last security checkpoint. The collision happens because API security assumes backend validation, while legacy systems assume upstream security. Neither side owns complete responsibility for data integrity at the junction point.
Patch Cadence Mismatch
Cloud-native components update weekly or daily. Middleware might update monthly or quarterly. Core banking systems update annually or not at all; applying patches to production mainframes is considered too risky without extensive testing [13].
As mainframes are increasingly integrated with cloud services and APIs to support modernization efforts, they experience greater exposure to external threats [14]. The expanded attack surface requires robust security measures, but the patch cycle can’t keep up.
One CISO at a major global bank admitted: “We never even thought we could have vulnerabilities on the mainframe, but once we began automated scanning, we found the volume and the severity to be much greater than anticipated” [14].
Attackers don’t chase patches; they map the attack surface and find the slow-moving components. Modern DevSecOps practices on the frontend create a false sense of security while backend vulnerabilities age undiscovered for months or years [15].
The pattern here: auditors evaluate security within each layer. Attackers exploit the gaps between layers.
Where Modernization Creates New Attack Surfaces
The Cloud Migration Half-Step
Most regional banks aren’t doing full core banking replacement (it’s too expensive and too risky). Instead, they’re doing lift-and-shift of some services, deploying new cloud-based customer-facing apps, and implementing hybrid networking. The result: attack surface expands without necessarily improving security posture.
The adoption of multi-cloud and hybrid cloud continues to rise, but traditional approaches with siloed tools and disparate security data actually introduce more security risks. The multi-tenant nature of public cloud infrastructure increases the attack surface area, as many users share hardware, resulting in the potential for more vulnerable or malicious code to arise. Over the past year, 47% of breaches originated in the cloud, with the pace of cloud migration outpacing security [16,17,18].
Legacy systems designed for internal networks are now accessible through cloud connectors. VPNs and private clouds don’t make legacy protocols secure; they just move the perimeter. As mainframes are increasingly integrated with cloud services and APIs to support modernization efforts, they experience greater exposure to external threats [19]. The offensive security perspective: more network paths to explore, more integration points to test, same vulnerable backend.
The Vendor Integration Explosion
Modern banking requires fintech integrations: payment processors, fraud detection, document management, customer communication platforms. Each vendor connection is another API, another authentication flow, another data transformation.
Due to their extensive reliance on third-party vendors, financial institutions face heightened cyber risks. From 2023-2024, third-party providers used by financial firms experienced a large number of cybersecurity incidents, with a particularly large increase during the first half of 2024. According to a Ponemon Institute report, 54 percent of companies surveyed have experienced a data breach caused by one of their third-party vendors [20,21,22].
Bank of America experienced this risk twice in 2023. In May, they were compromised through Ernst & Young’s systems during the MOVEit attack. Six months later in November, Infosys McCamish Systems was breached, and the bank wasn’t notified for 21 days [23]. Two different vendors, two different attack vectors, same vulnerable client data.
The collision: adding modern capabilities means adding complexity faster than security teams can validate the entire integrated system. Compromising a third-party integration point often provides deeper access than direct attacks on hardened perimeters.
What This Means for Security Architecture
Stop Treating Modernization as Security Improvement
Moving to the cloud or adding modern interfaces doesn’t automatically improve security. Migration to the cloud, expanding business transformation, and remote working all add complexity to modern infrastructure. If anything touches the internet, it can be attacked [24]. Each modernization decision should include an explicit security architecture review of the integration points.
The integration of Zero Trust Architecture with legacy systems presents a critical security challenge for modern organizations. Organizations often encounter challenges such as legacy systems, budget constraints, and internal resistance when implementing security improvements [25,26]. The question security teams should ask: if an attacker compromises this new component, what legacy systems become accessible? Modernization and security are separate problems that must be solved together, not sequentially.
Design for Security at the Junction
The middleware and integration layers need dedicated security architecture, not just operational security. Zero Trust principles matter most at translation points where authentication and authorization context changes. The “never trust, always verify” approach treats all access requests as potentially malicious regardless of origin [25].
Implementing Zero Trust Architecture requires configuring multiple technologies (IAM, MFA, and micro-segmentation) to work together seamlessly across diverse and often legacy infrastructure [27]. These layers should enforce security policy independently, not delegate to either modern or legacy components. Banks that secure the junction points force attackers to target either the modern or legacy stack directly, which is considerably harder than exploiting the gap between them.
Test Like Attackers Think
Compliance scans test components individually. Red team penetration testing simulates sophisticated adversary techniques and evaluates both technical defenses and human response mechanisms [28]. Red teaming goes beyond finding vulnerabilities; it tests how well security teams detect and respond to attacks moving through integrated systems [29]. The question isn’t “is each piece secure?” but “what becomes possible when these pieces connect?”
Building on Top vs. Building Right
Regional banks can’t rip out legacy systems overnight, and trying to do so often creates more risk than leaving them in place. The collision between modernization and security isn’t inevitable. It happens when banks bolt new technology onto old infrastructure without securing the connections.
Strong security architecture treats each integration point as a security boundary that must be explicitly designed and tested. The banks that handle this well don’t just modernize their customer experience; they modernize their security thinking to match their technical architecture.
The Accellion breach taught this lesson clearly: Washington State had finished migrating to the new platform but got caught in a narrow window during cutover. They did the right thing too slowly. The question for regional banks isn’t whether to modernize. It’s whether they’re securing the junction points while they build.
References
[1] Huntress. “Accellion Data Breach: What Happened, Impact, and Lessons.” https://www.huntress.com/threat-library/data-breach/accellion-data-breach
[2] MSSP Alert. “Accellion Vulnerabilities, Cyberattacks, Victims, Lawsuits: Customer List and Status Updates.” https://www.msspalert.com/news/accellion-vulnerabilities-victim-list
[3] Infosecurity Magazine. “Accellion Reaches $8.1m Data Breach Settlement.” https://www.infosecurity-magazine.com/news/accellion-reaches-81m-data-breach/
[4] Google Cloud Blog. “Threat Actors Exploit Accellion FTA for Data Theft and Extortion.” https://cloud.google.com/blog/topics/threat-intelligence/accellion-fta-exploited-for-data-theft-and-extortion/
[5] BankInfoSecurity. “The Accellion Mess: What Went Wrong?” Jeremy Kirk. https://www.bankinfosecurity.com/blogs/accellion-mess-what-went-wrong-p-2989
[6] Corbado. “10 Biggest Data Breaches in the Financial Sector [2025].” https://www.corbado.com/blog/data-breaches-finance
[7] Infisign. “What Issues Arise Integrating IAM with Legacy Systems?” https://www.infisign.ai/blog/issues-arise-integrating-iam-with-legacy-systems
[8] i3solutions. “Securing Legacy IT Systems.” https://i3solutions.com/digital-transformation/how-to-secure-legacy-it-systems/
[9] American Bankers Association. “Exploring Banking Middleware Solutions.” https://resources.gabankers.com/e-Bulletin/2023/Feb%2024/2022%20ABA%20Middleware%20Report.pdf
[10] KMS Solutions. “Core Banking Integration: Modernizing Financial Services.” https://kms-solutions.asia/blogs/core-banking-integration
[11] Achieve Internet. “How Legacy Banking Systems Pose a Threat to Digital Transformation and Stunt Growth.” https://www.achieveinternet.com/post/legacy-banking-systems
[12] Luxoft. “How come COBOL-driven mainframes are still the banking system of choice?” https://www.luxoft.com/blog/why-banks-still-rely-on-cobol-driven-mainframe-systems
[13] Substack – David Hollard. “Banking on the Past: Keeping Mainframes and COBOL Alive in the Digital Age.” https://davidhollard.substack.com/p/banking-on-the-past-keeping-mainframes
[14] Rocket Software. “The Ultimate Guide to Mainframe Vulnerability Management.” https://www.rocketsoftware.com/en-us/insights/ultimate-guide-mainframe-vulnerability-management
[15] ModLogix. “Legacy Systems and Cybersecurity Risks: What You Need to Know in 2025.” https://modlogix.com/blog/legacy-systems-and-cybersecurity-risks-what-you-need-to-know-in-2025/
[16] SecurityWeek. “Cyber Insights 2023: Attack Surface Management.” https://www.securityweek.com/cyber-insights-2023-attack-surface-management/
[17] Hyve Managed Hosting. “Cloud Security: Reflecting on 2023 to Improve 2024.” https://www.hyve.com/insights/cloud-security-reflecting-on-2023-to-improve-2024/
[18] InformationWeek. “8 Priorities for Cloud Security in 2024.” https://www.informationweek.com/it-infrastructure/8-priorities-for-cloud-security-in-2024
[19] Rocket Software. “The Ultimate Guide to Mainframe Vulnerability Management.” https://www.rocketsoftware.com/en-us/insights/ultimate-guide-mainframe-vulnerability-management
[20] SecurityScorecard. “2024 Third-Party Vendor Risk Management in the Financial Industry.” https://securityscorecard.com/blog/2024-third-party-vendor-risk-management-in-the-financial-industry/
[21] FINRA. “Cybersecurity Advisory – Increasing Cybersecurity Risks at Third-Party Providers.” https://www.finra.org/rules-guidance/guidance/cybersecurity-advisory-third-party-provider-risks
[22] Community Banking Connections. “Third-Party Cybersecurity Risk Management — Updates for a Changing Risk Environment.” https://www.communitybankingconnections.org/Articles/2023/I2-I3/third-party-cybersecurity
[23] IT Security Guru. “Cyber gaps in the supply chain — Bank of America breached in another vendor cyberattack.” https://www.itsecurityguru.org/2024/02/14/cyber-gaps-in-the-supply-chain-bank-of-america-breached-in-another-vendor-cyberattack/
[24] SecurityWeek. “Cyber Insights 2023: Attack Surface Management.” https://www.securityweek.com/cyber-insights-2023-attack-surface-management/
[25] International Journal of Scientific Research in Computer Science, Engineering and Information Technology. “Zero Trust Security Architecture for Legacy Systems.” https://www.ijsrcseit.technoscienceacademy.com/index.php/home/article/view/CSEIT25112503
[26] SANS Institute. “Building a Zero Trust Framework: Key Strategies for 2024 and Beyond.” https://www.sans.org/blog/building-a-zero-trust-framework-key-strategies-for-2024-and-beyond/
[27] Palo Alto Networks. “What Is Zero Trust Architecture? Key Elements and Use Cases.” https://www.paloaltonetworks.com/cyberpedia/what-is-a-zero-trust-architecture
[28] Integrity360. “Red Teaming & Pentesting: Tackling Modern Threats & Attacker Sophistication.” https://insights.integrity360.com/red-teaming-pentesting-tackling-modern-threats-attacker-sophistication
[29] IBM. “What is Red Teaming?” https://www.ibm.com/think/topics/red-teaming