September 16, 2026

Security, compliance, and operational efficiency continue to rise on the priority list for organizations of every size. The pressure is to strengthen all three without adding staff or increasing operational complexity.
To help address that, we are introducing a platform enhancement available to all customers and partners: reusable Security Policy Templates.
Security Policy Templates let you define a set of access controls once and apply it to groups of users, instead of configuring each person by hand. The result is stronger governance and less administration, while keeping the simplicity that our direct clients, our Managed Service Provider (MSP) partners, and our Independent Software Vendor (ISV)partners already rely on.
Here is what the feature does and who it helps.
Configuring users one at a time is where security drift starts. A contractor keeps access they should have had revoked months ago. Two people in the same role have different clipboard permissions because they were set up at different times. Nobody made a bad decision. The settings just accumulated.
Security Policy Templates let you build a named policy and assign it. Change the policy later and every assigned user picks up the change.
You will find them under Security in the dashboard, on the Policies tab. A policy has a name, a description, a set of controls, and a list of assigned users. You can create, edit, duplicate, and delete them. A default policy called Standard User ships pre-populated and cannot be deleted, so new environments have a starting point.
| Control | What turning it off prevents |
|---|---|
| File download | Moving files from the cloud desktop to the local device |
| File upload | Moving files from the local device into the cloud desktop |
| Clipboard | Copy and paste between local and remote sessions |
| Printing | Printing from the cloud desktop to a local printer |
| Multi-factor authentication (MFA) | Signing in without a second factor |
| Local user rights | Administrator rights on the desktop, versus standard user |
Two limitations worth naming:
A user belongs to exactly one policy at a time. There is no stacking and no per-user override, which also means there is no conflict to resolve. Assigning someone to a new policy removes them from the previous one.
Changes apply at the next session. If you tighten a policy while someone is connected, their current session continues under the settings it started with.
Drift Is the Real Vulnerability
Most incidents aren’t caused by missing controls. They’re caused by controls applied unevenly. A temporary exception becomes permanent because nobody wrote down that it was temporary. Permissions diverge quietly between people doing the same job. Assigning a policy instead of configuring a user removes the opportunity for those differences to appear.
One Change Instead of Two Hundred
When a requirement changes, you edit the policy rather than every user it covers. Everyone assigned picks up the change at their next session. That matters most where per-user administration breaks down first: teams hiring steadily, environments with high contractor turnover, and MSPs and ISVs maintaining different standards across multiple clients.
Restrictions That Match the Role
Not every user needs the same posture. Full-time staff usually need file transfer and clipboard access to do their work; contractors and bring-your-own-device users often shouldn’t have either. Rather than granting exceptions one person at a time, you build a policy per role and assign different types of users to the appropriate policy. Governance gets tighter without administration getting heavier.
Policy as the Evidence of Intent
For teams applying Zero Trust, least privilege access, or separation of duties, a named policy with an assigned user list is a readable statement of what each role is allowed to do. When a customer security questionnaire asks how access restrictions are enforced, the answer is a policy you can point at rather than a description of a process.
| Audience | What changes | Why it matters |
|---|---|---|
| Direct customers | New hires and contractors get the right restrictions on day one | Onboarding stops being a checklist someone can skip a line on |
| MSP partners | A reusable policy set per client tier | Client onboarding gets faster without loosening anything |
| ISV partners | Standard policies across internal staff, customer admins, and third parties | One configuration to maintain instead of one per user type |
Most teams get there in three passes. Start with the roles you already have: full-time staff, contractors, and anyone connecting from a personal device. Build one policy for each and assign your existing users. Then tighten. The contractor policy is usually where file download and clipboard come off first, because that is the access nobody intended to grant permanently. Finally, duplicate rather than rebuild. When a new client tier or department appears, copy the closest existing policy and adjust it, so your policies stay variations on a standard instead of a set of one-offs.
We will soon release further enhancements to the V2 Cloud web application, including webcam redirection to improve video conferencing performance inside the web app, and multi-monitor support so you can work across several monitors at once within the web app.
Security Policy Templates live under Security in the dashboard, on the Policies tab. Nothing to enable and nothing to install. The Standard User policy is already there when you open it.
No. The feature is included for direct customers, MSP partners, and ISV partners on every plan.
The change applies at each assigned user’s next session. Active sessions continue under the settings they started with.
No. Each user belongs to exactly one policy at a time. Assigning someone to a new policy removes them from the previous one, so there is never a conflict between two sets of rules.
Yes. Policies attach to users, not to virtual machines. Because our pricing is per VM by workload type and multiple users can share one VM, two people on the same machine can hold different restrictions.
No. The Standard User policy ships pre-populated and cannot be deleted, so every environment always has a working default to fall back on. You can edit it, duplicate it, and create as many additional policies as you need.
No single feature does that. Security Policy Templates help you enforce access restrictions consistently, which is one control most frameworks expect. Our data security page covers the broader requirements.
Policies govern access at the session boundary: file transfer, clipboard, printing, sign-in, and local user rights. They do not monitor activity inside the session, and there is no screen recording.
Security Policy Templates are live now. If you want a walkthrough of how to structure policies for your environment, talk to a cloud expert.
Your V2 CloudCare team — real people, on the line.