Most writing about CRM security comes from the people who implement CRMs. This piece comes from the other side of the table: how a security practice approaches a mid-market CRM stack as a threat-modeling exercise. Not an audit report, no findings from named engagements, but the methodology itself: where the trust boundaries sit, which attack paths get modeled first, and why the customer-controlled layer, not the vendor platform, is where almost everything interesting happens.
Why threat-model a CRM you do not even host?
Because the shared-responsibility line sits higher than most teams assume. The vendor secures the platform: infrastructure, application code, tenant isolation. Everything you configure, users, roles, sessions, tokens, connected apps, export permissions, integrations, is your attack surface, and it is the layer where public breach reporting consistently locates real-world CRM data loss.
A CRM concentrates the most monetisable data most companies hold: the full customer base, deal history, contact details, and often support and billing context. When we model one, we draw four trust boundaries:
- ▸The vendor platform, out of scope for you to fix, in scope for contract review.
- ▸Tenant configuration, roles, sharing rules, session policies, password and MFA settings.
- ▸The token layer, every OAuth grant, API key, and integration user with standing access.
- ▸The satellite estate, marketplace apps, no-code automations, BI connectors, custom scripts.
The last two are where the model earns its keep, because in most organisations nobody owns them day to day.
What does a typical mid-market CRM stack look like from the attacker's side?
A pattern that repeats across companies: one CRM at the centre; fifteen to forty connected apps accumulated over years; marketing automation and a support desk in deep bidirectional sync; a BI connector replicating the database nightly; several Zapier or Make scenarios; and custom scripts running under a single long-lived, over-privileged service account.
From the attacker's side this is not one system but a mesh with the CRM as hub, and every spoke inherits a path to it:
- ▸The perimeter is the token list, not the login page. Dozens of credentials grant API access, and most have no MFA anywhere in their path.
- ▸The weakest spoke sets the bar. A compromised marketing tool or a forgotten script reaches the same API as a legitimate user.
- ▸Nobody holds the full map. In our experience, the connected-app inventory surprises the very team that owns the CRM, which is exactly why the exercise is worth running.
The same modeling applied to ERP estates, where the data is financial rather than commercial, is covered in ERP Attack Surface: SAP, Odoo, and Custom Systems Compared.
How does OAuth grant sprawl become the biggest blind spot?
Every Connect click mints a long-lived refresh token carrying scopes the approving user rarely reads. Over years, a tenant typically accumulates dozens of grants, active vendors, abandoned trials, personal productivity tools authorised by employees who have since left, each one a durable, password-less path to CRM data that MFA does not challenge and offboarding rarely revokes.
Three properties make grants the first thing we model:
- ▸Tokens outlive people. Deactivating a user does not always invalidate every token that user authorised for third parties; verify your vendor's exact behaviour.
- ▸Tokens are stealable. Infostealer malware harvests them from browsers alongside session cookies, detection approaches are in Hunting Infostealers: Detection Rules for Browser Token and Cookie Theft.
- ▸Scopes trend maximal. Apps commonly request broad read-write access because narrow scopes generate support tickets.
Treat each grant as a standing credential: quarterly review, forced expiry of unused grants, and an approval step for new authorisations.
What risk does the app marketplace actually introduce?
A marketplace app is a third-party vendor holding API access to your customer data, often onboarded by a single employee without procurement, security review, or a data-processing agreement. Marketplace review programs assess the app at submission time, not the vendor's ongoing security posture, and public reporting shows ecosystem-wide token abuse is an established attack pattern.
Over recent years, public incident reporting across major SaaS ecosystems has repeatedly described the same shape: an app vendor's own infrastructure is compromised, its stored tokens are abused, and every tenant that installed the app becomes reachable at once. When we model marketplace risk, we ask per installed app:
- ▸What scopes does it hold, and are they broader than its function needs?
- ▸Who is the vendor, company, jurisdiction, sub-processors, disclosure history?
- ▸Is there a DPA, and does your processing register mention them at all?
- ▸What happens on compromise, can you revoke quickly, and would anything alert you?
This is supply-chain security with a friendlier interface; the mindset from Supply Chain Attacks: Why Your Dependencies Are Your Biggest Risk transfers directly.
Which data-export paths would an attacker actually use?
More than most teams can list from memory: report exports, bulk APIs, BI and ETL connectors, sandbox refreshes carrying full production data, mobile offline caches, email sync, and third-party backup apps. The modeling question is blunt: who can move ten thousand records out today, and which log line would prove that it happened?
What the exercise typically surfaces:
- ▸The classic insider path, a departing salesperson exporting the pipeline, is a well-documented and frequently litigated pattern, yet report-export rights are commonly granted to entire profiles by default.
- ▸The quiet paths matter more. A BI connector replicates everything nightly into a warehouse with its own, usually weaker, access model; sandboxes often hold real data under relaxed controls.
- ▸Detection is configuration. Mainstream CRMs can log export and API events, but detailed event logging is sometimes edition-gated and alerts are rarely wired to a human, verify what your edition captures.
Least privilege on export permissions plus one volume-based alert covers a disproportionate share of this risk.
How does an admin takeover typically unfold?
Rarely through the login page. The chains we model first: an infostealer lifts an admin's session cookie from a browser; a helpdesk social-engineering reset; or a compromised integration user carrying admin-equivalent API scopes. Once inside, the fast moves are minting a new connected app and scheduling exports, persistence that survives a password reset.
The OAuth-app-as-backdoor is the detail teams miss: an attacker with brief admin access authorises their own application, then leaves through the front door while the grant keeps working. Controls that map to the chain:
- ▸Phishing-resistant MFA and short admin sessions, with IP or device restrictions on admin roles where the platform supports them.
- ▸Alert on the persistence moves, new connected-app authorisations, new API clients, permission-set changes, and mass-export events.
- ▸No shared admin service accounts. Scope one integration user per system, the discipline argued in Non-Human Identity Governance: Finding and Killing Over-Privileged Service Accounts.
The same failure modes recur wherever privileged surfaces go unwatched; the pattern catalogue in What Security Auditors Find in Admin Panels reads as this article's sibling.
Who carries the liability when CRM data leaks?
You do. Under GDPR the customer is the controller; the CRM vendor and every marketplace app act as processors or sub-processors on your instructions. A leak through an app you installed lands on your 72-hour breach-notification desk, the vendor's compliance page does not transfer that duty. Contracts allocate money; regulators hold the controller.
Three things to verify before an incident forces the question:
- ▸Read the DPA for caps and carve-outs. Vendor liability is commonly capped near the fees you paid, a fraction of a real incident's cost.
- ▸Maintain the sub-processor picture. Every data-touching marketplace app belongs in your records of processing; most companies list none of them.
- ▸Rehearse the scoping questions. Could you establish which records, which fields, and which time period from the logs your edition retains? If not, that is itself a finding.
For the broader obligations map, see GDPR Compliance for SaaS Startups: A Practical 2026 Guide.
What controls give the best risk reduction per unit of effort?
Five, in rough order: a quarterly OAuth grant review with forced removal of unused grants; app installation restricted to an allowlist; one scoped integration user per connected system instead of a shared admin account; alerting on exports and new connected apps; phishing-resistant MFA with hardened sessions for admins. Most are configuration rather than new spend, though some capabilities are edition-gated, verify per vendor.
Two closing observations from the modeling side:
- ▸The threat model doubles as an exit inventory. The token list, the app census, and the export-path map are the same artifacts you need to price a migration, the overlap with The CRM Exit-Readiness Audit: Lock-In Mechanisms Hiding in Your SaaS Contract is not a coincidence.
- ▸Consolidation is a security control. Every satellite app replaced by owned, purpose-built software removes one third-party trust relationship. The trade-offs, you exchange vendor risk for operational responsibility, are mapped in Escaping SaaS: The Complete Guide to Migrating to Custom Software. Make that trade deliberately, not by default.
How TuniCyberLabs helps
TuniCyberLabs is a security firm that also builds software, which is why we model the whole mesh rather than a single product. We run SaaS-stack threat models, OAuth grant audits, marketplace app reviews, export-path mapping, admin hardening, and when consolidation is the right answer, the same team engineers the replacement.
If you cannot name every app with API access to your CRM today, that is the first finding, talk to us and we will map it with you.