Configure access modes and consent

View as Markdown Open in ChatGPT Open in Claude

Remote access policy is a set of ordinary profile settings. This page shows how to set the access modes an endpoint allows, the consent timeout, escorts, the session time limit, and the technician idle limits, so that sessions behave the way your organization or your client requires. For what each mode means, see Remote access.

How the mode is chosen

A technician does not choose a mode. When a session opens, your Outpost merges remote_access.allowed_modes from every profile that applies to the endpoint and opens the session in the most permissive mode left, in this order: Unattended, Attended, Consent required, Escorted.

A mode is allowed only where every applicable profile allows it.
Where two profiles share no mode at all, the stricter of the two wins, rather than nothing.
none is the most restrictive choice. A profile that allows only none turns remote access off wherever it applies.
With no profile setting it, every mode is allowed, so sessions open Unattended.

Profiles can be assigned to the whole client, a site, a device group, an endpoint, a user group, a person, or a technician. A profile assigned to a person applies while that person is signed in at the endpoint. A profile assigned to a technician applies to that technician’s sessions. Because modes merge by agreement, any of these can narrow access and none can widen it.

Permission for each mode

A technician needs remote:initiate and the permission for the mode the policy picks. If they do not have both, the session is refused with [RD_MODE_FORBIDDEN] Remote access requires <permission>, and the refusal is recorded in the audit log.

Mode	Permission needed with `remote:initiate`
Unattended	`remote:unattended`
Attended	`remote:attended`
Consent required	`remote:consent`. On the sign-in screen, where nobody is signed in to answer, also `remote:unattended`.
Escorted	`remote:escorted`

Your Outpost checks again each time the signed-in user at the endpoint changes during a session, because the new user’s policy can pick a different mode. To stop a role using a mode, remove that mode’s permission from the role. See Manage roles.

Before you begin

You need profile:manage. To make a setting or an assignment mandatory, you also need profile:manage_mandatory.
Know which framework baselines apply. A baseline’s floor clamps your values, and the console shows the setting as locked. See Compliance framework baselines.
Policy applies to sessions that open after you save it, and to each change of signed-in user during a session. A session already running keeps the mode it opened in.

Choose the modes an endpoint allows

Go to Profiles > All profiles, and open the profile for the scope you want, or create one. See Create and assign a profile.
On the Settings tab, in Search settings, enter remote_access.allowed_modes.

Select Set in this profile, and choose the modes to allow:

You want	Allow	Sessions open as
No prompt and no banner	`unattended` and any others	Unattended
Always tell the person, never ask	`attended`, `consent`, `escorted`	Attended
Always ask the person first	`consent`, or `consent` and `escorted`	Consent required
A second team member present every time	`escorted`	Escorted
No remote desktop at all	`none`	No session opens

To stop a narrower profile from changing it, select Mandatory.
Select Save.
Make sure the profile is assigned and its status is active.

In Consent required mode, the person at the endpoint has remote_access.consent_timeout_seconds to answer. The default is 120 (2 minutes). When it passes without an answer, the session is denied, and the technician sees Denied. When profiles disagree, the shorter timeout wins.

What the person sees is described in Consent prompts and session notices. The prompt appears in the Outpost tray app, so a consent session fails on an endpoint where policy has turned the tray app off.

Require escorts

An Escorted session lets the technician see the screen at once, but holds their input until enough escorts are present. remote_access.escort_quorum sets how many. The default is 1, and when profiles disagree, the larger number wins. The CJIS baseline raises it to 2.

Until the quorum is met, the viewer shows Awaiting escort.
If an escort leaves and the quorum is no longer met, input is held again. If nobody rejoins within 60 seconds, the session ends.
Escorts carry over when the signed-in user at the endpoint changes.
An escort needs the remote:escort permission.

Limit session length

remote_access.session_max_seconds, labeled Maximum session length in the profile editor, is the longest a session may run, in seconds. When no profile sets it, a session is authorized for 1 hour. Set it to 0 for no time limit. When profiles disagree, the shorter limit wins, and any limit beats 0, so a mandatory profile with a limit keeps it. No compliance framework baseline sets it. PCI DSS limits idle time, not session length. See Require a sign-in to resume.

