IT Support for Remote Workers: An MSP Playbook

Supporting a client's office is a solved problem. The same client with staff at home is a different job with different economics. 22.6% of US workers telework, per the Bureau of Labor Statistics in March 2026, and their laptops sit on networks you don't run. A password reset that took two minutes at a desk now eats twenty over a laggy screen share. This playbook covers the four things that hold up: security architecture, tiered workflow, onboarding templates, and the stack that makes the margin work.

TL;DR

• What remote IT support requires. MSPs supporting remote workers need zero trust access, MDM enrollment on every device, a tiered support workflow, and documented onboarding, not just a remote desktop tool.
• Security first. Breaches with remote work as a factor cost about $1 million more, per IBM's 2022 report.
• Workflow second. Self-service, then remote control, then escalation.
• Stack third. Consolidate RMM, access, MDM, and ticketing before adding headcount.

Why Remote Support Breaks the Office Support Model

The office model assumed three things. Devices on a network you manage. Users you can walk over to. A firewall that tells inside from outside. Remote teams void all three at once.

Start with the devices. Lookout surveyed 3,000 remote and hybrid workers in 2023 and found 92% did work on personal phones or tablets. 46% had saved a work file to one. That isn't an edge case you can wave off in the contract. It's what the workforce you're paid to support does by default, and it means your attack surface includes hardware you have never enrolled, patched, or seen.

Then the cost of getting it wrong. IBM's Cost of a Data Breach research put breaches with remote work as a factor at about $1 million more than breaches without it, in both the 2021 and 2022 reports. The 2021 report clocked them at 58 more days to contain. IBM stopped breaking remote work out after 2022, so treat those as the last hard numbers rather than live ones. Containment time is the one to watch. Fifty-eight extra days of incident response is fifty-eight days of technician hours you can't bill.

Then the ticket itself. At a managed office, a tier-one issue ends with a walk-up or a fast remote session. At home it involves a VPN that won't connect, an ISP you can't call, and a user who is also the site's only pair of hands. Remote tickets run longer and escalate more. Without a workflow built for them, that comes out of the margin on every per-user agreement you signed.

The MSPs who make money here rebuilt the offering instead of stretching the old one. Three layers: architecture, workflow, stack.

The Security Architecture for Distributed Teams

Remote security is something you design once, not a pile of add-ons bought as problems appear. What follows is the baseline, and it sits inside a broader MSP security stack.

A VPN asks one question at the front door and never asks again. Zero trust asks at every door. Each request gets checked against identity, device posture, and context, whether it comes from a home office in Denver or a hotel in Lisbon. A compromised home router stops being a road into the client's file server. Enforce MFA everywhere, including on the tools your own technicians use to reach client systems. Phish one MSP technician and you get every client at once, so your own remote access belongs under tighter control than anything you deploy client-side.

Device management is the second pillar. Every device that touches client data gets enrolled, company-issued or not. That's a contract conversation before it's a technical one, so write it into the agreement: enrollment required, minimum OS versions, remote wipe scoped to the work profile. Unified endpoint management runs this across laptops and phones from one enrollment path and one policy engine, instead of a console per device class.

Then you meet the client's staff, and the conversation narrows to two options. Enroll every personal device, which fails on people rather than technology: staff push back, HR gets involved, and the clause stops being enforced. Or enroll nothing and ask people to be careful. A BYOD clause you can't enforce is a disclaimer.

There's a third option. Manage the data, not the device. Work apps sit in a walled garden on the phone. Outlook, Teams, OneDrive and the Office apps inside it. Personal photos and messages outside it, untouched. The user meets the boundary as behavior rather than policy. Copy a client email in Outlook, paste it into Word, it works. Paste it into WhatsApp and the phone refuses. When someone leaves you wipe the work content and leave their phone alone.

Name the gap before a client finds it. App-level protection covers data, not devices. You still can't patch, inventory, or prove the posture of a phone you never enrolled, and the policy alone won't stop someone opening a browser and signing into webmail. A conditional access rule requiring app protection on mobile closes that second hole. Jonathan Edwards builds both halves in one sitting:

