In April, a single VPN vulnerability led to data breaches at more than seventy financial institutions running Marquis Software's infrastructure.
The 345‑day testing gap
The arithmetic is simple and unforgiving. A standard annual external penetration test typically comprises two to three weeks of active testing; that schedule leaves roughly 345 days of operational reality unvalidated. The gap matters because adversaries do not behave like an annual engagement calendar. Mandiant's M-Trends 2026 report puts the 2025 median dwell time at fourteen days, with espionage actors averaging 122 days. CrowdStrike's 2026 Global Threat Report ranks financial services fourth in interactive intrusion targeting. In short, the implicit model behind an annual test — that most exploitable opportunities will wait for the next engagement — no longer matches the measured behavior of attackers.
Regulatory baseline: PCI DSS, FFIEC, NYDFS
The regulatory floor around penetration testing already presumes testing tied to change rather than a once‑a‑year checkbox. PCI DSS 4.0 Requirement 11.3.1 mandates external penetration testing after any significant infrastructure or application upgrade or modification. The FFIEC IT Examination Handbook describes penetration testing as part of ongoing vulnerability management, not a discrete annual event. NYDFS Section 500.05 mandates annual testing alongside continuous monitoring obligations strengthened in the 2023 amendments to 23 NYCRR 500. Every one of these frameworks assumes testing happens in response to change — a posture drafted for institutions where significant changes historically occurred on quarterly release cycles, not the continuous churn of modern banking infrastructure.
A vendor‑operated mortgage portal and a cross‑tenant API
A recent Sprocket Security engagement illustrates how quickly exposure can compound across a portfolio. Testers identified a customer‑facing mortgage origination portal fronted at a subdomain the bank owned but operated by a third‑party platform vendor. An undocumented API endpoint returned organization records when given a tenant ID, required no authentication, and permitted cross‑origin requests from any site. The tenant ID was visible in public‑facing files, so an unauthenticated caller could increment the ID and retrieve the next institution's records. Iterating the range surfaced records for every financial institution on the platform plus the vendor's internal tenant.
The data returned was granular: named staff with business email addresses, direct‑dial phone numbers, job titles, and an internal code the platform used to attribute borrower submissions to specific personnel. That internal code had operational consequences: any caller in possession of a valid code could submit a prospective borrower application in a named officer's name against that officer's institution, and the platform would treat the submission as legitimate intake into the loan‑origination pipeline. The bank did not introduce this exposure; the platform vendor did. Yet any fraud, phishing, or compliance incident that followed would route to the institution named in the URL, regardless of which tenant's data was used.
Why continuous testing matters operationally
The mortgage‑portal finding would likely be overlooked by an annual model for three connected reasons. First, the asset entered the bank's external footprint when the vendor onboarded the bank to the platform, not necessarily when the bank's penetration‑test scope was set; a scope snapshot from six months earlier might omit the hostname. Second, vendor‑operated portals fronted at an institution's subdomain often occupy a gray zone in scoping conversations: the bank does not control source code or releases, and vendors commonly assume responsibility for testing. Continuous external reconnaissance does not honor that boundary — if a hostname is reachable under a domain the bank owns, it is part of the bank's external attack surface and will be encountered by an attacker.
Third, and crucially, the finding required active human testing. An automated scanner would likely report a responsive endpoint, a permissive CORS policy, and a missing authentication header, and then stop. It would not walk tenant IDs, validate cross‑tenant data returns, or chain the staff‑attribution code into a submission‑forgery scenario. Sprocket's continuous model emphasizes that attestation reflects what was tested against the infrastructure that existed when the test ran, not a snapshot from twelve months earlier.
What this means for banks, regulators, and third‑party vendors
- Banks: The compliance question is no longer whether the institution tested last year; it is whether the institution tested the things that actually changed. Attack surface management and continuous testing models treat new hosts and exposed services as testing triggers rather than waiting for the next annual scope conversation.
- Regulators: Existing frameworks already expect testing in response to change. Those expectations reflect an earlier operational cadence — quarterly release cycles — that may not map to modern cloud migrations, fintech integrations, and M&A activity that continuously expand attack surface.
- Third‑party vendors: Vendor‑operated platforms can introduce cross‑tenant exposures that surface under a bank's domain and routing. Organizations relying on vendor security programs should recognize that exclusion from an annual scope does not remove a hostname from an attacker’s view.
The lesson is structural, not merely calendar‑based. The institutions that close the exposure gap are not simply those that increase the frequency of tests; they are the ones whose testing programs respond to what their infrastructure actually does. Regulators wrote the floor assuming testing would follow change — modern operations require testing that follows automatically.
