Twice in 21 Months: Veradigm's Patient Data Left on Someone Else's Credential Again

"A small number of the Company's customers." That's the phrase Veradigm chose for its Form 8-K, signed on 8 September 2026. A few days earlier, ransomware trackers had logged a new post from The Gentlemen claiming about 3.5 million patient records taken from the same company.

Both statements can be true at once. A health IT vendor that serves physician practices can have a handful of affected customers sitting on top of millions of patients. And that's the first thing I'd want any healthcare security lead to understand about this incident: the number of contracts touched tells you almost nothing about the blast radius.

The second thing is less comfortable. This is the second time in under two years that Veradigm patient data has walked out the door on a credential that lived somewhere Veradigm didn't control. I've spent a lot of time on post-incident reviews where the root cause was "someone else's credential." It is rarely a one-off. It's usually an architecture.

What Veradigm actually disclosed

The 8-K is short, and it's filed under Item 8.01 (other events) rather than Item 1.05, the material cybersecurity incident item. The company says it "does not believe that this incident is reasonably likely to have a material impact" on its business.

Here's the substance, confirmed across the SEC filing and Paubox's write-up of it:

• An unauthorized party obtained credentials from a third-party vendor's environment.
• Those credentials were for a Veradigm API that the vendor used to serve Veradigm customers.
• The attacker used them to download copies of patient personal data, including Social Security numbers in some cases.
• No clinical or medical data was involved, and the credentials gave access only to "that limited interface," not Veradigm's wider network, servers or databases.
• No operational disruption. Law enforcement notified. Credit monitoring offered where applicable.

The vendor isn't named. Neither is the API.

On the other side, The Gentlemen's leak-site claim, as reported by Tech Insider and Aviatrix, describes full names, home addresses, Social Security numbers, email addresses, phone numbers and guarantor details for roughly 3.5 million patients. Tech Insider's timeline has the claim showing up on trackers on 4 to 5 September, Veradigm's public acknowledgment around 8 to 9 September, and a threatened publication date of 11 September.

Be careful with that 3.5 million figure. As of Tech Insider's reporting, no regulator filing or breach-notification index had corroborated it, and Veradigm hasn't confirmed a count. Ransomware crews inflate. They also sometimes undercount. Treat it as a claim, not a fact.

What isn't in dispute is the shape of the attack. No exploit. No malware on Veradigm's side. A valid credential, used against an interface that was built to hand out exactly this kind of data to exactly this kind of caller.

The 2024 incident had the same shape

Go back to the earlier breach, which Veradigm disclosed in 2025. According to the HIPAA Journal and BankInfoSecurity coverage of the subsequent class action:

• An attacker got into a Veradigm environment in December 2024.
• Veradigm only learned about it on 1 July 2025, and not from its own monitoring. It surfaced through a third-party investigation into one of its client's breaches.
• The way in was a credential found in a client's data breach. That credential opened a Veradigm storage account used for data migrations, and that account held data belonging to other Veradigm customers.
• Exposed data included names, contact details, dates of birth, health record information, insurance claims, payment data, Social Security numbers and copies of driver's licences.
• Veradigm agreed to a $10.5 million settlement fund. Tech Insider puts the final affected count at 2,672,036 people.

Put the two side by side:

	2024-25 incident	2026 incident
Whose credential	A client's	A vendor's
What it opened	Data-migration storage account	Customer-service API
Data scope	Multiple customers' PHI	Patient PII, SSNs in some cases
How it was found	Another party's investigation, ~7 months later	Not disclosed; leak-site claim preceded public notice
Company framing	Third-party credential	"Limited interface"

Two incidents. Two different outsiders. One identical failure: a credential issued for a narrow job worked just fine for a bulk extraction, and nothing on Veradigm's side flagged the difference in time.

"Limited interface" is doing a lot of work

Every post-mortem I've worked on has a sentence like this in the first draft of the customer notice. "The credentials only provided access to a limited system." It's meant to reassure. Read it as an attacker would and it says something else: the limited system was the one with the data in it.

Nobody steals an API credential hoping to pivot into the domain controller. They steal it because the API already returns names, addresses and Social Security numbers to whoever presents the right token. The scope limit stopped lateral movement. It didn't stop the theft, because the theft never needed to move laterally.

This is the same lesson we pulled out of the BigCommerce Ribon app key breach last week. The platform wasn't breached, and that was exactly the problem. A partner's key is a first-class identity on your system, whether or not your identity team counts it as one.

Why healthcare keeps landing here

Healthcare IT runs on integrations. A single ambulatory EHR vendor sits between practices, billing companies, clearinghouses, patient-engagement apps, analytics shops and migration contractors. Each of those connections needs a credential. Most of those credentials are long-lived, because rotating them means coordinating with a partner who has a support queue and a change-freeze calendar of their own.

Paubox's 2025 healthcare email breach report found business associates were involved in 16% of the breaches it analysed. That's email only. API and storage integrations aren't in that number, and in my experience they're where the bigger pulls happen, because an API returns records at machine speed and a mailbox doesn't.

Unit 42's 2026 Global Incident Response Report lands in the same place from a different angle: identity-based techniques drove 65% of initial access across its cases, and identity weaknesses played a material role in almost 90% of investigations. Credential misuse on its own accounted for 21%. Healthcare isn't an outlier in those figures. It's just the sector where the record you lose carries a Social Security number and a diagnosis code.