Identity is where the two pillars meet. Single sign-on plus conditional access makes identity the perimeter. A login from an enrolled, encrypted laptop goes straight through. The same credentials from an unknown device in an odd location hit step-up verification or a block. That catches a phished password before it becomes an incident. It's also what makes BYOD workable, because access stops depending on who owns the hardware and starts depending on what the device can prove. For regulated clients it's the cleanest way to show an auditor that remote access runs on policy rather than trust.

The rest is dull and load-bearing. Full-disk encryption on every endpoint, because remote laptops get stolen from cars and coffee shops, not server rooms. DNS filtering that follows the device off-network. Patch compliance enforced by the RMM agent rather than by asking nicely. A written home-network standard for high-risk roles: separate SSID for work devices, router firmware updated, default credentials changed. None of this is exotic. What's rare is packaging it as one architecture and pricing it that way.

The Tiered Workflow That Keeps Remote Tickets Profitable

Security architecture protects the client. Workflow protects your margin. Three tiers, each built to keep the ticket at the cheapest level that can close it.

Tier 0 is where the economics are won. A remote worker locked out at 7am in another time zone either resets it themselves or waits three hours for your help desk to open. Build the knowledge base around the twenty tickets your PSA says repeat most. Wire up self-service password reset. Let AI agents handle the requests that follow a known runbook. A ticket that closes at tier 0 costs almost nothing and closes instantly, which matters more for retention. The ceiling is worth naming: self-service that fails once teaches the user to skip it forever. So the twenty articles have to be the right twenty, and the reset flow has to work on a phone.

Tier 1 is the remote session. Speed comes from preparation, not heroics. Unattended access agents on every managed endpoint, so nobody reads a nine-digit code over the phone. Scripted fixes for the recurring issues, so the technician runs a remediation instead of clicking through settings on a shared screen. Session recording, so escalations carry context instead of starting over.

Under all three tiers sits monitoring, and it matters more now than it did in the office. The RMM agent is your only set of eyes on a laptop in someone's spare bedroom. Configure it to catch failures before the user does: a disk filling past threshold, a backup job failing quietly, patches pending past their window, a battery about to strand someone mid-workday. An alert that becomes a scheduled fix is a ticket nobody files. Track proactive catches against user-reported ones per client. A rising proactive share is the clearest evidence the offering works, and it reads better in a quarterly review than raw ticket counts.

Tier 2 is what genuinely needs a senior engineer. Keep it small. An infrastructure ticket that lands there because tier 1 lacked documentation or access is work you priced at tier 1 and paid for at tier 2.

Put response times in writing and segment them by severity, not by the client's mood. A team across four time zones will ask for 24/7 coverage. Price it as the premium it is, or scope after-hours to true outages. Don't leave it vague. Ambiguity in an SLA always resolves in the client's favor and against your payroll.

Onboarding and Offboarding Without an Office

Remote onboarding is where this succeeds or fails in public. There's no IT closet and no first-day desk visit. The laptop ships to a kitchen table and day one either works or it doesn't. Treat it as a production process, the same discipline as a full MSP onboarding checklist, run per employee instead of per client.

Documentation is what makes it repeatable across clients instead of dependent on whoever ran it last. Each client gets a runbook: their app stack, their access templates, their shipping addresses and device suppliers, their named approver for access requests. The asset register tracks every device from purchase to return, with serial numbers tied to users in the PSA. A technician who can answer "what laptop does this person have and what's on it" in one lookup closes calls faster. One who can't starts every interaction with five minutes of archaeology.

Two details separate a clean operation from a messy one. Role-based access templates: a new sales hire gets the sales bundle in one approval, not five ad-hoc requests over two weeks. And asset recovery: laptops that never come back are a real cost line, so the runbook carries a prepaid return label, a deadline, and an escalation path written into the agreement. Get that clause in before the first leaver. Introduced after a laptop goes missing, it reads as a new charge rather than a standard term.

Offboarding speed is also a security control. An account that outlives the employee is an open door, and that's the gap that turns into one of those million-dollar-premium breaches.

The Consolidated Stack for Remote Support

