When a Cyberattack Shows Up in the Earnings Guidance

A medical device maker with roughly $20 billion in annual revenue told investors last week that it is unlikely to hit its own sales and profit targets for the year. Not because of a product recall, a pricing war, or a bad quarter in Europe. Because attackers got into its network in August, and the company still cannot say when everything will be fully back.

That is a different kind of security story than the ones we are used to reading, and it is worth a few minutes even if you run something a great deal smaller.

What happened

In late August, Boston Scientific detected unauthorized activity on its systems that caused a network outage. The company notified the SEC the following day and filed further detail on September 8.

The disruption was operational, not just informational. Per the company’s own filings and public statements, the attack affected its ability to manufacture products and to ship and process orders globally. Manufacturing was interrupted at facilities around the world. Customers could still submit electronic orders, but those orders sat queued rather than shipping. For implanted cardiac devices already in patients, device function and data transmission were unaffected, though new remote monitoring activations were blocked while systems were down.

By the September 8 filing, the picture had improved considerably. The company reported “substantial restoration of its distribution network, with major distribution centers now processing and shipping customer orders at or above normal operating levels,” sterilization facilities running, and manufacturing resumed at most global sites. It has “not identified evidence of ongoing unauthorized access to its systems,” and its investigation “remains ongoing.”

Then came the sentence that made this a business story rather than a security story: the company “believes that it is unlikely to meet the net sales growth and adjusted EPS guidance ranges for the third quarter and full year 2026.” Shares fell roughly 4.5% in premarket trading. The company says it does not expect a material long-term impact to its financial condition, and it will update its outlook on October 28.

To be clear about what is still unknown: no threat group has claimed responsibility, the company has not said publicly whether ransomware was involved or how the attackers got in, and whether data was stolen is still under investigation. Anyone telling you the root cause today is guessing.

The interesting part is not the breach. It is the blast radius.

Boston Scientific is not a company that skipped security. It operates in 127 countries with roughly 59,000 employees. It engaged external experts immediately and, by the numbers in its own filing, ran a competent recovery.

And an intrusion still reached the part of the business that makes and ships things.

That is the detail worth sitting with. The damage here did not come from a stolen customer list. It came from the fact that a compromise of corporate systems translated into idle production lines and unshipped orders. Somewhere in that environment, a path existed between “an attacker has a foothold” and “we cannot ship product,” and nobody had walked that path in advance and closed it off.

That failure mode is not a large-company problem. It is the same shape at every size:

The manufacturing plant that finds out its production network was never really separated from the office network. Segmentation that exists on a diagram and segmentation that survives an attacker with valid credentials are two different things.

The distributor whose warehouse cannot ship because the order system authenticates against a domain controller that is now encrypted. One dependency nobody mapped.

The professional services firm that discovers its backups were reachable from the same account that got phished. Backups an attacker can delete are not backups.

The utility whose business network and control network share one flat address space because that is how it was built in 2009 and it has worked fine ever since. It worked fine because nobody was trying.

In every one of those cases, the weakness was knowable in advance. Nothing exotic was required to find it. What was required was someone deliberately trying to get from the outside to the thing that matters, and writing down what worked.

What proactive testing actually buys you

There is a version of security spending that is about buying tools and hoping. Proactive testing is the opposite. It is spending a small, known amount to replace assumptions with evidence. A few specific things it produces that no dashboard will:

Proof, or disproof, of your segmentation. Not “is there a firewall between these zones” but “starting from a compromised laptop in accounting, can a tester reach the systems that keep revenue moving.” That answer is either yes or no, and you want to know which one before somebody else finds out.

A real inventory of what is exposed. Organizations are consistently surprised by what is reachable from the internet: a forgotten remote access appliance, a management interface on a device someone stood up for a project three years ago, a vendor portal nobody owns anymore.

The privilege path. Most serious incidents are not one clever exploit. They are a chain of small, boring misconfigurations that add up to domain administrator. Testing finds the chain while it is still cheap to break.

Verification that remediation actually happened. A finding that was reported, marked closed, and never re-checked is not a fixed finding. Retesting is the unglamorous half of this work, and it is the half that determines whether the first half mattered.

A defensible answer for the people who ask. Insurers, customers, and boards increasingly want to know when you last had someone independent try to break in. “We take security seriously” is not an answer. A dated report with findings and verified fixes is.

The honest framing

Testing is not insurance against ever having a bad day. Boston Scientific may well have been doing all of this and still ended up here, and any consultant who promises otherwise is selling something. Attackers are creative, well funded, and only need to be right once.

What testing changes is the size of the bad day. It shortens the list of ways in, it removes the easy pivots, and it means that when something does happen you are dealing with a contained incident rather than discovering your own architecture live, in public, in a securities filing.

The organizations that come through incidents in reasonable shape are rarely the ones with the most technology. They are the ones who already knew where their weak points were, because they went looking on purpose.

Where to start

If you have never had an independent test, start with the boundary: what is reachable from the internet, and what can be reached from a single compromised workstation inside. That pair of questions covers the overwhelming majority of how real incidents begin.

If you had a test some time ago and never verified the fixes, that is the cheaper and more urgent piece of work. And if you are not sure which of these applies to you, that is a conversation, not a proposal.

If you want a straight answer on where your organization actually stands, talk to a founder directly. No sales process, no obligation.

Terry Bradley, CISSP, is the President and Founder of Mile High Cyber, with over 30 years of experience in cybersecurity. A CISSP since 2008, he specializes in penetration testing, vulnerability management, and virtual CISO services, helping small and mid-sized organizations identify, remediate, and verify their most critical security risks.