What Happened
On September 5, 2025, The Gentlemen ransomware group listed Veradigm (formerly Allscripts Healthcare Solutions) on its leak site, claiming to hold 3.5 million patient records. The Chicago-based healthcare technology company disclosed to the SEC that an attacker had obtained credentials from a third-party vendor's environment. These credentials granted access to a Veradigm API reserved for customer services, which the attacker used to copy patient data, including names, addresses, Social Security numbers, and email addresses. Clinical and medical information remained unaffected. Veradigm stated the compromised credentials provided access only through that limited interface, not to the broader network, servers, or databases.
Timeline
September 5, 2025: The Gentlemen ransomware group publicly claims the attack and lists Veradigm on its data leak site.
Shortly after discovery: Veradigm initiates incident-response procedures and notifies law enforcement.
SEC filing date: Company discloses the breach to the Securities and Exchange Commission, noting affected customers and individuals are being notified with credit-monitoring services offered where applicable.
September 11, 2025 (threatened): The Gentlemen sets this as the deadline for ransom negotiation engagement, threatening to leak the stolen data if demands aren't met.
Which Controls Failed or Were Missing
Vendor credential hygiene: The third-party vendor's environment was compromised, allowing attackers to obtain valid credentials. This suggests inadequate access controls, weak authentication, or undetected lateral movement within the vendor's systems.
API access scoping: While Veradigm's statement that credentials provided "access only through that limited interface" suggests some network segmentation existed, the API itself granted sufficient privilege to copy patient data for 3.5 million records. The interface wasn't sufficiently limited.
Credential monitoring and anomaly detection: No control appears to have flagged unusual API activity when credentials were used to systematically copy large volumes of patient data. Detection failed at both the vendor and Veradigm layers.
Vendor security assessment depth: Pre-contractual assessment or continuous monitoring didn't surface the vendor's exposure to credential compromise. If the vendor had access to this API, they should have been classified as handling critical data and subjected to rigorous security reviews.
Sub-processor visibility: If this vendor was using sub-contractors or had been breached through a fourth party, Veradigm lacked the Sub-Processor Disclosure or fourth-party oversight to detect that risk chain.
What the Relevant Standard Requires
SR 23-4 (Interagency Guidance on Third-Party Relationship Risk Management) requires institutions to conduct due diligence commensurate with the level of risk, complexity, and size of the third-party relationship. For arrangements involving access to sensitive customer information, this means:
- Assessing the third party's information security program, including access controls and monitoring capabilities
- Evaluating whether the third party's security measures align with the institution's own risk tolerance
- Establishing Continuous Monitoring of Active Arrangements to identify changes in the third party's risk profile
HIPAA Business Associate requirements mandate that covered entities enter into Business Associate Agreements (BAAs) with vendors that create, receive, maintain, or transmit protected health information. The BAA must require the Business Associate to:
- Implement administrative, physical, and technical safeguards that reasonably protect the confidentiality, integrity, and availability of electronic protected health information (45 CFR § 164.308, § 164.310, § 164.312)
- Report security incidents to the covered entity
- Ensure that any sub-contractors who handle PHI also agree to the same restrictions
ISO 27036 (Information Security for Supplier Relationships) specifies that organizations should:
- Define security requirements for supplier access to information assets (ISO 27036-1, clause 6.1.2)
- Establish monitoring and review processes for supplier compliance (clause 6.3)
- Implement access control measures that limit supplier privileges to only what's necessary for service delivery
In this case, the API should have enforced the principle of least privilege. If the vendor needed to query patient data for customer-service functions, access should have been rate-limited, logged, and restricted to individual record lookups, not bulk extraction.
Lessons and Action Items for Your Team
Classify APIs by data sensitivity, not just by function. If an API can touch PHI or PII, treat it as a critical system even if it's labeled "customer service" or "support." Map every vendor-facing API to your Criticality Classification framework and apply controls accordingly.
Require MFA and short-lived tokens for all vendor API access. Static credentials shouldn't exist in vendor environments. Implement OAuth 2.0 with token expiration, and enforce multi-factor authentication for any human access to credential stores.
Deploy API rate limiting and anomaly detection. A legitimate customer-service query doesn't pull 3.5 million records. Set thresholds for API call volume, data export size, and query patterns. Alert on deviations and auto-throttle suspicious activity.
Audit your vendor's Sub-Processor Disclosure and fourth-party dependencies. Ask: Who else has credentials in your vendor's environment? If your vendor uses a managed-service provider, that MSP is a fourth party with potential access to your data. Demand Sub-Processor Disclosure and assess those entities.
Test your vendor's incident detection capabilities during due diligence. Don't just review policies. Ask: How long does it take you to detect credential misuse? Can you show us alert logs from your SIEM? If they can't answer, they can't protect your data.
Segregate vendor access at the network layer. The fact that Veradigm's broader network remained untouched suggests some segmentation worked. Extend that principle: vendor credentials should never grant access to production databases directly. Use intermediary services, reverse proxies, or dedicated API gateways that enforce strict access policies.
Establish notification timelines in your BAA. HIPAA requires breach notification within 60 days to affected individuals, but your contract should require the vendor to notify you within 24 hours of discovering a compromise. Veradigm's timeline suggests discovery happened after the ransomware group's public claim. That's too late.
Run tabletop exercises that include vendor credential compromise. Your incident-response plan should cover: What happens if a vendor's credentials are stolen? Who revokes access? How do you verify what data was touched? How do you notify patients? Test this scenario annually.
The Gentlemen ransomware group's use of double extortion (encrypt and leak) makes vendor credential theft particularly damaging. Even if you never pay the ransom, the data is already gone. Your controls must prevent the initial copy, not just respond to the encryption. That means treating vendor access as a potential breach vector from day one.
