Granular Remote Desktop Settings Per Customer
Dear Atera Team,
Firstly, I’d like to express our gratitude for the incredible value Atera has brought to our business. Your platform has revolutionised how we operate, driving efficiencies across our workflows and empowering us to deliver outstanding support to our customers. It’s been a game-changer for us!
As enthusiastic users of Atera, we occasionally encounter small challenges where we feel there’s an opportunity to enhance the platform even further. One such area is the management of remote desktop functionality.
We have a use case where some of our customers require us to have remote access to their devices, while others specifically request that we do not. It would be immensely beneficial if Atera offered the ability to configure remote desktop settings on a per-customer basis. Ideally, this would allow us to enable or disable the remote desktop agent (e.g., Splashtop or AnyDesk) during the customer creation stage, or as part of the initial Atera agent installation process.
While we’re aware of the registry key method to disable these agents post-installation, it’s not always feasible for environments with hundreds or even thousands of devices, particularly when some are rarely online. Attempting to retrospectively disable remote desktop in such cases can take significant time and effort, which isn’t always practical.
By introducing this functionality, Atera could not only simplify compliance with individual customer requirements but also enhance deployment efficiency and reduce the administrative overhead for teams like ours.
We’re huge fans of Atera and are passionate about supporting your journey as much as you’ve supported ours. We hope this suggestion is something that resonates with your vision for the platform, and we’d love to see it come to life!
Thank you for considering this request, and please don’t hesitate to reach out if you need further clarification or details.
Best regards,
Ian
-
Ian Morris
commented
First, I want to say that we genuinely love the Atera platform. It’s central to how we operate, and we actively want to deepen our commitment to it. The automation, visibility, and overall direction of the product are excellent, which is why this issue stood out so starkly for us.
We recently experienced a serious operational incident caused by the current behaviour of the Remote Access settings UI.
What happened
We manage thousands of devices across many customers, often onboarding environments where previous MSP tools or customer-managed tools (for example, ScreenConnect) are already present on endpoints. In our environment, Splashtop is our only approved and enabled remote access tool.However, on the Remote Access settings page, the dropdown at the top of the screen:
Immediately switches the global default remote access tool
Enables that tool
Triggers uninstall actions for the previously enabled tool
Applies the change across all devices
Does all of the above without any warning, confirmation, or explanation
In our case, someone dropped down the list while navigating the page, assuming it was informational or a way to view configuration options. That single action silently changed the default remote access tooling for thousands of devices.
As a result:
Splashtop was uninstalled (or queued for uninstall) across the estate
Devices began surfacing ScreenConnect as the active remote tool simply because it was already present on endpoints
Customers were rightly asking why remote access software had been installed or changed without consent
We were left explaining and remediating a change that no one knowingly approved
Why this is a UI problem
The dropdown visually behaves like a navigation or filter control, not a destructive global action.
There is no indication that selecting an option will:Change account-wide behaviour
Impact all devices
Trigger installs/uninstalls
Override existing operational decisions
Compounding this, the actual enable/disable options for tools exist elsewhere on the page, which reinforces the assumption that the dropdown is informational rather than authoritative.
What we are requesting
At a minimum, one (or more) of the following safeguards should be introduced:A confirmation prompt clearly stating the impact
Example:
“Changing the default remote access tool will affect all devices and may trigger installs or uninstalls. Are you sure?”Separation of concerns
Use the dropdown purely as a view selector
Require an explicit “Set as default” or “Apply globally” action elsewhere
Change logging visibility
Clear audit entries for default remote access changes
Ideally surfaced inline on the Remote Access settings page
Optional role-based restriction
Ability to limit who can change global remote access defaults
This is not a request for new functionality, but for protection around an action that has very large blast radius and real customer impact.
We are very keen to continue expanding our use of Atera, but incidents like this make it difficult to do so confidently. Addressing this would significantly improve operational safety and trust in the platform.
Thank you for listening, and for continuing to build a genuinely powerful product.