CRM Security Requirements: A Buyer's Guide

Customer relationship management (CRM) platforms have become one of the most targeted SaaS systems, because one OAuth grant or one persuaded employee can export an entire customer base and the secrets staff paste into support cases. In 2025 the FBI warned that two criminal groups were stealing data from Salesforce instances, one by phoning staff and persuading them to approve a malicious connected app, the other with OAuth tokens stolen from a third-party chatbot integration. CRM selection is still led by sales, service and marketing on features and licence cost. This vendor-neutral buyer's guide sets out the security requirements to put into the RFP, how to weight them, what to ask and how to test it before signing. It is for security architects, CRM platform owners, privacy teams and procurement leads. For hardening a CRM you already run, see Securing the customer relationship management (CRM) platform itself.

Key takeaways

Control who can connect apps. The ability for any user to authorise a third-party or look-alike app is the single most important CRM control to evaluate; require administrator pre-approval of OAuth apps and per-app restrictions.
Integrations are the attack surface. Marketing automation, chat, enrichment, sales engagement and data tools all hold long-lived tokens; require scoped, expiring, IP-restricted and revocable integration access with an inventory.
Bulk export must be visible. Require logging of API queries, report exports and bulk data jobs with enough detail to see which app or user pulled how many records.
Cases and notes hold secrets. Support records collect passwords, API keys and access tokens pasted by customers and staff; require detection, masking and retention controls.
Test the attack paths in the PoC. Try to authorise an unapproved app, run a bulk export, revoke a token and search the audit log before you sign.

Define requirements

Agree the following with sales and service operations, marketing, the privacy office and the identity team before talking to vendors:

Clouds and modules: sales, service, marketing, commerce, partner portals, field service and analytics. Customer- or partner-facing portals add external identities and guest access paths. See the Salesforce Experience Cloud Security guide for how one portal model can expose records to guests.
Data classes: contact and account data, opportunity and pricing data, support cases and attachments, call recordings, payment references and any special category data. Decide which fields need encryption, masking or exclusion.
Integrations: list every planned connection: email and calendar sync, telephony, marketing automation, chat and AI assistants, enrichment, sales engagement, data warehouse and ETL, ERP and billing. Each is a non-human identity with standing access to customer data.
AI features: whether built-in AI assistants or agents will read records, draft replies or take actions, and on whose authority. See the AI Agents in Sales and CRM guide.
Residency and keys: hosting region, customer-managed key needs and any sector hosting requirement.
Help desk paths: who supports CRM users, how they verify callers, and who can reset CRM credentials or MFA. The FBI flash describes callers posing as IT support.
Exit: how records, attachments, metadata, audit history and configuration will be exported and deleted.

Small organisations with a single CRM tenant should focus on SSO with phishing-resistant MFA, app approval, integration token hygiene and export logging. Large organisations should add multiple tenants or business units with separate administration, field-level encryption with customer-managed keys, real-time event monitoring and a formal integration review board.

Capability areas

Identity and administration

Single sign-on and MFA: SAML 2.0 or OpenID Connect for every internal user, phishing-resistant MFA enforced through the identity provider, and local login disabled except for documented break-glass accounts. CISA's Secure by Demand guide asks whether standards-based SSO is included at no extra cost.
Provisioning: SCIM 2.0 or equivalent so leavers lose CRM access and their personal API tokens when the identity provider disables them. See the SCIM Provisioning Guide.
Permission model: object-level, field-level and record-level access, with administrative permissions such as "modify all data", "view all data", "export reports" and "API enabled" granted to named roles only.
Network and session controls: trusted IP ranges or device conditions for administrators and integration users, session timeouts and re-authentication for sensitive actions.
Administrator actions: impersonation or "log in as" restricted, logged with both identities and subject to the user's consent where the platform supports it.

Connected apps and OAuth governance

Pre-approval: the ability to block users from authorising any OAuth app that an administrator has not installed and approved, including for API-only tools such as data loaders.
Per-app policy: scopes limited to what the app needs, refresh token lifetime and rotation, IP restrictions, and the profiles or permission sets allowed to use each app.
Inventory and revocation: a list of every authorised app and active token with user, scopes, issue date and last use, and the ability to revoke one app's tokens across all users at once.
Standards alignment: RFC 9700, the IETF Best Current Practice for OAuth 2.0 Security, recommends limiting token privileges to the minimum needed and audience-restricting access tokens, and requires PKCE for public clients.