Paubox also compared the Veradigm pattern to UNC6395, the group behind the 2025 Salesloft Drift OAuth token thefts. I think that's the right comparison. Compromise the integration once, and you get read access to every downstream tenant the integration serves. It's the cheapest way to get millions of records out of an industry that has spent a decade hardening its front doors.

The detection problem nobody budgets for

Here's the uncomfortable part for security teams: a vendor using its own valid API credential looks normal by definition. Your SIEM sees a known client ID, from roughly the expected network region, calling documented endpoints with a 200 response. EDR has nothing to say, because there's no endpoint of yours involved. MFA doesn't apply to a service credential.

The signals that do exist are behavioural, and they're weak:

• Volume changes. A practice-management integration that normally fetches a few hundred patient records a day suddenly paging through the full set.
• Endpoint mix. A credential that historically calls appointment and eligibility endpoints starts calling demographics in bulk.
• Source changes. New ASNs, residential proxies, or cloud regions the vendor has never used.

Each of these needs a baseline per integration, and someone has to own the alert. In most health IT shops I've seen, nobody does. The vendor relationship belongs to a partnerships or product team, the API gateway belongs to platform engineering, and security sees the gateway logs only after an incident.

The 2024 incident is the proof. Seven months between access and discovery, and discovery came from someone else's forensics. That's not a tooling failure so much as a signal failure: there was nothing on that storage account that would have screamed when the wrong party touched it.

Make the stolen credential report itself

This is where I think deception earns its place, and I'll be specific, because "deploy honeytokens" is advice that sounds good and changes nothing unless you put them where this attack actually runs.

1. Canary records inside the API's data set. Seed a small number of synthetic patient records into each customer tenant that an integration can read. No real practice will ever query those IDs, so a fetch of one is a near-certain sign of enumeration. Bulk pulls hit them early. A legitimate integration pulling scheduled appointments never touches them at all. That gives you a zero-noise alarm on exactly the event that turned both Veradigm incidents into breaches: someone reading far more than their job requires.

2. Decoy credentials in the places vendor credentials leak from. The 2026 credential came out of the vendor's environment. You can't instrument the vendor's network, but you can control what you hand them. Issue each integration partner a second, decoy API key alongside the real one, documented in the same onboarding pack, the same shared vault entry, the same config template. Any authentication attempt with the decoy tells you the vendor's secret store has been read by someone who shouldn't have it. That's often your earliest warning that a partner is compromised, days before they tell you. We walked through the same idea for build systems in the Artifactory empty-string token post, where patching didn't evict an attacker holding a valid token.

3. Decoy storage next to migration buckets. The 2024 incident ran through a data-migration storage account. Migration storage is the worst kind: high-value, temporary, and forgotten once the project closes. Place a decoy container or blob next to each real migration store, with a name that looks more interesting than the real one. An attacker listing the account will open it. A migration job, which knows its exact paths, never will. We've seen this pattern pay off in Azure specifically, as in the Storm-3168 service-principal case, where an attacker went from one leaked secret to 100 storage accounts in seven minutes.

The edge case people miss: don't put canary records anywhere a downstream analytics or billing job does a full-table scan. I've watched a team seed canaries into a dataset that a nightly reporting export read in full. Every night, every canary fired. They turned the alerts off within a week, and the deception layer died quietly. Map the legitimate bulk readers first, exclude them by design, and then the alert genuinely means something.

What I'd change on Monday

If you run security at a health IT vendor, or at a provider with a dozen of these integrations, this is the short list:

1. Inventory every inbound integration credential. Owner, partner, endpoints used in the last 90 days, record volume per day. If you can't produce this in a week, that's the finding.
2. Scope by endpoint and by volume, not just by tenant. "Read access to customer X" is not a scope. "Read appointments for customer X, up to N records per hour" is.
3. Shorten credential life and bind it. Move partners to short-lived tokens via OAuth client credentials with mTLS or private-key JWT where they'll support it. A static API key in a vendor's config file is the exact artefact that walked out in September.
4. Seed canaries per tenant and decoy keys per partner. As above. Wire them to a channel someone actually reads.
5. Write the partner-compromise playbook now. When a vendor calls to say their environment was breached, you should be able to revoke, reissue and review that integration's last 30 days of API calls in hours, not weeks.
6. Ask your vendors the same questions. If you're a practice using a third-party app on top of your EHR, ask where its credentials to your data live, and how it would know if they'd been read.

Our solutions overview covers how these pieces fit together across credentials, cloud storage and on-prem services.

The part the 8-K can't say

Veradigm may well be right that this incident isn't material to its business. Materiality in an 8-K is about revenue and operations. For the patients whose Social Security numbers were in that API response, materiality looks different, and it lasts longer than a credit-monitoring subscription.

The pattern is what should bother you. In 2024 a client's credential opened a storage account. In 2026 a vendor's credential opened an API. Next time it'll be a different outsider and a different interface, and the same question will decide how bad it gets: does anything on your side notice when a trusted credential starts behaving like a thief? If you want to see what that alarm looks like when a decoy key or canary record gets touched, book a Mine2 demo and we'll walk through it on an integration that looks like yours.