Most CRM security discussion focuses on people: passwords, multi-factor authentication, who can see which records. Meanwhile a quieter population of non-human access grows in the background. API keys, OAuth tokens, connected apps and service accounts let your marketing platform, billing tool, data warehouse and a dozen scripts read and write customer data around the clock, and nobody logs in to them or notices when they misbehave.

In practice these credentials are often the weakest link. They are created in a hurry, given broad permissions because it was easier, pasted into a config file, and then forgotten when the person who set them up moves on.

Build the Inventory First

You cannot protect what you cannot list. Start by finding every non-human way into the CRM:

• API keys and personal access tokens generated by individual users.
• Connected or OAuth-authorised apps, including marketplace add-ons.
• Integration users or service accounts created for middleware.
• Webhook endpoints that receive data from the CRM.
• Scripts and scheduled jobs on someone’s laptop or a shared server.

Check your CRM’s administration console for lists of connected apps and tokens, and the vendor’s current documentation for where each type is shown. For each entry, record what it connects to, who owns it, what it can access, when it was created, and when it last made a call. Entries with no owner or no recent activity go on a review list.

The last-used date is the most useful column. A key unused for months is a risk with no benefit, and retiring it costs nothing.

Apply Least Privilege to Machines Too

A person with a broad profile is bounded by what they do in a day. An integration with a broad profile can export everything quietly. Scope every integration to the minimum it needs:

• Give each integration its own identity, never a shared admin login or a human user’s credentials. When that person leaves and is deactivated, the integration should not stop, and when the integration is compromised, you should not have to rotate a person.
• Limit it to the objects and fields it needs. A mailing sync does not need access to contract values.
• Prefer read-only access where the tool only reads.
• Where the platform supports it, restrict by IP range or network, so a stolen key is less useful elsewhere.
• Prefer tokens that expire or can be revoked individually over one permanent key shared across tools.

Store Secrets Where Secrets Belong

A common trap is the secret in the wrong place: a key in a spreadsheet, a chat message, a shared document, or committed to a code repository. Treat any secret that has appeared in those places as exposed.

Use a dedicated secrets manager or your cloud platform’s secret store, and have applications read credentials at run time. Keep keys out of source code and out of client-side scripts, since anything delivered to a browser can be read by a user. Limit which people can read the secret itself; being able to deploy an integration does not require being able to see its key.

Where a vendor offers a choice between a static key and an OAuth-style flow with refresh tokens, the latter usually gives you better control over scope and revocation. Check what your platform supports.

Rotate on a Schedule and on Events

Set a rotation rhythm appropriate to the sensitivity of the data, and rotate immediately on specific events: a team member with access leaves, a key appears somewhere it should not, an integration vendor reports an incident, or a project is retired. Rotation is much easier if each integration can be reconfigured in minutes. If rotating a key means a week of detective work, that is itself a finding.

Monitor What the Machines Do

Turn on whatever audit and API-usage logging your plan offers. Useful signals are sudden spikes in call volume, bulk exports at odd hours, calls from unfamiliar locations, and failed authentication bursts. Even a monthly look at per-integration usage will show what normal looks like, which is what makes abnormal visible.

A Review Table You Can Reuse

Question	Good answer	Action if not
Does it have a named owner?	Yes, with a backup	Assign or retire
Is it a dedicated identity?	Yes, not a person’s login	Create a service identity
Is access minimal?	Only needed objects, read-only where possible	Reduce scope
Where is the secret stored?	Secrets manager	Move it and rotate
When was it last used?	Recently and as expected	Investigate or revoke
When was it last rotated?	Within your policy	Rotate
Is activity logged?	Yes, reviewed periodically	Enable logging

A Hypothetical Example

An administrator reviewing connected apps finds eleven entries. Three have no owner. One is a token created by a former employee for a reporting script, with access to all objects, last used many months ago. Two others are marketplace apps from a trial nobody finished.

She revokes the stale token and the abandoned trials, which takes ten minutes and breaks nothing. The reporting need turns out to be live, so she creates a dedicated read-only identity for the script, with access limited to the three objects it uses, and has the owner move the key into the company’s secrets store. The review table becomes a quarterly calendar entry.

When a Key Leaks

Have the sequence ready before you need it. Revoke the credential first, since speed matters more than elegance. Issue a replacement with narrower scope and update the dependent integration. Then look back through logs for what the old credential did and when it was exposed, to judge whether customer data was accessed. Depending on your jurisdiction and contracts, a data exposure can trigger notification obligations, so involve whoever handles legal and privacy and consult qualified professionals about your specific duties.

Frequently Asked Questions

Do integration users count toward our licences? It depends on the vendor and plan. Check the current licensing documentation rather than assuming either way.

Is it safe to use one API key for all our tools? No. One shared key means one leak exposes everything and you cannot tell which tool did what. Use separate credentials per integration.

How often should we rotate API keys? There is no universal answer. Base it on data sensitivity and how easily you can rotate, and always rotate on staff departures or suspected exposure.

Should marketplace apps be reviewed too? Yes. Read the permissions they request, remove those you do not use, and prefer apps that ask for narrow scopes.

Who should own integration credentials? A named team or role, not an individual who might leave. Record a backup owner too.

Next Step

Open your CRM’s connected apps and token list this week, add an owner and a last-used date to each, and revoke anything nobody can explain.