The access nobody reviewed: contractors, remote access and connected apps

Three years ago, an integrator needed an administrator account to migrate the ERP. The IT provider installed a remote support tool "for support". A sales rep connected a chat assistant to the CRM, accepting the requested permissions in one click. Each time, the need was real and the access legitimate. Each time, nobody set an end date.

Our position: your riskiest vendor access was probably granted in one click, and nobody has reviewed it since. It doesn't show up in the account review, in the vendor's security questionnaire, or in the inventory of what you expose. It falls between all three.

What the Salesloft Drift incident showed

Drift is a website chat assistant made by Salesloft. To do its job, it connects to its customers' Salesforce CRM with an OAuth token: a lasting authorization, granted once, that lets the app read and write in the CRM without asking for a password again.

• From August 8 to at least August 18, 2025, an actor Google tracks as UNC6395 used stolen OAuth tokens from the Drift app to export large volumes of data from numerous Salesforce instances: support cases, accounts, users, sales opportunities. It then searched that data for AWS access keys, passwords and Snowflake tokens. Status: confirmed by the Google Threat Intelligence Group in its August 26, 2025 advisory.
• Tokens from the "Drift Email" integration were also used on August 9 to read email in a very small number of Google Workspace accounts connected to Drift. Status: confirmed by Google.
• On August 20, Salesloft and Salesforce revoked every active token for the app. Status: confirmed.
• More than 700 organizations were potentially affected, according to the Google Threat Intelligence Group as quoted by The Hacker News. Status: reported.
• The root: access to Salesloft's GitHub account from March to June 2025, then to Drift's AWS environment, where the tokens were taken, according to Salesloft's September 6, 2025 update following Mandiant's investigation. Status: confirmed by the company, reported by The Register.

What it changes: the affected organizations weren't hacked in the usual sense. No employee password stolen, no multi-factor authentication bypassed. The token was valid: it had been granted, sometimes long before, often with broad rights, and it worked exactly as designed, for someone else. The Google Threat Intelligence Group also states that the incident did not stem from a vulnerability in the Salesforce platform. And the most valuable thing in the CRM for the attacker wasn't the customer list: it was the passwords and keys pasted into support cases, which opened other doors.

Three kinds of access that age badly

Contractor accounts. The account created for the integrator, the consultant, the former IT provider. Often shared by several people at the vendor, sometimes with admin rights, rarely disabled when the project ends. The end of the contract ends the invoicing, not the access.

Remote access. VPN accounts, remote support tools, management agents a provider installed on workstations and servers. CISA, with the NSA, the FBI and their partners, devoted an entire guide to these tools: they often carry privileged access, they are legitimate, so security tools rarely flag them, and attackers co-opt them to get in and stay in. A tool installed by a former provider is a door you no longer hold the key to.

Connected apps. The connector between your email and an e-signature tool, between your CRM and an assistant, between your files and a scanning service. An OAuth token doesn't go through multi-factor authentication each time it's used, and it often survives a password change: it has to be revoked explicitly. We covered the specific case of consumer AI assistants and their connectors in the October 29 episode of our AI series.

What the three have in common: a creation date, almost never an end date, and rarely an owner on your side.

Why nobody reviews them

Every existing review looks somewhere else.

• The account review covers employees, starting from payroll. The contractor's account isn't on it, the connected app even less.
• The vendor security questionnaire asks the vendor how it protects its systems. It doesn't ask what access you gave it inside your environment, or what a token is worth if it's stolen from the vendor. That is exactly what played out with Drift.
• The exposure inventory lists what can be reached from the internet. An OAuth token can't: it lives inside the SaaS platform, not on your perimeter.

The result: the access belongs to IT, to procurement and to the team that asked for it, so to nobody. The day the vendor is compromised, you discover that you know neither what access it had nor who can cut it.

The three-field rule

Any access granted to a third party, whether an account, remote access or a connected app, should only exist with three fields filled in:

1. An owner on your side, named, who answers for that access and can cut it.
2. A need and a scope: why the access exists and what it can read or change. "Full access" is not a scope.
3. An end date, or failing that a review date. Access without an expiry renews itself silently, forever.

Add one line to your contract exit procedure: ending a vendor relationship triggers the revocation of its accounts, remote access and connected apps, with a date. The NIST Cybersecurity Framework 2.0 makes this an explicit expectation: supply chain risk management plans include provisions for what happens after a partnership or service agreement ends (GV.SC-10).

This weekend's test: thirty minutes, three lists

Sit down with the person who administers your email and your CRM.

1. Connected apps. In Microsoft Entra ID, the list of enterprise applications and the permissions granted to them; in Google Workspace, the API controls page, which lists third-party apps with access to your data. Flag the ones that read email, files or calendars.
2. Remote access. List the VPN accounts and remote support tools third parties use, with the last time each was used.
3. Your most critical SaaS. Open the connected apps list of your CRM or ERP, and note for each one the date it was authorized and the rights it holds.

Three results should worry you. An app that reads email or files and that nobody recognizes: that's permanent access without an owner. An account or remote access still active for a vendor whose contract has ended: your exit procedure stops at the invoice. A connected app with full access, authorized more than a year ago: nobody knows what it does anymore, or what its token would do in other hands.

This test only sees the access that goes through your consoles. Accounts a vendor created directly inside a business application escape it: it's a floor, not a ceiling.

What you should have a week from now

One page: every access granted to a third party, with its owner, need, scope and end date. Access without an owner is cut or assigned. And one more line in the contract exit procedure. It's half a day's work, to be repeated every quarter for critical vendors.

The vocabulary is in our entry on third-party risk management.

Sources: Google Threat Intelligence Group, Widespread Data Theft Targets Salesforce Instances via Salesloft Drift (August 26, 2025, updated August 28) · The Hacker News, more than 700 organizations potentially affected · The Register, the way in through Salesloft's GitHub account (September 8, 2025) · CISA, Guide to Securing Remote Access Software · Microsoft Learn, review permissions granted to enterprise applications · Google Workspace, control which third-party apps access your data · NIST, Cybersecurity Framework 2.0 (CSWP 29)