Tool sprawl costs more on remote work than it does in an office. A ticket that touches a separate RMM, remote access tool, MDM console, ticketing system and password manager makes the technician swivel through five tabs while a frustrated user watches the shared screen. Each tool also carries its own per-technician license, and those add up against the same margin the per-user price is already squeezing.

A remote support stack has to cover: RMM for monitoring and patching wherever endpoints sit, remote access with unattended agents, MDM or UEM for enrollment and policy, a PSA for ticketing and time, identity with MFA and SSO, and endpoint security with DNS filtering. Before renewal season, ask how many vendors that list takes, and what moving data between them costs in technician hours.

That's the problem OpenFrame was built for. RMM, MDM, remote access and a native PSA in one place, with AI agents that work tier-one tickets and surface issues nobody reported. For remote support that means the alert, the ticket and the session live in one pane, and the agent handles the password resets and disk cleanups that fill a distributed queue overnight. It won't fit every MSP, and no platform does. Name the cost first: consolidating means a migration, and the month you migrate is the month your resolution times get worse. What's left after that is consolidation, price, and no lock-in, so the decision stays reversible.

Whichever way you go, consolidate before you hire. An MSP running eight remote-support tools with three technicians usually has a tooling problem wearing a staffing costume.

Packaging and Pricing Distributed Support

Per-user pricing fits remote teams better than per-device. Device counts move without anyone telling you, and BYOD makes them slippery. Price the user, say what a supported user includes (two enrolled devices is a common line), and put BYOD enrollment in scope with a surcharge for exceptions.

The tempting move is a cheap tier for mobile-only staff. An MSP onboarding a healthcare client with 15 office users and 60 field users on F3 licenses asked r/msp about exactly that in August 2026, and the answers landed in three places rather than two. Charge one rate for everyone. Or build a support-free package, which the operator who tried it went back on, because those users end up needing support anyway. The third answer is the useful one: a lighter tier priced off the real tool cost, since field users skip the password manager and the awareness training, and visible to whoever picks up the ticket. Read the thread before you price one:

A lighter tier holds when two things are true. The exclusions are real, and your help desk can tell which tier a user is in before picking up the ticket. A tier nobody can see at triage is a discount you give away by accident.

Build the offer in tiers that mirror the architecture. Baseline covers managed identity, enrolled devices, business-hours support and the self-service layer. Security-forward adds zero trust access, DNS filtering and awareness training. Extended coverage adds after-hours response for teams that are genuinely global. Publish what each tier excludes as clearly as what it includes. The excluded list is what protects your technicians from scope creep, one goodwill favor at a time.

Reporting closes the loop. A remote client can't see your work the way an office client sees a technician at a desk, so the quarterly review carries more weight: patch compliance, MFA coverage, tickets closed at each tier, resolution time by severity, and the proactive-to-reactive ratio. Numbers make invisible work visible, and visible work renews contracts.

Revisit pricing quarterly. Costs move with headcount you don't control, like a client hiring five people in three new time zones and mentioning it when the tickets arrive. The agreement should let seat counts and coverage windows move at review time instead of holding you to last year's assumptions.

Where Remote Support Programs Fail

Three things account for most of the pain.

Shadow IT is the first. Remote employees pick up unsanctioned file-sharing and note-taking apps faster than a quarterly review catches them. The counter is SaaS discovery plus a sanctioned list people will use. When the approved tool is slower than the one an employee found, policy loses to convenience every time. That makes tool selection a support decision, not just a procurement one.

The second is the home network. No MSP can control it. Every MSP can de-risk it, with device-level DNS filtering, zero trust access, and the written home-network standard above. The goal is making the home network irrelevant to security rather than managing a thousand consumer routers.

The third is treating remote work as temporary. Six years past the forced experiment, it's a permanent segment: the BLS telework rate averaged 22.4% across 2025 and sat at 22.6% in March 2026, flat rather than falling. Clients who staffed up remotely aren't planning a return. MSPs still serving them with an office-era playbook are paying for the mismatch out of their own margin.

The MSPs winning here made one shift. Remote support stopped being a worse version of office support and became the product. Build the architecture once, run the workflow with discipline, consolidate the stack, and a remote client base becomes the stickiest, highest-margin work on your books.

The office isn't coming back to save your ticket queue. Build for the kitchen table.