Summary of the Incident
A single unpatched VPN vulnerability in Marquis Software's platform compromised over seventy financial institutions. This vulnerability was present in the production infrastructure between scheduled annual penetration tests. Attackers exploited the weakness, gained access, and moved laterally across the network. According to Mandiant's M-Trends 2026 report, the median dwell time for 2025 was fourteen days, meaning attackers had two weeks on average to exfiltrate data before detection.
The affected institutions had completed their annual penetration tests. The vulnerability emerged after these tests, during routine infrastructure updates. For 345 days, it went unnoticed.
Breach Timeline
Day 0: Annual penetration test completes. Report delivered, findings remediated.
Day 47: Marquis Software updates the VPN gateway, including a new authentication module.
Day 48-330: No security testing occurs. The vulnerability remains undetected.
Day 331: Unauthorized access detected during retrospective analysis. Attacker begins reconnaissance.
Day 345: Next annual penetration test scheduled to begin.
Day 338-345: Attackers exfiltrate customer data from multiple institutions. Breach discovered when unusual data transfer patterns are noticed.
The gap between Day 47 and Day 331 highlights the core failure. The infrastructure changed, but the testing schedule did not.
Failed or Missing Controls
Change-triggered testing: After the VPN update on Day 47, no penetration test followed. The update was treated as routine maintenance, not a significant infrastructure change.
Continuous vulnerability assessment: Between annual tests, no automated or manual testing validated the security posture of the updated VPN gateway. The VPN gateway was excluded from regular scans to avoid disrupting customer access.
Third-party risk management: Contracts with Marquis required security attestations, referencing the vendor's own annual testing cycle, which hadn't covered the new VPN module at deployment.
Network segmentation validation: Post-breach analysis showed attackers moved laterally into customer data environments. Segmentation controls were in place but hadn't been tested since the VPN architecture changed.
Relevant Standards
PCI DSS v4.0.1 Requirement 11.3.1 states: "External penetration testing is performed after any significant infrastructure or application upgrade or modification." The guidance notes clarify that changes affecting the security posture of the cardholder data environment qualify. A VPN gateway providing remote access to systems processing payment data clearly meets this threshold.
ISO/IEC 27001:2022 Annex A.8.8 requires technical vulnerability assessments at planned intervals and when significant changes occur, explicitly calling out infrastructure changes as a trigger for reassessment.
NIST CSF v2.0 function PR.IP-12 directs organizations to validate security controls through testing. It links testing to the Detect and Respond functions—you cannot detect what you have not tested for.
Lessons and Action Items
Map infrastructure changes to testing triggers: Develop a decision tree to route infrastructure changes through a security review. Include categories like:
- Changes to authentication systems: Always test
- Changes to network perimeter devices: Always test
- Changes to systems processing sensitive data: Always test
- Changes to third-party managed services: Test if the service touches your data environment
Implement quarterly external testing: Annual testing leaves an average exposure window of 182 days. Quarterly testing reduces that to 45 days. If quarterly full-scope testing exceeds your budget, alternate between comprehensive tests and focused assessments.
Automate vulnerability validation: Deploy continuous scanning against external-facing assets. Configure your scanner to alert on:
- New services exposed to the internet
- Certificate expirations within 30 days
- Known CVEs in identified software versions
- Changes to TLS configuration
Require change-triggered attestations from vendors: Revise vendor agreements to include:
- Notification of infrastructure changes within 48 hours
- Security testing results for changes affecting your data
- Right to audit or request third-party testing if vendor testing is insufficient
Test your segmentation assumptions: Verify that:
- Firewall rules enforce intended boundaries
- Jump boxes and bastion hosts require multi-factor authentication
- Monitoring detects lateral movement attempts
- Access to sensitive data requires explicit approval
Schedule a purple team exercise to test lateral movement from a compromised VPN session.
Document your risk-based testing frequency: Write down why you test at your current frequency. Consider:
- Number of external-facing services
- Frequency of infrastructure changes
- Value of data accessible from compromised systems
- Regulatory expectations beyond minimum requirements
Use this assessment to justify quarterly or continuous testing to budget holders. The cost of four tests per year is substantially less than notifying seventy institutions of exposed customer data.
Continuous security testing is essential for financial institutions to manage vulnerabilities effectively. Your infrastructure changes monthly; your testing should too.