The FBI's September 2025 FLASH describes UNC6040 callers guiding staff to the connected app setup page to approve a malicious app, often a modified Data Loader, which then bypassed MFA and bulk-exported data. See the ShinyHunters Salesforce data theft campaign. The same FLASH describes UNC6395 using OAuth tokens stolen from the Salesloft Drift chatbot integration; Salesloft and Salesforce revoked all Drift access and refresh tokens on 20 August 2025. See the Salesloft Drift breach and the Gainsight Salesforce breach.

Integration users and API access

A dedicated, non-interactive integration user per connection, with a permission set scoped to the objects and fields that integration needs, rather than a shared administrator account.
Integration authentication by certificate or JWT bearer flow, or by OAuth client credentials, rather than a stored username and password.
API rate and volume limits configurable per integration, with alerts when an integration exceeds its normal pattern.
Signed outbound webhooks and an allowlist of outbound endpoints. See the CRM platform integration security guide and How to review Salesforce connected apps and integration users.

Data protection and export controls

Encryption at rest with an option for customer-managed keys and, for high-risk fields, field-level encryption that still supports the search and reporting you need.
Permission to export reports, run bulk API jobs and use data loader tools granted separately from read access.
Detection or masking of secrets and payment card numbers in cases, notes, chat transcripts and attachments, with retention by record type.
Guest and portal sharing settings that default to private, with a report of objects exposed to unauthenticated users.

Logging and detection

Audit records for sign-ins, permission changes, app authorisations, token use, API queries with row counts, report exports, bulk jobs, file downloads and setup changes.
Streaming of those events to your SIEM in near real time, and policy-based alerts or blocks on unusual export volumes where offered. See the Salesforce Event Monitoring Detection Guide for one example of event coverage and its licensing.
Security logs retained for at least six months at no additional charge, the baseline CISA's Secure by Demand guide sets for cloud and SaaS providers. Check carefully which events are in the base licence and which need an add-on.

Vendor assurance and contract

Independent assurance covering the clouds and region you will use, a published vulnerability disclosure policy and a recent penetration test summary.
A processor contract with the GDPR Article 28(3) terms and sub-processor notice under Article 28(2), and breach notification that lets you meet Article 33: notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals.
Rules for marketplace app vendors: what security review the CRM vendor performs and what it does not.

Evaluation criteria

Weights are illustrative. Increase the weight on OAuth governance and export logging if many third-party apps will connect.

Criterion	What good looks like	Evidence to request	Weight
Authentication and provisioning	SSO, phishing-resistant MFA and SCIM included; no login paths that bypass MFA	Licence schedule; authentication documentation	15%
Connected app governance	Admin pre-approval, per-app scopes and IP limits, token lifetime controls, bulk revocation	PoC test of an unapproved app	20%
Integration users	Per-integration non-interactive users, certificate or JWT auth, scoped permission sets, inventory with last use	Integration architecture; account list	15%
Permission model	Object, field and record controls; export and API rights separate from read	Permission matrix; PoC role test	10%
Data protection	Customer-managed keys option, field encryption, secret masking in cases, guest access defaults	Encryption whitepaper; PoC test	10%
Logging and detection	API, export and app events with row counts, SIEM streaming, six months or more included	Event list per licence tier; sample export	20%
Vendor assurance and contract	Reports in scope, VDP, Article 28 terms, marketplace review process, exit export	Reports under NDA; data processing agreement	10%

The threats below drive these criteria. ATT&CK IDs are from ATT&CK v20.

Threat	ATT&CK	Requirement
Voice phishing of staff to approve an app or share credentials	T1566.004 Spearphishing Voice	App pre-approval, phishing-resistant MFA, help desk verification
Theft of integration OAuth tokens	T1528 Steal Application Access Token	Short token lifetimes, IP restrictions, inventory and bulk revocation
Use of stolen tokens to query the CRM	T1550.001 Application Access Token	Per-app policies, anomaly alerts on API volume
Bulk theft of CRM records	T1213.004 Customer Relationship Management Software	Export and bulk API permissions, row-count logging, export alerts
Compromise through a connected vendor	T1199 Trusted Relationship	Integration review, scoped integration users, vendor token revocation
Credentials found in case records	T1552.001 Credentials In Files	Secret detection and masking in cases and attachments

Where identity fits

