Most companies have a remote onboarding process. Very few have a secure one.
The reason is structural rather than negligent. HR owns onboarding: contracts, payroll, benefits, the welcome call, the first-week schedule. IT owns security: accounts, devices, access. Both do their jobs properly. What nobody owns is the seam between them, and that seam is where a new hire spends their first week logging into company systems from an unvetted home network on a laptop that shipped with default settings.
The gap is widest in companies that don’t have a dedicated IT function at all, which is most companies under 200 people. Onboarding lands on an ops manager or the HR lead, who does an excellent job of the parts they were trained for and reasonably assumes the technical parts are handled somewhere.
Here is what actually falls through, and a checklist you can run for every remote hire without needing a security team.
Why onboarding is a security event, not a paperwork event
A new starter is, briefly, the least-defended identity in your organisation. They have live credentials and no instinct yet for what a normal request from your CFO looks like. Attackers know this. Business email compromise attempts cluster around new hires precisely because a message from “the CEO” asking for an urgent favour is much harder to sanity-check in week one than in year three.
At the same time, week one is when access accumulates fastest. Every tool the new hire needs gets provisioned in a hurry, usually by whoever has admin rights and five spare minutes. Permissions granted under time pressure are rarely scoped tightly, and almost never revisited.
Treat onboarding as the moment your attack surface expands, because that is what it is.
The checklist HR keeps missing
Before day one (T-5 to T-1)
- Decide the device question in writing. Company-issued or BYOD? If BYOD, set the minimum requirements: OS version, disk encryption, screen lock, no shared family account. Vague answers here become permanent.
- Ship the device configured, not blank. Full-disk encryption on, automatic updates on, admin rights separated from the daily-use account, endpoint protection installed. A device that arrives pre-hardened is a device that stays hardened.
- Create accounts with least privilege as the default. Start from the minimum role for the job and add on request. Cloning an existing employee’s permissions is the single most common source of over-provisioning.
- Prepare credential delivery that isn’t email. Temporary passwords sent by email, then confirmed by email, is a chain with one link. Use a password manager invite or an out-of-band channel.
- Set up the secure connection layer before they need it. This is the item skipped most often, and it gets its own section below.
Day one
- Enforce MFA during the first login, not “within 30 days”. Deferred MFA is unenforced MFA. Make it a gate, not a reminder.
- Get them into the password manager before they create a single account. The habit forms in the first hour or not at all.
- Name a security contact by first name. “Message Priya if anything looks odd” gets used. “Contact the IT department” does not.
- Explain your payment and approval process out loud. Tell them explicitly that no executive will ever ask them to buy gift cards, change bank details over chat, or approve an invoice by text. This single conversation defuses most BEC attempts aimed at new staff.
- Confirm the home network basics. Router firmware updated, default admin password changed, WPA3 or WPA2 with a real passphrase. Ninety seconds of questions that nobody asks.
Week one
- Run a short phishing walkthrough with real examples from your industry. Generic training modules get clicked through. Three real screenshots of attacks your company has actually received do not.
- Document what they were given access to. A one-line record per system. This becomes your offboarding checklist later, and your audit trail if you ever need one.
- Cover data handling rules concretely. Which client files can leave the sanctioned tools, which cannot, where backups live, what to do with a laptop in a coffee shop.
- Check the physical layer. Privacy screen if they work in shared spaces, no sensitive calls in co-working areas, lock screen on step-away.
Days 8 to 30
- Review the access you granted in the rush. Two weeks in, most new hires know which tools they actually use. Remove the rest.
- Verify the VPN and password manager are still in daily use. Adoption decays quietly. Check rather than assume.
- Run one simulated phishing test. Frame it as a calibration exercise rather than a trap, with a supportive follow-up either way.
- Confirm backup and recovery. If their laptop died tomorrow, what would be lost? If the answer is “some things,” fix it now.
Who owns what
Most of the failures above are ownership failures rather than knowledge failures. Assigning them explicitly solves the majority of the problem:
| Task | Owner | Timing |
|---|---|---|
| Device policy decision (issued vs BYOD) | HR + IT jointly | Before offer accepted |
| Device hardening and shipment | IT or ops | T-5 days |
| Account creation at least privilege | IT or system owner | T-2 days |
| Secure connection setup (VPN) | IT or ops | T-1 day |
| MFA enforcement | IT | Day one, as a login gate |
| Social engineering and payment-process briefing | Hiring manager | Day one |
| Access inventory record | HR, in the personnel file | End of week one |
| Access review and pruning | Hiring manager + IT | Day 14 |
| Offboarding trigger list | HR | Created during onboarding |
The connection layer: the item that gets skipped most
Of everything on the list, the step most consistently missed is securing the network the new hire connects from. It is easy to see why. The laptop is visible, the accounts are visible and the paperwork is visible. The network is invisible, sits in someone’s home, and belongs to nobody in the org chart.
It is also where the risk concentrates. A remote employee’s traffic crosses their home Wi-Fi, their ISP, and whatever café, hotel or co-working network they use in a given month. Any of those can be hostile, and none of them are yours. The practical answer is to encrypt traffic before it leaves the device, and to have that running before the first login rather than bolted on later once someone notices.
For onboarding specifically, only two things really decide whether this step survives contact with reality: how many devices you can cover, and how long setup takes. Per-seat licensing tends to quietly limit protection to the work laptop while the phone and the home router go untouched, and any tool that needs a configuration call will get postponed on somebody’s first morning. This is the gap professional VPN services are built to close. ZoogVPN, for instance, puts unlimited devices on a single account and ships one-click apps for Windows, macOS, Linux, iOS and Android, which is what turns this from an IT project into one line on the pre-day-one checklist.
Whichever provider you choose, the operational point stands. Add VPN provisioning to the same workflow that produces the email account. If it lives in a separate process, it will be done late or not at all.
Build offboarding into onboarding
The strongest argument for the access inventory in week one is that it is really an offboarding document written early. Remote departures are messier than in-office ones. There is no badge to hand back, no desk to clear, and no physical moment that signals “this person is done.” Accounts linger for months.
When you record each system a new hire is given access to, you are building the revocation list at the only moment when the information is complete and someone cares. Store it in the personnel file, keep it updated when access changes, and make retrieving it the first step of any exit process.
A 10-minute version if you have no IT team
If the above reads like more process than your company can absorb, run this stripped-down version. It covers most of the real-world risk:
- MFA enforced on email and the password manager, day one, no exceptions.
- Full-disk encryption confirmed on the device.
- Business VPN installed and running before first login.
- A five-minute conversation about how your company does and does not request payments.
- A written list of every system they were given access to.
Frequently asked questions
Should HR or IT own remote onboarding security?
HR should own the checklist and IT or ops should own execution of the technical items. The failure mode is not one team doing it badly. It is both teams assuming the other has it.
Is a VPN necessary if all our tools are cloud-based and use HTTPS?
HTTPS protects the contents of a connection but still exposes metadata, including which services are being used, from where and when. It also offers nothing against a compromised local network or a malicious DNS resolver. A VPN addresses the transport layer that HTTPS assumes is merely untrusted rather than actively hostile.
How do we handle contractors and freelancers?
Same checklist, shorter access lists, and a hard expiry date on every account set at creation. Contractor access outliving contractor engagements is one of the most common findings in small-company security reviews.
What about employees who joined before we had any of this?
Run the checklist retroactively in small batches, framed as a company-wide security refresh rather than an audit. Start with whoever has the broadest access.
The bottom line
Remote onboarding fails at the seam. HR does the paperwork, IT does the accounts, and two things belong to nobody: the network the person actually works from, and the access that quietly accumulates in week one. Assign both to a named owner, run them before day one rather than after, and write the offboarding list while the information is still fresh.
None of it is expensive. All of it is easier to do once, at the start, than to reconstruct eighteen months later when someone asks what a departed contractor still has access to.