The limit applies to the whole connection. A change of signed-in user during the session does not restart it. The viewer’s Statistics panel shows the length in Authorized for, such as 1 hour (Workstations profile). When it runs out, the viewer shows Session time is up and says where the limit came from: the profile that set it, the profile that decides among several that set it, the default, or the time left on the session’s original authorization. The session ends with a reason such as [RD_SESSION_EXPIRED] Authorized session duration of 1 hour elapsed (Maximum session length in the profile "Workstations").

An expired session does not reconnect on its own. The technician selects Reconnect to start a fresh session, which policy authorizes again.

Limit technician idle time

Your Outpost watches for technician activity and steps an idle session through three stages:

Stage	Setting	When unset	What happens
Warning	`remote_access.tech_idle_warn_minutes`	5 minutes	The viewer shows Are you still there?, and the warning is recorded in the audit log. Input still reaches the endpoint, and the technician’s next input clears the warning.
Pause	`remote_access.tech_idle_pause_minutes` (Pause after technician idle)	10 minutes	Input to the endpoint is held, and the status reads Paused. Recording pauses too, unless `remote_access.recording_pauses_on_idle` is off. The technician’s next input resumes the session, unless a sign-in is required. See Require a sign-in to resume.
End	`remote_access.tech_idle_terminate_minutes`	30 minutes	The session ends.

Each time counts from the technician’s last activity. Set a stage to 0 to turn it off. When profiles disagree, the shorter time wins, and any time beats 0.

Activity is mouse and keyboard input sent with Control on, and clipboard or file transfers the technician starts. A technician who is watching with Control off sends nothing, so their session counts as idle.

To resume a paused session, the technician turns on Control and selects the endpoint’s screen. The viewer says Paused for inactivity. Turn on Control and click the screen to resume. While the warning shows, any input keeps the session going.

Require a sign-in to resume

remote_access.idle_resume_requires_reauth, labeled Sign in again to resume after an idle pause in the profile editor, makes a paused session wait for the technician to confirm their identity again. While it is on, input to a paused session does nothing. The viewer says Paused for inactivity. Sign in again to resume., and the technician selects Resume and confirms their identity with a passkey, their password, an authenticator code, or a recovery code. See Confirm it is you. A technician who signs in only with a code sent by email cannot confirm this way, and starts a new session instead. It is off by default, and any applicable profile that turns it on wins.

Where this setting is on, a terminal shell that gets no input from the technician for the pause time closes, with a line such as This shell closed after 15 minutes without input. PCI DSS requires it. A shell has no pause to resume from, so it ends instead. Open a new tab to carry on.

The PCI DSS baseline applies Requirement 8.2.8, which requires a fresh sign-in after a session has been idle for more than 15 minutes:

remote_access.tech_idle_pause_minutes is 15 minutes or less. A shorter value is kept, and 0 becomes 15.
remote_access.idle_resume_requires_reauth is on.

PCI DSS does not cap the length of a session and does not require an idle session to end, so the baseline sets neither remote_access.session_max_seconds nor remote_access.tech_idle_terminate_minutes. You can still set either one.

Idle time counts from the technician’s own input. A clipboard or file transfer counts as activity, but never resumes a paused session.

Verify

Open an endpoint in the profile’s scope, and select Remote > Overview. Access mode shows the mode a session will open in, with Set by the profiles that apply to this endpoint. underneath.
Go to Profiles > Effective config for the same endpoint to see each resolved remote_access value and where it came from, including any value a baseline floor changed. See Check an endpoint’s effective configuration.

If something goes wrong

Symptom	Cause	Fix
Access mode reads Off	The applicable profiles allow only `none`.	Find the profile in Effective config, and allow a mode.
The mode is stricter than the profile you edited	Another profile, a mandatory assignment, or a baseline floor is stricter.	Check Effective config. Modes merge by agreement, so the strictest profile decides.
A technician cannot start a session that another technician can	They do not have the permission for the mode the policy picks.	Grant the mode permission in their role. See Permission for each mode.
Consent sessions fail at once on some endpoints	The tray app is turned off on those endpoints, so nobody can be asked.	Turn the tray app on for them, or allow a mode that needs no prompt.

Next steps

Content is licensed CC BY 4.0. Code samples are MIT. Outpost and the Outpost mark are trademarks of Outpost Business Solutions, PBC and are not covered by either license.