<style> /* Reveal x-cloak content so sidebar branch lists and closed-state chips render — EXCEPT the mobile slide-in backdrop, which would otherwise cover the whole viewport in black/40 with no way to dismiss (the dismiss handler is x-on:click="mobileHeader = false" and can't fire without Alpine). */ [x-cloak]:not([x-show="mobileHeader"]) { display: revert !important; } /* (1) Force every version card OPEN so all release-notes content is visible. Overrides the default `.rn-ver-body { grid-template-rows: 0fr }` from release-notes.css, which is normally lifted to `1fr` via Alpine's `:class="{ 'rn-ver-body--open': open }"`. */ .rn-ver-body { grid-template-rows: 1fr !important; } /* (1b) Strip `hidden="until-found"` from collapsed card bodies. WEB-3164 added that attribute on cards 2..N (the first card omits it, see the `{% unless forloop.first %}` in release-notes-cards.eleventy.liquid) so Chrome/Edge browser find-in-page can reveal text inside collapsed bodies and fire a `beforematch` event Alpine catches to pop the card open. Alpine's `x-effect` directive normally removes the attribute when `open` flips true — but without JS that directive never runs, so cards 2..N stay hidden via either `content-visibility: hidden` (Chrome/Edge/Safari 17+ resolve `hidden="until-found"` to that) or `display: none` (older Safari / unknown browsers treat it as a plain boolean `hidden`). Rule (1) above lifts the SCSS-based grid-rows collapse but does NOT override `[hidden]` — the attribute applies a higher-priority `display: none` / `content- visibility: hidden` that wins over grid-template-rows. This rule covers both browser-engine paths: `display: revert` restores the element's normal display (the `grid` utility on the wrapper), `content-visibility: visible` overrides the modern-browser path. */ .rn-ver-body[hidden] { display: revert !important; content-visibility: visible !important; } /* (2) Hide controls that can't do anything without JS so the UI doesn't lie about being interactive: the expand/collapse chevron, the closed-state category chips (Security 3 / Features 5 / …), the section-level expand-all toggle if reintroduced, and the cursor-pointer hint on the header. */ .rn-ver-chevron, .rn-ver-chips, .rn-toggle-all { display: none !important; } .rn-ver-header { cursor: default !important; } /* (3) Hide status pills (Current / Beta / Extended maintenance) and the matching sidebar dots. Pills are rendered server-side from productInfo.json at build time and are accurate at publish — but a stale cached page in Sparkle could surface them on a version that is no longer "Current" by the time the user opens RDM, so hiding them entirely under no-JS removes the whole class of misleading-stale-pill failure modes. */ .rn-ver-tag-line, .rn-status-pill, .rn-status-dot { display: none !important; } /* (4) Sidebar branch chevrons stay frozen in the "closed" rotation without Alpine to flip them — drop them since the branch lists below are already revealed by the x-cloak rule above. */ .rn-toc-branch-head > span:first-child { display: none !important; } /* (5) Hide mobile-only chrome whose Alpine click handlers can't fire: the top mobile menu-open bar and the sidebar's mobile close bar. Both gate `mobileHeader`, which never toggles without JS. */ .rn-main-header, .rn-sidebar > div:first-child { display: none !important; } </style>

Release notes

Release notes

Beyond automation: PAM and remote access in modern IT

Marc Beausejour · July 22, 2026

Table of contents

The endpoint your team supported in 2016 isn’t the endpoint you support today.

Windows desktops, Mac laptops, iPads on a factory floor, iPhones with field crews. Automation and scripting have grown alongside this complexity, but a long tail of work still demands a technician on the machine. And every time a technician opens a session on a critical system, that’s a moment of privileged access that needs governance.

When automation isn’t enough

Some problems don’t scale to scripts. A user reports something “feels off” with nothing in the logs. A legacy application needs a configuration change behind a GUI that has no CLI. A rendering issue exists only at the pixel level. A multi-factor authentication (MFA) prompt requires the user’s physical presence. The remote monitoring and management (RMM) agent itself stops responding. These aren’t exotic edge cases; they’re the daily reality of IT teams working in modern environments. They all require a human inside the system, often with elevated rights. Each one is a privileged session waiting to happen.

Where Remote Desktop Manager fits

This is where Devolutions Remote Desktop Manager (RDM) and Devolutions PAM earn their place.

RDM centralizes remote connections and credentials in a single interface, applying privileged access management (PAM) controls across every connection type. Credentials live in a vault and are brokered to sessions without ever being exposed to the technician. Role-based access controls decide who can reach which system. Session events are logged for audit and recorded, helping satisfy compliance requirements without depending on the underlying engine. For higher-risk targets, just-in-time access and dual-approval workflows ensure critical sessions never start unsupervised. The result is a governance envelope that wraps around every remote session, regardless of the protocol or tool driving it underneath.

These controls don’t stop at the session layer. Pair RDM with Devolutions PAM, and the privileged accounts behind those sessions get the same discipline. PAM discovers privileged accounts across the environment, brokers them through check-out and check-in workflows, and rotates passwords automatically after use. A technician can open a session on a critical system without ever seeing the password, and by the time the session ends, that password is already obsolete. Combined with just-in-time elevation and approvals, privileged access becomes something granted for a task, monitored while it’s used, and revoked when it’s done, not a standing door left open between incidents. That’s privileged access management sized for real IT teams: no dedicated PAM administrator required, no six-month deployment project.

How Supremo plugs in

Supremo is one of the remote access engines that integrates with RDM as a native connection type (we introduced the integration in a previous Spotlight article). Available on Windows, macOS, Android, and iOS, Supremo handles both attended sessions (the classic technician-supports-user scenario) and unattended access for systems that need to be reached without anyone at the other end. Within RDM, Supremo sessions inherit the same governance as RDP, SSH, or any other entry: vault-managed credentials, role-based access, and audited session logs.

Supremo integration in Devolutions Remote Desktop Manager

Supremo integration in Devolutions Remote Desktop Manager

Beyond standard remote access, Supremo adds extra functions like an RMM module and a Helpdesk toolkit, expanding the range of services technicians can offer their users from a single tool. Supremo also stands apart from other remote support tools with its flexible licensing model, which scales as your business grows.

A look ahead: Supremo 5 and the mobile gap

One gap most remote access tools haven’t closed is iOS. Field technicians on iPads, point-of-sale tablets, executives on iPhones: these are real endpoints, and remote support for them has historically meant screenshots and guesswork. The next release, Supremo 5, introduces remote control of iOS devices, extending RDM’s governance envelope to iOS endpoints that have lived outside it for too long.

Join the discussion and share your feedback in the comments section below or on our forum.

Learn more about the Supremo integration and see how it fits into governed remote access with RDM.