Thanks everyone for the thoughtful feedback — offline elevation is an important real‑world scenario, and we appreciate how clearly you outlined the challenges.

AutoElevate’s current architecture requires the device to be online to validate and process approvals. That means offline situations (isolated servers, field techs without connectivity, etc.) don’t currently have a built‑in approval path, which forces partners to maintain their own breakglass solutions.

We agree this creates friction, and we are actively reviewing a secure offline‑capable approach that would provide:

* A protected override code or temporary elevation token

* No need for partners to create or manage separate breakglass accounts

* No plaintext passwords in scripts

* No per‑device/per‑org password sprawl

* No dependency on external tools just to cover offline scenarios

This capability is under consideration and the feedback here directly helps shape and prioritize the final design.

Here is a call to action from everyone here:

Please share your specific offline use cases (e.g., field devices with no connectivity, isolated servers, customer environments with restricted outbound connections). These details help ensure the final solution fits the scenarios you face most often.

+1 to Jasper's comment - without the ability to assume admin when the device is offline there is a massive gap in the AutoElevate solution.

I'd like to make a feature request to have AE create a breakglass account (or temporary override code) for these types of scenarios, with the password stored (and protected via granular access control) in the portal. This would greatly alleviate some of the challenges faced by forcing partners to manage break glass accounts including:

1) Needing to engineer and implement a separate solution for break glass accounts (e.g., Windows LAPS)

2) If using RMM scripting, needing to manually pass a plaintext password as a variable to the script

3) If running a custom RMM script per device, you will having hundreds of different local admin PWs to manage

4) If running a custom RMM script per client, there will be one breakglass PW per org which is not best practice

5) The need to manually add breakglass account passwords to a separate password management solution to ensure retention, accessibility, and security

6) The risk of Breakglass admin passwords growing stale without appropriate password rotation

this shoud be an essential feature

At least Support Admins need a way to get Admin Privileges.