What "internal legacy systems" actually means in a breach notice

In July, Abbott Laboratories disclosed it was investigating two separate cyber incidents. The first traced back to a vishing (voice-phishing) attack against Abbott and Exact Sciences employees in mid-June, which the extortion group ShinyHunters claims let them compromise a Microsoft Entra single sign-on account and reach internal legacy systems tied to Abbott’s Cancer Diagnostics business — reportedly exfiltrating around 30 million rows of data, including close to a million Social Security numbers, according to BleepingComputer and Rescana’s analysis. A second, unrelated incident hit Abbott’s LabCentral customer portal, with a group calling itself ShadowByt3$ claiming access starting July 4 and taking manufacturing certificates, technical specifications, and regulatory documentation.

The specifics of who-did-what matter less here than one recurring phrase: “internal legacy systems.” It shows up in breach notice after breach notice, across industries, almost as filler. It’s worth actually unpacking, because it’s doing more work than it looks like.

What the euphemism is usually covering for

“Legacy system” in a breach notice is corporate-speak for a fairly specific and common set of conditions, and they’re rarely about the system being simply “old” in years:

• Unpatched, because patching would break something nobody wants to touch. Legacy usually means the system runs a dependency, an integration, or a business process that a newer version would break, so upgrades get deferred indefinitely.
• Undocumented. Original engineers and vendors are gone; the people maintaining it today are often working from institutional memory or none at all.
• Nobody owns it. It survived a reorg, an acquisition, or a platform migration, and ended up without a clear team responsible for its security posture — which means it’s rarely in scope for the security reviews and access audits that newer systems go through routinely.
• It’s connected to more than anyone realizes. Legacy systems accumulate integrations over years — SSO tie-ins, data feeds, service accounts — that expand their blast radius well past what the system was originally scoped to touch, which is exactly the pattern in the Abbott case: a compromised SSO credential reaching into a system whose access boundaries hadn’t been re-scoped in years.

None of that requires a single bad decision. It’s what happens by default to software that keeps working well enough that nobody prioritizes replacing it, inside an organization that keeps growing, acquiring, and reorganizing around it.

Why this accumulates even without anyone doing anything wrong

Every company that survives long enough and grows through any combination of acquisitions, platform migrations, and org changes ends up with a version of this. Abbott is a large, decades-old healthcare and diagnostics company that has acquired and integrated other businesses (Exact Sciences among them) — exactly the kind of history that produces systems nobody fully owns anymore. That’s not a knock specific to Abbott; it’s close to structurally guaranteed for any company of comparable age, size, and acquisition history. The interesting failure in this case isn’t that a legacy system existed — it’s that a single compromised SSO credential from a vishing call was enough to reach it, which says more about access-scoping discipline than about the system’s age.

The entry point is rarely the legacy system itself

It’s also worth noting how attackers reportedly got in: not by directly exploiting a flaw in the old system, but through a vishing call that compromised a modern, well-maintained piece of infrastructure — a Microsoft Entra single sign-on account — that happened to have standing access into the legacy environment. That ordering matters. The legacy system wasn’t the weak link that let attackers in; it was the high-value target that a compromised modern credential turned out to unlock. A company can invest heavily in current-generation identity security and still end up breached through an old system, because the connection between the two was never re-evaluated once the SSO integration was in place. Defense in depth means treating “this account has access to the old finance system nobody’s touched since 2019” as a fact worth auditing on its own, independent of how strong the authentication in front of it is.

What to take from this if you’re not Abbott

You don’t need a diagnostics business or a decades-old IT estate for this pattern to apply. Any growing company accumulates systems that fit the same description — an early integration nobody’s revisited, an admin panel from a tool you migrated off of two years ago but never fully decommissioned, a service account with broader access than its current job requires. A few habits catch this before it becomes a breach notice of your own:

• Inventory what’s reachable from your SSO/identity provider, not just what’s actively used day to day — old integrations often keep valid credentials long after anyone remembers they exist.
• Re-scope access on a schedule, not just at rollout. Permissions that made sense when a system launched rarely get revisited as the organization around it changes.
• Treat “we don’t actively use this anymore” as a decommissioning trigger, not a reason to leave something alone because it’s not causing visible problems.
• When you retire a vendor, tool, or integration, confirm the access it had is actually revoked — not just that your team stopped using it.

If your own compliance posture depends on knowing exactly what data you hold and where, that discipline compounds: read up on data minimization as a standing practice rather than a one-time cleanup, and make sure your offboarding and export process actually closes out access, not just billing. “Legacy system” is what you call the thing you meant to get to eventually — the cheapest time to deal with it is before it’s the subject line of your own breach notice.

It’s also the reason the specific systems that hold your prospect and customer data are worth being deliberate about from day one, not just auditing years later — the same discipline that prevents a platform like Norbelys from accumulating the kind of unowned, unscoped access described above applies to any tool holding your outreach data. Norbelys itself was built to make “what do we actually hold, and can we prove it” answerable on demand rather than reconstructed under pressure: a documented API and CLI mean there’s no undocumented integration quietly holding standing access nobody remembers granting, and a separate, audited erase endpoint — distinct from the ordinary archive-and-restore delete — means “we still have that person’s data somewhere” isn’t a question you have to guess the answer to when a customer, auditor, or regulator asks.