The Supplier's Notice Landed on a Tuesday: Own the Vendor Vulnerability and Brief the Board on Exposure Windows

The views expressed are my own and do not represent those of my employer.

Imagine a plant controls engineer who gets a note from an equipment supplier on a Tuesday afternoon. The supplier's customer portal showed suspicious activity. Drawings, service tickets and a few shared logins may be involved. The note is polite and vague. It has no CVE number, no patch and nothing your scanner can see.

By Wednesday morning the real question surfaces. Is this the vendor's problem or yours? It is yours. The moment your data or your access sits inside their environment, their intrusion becomes your incident. You carry the customer calls, the notification duties and the board questions.

Most vulnerability programs measure what sits inside their own scanning scope. Attackers ignore that boundary. IANS's Q3 2026 Vulnerability and Breach Update reflects it: the quarter's breaches entered through third parties and cloud environments. IANS also tells teams to rank fixes by real exploitation and exposure, not CVSS. This is part 5 of 5 in my vulnerability management update series.

The scale matters too. The Identity Theft Resource Center counted 1,266 data breaches in Q3 2026, the highest of any quarter this year. Just 29 supply chain attacks accounted for nearly half of all victim notices. One vendor failure becomes many victims. If your reports cover only your own patching, you are measuring the smaller half of the risk.

Four Breaches, One Pattern

The IANS update draws on a run of 2026 breaches that began outside the victim's own walls. Four tell the story. One line each.

AdaptHealth. A social engineering ploy compromised a privileged account belonging to a third party contractor, and HHS lists 4,115,802 affected individuals.

Ernst & Young. Between March 28 and April 12, 2026, an unauthorized party accessed a third party support platform and downloaded client documents, and tickets on that platform may have included client tax information.

Amgen. In a July 2026 8-K, the company said proprietary data and patient protected health information were exfiltrated from cloud environments hosted by third party cloud service providers.

Aesto Health. HHS was told 9,540,683 people were affected after unauthorized activity in a portion of the company's AWS infrastructure, and the health systems and practices it served bear ultimate responsibility for notifying patients.

None of the four public accounts describes a patch the victim could have deployed on its own systems. Each began with trust extended to someone else. The lesson is blunt. A vendor's vulnerability is your incident, and data sitting in support tickets is in scope.

A vendor's vulnerability becomes your incident the moment your data or your access sits inside it.

What Changed Since My GV.SC Post

I covered the basics of supply chain risk governance in my NIST CSF 2.0 GV.SC post back in February 2026. If you are new to this, start there. This post picks up where that one left off.

That post built the governance: who owns supplier risk and what policy requires. Three things have changed since, and each one changes how you execute.

Speed. Rapid7's Q3 2026 threat update found exploitation came an average of three days after public disclosure, with 80% of tracked exploitation inside 14 days. A vendor on a quarterly patch cycle leaves your data exposed for weeks.

Fan out. A single compromised provider now reaches dozens of downstream organizations. At least two dozen Aesto Health provider clients were affected, and many never chose the vendor's cloud. They inherited it.

Delay. Aesto detected the activity on December 18, 2025, and began notifying its covered entity clients on June 26. That is roughly six months. Your clients, regulators and board will ask what you knew and when. Your contracts need to answer that before the incident.

Tier Vendors by What They Touch

Start with a tiering model built on two questions. What data does this vendor hold? What access does it have into your environment? Spend of any size does not belong in the answer.

Tier 1 holds regulated or crown jewel data, or has privileged access. Cloud hosts, managed service providers, IT service management platforms and contractors with admin rights land here. Tier 2 holds sensitive data without privileged access. Tier 3 holds neither.

Keep Tier 1 short enough that you can manage it by name. A list of 300 vendors with equal attention is a list nobody watches. Tier decides everything that follows: contract language, review cadence, monitoring and what the board sees.

Include your own role in the chain. If you process data for customers, you are their Tier 1 vendor. Aesto's clients inherited a notification duty they never chose. Your customers will do the same to you.

Write Two Clocks Into Every Tier One Contract

The first is a patch clock. Define how fast the vendor must remediate known exploited vulnerabilities on systems that touch your data. I start at seven days for internet facing systems on Tier 1 vendors, and I require a compensating control within 72 hours if a patch is not available. Rapid7's three day average is why the number is short.

The second is a suspicion clock. Most notice clauses trigger on confirmed compromise, and confirmation can take months. Trigger notice on suspicion instead. One practitioner newsletter suggests asking whether agreements require a contractor to report possible compromise of its credentials, session, device or identity provider before it knows whether your data was touched. I agree with that test. I write 24 hours into Tier 1 contracts.

Then track vendor exposure to CISA's Known Exploited Vulnerabilities catalog. Ask Tier 1 vendors for their internet facing product and component list. Match it against the catalog monthly. When a vendor product lands on the list, you should know before the vendor's notice arrives. If a vendor will not share the list, record that as a risk, because it already tells you something.

Treat Contractor Sessions as Privileged and Empty the Ticket Queue

AdaptHealth is a contractor identity story. After compromising the contractor, attackers used the credentials to find a stored insurance billing password and reach external electronic health record portals. A contractor account that can reach stored secrets is a privileged account, whatever the HR system calls it.

Apply the same controls you apply to your own administrators. Require phishing resistant MFA. Grant access just in time. Record sessions. Verify any help desk reset request with a callback to a number you already hold. Scan the places where contractors work for saved passwords and remove them.

