Secure remote access for MSPs is the controlled way technicians reach client servers, private networks, databases, dashboards, and management systems without receiving permanent, unrestricted access across every customer environment.
Use a bastion when technicians mainly need controlled SSH or RDP access to private servers. Use a VPN or private-access gateway when they need several internal protocols or services. Use identity-aware zero-trust access when permissions must be tied more narrowly to a specific technician, device, resource, client, or time window.
For Raff Technologies customers and MSPs, the important design question is not simply which tunnel or gateway to deploy. It is whether the provider can explain which technician can reach which client resource, through which path, for how long, and how that access is removed without affecting other customers.
This guide focuses on privileged infrastructure access rather than end-user remote-support software or RMM. For the simpler infrastructure comparison, see Bastion Host vs VPN vs Public SSH.
Secure remote access for MSPs: quick decision
| Access model | Best fit | Main advantage | Main risk |
|---|---|---|---|
| Restricted public SSH/RDP | Very small or temporary environments | Lowest setup burden | Management endpoints remain internet-routable |
| Bastion host | Focused SSH/RDP access to private servers | Centralizes the admin entry path | Bastion becomes a privileged shared dependency |
| VPN/private-access gateway | Several private protocols and resources | Practical network-level access | Reachability can become broader than the task |
| Zero-trust / identity-aware access | Many technicians, contractors, or client-specific policies | Narrower resource- and identity-level policy | More identity and policy lifecycle work |
| Dedicated client access plane | High-risk or contractually isolated customers | Strongest customer separation | Higher operational cost and duplication |
A useful rule is:
Give each technician the minimum client access required, for the minimum time required, through a path that can be attributed, reviewed, and revoked.
MSP remote access starts with the customer boundary
An MSP crosses more trust boundaries than an internal infrastructure team.
One technician may support several customers. A contractor may need one migration server for two days. Another customer may require a dedicated administrative path, separate credentials, or explicit approval before production access.
The customer boundary therefore comes first:
Named MSP technician ↓ approved identity Controlled access path ↓ client-specific permission Client VPC / private network ↓ target-level authorization Approved server or service
Client environments should not become mutually reachable merely because the same MSP manages them.
Avoid designs where:
- one VPN profile reaches every customer;
- one shared SSH key works across several tenants;
- one Administrator password is reused across Windows servers;
- one bastion has unrestricted routes into every client network;
- one automation token can modify unrelated customer resources.
For the network-separation side of the design, use Private Cloud Networking for MSPs.
Bastion hosts fit focused server administration
A bastion host is a controlled entry point used to reach private servers.
Technician ↓ restricted access Bastion ↓ private client network Approved Linux or Windows server
A bastion fits when:
- technicians mainly need SSH or RDP;
- target servers should not expose administration publicly;
- the MSP wants a small number of controlled entry points;
- broad network access is unnecessary;
- technician activity needs to be easier to attribute and review.
The benefit is reduced direct exposure. The trade-off is concentration of privilege.
A shared bastion with routes to every customer can become a large cross-client failure domain. Reduce that risk with:
- client-scoped routes;
- named technician identities;
- separate credentials per customer;
- no universal private key stored on the bastion;
- firewall rules that permit only required targets and ports;
- separate bastions for customers that require stronger isolation.
A bastion should also remain intentionally narrow. Do not turn the privileged entry host into a file server, CI runner, application host, or shared database server.
VPN access fits mixed protocols and several private resources
A VPN or private-access gateway is usually more practical when technicians need more than one management protocol.
Typical MSP use cases include:
- Windows RDP;
- Linux SSH;
- database administration;
- private monitoring dashboards;
- backup systems;
- internal web applications;
- several servers inside one customer network.
Technician device ↓ authenticated VPN/private access Client network ├─ RDP → Windows VM ├─ SSH → Linux VM ├─ DB client → database └─ HTTPS → internal dashboard
A VPN creates reachability. It does not automatically create least privilege.
Control the scope with:
- client-specific routes or gateways;
- named users or peer identities;
- MFA where supported by the selected access layer;
- target-level firewall rules;
- separate production and non-production routes;
- explicit contractor expiry;
- recurring access reviews.
Avoid a flat MSP VPN where every authenticated technician can route to every customer environment.
For some customers a VPN can replace the need for a bastion. For higher-control environments, the two can coexist: the VPN provides entry to the client network, while a bastion remains the narrower privileged path to production servers.
Zero-trust remote access narrows authorization
Zero trust does not mean “no VPN.” It means a user or device is not trusted merely because it joined a particular network.
For MSP administration, a zero-trust or identity-aware access policy can express narrower decisions such as:
Technician A → Client A production bastion Technician B → Client B monitoring dashboard Contractor C → one migration VM until Friday
instead of:
Connected technician → entire MSP management network
Zero-trust remote access is useful when:
- many technicians support different customer groups;
- contractors receive short-lived access;
- access should vary by client and resource;
- device identity or posture matters;
- approval or expiry is important;
- audit evidence is a customer requirement.
It does not make VPCs, VPNs, bastions, firewalls, or operating-system permissions obsolete. It adds a narrower authorization layer.
The operational cost is policy ownership. Stale identity-aware policies can become just as permissive as a flat VPN if nobody removes old users, customer assignments, device records, or exceptions.
Bastion vs VPN vs zero trust for MSPs
The three models are often complementary rather than mutually exclusive.
| Requirement | Bastion | VPN | Zero-trust / identity-aware layer |
|---|---|---|---|
| Mainly SSH/RDP | Strong | Strong | Strong |
| Several private protocols | Limited | Strong | Depends on implementation |
| Keep target servers private | Yes | Yes | Yes |
| Resource-specific authorization | Moderate | Needs target controls | Strong |
| Contractor expiry | Manual or external identity | Manual or identity-backed | Strong fit |
| Client-specific segmentation | Routes/firewall | Routes/firewall | Policy + network controls |
| Simple small-team operation | Strong | Strong | More operational overhead |
Do not select a technology based only on the security label. Select the smallest access architecture that supports the customer's risk, protocols, technician model, and evidence requirements.
Windows and RDP deserve a stricter MSP model
MSPs frequently manage Windows workloads where RDP is part of daily administration or where customers run business software, IIS, databases, or remote desktop workloads.
For production Windows access, prefer:
- private or tightly source-restricted RDP reachability;
- named technician accounts;
- strong credentials;
- Network Level Authentication where supported;
- limited local Administrators membership;
- current Windows security updates;
- MFA at the VPN, gateway, or identity layer where available;
- removal of technician accounts when support responsibility ends.
Do not use one shared Administrator credential across several customers simply because it simplifies support.
Raff Windows VM can host Windows Server workloads, while VPC can keep supporting services and administrative traffic on private network paths where public exposure is unnecessary.
For the broader public-versus-private decision, use Private vs Public Admin Access.
SSH access should be attributable to a technician
For Linux environments, every trusted SSH key should have a known owner and current purpose.
Avoid:
- one private key copied across the MSP team;
- customer servers that still trust keys belonging to former staff;
- direct root access that bypasses named users;
- unrestricted SSH from the entire internet when a narrower path is practical.
Prefer named users, individual keys, target-level privilege control, and clear removal when the technician no longer supports that client.
Use User Access Review for Cloud Servers to keep human and machine access current after deployment.
Network reachability and authorization are separate controls
A common MSP mistake is assuming that reaching the client network means the technician is authorized for every resource inside it.
Use separate controls for:
- entering the network;
- reaching a target server;
- authenticating to that server;
- becoming root or Administrator;
- accessing a database;
- deleting backups or recovery points;
- changing firewalls or routes.
For example:
VPN membership ≠ access to every client subnet ≠ SSH/RDP authorization ≠ sudo/Administrator privilege ≠ backup deletion permission
This separation reduces the blast radius of one compromised technician identity.
Use Cloud Firewall Best Practices for inbound and outbound rule design.
Joiners, movers, and leavers determine whether the model stays secure
The connection technology matters less if identity lifecycle is weak.
Joiners
When a technician joins:
- create an individual identity;
- assign only approved customer groups;
- separate human and machine credentials;
- record an access owner;
- require the approved authentication method.
Movers
When responsibilities change:
- remove obsolete client assignments;
- add new access through the normal approval path;
- review stored credentials and devices;
- confirm automation is not tied to the person's identity.
Leavers
When a technician or contractor leaves:
- disable central identity access;
- revoke VPN and bastion membership;
- remove SSH keys and certificates;
- remove Windows/RDP accounts;
- rotate shared credentials they knew;
- invalidate sessions where the tooling supports it;
- verify access per client, not only at the central MSP layer.
Temporary access should receive an expiry condition when it is granted. A migration permission without an end date is likely to become standing privilege.
MSP remote-access logging should answer a client question
A useful audit trail should help answer:
Who reached which customer resource, when, through which access path, and what privileged action followed?
Depending on the architecture, evidence may come from:
- VPN or gateway logs;
- bastion authentication logs;
- Linux SSH and sudo logs;
- Windows security events;
- firewall and route changes;
- cloud API activity;
- database audit logs;
- backup restore or deletion records;
- incident tickets.
Logs should support a review process rather than becoming an archive that nobody can interpret.
Break-glass access should survive gateway failure
Private-access architectures introduce dependencies. A VPN, bastion, route, identity service, firewall rule, or DNS record can fail at exactly the time the MSP needs production access.
Define a break-glass path before the incident.
It should document:
- who can authorize emergency access;
- where the recovery credential or procedure is protected;
- which customer resources can be reached;
- which emergency actions are permitted;
- how use is recorded;
- how emergency credentials are rotated afterward;
- how the normal access path is restored.
If technicians routinely use break-glass access because it is easier than the primary path, redesign the primary path.
Recovery access should not inherit everyday admin scope
The ability to administer a server does not automatically require the ability to delete its recovery points.
For important customers, review separately who can:
- create snapshots;
- restore backups;
- change retention;
- delete recovery points;
- access application-level backup exports.
This helps prevent one compromised technician identity from removing both production and recovery.
Use Cloud Snapshots vs Backups for the recovery-model decision.
How Raff maps to MSP remote-access architecture
Raff provides infrastructure building blocks that can support client-separated administration:
- Raff Cloud Servers for Linux workloads, gateways, bastions, and supporting services;
- Windows VM for Windows Server and RDP-based workloads;
- VPC for private service-to-service and administrative traffic;
- IAM for Raff's current identity and access product surface;
- Security for the current security product path;
- Site-to-Site VPN when an office or approved network needs a private tunnel into cloud resources;
- Data Protection for snapshots and automated backup workflows.
Current Raff VPC traffic is private and unmetered, and VPC itself does not carry a separate VPC charge. Raff VM public traffic currently uses a 3 Gbps connection with unmetered VM traffic and no VM egress fee.
Current network pricing also includes a VPN gateway at $15/month for up to 10 peers and Site-to-Site VPN at $20/month per tunnel. Check the live pricing page before relying on a commercial value because product pricing can change.
A practical client-specific design can look like:
Named MSP technician ↓ approved VPN / bastion / identity-aware access Client-specific Raff VPC ↓ explicit target rules Linux VM / Windows VM / private service
Raff provides the infrastructure boundary. The MSP still owns technician identity, customer-specific permission design, operating-system accounts, access reviews, logging, credential lifecycle, and offboarding.