The 2025 Salesforce data theft campaigns described by the FBI did not need a software vulnerability: they used an identity the CRM already trusted, either an approved OAuth app or an integration token. That makes the CRM's non-human identities the centre of the evaluation. Require that every app and integration user has a named owner, a documented purpose, minimum scopes and a token lifetime, and that the platform can show last use so dormant grants are removed. Treat secrets found in CRM records as exposed and rotate them after any CRM or integration incident; the FBI FLASH recommends reviewing all third-party integrations and rotating their API keys, credentials and tokens. See the API Keys vs OAuth Tokens Guide and the OAuth Token Theft Incident Playbook.

Questions to ask vendors

Can we stop users from authorising any OAuth app, including API tools such as data loaders, unless an administrator has approved it?
For each connected app, can we set scopes, refresh token lifetime, IP restrictions and which users may use it, and revoke all its tokens at once?
Can integration users be non-interactive, authenticate by certificate or JWT, and be limited to specific objects and fields?
Which login paths, apps or API endpoints bypass SSO or MFA, and can each be disabled?
Which events (API queries with row counts, report exports, bulk jobs, file downloads, app authorisations) are in the licence tier we are buying, and how long are they kept at no extra cost?
Can we alert on or block unusual export volumes per user or per app?
How do you help us find passwords, keys and tokens pasted into cases and notes?
What default sharing applies to guest and portal users, and how do we report what unauthenticated users can see?
What security review do marketplace apps receive, and what happens to their tokens if the app vendor is breached?
Where is our data hosted and supported, who are your sub-processors, and what do you export and delete on exit?

Red flags

Any user can authorise any OAuth app, and there is no setting to require administrator approval.
Integration access only through a named user's password and security token.
Refresh tokens that never expire and cannot be restricted by IP address.
API query, export or download logs available only in a premium add-on, or kept for days.
No way to list all active tokens with last use.
Guest or portal sharing that defaults to public read on standard objects.
An assurance report that excludes the clouds or region you are buying.

Proof of concept

Connect the trial tenant to your identity provider with SSO, phishing-resistant MFA and SCIM; disable a test user in the identity provider and confirm their CRM session and personal tokens stop working.
Turn on app pre-approval, then as an ordinary user try to authorise an unapproved OAuth client and an unapproved data loader tool; both should fail and be logged.
Create two integration users with certificate or JWT authentication and different permission sets; confirm each can read only its scoped objects and fields.
Run a report export and a bulk API job for a large synthetic record set; confirm each appears in your SIEM with the user or app, record count and source IP, and test any volume alert.
Revoke all tokens for one connected app and confirm the integration stops within the documented time while others continue.
Paste a dummy API key and a test card number into a case and an attachment; check detection, masking and who can view the original.
Run the guest access report on a test portal and confirm unauthenticated users see only intended objects.

Use synthetic customer data. Score each step pass or fail; if app approval, token revocation or export logging fail, do not proceed on the promise of a later release.

After selection: measures and common failure patterns

Once live, track: connected apps without a named owner or used in the last 90 days (an NHI Mgmt Group recommendation for review frequency, adjust to your policy); integration users with "view all" or "modify all" style permissions; refresh tokens older than your standard; exports and bulk jobs above the normal volume per user or app; and the share of CRM sign-ins through SSO with phishing-resistant MFA. See the CRM platform health check and the Top 10 Salesforce Security Misconfigurations.

Open app authorisation: users can still approve any app, so one convincing phone call becomes a data theft.
Integration users as administrators: connectors run with full data access because scoped permission sets were never designed.
Forgotten integrations: trial or retired tools keep valid tokens for years. The Klue OAuth breach is an example of a forgotten integration credential exposing customers' CRM data.
Logs bought too late: event logging is added after an incident, leaving no record of what was exported. See If your CRM platform is compromised.
Secrets left in cases: credentials in support records are not rotated after an integration breach.

Framework mapping

Framework	Reference	Relevance to selection
NIST CSF 2.0	GV.SC-05, GV.SC-06, PR.AA-05, PR.PS-04	Supplier requirements and due diligence, access permissions, log availability
NIST SP 800-53 Rev. 5	SA-4, SA-9, SR-6, AC-2, AC-6, IA-2, IA-5, AU-11	Acquisition, external services, supplier review, accounts, least privilege, authentication, authenticators, log retention
GDPR	Articles 28, 32, 33	Processor contract, security of processing, breach notification
ISO/IEC 27001:2022 Annex A	5.15, 5.19, 5.23, 8.15	Access control, supplier relationships, cloud services, logging
MITRE ATT&CK v20	T1213.004, T1528, T1566.004	CRM data collection, token theft, voice phishing

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Security Requirements for Selecting a CRM: A Buyer’s Guide to Connected Apps, Data Export Controls and Testing