What we measured
Between January 2024 and December 2025, FireShield ran assessments across more than 200 financial institutions — retail banks, credit unions, payment processors, lenders, and insurers, from 80-person regional operations to multi-country groups. Every assessment was performed by the CloudShark engine against production environments. That matters for the data: nothing here comes from a lab replica or a sanitized staging copy. Each check is designed to prove a route exists without disturbing it, so live systems stayed live throughout.
The unit of measurement is the proven attack route: a chain of weaknesses walked end to end, from a starting point an outsider could actually reach to an asset the institution actually cares about, with evidence recorded at every hop. That is a deliberately higher bar than a scanner finding, and the gap between the two is the story of this report.
The headline numbers
- 4,100 raw scanner findings per institution, at the median — against a median of 2 proven attack routes. Scanners across the wider FireShield dataset average 4,000+ unverified findings; finance ran slightly above that average.
- 48 hours — the median time from kick-off to the first confirmed attack path.
- 94% of critical exposure closed with 3 or fewer changes. The routes were long; the fixes were not.
- Every confirmed route chained at least one identity weakness — a reused, stale, or over-privileged credential. Not most routes. Every one.
Read those together and a pattern emerges: finance institutions are not drowning in exploitable software flaws. They are carrying a small number of quiet, chainable weaknesses — most of them about who can access what — buried under a very large pile of noise.
The three recurring paths in finance
Across 200+ institutions, three route shapes accounted for the large majority of confirmed critical paths. If you work in financial services, at least one of these almost certainly exists in some form in your environment today.
Path 1: Reused service credential → stale access rule → shared data store
A service account created for one integration turns out to authenticate to a second, unrelated system, because the same credential was reused when the second system was set up years ago. From there, an access rule written for a long-decommissioned workflow still permits a connection onward to a shared data store — the kind that accumulates statement exports, reconciliation files, and report archives. Three individually boring facts; one route to regulated data.
Path 2: Vendor VPN access → flat internal network → finance systems
Third-party remote access — a core-banking vendor, an ATM servicer, a managed print supplier — lands on a network segment that can reach far more than the vendor's own system. Where the internal network is flat, that entry point is functionally an employee workstation with no employee attached to it. In our assessments, vendor access points reached finance systems the vendor had no business reason to see in the majority of institutions where such access existed.
Path 3: Exposed or forgotten API → over-privileged service account → customer records
An API stood up for a pilot, a migration, or a partner that has since churned remains reachable but has fallen out of the asset inventory. Behind it sits a service account whose permissions were set generously "to get the project working" and never revisited. The API only needed to read one table; the account behind it could read customer records wholesale.
Why scanner ranking failed to predict them
Here is the uncomfortable finding: the individual hops in these routes scored low on scanner output — or did not appear at all. A reused service credential is not a CVE. A stale firewall rule has no CVSS score. A flat network is an architecture property, not a plugin result. An over-privileged account looks identical to a correctly privileged one until something walks the path.
Scanners rank items by per-item severity. Attackers work in sequences, where three "low" facts compose into one critical route. In the median finance assessment, not one link of a confirmed route appeared in the scanner's top 100 findings by severity. Teams that triaged strictly by scanner ranking were, in effect, working hard on the wrong list.
What the top quartile does differently
The best-performing 25% of institutions — fewest confirmed routes, fastest closure — were not the ones with the biggest security budgets. They shared four operational habits:
- Credential vaulting and rotation. Service account passwords live in a vault, are unique per system, and rotate on a schedule. This single habit breaks Path 1 at the first hop.
- Access-rule review cadence. Every firewall and access rule has a named owner and a review date. Rules that nobody claims get removed, not grandfathered.
- Decommissioning discipline. When a system is retired, the same ticket removes its DNS entries, credentials, API endpoints, and access rules. Path 3 is almost entirely a decommissioning failure.
- Re-test verification instead of ticket-close. A finding is closed when the route no longer works on re-test — not when the remediation ticket is marked done. In the bottom quartile, roughly a fifth of "closed" findings were still walkable.
A Monday-morning checklist
Six things worth doing this week, in order of payoff:
- Inventory service accounts and check for credential reuse across systems. Vault and rotate anything shared.
- Put a named owner and an expiry date on every access rule. Schedule the first review now.
- List every third-party VPN and remote-access connection, then verify what each can actually reach. Segment vendor entry points to the one system they serve.
- Compare your API inventory against what is actually reachable from the internet. Retire anything nobody claims.
- Cut each service account's permissions down to what its service demonstrably reads and writes.
- Change your closure rule: a finding is fixed when a re-test proves the route is gone.
The median institution in this report was two proven routes away from its customer records, and 94% of that exposure closed with three or fewer changes. The work is small. Knowing which work to do is the hard part — and that is exactly what a proven attack route tells you.