Granular Permissions & Splashtop Policy Controls: How Atera Secures Remote Access at Scale

Modern IT operations live and die by access control. Whether you are an MSP handling dozens of customer environments or an internal IT team supporting multiple departments and locations, the challenge is the same: give technicians exactly the access they need - and nothing more.
 

This is where Atera takes a deliberately structured approach. Instead of broad, one-size-fits-all permissions, Atera combines role-based access control with layered Splashtop policies, allowing organizations to enforce security without slowing down day-to-day support.

The result is a platform where remote access, automation, ticketing, and reporting are powerful - but always governed.

At-a-glance: What this blog covers

This article explains how Atera handles:

• Role-based permissions across RMM and PSA
• Granular control of Splashtop remote access
• Folder, site, customer, and device-level overrides
• MSP and internal IT use cases
• Auditability, compliance, and real-world governance limits

Understanding roles and permission scope in Atera

In Atera, a role is not just a job title — it is a clearly defined set of permissions that determines what a technician can see and do inside the platform. Roles apply across the full RMM and PSA stack, ensuring that access is consistent whether a technician is responding to tickets, managing devices, or initiating remote sessions.

Permission scope in Atera spans five core areas:

• Remote monitoring and management
  Access to devices, system tools, terminals, file transfer, and remote connections.
• PSA and ticketing
  Visibility into tickets (assigned, unassigned, or all), ticket actions, and customer interactions.
• Scripts and automation
  Creating, viewing, running, and restricting scripts, along with managing automation and patch profiles.
• Reports and system functions
  Access to operational reports, billing data, and knowledge base management.
• AI capabilities
  Advanced AI features, including the AI Center and optimization tools, reserved for full administrative roles.

This structure ensures that permission decisions are not isolated to one function — they apply consistently across the entire operational workflow.

Default roles and how RBAC actually works

Atera starts with two preset roles that establish safe boundaries:

• Admin
  Unrestricted access to the platform. This role cannot be edited or limited and ensures that at least one user always has full control of the account.
• Beginner
  A view-only role automatically assigned to new technicians. It allows visibility without the risk of accidental changes and can be limited to specific customers or sites.

Beyond these presets, organizations can create unlimited custom roles. This is where Atera’s RBAC model becomes practical rather than theoretical.

Custom roles allow administrators to:

• Enable or disable remote access tools
• Control who can run scripts and from which script libraries
• Restrict automation and patch profile management
• Limit ticket visibility and customer access
• Control reporting and system-level functions

Roles can also be scoped to specific customers, sites, or folders, preventing technicians from even seeing environments they are not assigned to.

How Splashtop access is controlled inside Atera

Splashtop is tightly integrated into Atera, but remote access is never “all or nothing.” Instead, Splashtop usage is governed by two layers working together:

1. Technician permissions (RBAC)
   A technician must explicitly have remote connection permissions enabled in their role to initiate sessions.
2. Configuration policies (device behavior)
   These policies determine how Splashtop behaves on devices — and where access is allowed.

Splashtop access can be controlled at multiple levels:

• Customer or site level
• Folder level (overriding parent settings)
• Individual device level
• Desktop versus server devices

This allows organizations to enforce rules such as:

• Remote access allowed for workstations but restricted on servers
• Unattended access disabled for sensitive systems
• File transfer or terminal access blocked for junior technicians

Additional controls like session timeouts, attended-only access, auto-lock after sessions, and screen blanking further tighten security without impacting productivity.

Why this matters for MSPs

For MSPs, the biggest operational risk is cross-customer exposure — even accidental. Atera’s permission model addresses this directly.

With role scoping:

• Technicians only see customers they are assigned to
• Remote access is automatically restricted to approved environments
• Automation and scripts cannot be run outside defined boundaries

This removes the need for manual access adjustments during onboarding or offboarding and ensures customer isolation by design. It also simplifies audits and strengthens trust when customers ask how access is controlled.

Why this matters for internal IT teams

Internal IT teams face a different challenge: managing access across departments, locations, and skill levels.

Atera supports this by enabling:

• Separation of helpdesk and system administration roles
• Restrictions on server access for non-senior staff
• Controlled script and automation permissions
• Private technician groups for sensitive departments like HR or Finance

New team members can start in a safe, view-only role, while senior engineers retain the ability to manage automation, policies, and platform-wide settings.

Visibility, audit trails, and accountability

Access control only works if actions are traceable. Atera addresses this through comprehensive logging:

• Every remote session, file transfer, and device action is recorded
• Permission and configuration changes are logged in the audit trail
• Administrators can see exactly who accessed which device and when
• Script executions include detailed outcomes and exit statuses

This level of visibility supports both internal governance and external compliance requirements, without adding operational overhead.

Known boundaries and practical constraints

Atera’s permission system is intentionally structured, and that means some boundaries are fixed:

• Preset Admin access cannot be partially restricted
• Only one configuration policy can be assigned per folder
• Some remote management tools are OS-specific
• Certain features, like unattended access add-ons, depend on licensing tiers

Rather than being limitations, these constraints create predictable behavior — critical for secure operations at scale.

Strategic takeaway

Granular permissions in Atera are not an afterthought — they are foundational.

By combining role-based access with layered Splashtop policies, Atera enables:

• Secure multi-customer MSP operations
• Clear separation of duties in internal IT teams
• Reduced risk of accidental changes
• Strong auditability without manual effort

The result is an IT environment where access is deliberate, remote support is controlled, and growth does not come at the expense of security.

Prevent cross-customer access by design, not policy→ Schedule a 30-minute Atera RBAC review.

FAQs

How do granular permissions in Atera RMM protect MSP customer environments?

Atera RMM allows technicians to be restricted to specific customers, sites, or folders. This ensures MSP technicians cannot see or access devices outside their assigned environments, preventing cross-customer exposure.

Can Splashtop access be limited by technician role in Atera?

Yes. Splashtop access is governed by role-based permissions in Atera. Technicians must have explicit remote connection rights, and additional restrictions can be enforced using configuration policies.

How does Atera PSA handle permission-based ticket visibility?

Atera PSA allows roles to control whether technicians see only assigned tickets, unassigned tickets, or all tickets. This helps separate helpdesk workflows from administrative oversight.

Can Atera restrict remote access to servers only for senior engineers?

Yes. Atera supports device-type-specific permissions, allowing administrators to enable remote actions for desktops while restricting server access to senior roles.

Are Splashtop sessions logged for audit purposes in Atera?

All Splashtop sessions are logged in Atera. Session activity, technician identity, and timestamps are available for review, supporting compliance and accountability.

How do granular permissions help internal IT teams reduce mistakes?

By assigning junior staff to restricted roles and limiting automation or script execution, Atera helps prevent accidental changes while still allowing effective day-to-day support.

Does Atera AI Copilot respect permission boundaries?

Yes. AI features in Atera operate within the permissions assigned to the technician’s role. Advanced AI capabilities require full administrative access.