Four 8-Ks in two weeks: legitimate access, misused

Between September 8 and September 23, 2026, four listed companies filed a Form 8-K with the SEC for a cybersecurity incident, and the Office of the Privacy Commissioner of Canada acted twice on third-party service providers. Read together, these six texts tell the same story: the attacker did not force the door, it used an access that already existed.

What the filings say

Boston Scientific (Item 1.05, report dated September 7, signed on the 8th). On August 25, 2026 the company had identified "a cybersecurity incident that affected certain of its information technology systems and resulted in a global disruption to the Company's operations". The filing describes "a network outage affecting access to certain operating systems and business applications". The company concludes that the incident "is likely to have a material impact on the Company's results of operations for the third quarter and full year 2026". The filing does not describe the entry vector.

Veradigm (Item 8.01, September 8). A third-party vendor suffered an incident: "an unauthorized party obtained credentials from the vendor's environment to a Company application programming interface used by the vendor to provide services on behalf of the Company's customers". Those credentials were used to download personal data of patients, "including, in some instances, Social Security numbers". The filing states that the credentials "provided access only through that limited interface" and that the incident "did not result in any operational disruptions".

CenterPoint Energy (Item 8.01, September 14). The company established that an unauthorized third party obtained personal information "through one of the Company's external facing systems". Electric and gas delivery "has not been impacted and remains operational and undisrupted", and the company does not consider a material impact on its results "reasonably likely".

Astrana Health (Item 1.05, signed September 23). The filing describes "a series of social engineering attempts in which threat actors, impersonating Company personnel and spoofing the Company's main corporate telephone number, contacted certain employees". It "has determined that the incident is material as of September 22, 2026, due to the potential confidential and sensitive nature of the data that is involved", while not expecting a material effect on its results.

The Commissioner, twice. On September 10, the OPC published guidance for organizations subject to PIPEDA on assessing a third-party service provider before retaining it, open for comment until December 4, 2026. The release reminds organizations that they remain responsible for personal information under their control, "including data that is collected by a third party on their behalf or transferred to a third party for processing". On September 21, it opened an investigation into IDScan.net after the theft of "digital scans of driver's licences and other types of identification"; the investigation will examine the security safeguards in place and "the adequacy of its notifications to affected individuals".

Why it matters

Three of the four filings name a legitimate entry path: an external-facing system, vendor credentials to an API, a call displaying the company's own number. None mentions a software vulnerability. The controls that would have counted are identity and access controls, not patching.

The second lesson is about materiality. Astrana declares itself material because of the nature of the data and files the day after its determination. Boston Scientific declares itself material through its operations. CenterPoint and Veradigm choose Item 8.01 with the words "not reasonably likely". The decision does not depend on the number of people affected, which none of the four filings quantifies. It depends on two questions the board must have settled before the incident: which interruption of operations is material, and which category of data is material by nature.

Finally, the two OPC actions ask the questions a Canadian regulator will ask after any of these incidents: what had you verified about this third party before entrusting it with data, and were your notifications to affected individuals adequate?

What we think at Sentrix

An annual questionnaire would have seen nothing of this September. In order:

1. Write the materiality grid before the incident. Two axes, operations and data, with thresholds drawn from your own business. On the day, you tick boxes, you do not debate.
2. Inventory every third party that holds a credential or API access in your environment. That is the inventory the CTEM continuous exposure module keeps current: exposed systems, service accounts, API keys, one owner per line.
3. Require by contract what the filings show is necessary: access bounded to the interface strictly needed (the clause that contained the Veradigm incident), rate limiting and an alert on bulk downloads, MFA on the vendor's accounts, credential rotation on a fixed schedule, API access logs you can read, notice of any incident at the vendor within 24 hours.
4. Verify by call-back any call that asks for access, even when the displayed number is the company's own, as Astrana shows.
5. One program, four frameworks. PIPEDA (s. 10.1), Law 25 (ss. 3.5 to 3.8 on confidentiality incidents, 18.3 on communication outside Quebec), NIS 2 (art. 21(2)(d), supply chain) and DORA (chapter V, ICT third parties) ask for the same things: a register of third parties, an assessment before engagement, contractual clauses, a notification process. Evidence is collected once and mapped to each.

Our third-party management module keeps that register and that evidence, with data hosted in Canada (execution in the United States or another region on request).

The next step

Take the list of your third parties that hold a credential or an API key and write, for each one, the date of the last rotation and the name of the person who reads the logs. The empty lines are your work plan. If you want us to run the exercise with you, contact us.