Now the ticket queue. The Ernst & Young breach is a reminder that a support platform is a data store. People attach contracts, screenshots, exports and tax files to tickets because it is the fastest way to get help. Nobody classifies those attachments.

Clean it up this quarter. Inventory every support and ticketing platform, including the ones vendors run for you. Set retention so old attachments are purged. Block or flag sensitive uploads. Restrict bulk download. Rotate any credential that ever appeared in a ticket.

The ticket queue is a data store. Classify it, limit it and purge it like one.

The Plant Floor Has a Vendor Problem Too

Manufacturing adds three vendor paths that questionnaires rarely cover. OEM and supplier links carry orders, forecasts and specifications. Shared portals hold drawings, quotes and quality records. Remote vendor maintenance gives an outside engineer a live connection to equipment.

Treat each portal as a data store in your tiering. Ask who has accounts, who removes them when a supplier employee leaves, and what is stored there that should have expired.

For remote maintenance, I recommend brokered, time boxed sessions approved per event, recorded, and watched by a named employee for critical equipment. A scenario I have seen play out at multiple organizations is a standing vendor connection that nobody remembers approving. It stays open for years until an attacker finds it.

One more point for plant leaders. Many industrial vendors cannot patch on a corporate timeline, and that is real. Put the exception in writing with an owner, a compensating control and an end date. I wrote about the broader exposure approach in my guide to continuous threat exposure management.

The Board Page That Holds Up

Patch counts tell the board how busy your team was. They say nothing about how long the company was exposed. Replace them with exposure windows, which show the time between a risk becoming exploitable and your closing it.

Four measures cover the page. First, time to remediate known exploited vulnerabilities on internet facing assets. Second, the share of edge devices patched within SLA. Third, end of life exposure: how many unsupported systems are reachable and for how long. Fourth, accepted risks with an expiry date, because an exception with no end date is a permanent decision nobody made.

Add a vendor view. Show how many Tier 1 vendors carry a known exploited vulnerability today, how many have the patch and suspicion clocks signed, and how many contractor sessions run under privileged controls. Keep it to a handful of numbers with a trend line.

Close the page with a decision table of three rows. Each row names the decision, the exposure it addresses, the owner and the date. Here is what I would put in it.

Decision one. Approve the patch and suspicion clocks as a contract standard for Tier 1 vendors, with executive sign off when a vendor refuses.

Decision two. Fund privileged access controls for contractors and vendor remote sessions.

Decision three. Set a retirement date for the oldest end of life system with the highest exposure, or sign a time limited acceptance.

Patch counts show how busy you were. Exposure windows show how long the business was at risk.

Getting Organizational Support: Say Exposure, Not CVE

The board. Frame it as a question of who holds your data and how long you stay exposed when they fail. Cite the breaches above. Ask for three decisions, not a briefing. For more on this approach, see Winning the Room.

The CEO and CFO. Talk about downstream customer commitments, notification costs and revenue at risk if a key supplier or portal goes down. A contract clause costs less than an incident response retainer used on a vendor's behalf.

Legal and procurement. They own the contract language. Bring them a one page standard with two clocks and a short list of vendors. Make it easy to say yes.

Business owners. They chose the vendor and hold the relationship. Show them that tiering protects their operation and does not slow their purchase.

IT and plant leaders. Offer a clear exception process with owners and end dates. People accept rules they can see an exit from.

Vendors. Most will agree to clocks if you ask early and consistently. The ones who refuse are telling you about their posture.

Key Points

• A vendor's breach is your incident when your data or access is inside it.
• Tier vendors by data held and access granted, and keep Tier 1 short.
• Put a patch clock and a suspicion based notice clock in every Tier 1 contract.
• Treat contractor sessions as privileged and remove saved passwords.
• Inventory support platforms and purge old ticket attachments.
• Track vendor products against the known exploited vulnerabilities catalog.
• Give the board exposure windows, a vendor view and three decisions.

Pro Tips

Ask for the component list, not the questionnaire. A vendor's answer to "what internet facing products do you run" tells you more than 200 yes or no controls.

Rehearse the Tuesday call. Run a 30 minute tabletop where a Tier 1 vendor sends a vague notice. Time how long it takes to learn which of your data sits there.

Watch your own exposed support accounts. Attackers who hit a ticketing platform often find credentials for other systems inside it. Rotate on the day you hear about a vendor incident.

Keep an exit path for every Tier 1 vendor. You rarely replace one in a week. You can still document what you would disable first.

Pitfalls to Avoid

Do not tier by spend. A small vendor with a privileged login is a bigger risk than a large vendor with no access.

Do not write notice clauses that wait for confirmation. By then the facts are months old.

Do not report patch counts to the board and call it vendor risk. Counts reward activity, not reduced exposure.

Do not forget your support platforms. The data you never classified is the data an attacker finds first.

Do not leave accepted risks open ended. Every exception needs an owner and an expiry date.

Final Thought

You will not patch your vendors' systems, but you can decide how fast they must, how soon they must tell you, and how much of your business sits inside their walls, and the CISOs who set those terms before the Tuesday notice arrives will be the ones the board trusts afterward.

If this was useful, subscribe so you get the next post, and share it with a CISO who is rewriting a vendor contract this quarter. Tell me in the comments which of the four breaches changed your thinking and what your vendor notice clause says today. I read every one.