Give a remote hire their own named seat, a permission set with export and bulk delete switched off, and make sure every integration they build runs on a company-owned account instead of theirs. Locking down the login is the quick bit, while the tokens behind their Clay tables and n8n workflows can stay live long after they've gone.
The CRM is in most of these jobs. Salesforce was named in 58% of the 294 RevOps job posts we tracked between 3 May and 5 October 2026, and HubSpot in 57%. In the 98 GTM engineer posts from the same period, Clay showed up in 61%, n8n in 34%, and 37% mentioned integrations. Every one of those tools talks to your CRM through a connection someone set up, so a hire like this gets into your data two ways: through their own login, and through whatever they plugged in.
Verizon's 2025 Data Breach Investigations Report says third-party involvement doubled to 30% of the 12,195 confirmed breaches it looked at, and that credential abuse was the initial way in for 22%. Verizon's third-party category is about outside organizations, not a person on your team in another country, so I wouldn't read that as a number about remote hires. It's a number about access you granted and stopped watching.
One person, one seat, their name on it
No shared logins. A shared "ops@" user means your audit log tells you that ops@ exported your whole contact list, which is useless the day you need to know who did it. It also means you can't cut one person off without changing a password everyone else uses.
In HubSpot, there's a free partner seat that agencies use, but it only works for people who already sit in a HubSpot Solutions Partner account with a matching email domain. A full-time hire on your team isn't that. They get a normal seat on your company email, like anyone else, and you set their permissions the same way you would for a US employee. Same for Salesforce: a standard user on a profile you control.
Switch on two-factor for the seat before you send the invite.
Export and bulk delete are the switches that matter
Permission screens are long. For a new remote hire, my read is that only a handful carry real risk, and HubSpot's permissions guide makes them easy to find.
Export is its own switch, and HubSpot splits it further into "Export without approval" and "Approve exports". So you can let someone pull a report while a manager signs off on anything leaving the account. Bulk delete is separate too, and it covers every main record type, deals included. Leave it off for the first month. Someone with plain Edit access can still delete a single record, which is fine; it's the bulk version that ruins a Friday.
Record access is scoped per object. View can be set to all records, their team's or their own, and HubSpot says there's no "None" option for View, so if a hire should never see a pipeline at all you handle that with teams, not by switching off visibility. Super Admin, which HubSpot says can do "virtually anything in the account", should stay with whoever owns the account on your side. Only a Super Admin can make someone else one, so that decision can't drift.
Salesforce gives you two blunter tools on the profile. Its security guide says login attempts outside set hours are denied, and logins from outside a profile's IP range are blocked. Login hours do a decent job if you want the seat dead on weekends. IP ranges only make sense if the hire connects through a company VPN with a fixed address, since a home connection can't be counted on to keep one.
The tokens outlive the login
The security pages I read for this search were written about developers and servers, and they barely touch this part. Going by the posts above, a GTM hire is far more likely to be connecting Clay or n8n to your CRM than asking for your database, and those connections run on OAuth grants and API keys.
If those connections are made under the hire's personal account, deactivating their CRM seat doesn't touch them, and a credential sitting in their own n8n instance keeps writing to your deals until someone revokes it. We wrote up a version of this problem with Make scenarios in our guide on hiring a full-time Make.com expert.
On day one, create a service user or a shared integrations mailbox that your company owns, have every tool account and every CRM connection sit under it, and give the hire access to that account rather than letting them sign up with their own email. Keep a list of every key they create. A spreadsheet with tool, what it connects to, who created it and the date is enough.
What to log, and when to look
HubSpot's security activity export covers user and permission changes, contact and user exports, integration installs and sandbox activity for the last year, on every paid tier from Starter up. The Login History view only goes back 30 days. So if you want a record of who logged in from where, download it monthly, because a problem you spot in week six has already fallen out of that window.
Once a month, pull the export, check for integration installs you don't recognize and any large contact export.
When to keep the CRM closed
Some companies shouldn't hand this access to anyone outside the country, and that includes the people we place. If your customer contracts say where their data can be processed, or you hold health or financial records under rules that cover location, read the contract before you read this guide. A US hire, or a remote hire who only works in a sandbox with fake data, is the better call there, even though it costs more. Our guide to hiring a HubSpot admin covers when a US admin makes more sense for other reasons too.
For everyone else, this is the offboarding list we'd keep pinned.
- Deactivate the CRM seat and any sending tool seats the same day.
- Revoke every API key and OAuth connection on the tracking sheet, then rotate the ones you can't revoke.
- Move any workflows, tables or scenarios still under their name to the company account.
- Pull the security activity export and check the last 30 days of exports.
- Remove them from Slack and Google Workspace, and take back any password manager vaults.
If you can't write down, today, every tool your current ops hire has connected to your CRM, fix that before you hire the next one.