Your Vendor’s Certificate Doesn’t Describe Your Keys

October 6, 2026

Information Security

Snowflake’s own platform was never breached in the 2024 campaign that carries its name. Infostealer malware had been collecting customer credentials for months, in some cases years, and attackers used them to log into tenants where multi-factor authentication had never been switched on. A few of the passwords dated to 2020 and had never been changed. About 165 customers were affected, and every one of them was buying from a vendor with serious certifications and a decent reputation.

A later incident came at the same problem from the side. Credentials taken from an analytics vendor opened the Snowflake environments of that vendor’s own customers. Nothing in Snowflake needed to be broken. Anyone searching Snowflake’s footprint alone would have missed the link, because the grants sat in the identity provider and in stored keys outside single sign-on. The procurement record named one vendor. The access reality was a credential the client no longer fully controlled.

Neither story is about a bad vendor. Both involve an access relationship that went untouched after go-live.

Two documents that never meet

Open a typical vendor file, and the contents are predictable. A SOC 2 report from last spring. A questionnaire with a hundred and forty answers. A certificate of insurance, a signed data processing addendum, a note that the annual review is due in March.

Now open the admin page of the CRM that the vendor connects to. Three named users, two of whom have left the vendor. A service account created in 2021 called sync_prod. An OAuth grant whose scope nobody on the current team chose. Next to the grant is a button labelled “last used,” and it says yesterday.

Procurement owns the first document. Whoever needed the integration to go live owns the second, if anyone does. Certifications describe the vendor’s house. They do not describe the keys handed over to yours.

One vendor, many ways in

One line in procurement can stand for dozens of routes into an environment. Some are easy to picture: named support staff, a contractor, a break-glass administrator account. Others are indirect, such as a vendor’s subcontractor or a managed service provider’s remote tool.

Machine routes cause the most trouble, partly because they get created so casually. A marketing manager connects a new email tool to the CRM. A permissions screen asks for read and write access to every contact. The launch is Thursday, so the request gets approved. Procurement never hears about it. No owner is recorded, and no expiry is set. MFA does not apply, since there is no person to challenge. Eventually the integration vendor is acquired, and its engineers move on. The token goes on working.

Surveys keep finding that most organisations cannot see all the vendors connected to them this way. The people who approved the grants were not careless. They needed something to work by Friday.

How excess access gets made

Nobody sets out to over-provision a vendor. An implementation is urgent, and the role design is vague, so administrator rights get granted. The project wraps up, and no step in the process asks anyone to take them back. When the next project starts, permissions grow again. Nobody subtracts the old ones.

The real version is untidier. There is a shared login called something like vendor_support2, created because individual onboarding was going to take three weeks. Its password sits in a spreadsheet that four people can edit, one of whom left last spring. The spreadsheet tab is named “temp.” Somewhere in the helpdesk system, there is a 2022 ticket with an API key pasted into it, put there so the vendor could debug a sync failure. Anyone with helpdesk access can still search for it, and the engineer who pasted it has since changed teams twice.

Temporary access becomes the architecture. The permission granted for the cutover is still there at renewal. Excess access is the absence of a decision to remove it.

Verizon’s 2026 Data Breach Investigations Report puts numbers on how slowly this gets fixed. Among third-party organisations, 23% had fully corrected missing or improperly secured MFA on their cloud accounts. Weak passwords and permission misconfigurations in third-party cloud environments took close to eight months to resolve for half of the findings. The report’s explanation is that excessive-privilege problems seldom have a simple fix, particularly where cloud permissions are granular. Most people hesitate before removing something they cannot fully trace.

Its headline figure, 48% of breaches with third-party involvement, needs careful handling. Verizon counts partner infrastructure and flaws in third-party software together, so the number does not mean half of all breaches began with a vendor login. The trend is the usable part. The same measure stood near 15% two years earlier.

Same vendor, different exposure

Every Snowflake customer had the same vendor. Customers that enforced MFA, rotated credentials, and restricted network access were mostly untouched. The platform offered those controls, but on many accounts they were optional and off by default, so responsibility sits on both sides. Snowflake has since moved to default MFA enforcement for new accounts.

Picture two clients of one analytics vendor. The first connects through a named service principal, scoped to one reporting dataset, allowed only from the vendor’s published IP ranges. The credential expires every ninety days, and the person who renewed it last time still works there. The second client’s vendor logs in as admin. The password was set during the pilot and changed once, when somebody left. Nobody has written down what admin can see.

Then the vendor’s laptop fleet gets hit. The first client rotates a key on a Tuesday afternoon. The second spends three weeks working out what admin touched.

Incidents filed under one heading often differ in kind. MOVEit in 2023 was a zero-day in a file-transfer product, with public reporting putting the affected organisations above 2,600. The data was already sitting with the vendor, so revoking anyone’s login recalled nothing. Target in 2013 belongs to a different group. Attackers used credentials from an HVAC contractor whose connection, by most accounts, handled billing, contract submission, and project management. The access was ordinary and justified on its face. The trouble was where the network let it travel next, toward the systems holding payment data.

Map the path, not the list

The Salesloft Drift compromise in 2025 shows how far a single integration can reach. OAuth tokens tied to a third-party app connected to Salesforce exposed more than 700 organisations. Google’s threat intelligence group found the attackers combing the stolen data for secrets that would open further doors, such as cloud keys and Snowflake tokens. Some of that material sat in support-case text, where customers had pasted credentials while asking for help. The vendor’s reach included everything it could read, not only what it could log into.

A useful record per vendor fits on one page. Two names go on it: one business owner and one technical owner. A review date. A plain statement of what the access can do. Then the field most records leave blank: where it leads next. From this credential, can someone move into identity, backups, finance, customer data? Beside that goes an estimate of how long full revocation would take, ideally from someone who has tried it.

Starting with every vendor at once is a mistake. The first pass belongs to those touching regulated data, production systems, identity, and financial or HR platforms.

Reduction is the step nobody owns

Accounts get requested, approved, and reviewed. Far fewer processes ask whether a privilege that made sense six months ago should still exist today. Annual reviews certify the company. They miss that a project account is still live, that a token was copied into a second tenant, or that a support user inactive for 140 days still holds administrator rights.

The signals that would catch these cases already exist. Renewals show up in procurement, project closures in the PMO, inactivity in IAM logs, new grants in SaaS admin alerts. Nobody connects the four.

Shared vendor accounts are the easiest place to start, since they can be retired without rearchitecting anything. Administrative access should expire on its own. An API key with no internal owner eventually becomes nobody’s problem.

Some of this is hard. Just-in-time access takes engineering effort, and some SaaS platforms offer only coarse controls.

The test

Pick any vendor. How long would it take to cut every path that vendor has into the environment, and how sure is anyone that the list of paths is complete?

Questionnaires, contracts, and certifications keep their place. They show whether a vendor can protect what it holds.

An organisation that cannot remove a vendor’s reach in hours has a dependency, not an access relationship.