A CRM holds names, contact details, deal history and often notes nobody meant to be permanent. Whether you run it yourself or buy it as a service, two questions decide most of your exposure: who can reach it, and who can do what once they are in. This guide treats those as architecture decisions rather than settings to fix later.

Requirements differ by jurisdiction and industry, so use this as engineering guidance and involve your security and legal people for anything regulated.

Start with identity, not the firewall

For a CRM delivered over the internet, identity is the main perimeter. People log in from home, airports and phones. A network rule cannot tell a legitimate sales rep from someone holding a stolen password, but a good identity setup can make that theft much less useful.

The core pieces:

• Central sign-on. Connect the CRM to your identity provider so accounts are created and removed in one place. The most valuable effect is offboarding: when someone leaves, one change cuts access everywhere.
• Multi-factor authentication. Require it for everyone, and be stricter for administrators.
• Automated provisioning. Where your CRM supports it, let the identity provider create and deactivate users, rather than relying on a person remembering.
• Separate admin identities. Administrators should use a distinct account for administrative tasks, not the one they use for daily email.

Roles: design them from tasks, not job titles

The common failure is a role list that grew by copying. “Sales Manager 2” exists because one person once needed one extra permission. Three years later nobody knows what it does.

Instead, write down the tasks: view all accounts, edit own accounts, export data, change fields, manage integrations, manage users. Group those tasks into a small number of roles. Treat the dangerous ones, such as bulk export and user management, as separate grants rather than defaults.

In practice, bulk export deserves particular suspicion. It is the permission that turns one compromised or careless account into a data leak. Limit it, log it, and review who holds it.

Service accounts and API credentials

Integrations are users too. A few rules keep them from becoming the weakest link:

1. One credential per integration, so you can revoke one without breaking the rest.
2. Minimum permissions. A reporting sync needs read access, not delete.
3. Store secrets in a secrets manager, never in source code, spreadsheets or chat.
4. Rotate on a schedule and whenever someone with access leaves.
5. Record an owner for each credential. Orphaned keys are how old integrations stay alive and dangerous.

Network boundaries

Even with strong identity, network controls add useful layers, and what is available depends on your hosting model.

If you use a fully managed CRM service, you may be able to restrict logins to known IP ranges or require traffic to come through your identity provider. Check the vendor’s current documentation for what is offered.

If you host components yourself, such as a database or custom services on a cloud platform, the durable principles are:

• Put databases on private subnets with no public address.
• Allow traffic only from the specific services that need it, rather than whole address ranges.
• Keep public entry points few, and put them behind a gateway or load balancer that you can monitor.
• Separate production from test environments, ideally in different accounts or projects, so a mistake in one cannot touch the other.
• Encrypt traffic between components and data at rest, using the platform’s managed keys unless you have a reason to manage your own.

A review checklist

Area	Question to answer	Evidence to collect
Sign-on	Does every human user authenticate through the identity provider?	List of local accounts, ideally empty or minimal
MFA	Is it required for all users and admins?	Policy screenshot or export
Roles	Can each role be explained in one sentence?	Role-to-task document
Export	Who can bulk export, and is it logged?	Permission holder list, audit log sample
Integrations	Does each credential have an owner and expiry?	Credential register
Databases	Is anything reachable from the public internet that should not be?	Network rule review
Environments	Is test data separated from production data?	Account or project layout

A hypothetical walk-through

Imagine a growing company with a hosted CRM and about forty users. During a review they find eleven accounts with no matching employee, three roles nobody can describe, and one integration key shared by four scripts. The fix is not dramatic. They connect sign-on and let provisioning disable the orphan accounts, collapse the roles into four task-based ones, and issue a separate key to each script with an owner noted in a simple register. Total effort: a few days of careful work, mostly spent understanding what each old thing did before removing it.

The lesson is to go slowly on removal. Before disabling an unfamiliar account or key, check the audit log for recent use, disable rather than delete, and wait a cycle before cleaning up.

Frequently Asked Questions

Is single sign-on worth it for a small team? Usually yes, mainly for offboarding and for enforcing MFA in one place. The setup effort is modest compared with the risk of leftover accounts.

Should salespeople be allowed to export contacts? Only if their job requires it. Many roles need reports but not raw bulk exports. If export is needed, log it and review the list of holders regularly.

Do I need a VPN to use a cloud CRM? Not necessarily. For a managed service, strong identity controls often matter more. A private connection can make sense when you host components yourself or have specific policy requirements.

How often should I review CRM permissions? At least a couple of times a year, and after reorganisations. Tie it to a calendar so it actually happens.

What is the first thing to fix if I can only do one? Make sure departed employees lose access promptly. Central sign-on with automated deprovisioning solves the most common real-world gap.

Next Step

Export your current user and role list, plus every API credential, and mark each entry with an owner and a last-used date. Anything without an owner or recent use is your first cleanup candidate.