A customer relationship management (CRM) platform holds the customer list, contact details, deal history, support cases and often contract and payment data, and it is wired into marketing, email, telephony, billing and data warehouse tools, so a single compromised admin or integration user can export the whole customer base. CRM platforms are usually run by sales operations or a business systems team, and their administration often sits outside the security team's normal privileged access controls. This guide treats the CRM as a product class and covers how to secure the platform itself: administrator roles, integration users and connected apps, API tokens and keys, public portals, sandboxes, logging and lifecycle. It is vendor-neutral and based on NCSC, NIST SP 800-53, OWASP and CIS Controls v8.1 guidance. It is written for CRM administrators, business systems owners and security teams. For SaaS security as a discipline, see the SaaS Security Guide.
Key takeaways
- Treat CRM administration as privileged access. CRM admins can change sharing rules, grant API access, install integrations and export data; they need dedicated accounts, phishing-resistant MFA and review like any other privileged role.
- Connected apps and integration users are the main exposure. OAuth grants and API users often hold read access to every record. Restrict which apps users can authorise, scope each integration and inventory them.
- Control the bulk export paths. Report export, data export jobs, bulk APIs and data loaders are how CRM data leaves in volume; limit who holds them and alert on use.
- Public portals and guest access are part of the platform. Customer and partner portals expose CRM objects to the internet; their sharing settings need the same scrutiny as internal roles.
- Help desk and phone-based tricks target CRM users. Social engineering that gets a user to authorise a malicious app needs no password theft; control app authorisation centrally.
What makes up the CRM's attack surface
Most CRM platforms are software as a service, so the provider runs the infrastructure and the customer owns configuration, identities, integrations and data access: a shared responsibility. The table below lists what the customer controls.
| Component | What it can do | What an attacker gains |
|---|---|---|
| System administrator roles | Change security settings, sharing model, users, permissions and integrations | Read and export everything, switch off logging, add backdoor users |
| Connected apps and OAuth grants | Read or write records on behalf of users or a service | Persistent API access that survives a password reset |
| Integration and API users | Sync records with marketing, billing, support and analytics tools | Bulk read of customer data through a trusted identity |
| Installed packages and extensions | Run code and hold permissions inside the tenant | Code running with platform rights |
| Customer and partner portals | Expose objects to external and guest users | Unauthenticated or low-privilege access to records |
| Sandboxes and test tenants | Hold copies of production configuration and often data | A lower-assurance copy of the customer base |
| Outbound messages, webhooks and email services | Send data and email to external endpoints | Data sent to an attacker endpoint, or trusted email for phishing |
The ATT&CK techniques this enables include T1528 Steal Application Access Token, T1213 Data from Information Repositories and T1566.004 Spearphishing Voice.
Administrative roles and access to the platform
- Few full administrators: keep the full system administrator role to a small number of named people. Use delegated or limited admin roles for user support, report management and object configuration. NCSC: full, system-wide access should be the exception, not the norm.
- Single sign-on with phishing-resistant MFA: enforce sign-in through the identity provider with phishing-resistant MFA for all users and especially admins (CIS safeguard 6.5). Keep one or two local break-glass admin logins, vaulted and alerted on. See the Break-Glass Account Guide.
- Dedicated admin accounts: CRM administrators should use a separate account for administration where the platform licensing allows it (CIS safeguard 5.4), and admin sessions should be restricted by network location or managed device where the platform or identity provider supports it.
- High-risk permissions as privileges: treat permissions such as "view all data", "modify all data", "manage users", "export reports", "API enabled" and "authorise connected apps" as privileged, whatever the role name. Grant them through permission sets with an owner and expiry rather than in base profiles.
- Login as user and support access: features that let admins or the provider's support staff log in as a user should be enabled only for named admins and time-limited grants, and logged.
- Separation of duties: the person who configures sharing rules or integrations should not be the only reviewer of them (AC-5). See the Segregation of Duties Guide.
Connected apps, integration users and API tokens
A typical CRM tenant has dozens of integrations. Each one is a non-human identity with standing access to customer data, and OAuth refresh tokens issued to connected apps keep working after the user's password changes. The controls below are our recommendation.
| Control | What to do |
|---|---|
| App authorisation policy | Block users from authorising unapproved connected apps; require admin pre-approval and an allow list |
| One integration user per integration | A dedicated, non-interactive integration user for each connected system, never a named employee's account or a shared admin |
| Scopes and object access | The narrowest OAuth scopes and object or field permissions the integration needs; avoid "view all data" and full access scopes |
| Token lifetime and binding | Short access token lifetimes, refresh token expiry or inactivity limits, and IP restrictions to the integration's published egress addresses where the platform supports them |
| Inventory and ownership | Integration, app, scopes, integration user, business and technical owner, last use, credential expiry (CIS safeguard 5.5) |
| Review and removal | Quarterly review of authorised apps and tokens; revoke tokens and remove apps at contract end or when unused for 90 days |
- Credential type: prefer certificate-based or JWT bearer flows for server-to-server integrations over username, password and security token combinations. Where API keys or static tokens remain, vault them and rotate on a schedule (NIST SP 800-53 IA-5). See the SaaS API Token Security Guide.
- Third-party integration risk: a compromise at an integration provider can expose the tokens it holds for every customer. Ask providers how tokens are stored and how quickly they can be revoked, and know how to revoke every token for a given app in one action. See the SaaS and OAuth App Governance Guide.
- Installed packages: review the permissions requested by extensions and marketplace packages before install, prefer packages that have passed the provider's security review, and remove unused packages.
- AI features and agents: AI assistants and agents built on the CRM act with the permissions of a user or an integration identity. Scope them like any integration user and check which data they can reach. See AI Agents in Sales and CRM.
Data protection, export and public exposure
- Restrict bulk export: limit report export, data export jobs, bulk APIs and data loader access to named roles, and alert on large exports. OWASP's Logging Cheat Sheet lists data import and export, including screen-based reports, among the higher-risk events to log.
- Sharing model: start from private defaults for sensitive objects and open access with sharing rules, rather than starting open. Review sharing rules after every reorganisation (CIS safeguard 3.3).
- Portals and guest users: review which objects, fields and records guest and external users can read, switch off guest access to APIs that are not needed, and test portals for object-level authorisation (OWASP API Security Top 10 2023: API1 Broken Object Level Authorization).
- Field-level protection: classify sensitive fields (payment, health, government identifiers) and apply field-level security and, where available, platform encryption with customer-managed keys. Know who can manage those keys. See the Data Classification Guide.
- Sandboxes: full-copy sandboxes carry production data and copied integration settings. Mask personal data after refresh, reset integration credentials and point outbound integrations at test endpoints. See Production Data in Non-Production.
- Outbound endpoints and webhooks: keep an allow list of external endpoints, sign webhook payloads and review new endpoints. See the Webhook Secrets Security Guide.
Help desk and social engineering paths
Phone-based social engineering against CRM users and help desks has been used to persuade staff to authorise attacker-controlled apps or approve logins. Defences sit in the platform settings as much as in awareness training.
- Require admin approval for new connected apps, so a user cannot authorise one during a call.
- Require strong identity verification before help desk staff reset MFA or passwords for CRM admins.
- Alert on new connected app authorisations, new device-code or OAuth grants and logins from new networks within minutes of each other.
See the Vishing and Help Desk Social Engineering Awareness Guide.
Logging and detection
CRM platforms keep a configuration audit trail, login history and, in many editions, detailed event or API logs. Confirm which logs your licence provides and how long they are kept, export them to a SIEM that CRM admins cannot change (AU-9), and alert on these events.
| Event | Why it matters |
|---|---|
| Admin role or high-risk permission granted | New route to all data |
| New connected app authorised or installed | Possible malicious app or consent grant |
| Large report export, bulk API job or data export | Customer data leaving in volume |
| Integration user signing in interactively or from a new network | Non-human identity used by a person or from stolen credentials |
| Sharing model, guest access or session security settings changed | Exposure widened |
| Login as user or provider support access granted | Impersonation of a user |
| Audit trail or event log settings changed | Possible attempt to reduce evidence |
Lifecycle of the platform
- Certify the platform's own access: review admins, high-risk permission holders, integration users and authorised apps at least quarterly (our recommendation), with the reviewer outside the CRM admin team (AC-6(7)).
- Configuration baseline: export security settings, profiles and permission sets and compare them with an approved baseline after each release and change (CM-6). Use the provider's security health or posture tooling where available, and an SSPM tool for estates with several SaaS platforms.
- Backup: the provider protects the service, and the customer is responsible for recovering from its own data deletion or corruption. Run regular backups of data and metadata and test restores (CIS safeguard 11.2).
- Offboarding integrations: when an integration is retired, revoke tokens, deactivate the integration user, remove the connected app and delete stored credentials in the other system.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Admin accounts and MFA | AC-6(5) Privileged Accounts, IA-2(1) Multi-factor Authentication to Privileged Accounts | PR.AA-05, PR.AA-03 | 5.4, 6.5 |
| Integration users and tokens | AC-2 Account Management, IA-5 Authenticator Management | PR.AA-01 | 5.5 |
| Data access and sharing | AC-3 Access Enforcement, AC-6 Least Privilege | PR.AA-05, PR.DS-01 | 3.3 |
| Configuration baseline | CM-6 Configuration Settings | PR.PS-01 | 4.1 |
| Logging and monitoring | AU-9 Protection of Audit Information, AC-2(12) Account Monitoring for Atypical Usage | PR.PS-04, DE.CM-03 | 8.2 |
| Provider responsibilities | SA-9 External System Services | GV.SC-07 | 15.4 |
Common failure patterns
- Integration running as a former employee: the sync broke when they left, or worse, kept working on their still-active account.
- Users free to authorise any app: one click on a consent screen gives an unknown app API access to the records the user can see.
- "View all data" on integration users: granted during setup because it was quicker than mapping objects.
- Guest portal reading internal objects: sharing settings changed for one portal feature expose records to unauthenticated users.
- Sandbox with live data and live integrations: a test tenant sending real email or syncing to production billing.
- Event logs not retained: short default retention means an export is only discovered after the evidence has expired.
Practitioner checklist
- Limit full CRM administration to a few named people with phishing-resistant MFA through SSO.
- Treat view all, modify all, export, API and app authorisation permissions as privileged and time-bound.
- Block user-authorised connected apps; approve and allow list apps centrally.
- Give each integration its own non-interactive integration user with narrow scopes.
- Set token lifetimes, IP restrictions and certificate-based flows for integrations where supported.
- Inventory apps, integration users and tokens, and review them quarterly.
- Restrict and alert on bulk export paths.
- Review portal and guest user access and test object-level authorisation.
- Mask sandbox data and reset copied integration credentials after each refresh.
- Export audit, login and event logs to a SIEM with retention that covers your investigation window.
Standards and references
- NCSC: Secure system administration, use privileged access management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- Cloud Security Alliance: SaaS Security Capability Framework (SSCF)
- OWASP: Logging Cheat Sheet
- OWASP: API Security Top 10 2023
- CIS: Controls v8.1 Assessment Specification, Control 5 Account Management
- CIS: Controls v8.1 Assessment Specification, Control 6 Access Control Management
- CIS: Controls v8.1 Assessment Specification, Control 8 Audit Log Management
- MITRE ATT&CK: T1528 Steal Application Access Token
Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Securing the identity governance and administration (IGA) platform itself · Top 10 SaaS Security Risks · Service Account Security Guide