Hardening Salesforce access after token compromise
A token compromise changes the order of operations. Reaching for the rest of the tenant first only helps the attacker keep access while the clean-up drags on. Revoke the exposed token chain, kill active sessions, and cut off linked app access before any wider investigation starts.
That matters because a third-party compromise often leaves more than one credential in play. OAuth access tokens expire, refresh tokens do not behave like a polite guest, and connected apps can keep handing out access long after the original login looked dead. If a franchise document system, a Salesforce integration, or a synced storage account sits in that chain, assume the access path is still open until it is explicitly broken.
Pin down which Salesforce records and integrations were actually exposed
The blast radius is usually messier than the first alert suggests. In incidents of this sort, the exposed material can include Salesforce records holding personal and corporate data, plus franchisee documents stored through linked systems. That is enough for data exposure without any obvious outage or customer-facing disruption.
Start with the records that a compromised account could see, export, or sync. Then map the integrations that touched those records. A connected document repository, CRM automation, support tooling, or identity bridge may have pulled more than the attacker ever logged into directly.
Keep the scope tight. Not every connected system is part of the incident, and not every read access path becomes a write path. The useful question is dull but necessary: which records were readable, which files were reachable, and which integrations cached or mirrored them elsewhere.
Close the re-entry routes that token theft usually leaves behind
Token theft tends to leave side doors open. Session cookies survive longer than people expect. Refresh tokens survive even longer. API keys and app passwords often sit around in plain sight, which is a gift to anyone who has already got a foothold.
Resetting one password does not repair that. Disable or rotate the affected connected app credentials, clear trusted devices, and review any account that can mint tokens without a fresh human login. If the compromise came through a third-party account, treat that account as hostile until its auth path is rebuilt from scratch.
Cloud application logs matter here, but only if they actually cover the path used in the compromise. Logins, token grants, file reads, API calls, and admin changes need to sit in the same review window. Gaps are common. If the logs only show sign-in events and nothing from the document layer, the attacker probably had more room than the dashboard suggests.
Rebuild access with tighter scopes and logs you will actually read
Once the old chain is dead, rebuild the access path with smaller scopes. A connected app that can read records should not also be able to export documents, refresh sessions, and impersonate a user across half the tenant. Split those privileges where the platform allows it, then remove anything that was added for convenience and never revisited.
Logging should be boring and complete. Cloud application logs need to show token creation, token use, file access, admin changes, and unusual integration behaviour in one place. If the logs are too noisy to read, they are not a control, just decoration.
For Salesforce document access, that means watching for the combinations that matter: a third-party login followed by document pulls, record access outside normal franchisee workflows, and API activity from an account that never needed broad read rights in the first place. Narrow scopes do not stop every compromise. They do stop one compromised account from dragging the rest of the tenant along with it.
