Most organizations lock down who can log in to the CRM and then forget the other doors. Every connected marketing platform, billing tool, enrichment service, and custom script has its own credential, and those credentials often have broad access, no expiry, and no clear owner. When a CRM data leak traces back to a connected application, the cause is usually not a clever exploit. It is a long-lived token that nobody remembered to review.

Why Integrations Are a Distinct Risk

User accounts are tied to people, who get onboarding, offboarding, and multi-factor prompts. Integration credentials are tied to systems, and systems rarely get any of that. A token created during a pilot can outlive the pilot by years. Because integrations run unattended, misuse can look like normal traffic. And because they often read or write at volume, a compromised integration can move a large amount of data quickly.

Build an Integration Register

You cannot secure what you have not listed. Start with an inventory that records, for each connection: what it is, what business purpose it serves, who owns it, what data it can read or write, what type of credential it uses, and when the credential was created. Sources for this list include the CRM’s own connected-apps or API settings, your identity provider’s application list, finance records for subscriptions, and a short conversation with each department. Expect to find items nobody on the IT team knew about.

Apply Least Privilege to Every Connection

For each integration, ask what it genuinely needs. A tool that sends newsletters probably needs to read contacts, not delete accounts or export financial notes. Where the platform supports granular scopes, grant only those required. Where it only offers broad access, consider whether a dedicated integration user with a restricted role is possible, since that limits what the credential can do even if the integration itself requests more. Check the vendor’s current documentation for what scoping options exist.

Handle Credentials Like Secrets

API keys and tokens should never live in spreadsheets, chat messages, shared documents, or source code repositories. Store them in a secrets manager or the secure credential storage your platform provides. Give each integration its own credential rather than reusing one across tools, so that you can revoke one without breaking others and so that logs show which integration did what. Where possible, prefer short-lived tokens obtained through standard authorization flows over permanent static keys.

An Integration Review Table

Use these checks when reviewing each connection.

Check	What good looks like	Red flag
Ownership	A named person and team are accountable	“Someone in marketing set it up”
Scope	Only the objects and actions required	Full administrative access for a read-only task
Credential age	Rotated on a schedule or short-lived	No record of when it was created
Storage	Held in a secrets manager	Pasted in a shared document or code
Visibility	Activity appears in logs and can be attributed	Shares a login with other tools
Lifecycle	Removed when the project or contract ends	Active long after the business need ended

Rotation and Retirement

Set a rotation routine that matches the sensitivity of the access, and rotate immediately when a person with knowledge of a key leaves, when a key may have been exposed, or when a vendor reports an incident. Rotation is easier when each integration has its own credential and a documented procedure, because you know exactly what to update. Retirement matters just as much: when a tool is cancelled, revoke its access in the CRM on the same day, not when the invoice stops. Deleting the vendor account without revoking the token leaves the door unlocked.

Test Changes Before You Break Production

The reason teams avoid tightening integrations is fear of breaking workflows. Reduce that fear with a staging approach. Use a sandbox environment if your CRM offers one, apply the narrower scope there, and confirm the integration still works. Announce the change to the business owner, schedule it outside peak sales hours, and keep the previous credential available briefly for rollback. A planned, communicated change is far less disruptive than an emergency revocation after an incident.

A Realistic Example

Picture a company reviewing its integration register and finding eight connections. Three are active and well understood. Two belong to tools the company stopped using last year, but their tokens still work. One is a custom script written by a former contractor, using an administrator’s personal credential. Two have unclear owners. The team revokes the two dormant tokens immediately, replaces the contractor script’s credential with a restricted integration user, and asks each department to claim or release the unclear ones within two weeks. Anything unclaimed gets disabled with a notice. The result is a smaller, owned, documented set of connections.

Monitor for Misuse

Once the register exists, add monitoring. Watch for sudden spikes in API calls, large exports from an integration that normally reads a few records, access from unexpected networks, and failed authentication bursts. Alert thresholds should be based on each integration’s own normal behavior, which is why attribution through separate credentials is so useful. Route alerts to someone who can act and who understands what the integration should be doing.

Frequently Asked Questions

What is the difference between an API key and an OAuth token? An API key is typically a static secret that grants access until revoked. OAuth tokens are issued through an authorization flow, usually with defined scopes and an expiry, which generally makes them easier to limit and rotate. Which options exist depends on the platform.

Should integrations use an administrator’s account? Generally no. Use a dedicated integration identity with a restricted role, so the connection does not break when a person leaves and does not inherit unnecessary privileges.

How do we find integrations nobody told us about? Combine the CRM’s connected-apps list, identity provider application records, subscription and expense data, and conversations with team leads. Treat the first sweep as an amnesty, not an investigation, so people disclose openly.

How often should API keys be rotated? There is no single right interval. Base it on sensitivity, vendor guidance, and your own policy, and always rotate after staff changes or suspected exposure.

Can a vendor’s security certification replace our own review? No. A certification says something about the vendor’s practices, but your configuration, scopes, and data-sharing choices remain your responsibility.

Next Step

Create the integration register this week, even if it starts as a simple spreadsheet with six columns. Revoke anything dormant, assign an owner to everything else, and schedule the first rotation. Consult qualified security professionals where integrations handle regulated or especially sensitive data.