Client settings pushed from the console: permissions, security and password rules, capture options. Set the policy once, assign it, and devices pick it up on their next heartbeat.

The console calls them Strategies, matching RustDesk's own terminology.

Strategies → New Strategy. Options are grouped:

• Permissions — keyboard, clipboard, file transfer, audio, camera, terminal, tunnel, remote restart, recording, block input, privacy mode, remote printing, and the overall access mode
• Security — verification method, approve mode, temporary password length and rules, IP whitelist, auto-disconnect timeout, trusted devices, whether the device may have its settings changed locally
• Capture and display

Every control names the underlying client option key, so you can match it against a device's own settings screen.

Leave an option unset and the strategy says nothing about it — the device keeps whatever it has. Only options you actually set are pushed.

Since 1.10.0.

Saving a strategy (Review Impact), deleting one, or restoring an older revision first opens a preview. Nothing has changed at that point. It shows:

• how many devices would get a different effective strategy or policy
• high-impact controls that change, and managed options that would reset to the client default
• a before and after table of every option that changes
• a sample of up to 50 affected devices, with the level the strategy wins at

Apply strategy (or Delete strategy, Restore revision) writes the change. If the strategy was edited, or a device enrolled or moved, after the preview, the console refuses and asks you to review again. Turning a strategy on or off with its switch still applies at once.

Since 1.9.0.

Every change to a strategy is kept as a numbered revision: a save from the editor, a flip of its Enabled switch, and a restore. A strategy that loses Default to another one gets a revision too. Each revision records who made it, when, how many devices the strategy was in force on, and a change note. Revisions cannot be edited or deleted.

The editor's Change note field is where the reason goes. Left blank, the note reads "Saved from the strategy editor", or "Initial revision" for a new strategy.

History on a strategy's row lists its revisions, newest first, and marks the active one. Pick two under Compare from and Compare to to see every field and option that differs between them.

Restore as new revision loads an old revision into the editor and opens the impact preview. Applying it writes a new revision; the old one is left as it was. A restore brings back the note, Enforce and the options. It keeps the strategy's current name, Enabled and Default settings, and confirmation timeout.

Viewing history needs read access to strategies; restoring needs write access.

Some changes are not revisions:

• Assigning a strategy or removing an assignment. Those are in the console audit log.
• Deleting a strategy. Its revisions stay in the database and its name is free for a new strategy, but a deleted strategy leaves the list, so its history can no longer be opened from the console.

Strategies that existed before 1.9.0 start at revision 1, a baseline written by the upgrade.

Since 1.9.0. Administrators only.

Compliance on a strategy's row shows which devices have picked it up. A device confirms a policy by echoing it back on the heartbeat after it arrives.

The first four cover devices the strategy is in force on. The default strategy never shows Overridden devices, because it only applies where nothing else is assigned.

The buttons filter by state and show the count for each. The table lists when each device was last online, when the current options were sent and when it confirmed. It shows the first 200 devices; the counts cover all of them.

Confirmation timeout (minutes) in the editor sets how long a device may go unconfirmed before it counts as stale or offline. Default 15, from 1 to 10080 (a week). The clock starts when the current options were sent to that device, or when they last changed if they have not been sent yet. Online and offline follow the Online window in Settings.

Confirmed means the device received the options. With Enforce off, the person at the device can still change a setting afterwards, and compliance does not see that.

A strategy can be assigned to devices, users and device groups, from the Assign button on the strategy, or per device from the device editor.

When more than one applies, the most specific wins:

device  >  user  >  device group  >  default strategy

Exactly one strategy is ever in force on a device. The device editor shows which one won and why, listing every level and marking it as winning, overridden, skipped because the strategy is disabled, or not set.

Mark a strategy Default to have it apply to any device with no other assignment.

By default a strategy is a default, not a rule.

The console cannot lock a setting in the RustDesk client's own interface. The policy is written into the device's configuration, and the person at that device can change it back. With Enforce off, the console pushes only when the policy itself changes, so a local change stands.

Turn Enforce on and the policy is re-sent on every heartbeat, so a local change is reverted within about fifteen seconds.

Pick deliberately. Advisory is right for a sensible baseline people may adapt. Enforced is right for anything you are relying on for security.

Devices heartbeat roughly every fifteen seconds, so a newly assigned policy applies within about that. Removing an assignment reverts the device, usually within two heartbeats — about thirty seconds.

The RustDesk client's settings window does not refresh while open. If you are watching a device apply a policy, reopen its settings pane to see the new value. The setting is read when a connection asks for the capability, so a stale-looking pane does not mean the policy failed to apply.

Unassign it and the device reverts. The console pushes an explicit reset for the options it had set, because the client has no notion of "revert" by itself.

Disabling a strategy has the same effect on every device holding it, and is the fastest way to roll a bad policy back across a fleet.

Devices can be given a policy at deployment time with the RustDesk client's --assign flag and an API token:

rustdesk.exe --assign --token <token> --strategy_name "Workstations"

The token needs strategy: rw as well as device: rw. An unknown strategy name is an error rather than being silently ignored.

Upgrading from an earlier release: API tokens cannot be edited, only created and revoked. If you have a token that passes --strategy_name, issue a replacement with the strategy permission and retire the old one. Before this release the flag was accepted and did nothing.

• A strategy cannot lock the client's settings interface. Use Enforce if you need the value to stick.
• It reaches the client's main settings only. Display preferences held elsewhere in the client, and options baked into a custom client build, are out of reach.
• Options that only take effect on restart are not offered, because the console cannot make a device restart and would otherwise promise an effect it cannot deliver.
• Devices awaiting approval receive no policy until approved.