Copilot remote control managed device testing helps QA and security teams prove that remote agent sessions can be hosted only where enterprise policy allows. GitHub announced on July 30, 2026 that enterprises and organizations can restrict which devices are eligible to host remotely controlled Copilot sessions.

The new remoteControl managed setting supports three modes: enabled, disabled, and requireSSO. It works with the broader enterprise policy that controls whether users can access remote control at all. This tutorial builds a safe device, identity, and policy matrix so teams can validate the effective control before rollout.

What GitHub officially documents

GitHub says requireSSO enforces SSO authorization, disabled blocks remote control, and enabled permits it without that restriction. Administrators can add the setting to copilot-settings.json.

The setting can be deployed server-side through a .github-private repository, through mobile-device management for specific devices, or as a file delivered to a machine. These mechanisms support layered controls, but the existence of a configuration file is not proof that every device received or enforced it.

Test objective and safe boundaries

Use synthetic repositories, test accounts, and non-sensitive prompts. Do not expose production source code, customer data, deployment credentials, privileged terminals, or personal browser sessions. Prepare at least one managed QA device and one unmanaged test device.

  • Disabled mode blocks session hosting on every tested device.
  • Require-SSO mode allows only an authorized identity and organization.
  • Enabled mode follows the broader enterprise access policy.
  • Unmanaged devices are denied when the device-scoped control requires management.
  • Policy changes take effect within the documented or observed refresh window.
  • In-flight sessions respond safely to revocation.
  • Audit evidence identifies device, identity, policy, outcome, and time without leaking secrets.
  • Rollback restores the previous approved behavior.

Step 1: inventory the effective controls

Record the enterprise remote-control policy, the remoteControl managed value, delivery mechanism, device-management enrollment, SSO organization, client build, operating system, and last policy refresh. Capture expected precedence before testing.

Do not assume that server-managed, MDM-managed, and file-based settings merge identically. Create one case for each mechanism used by your organization and one deliberate conflict so you can observe which value wins.

Step 2: build the device and identity matrix

Case Device Identity Mode Expected
RC-01 Managed Authorized SSO requireSSO Allowed
RC-02 Managed Wrong organization requireSSO Blocked
RC-03 Unmanaged Authorized SSO restricted Blocked
RC-04 Managed Authorized disabled Blocked
RC-05 Managed Authorized enabled Enterprise policy decides

Add expired SSO, revoked membership, offline policy cache, stale MDM state, and multiple-account cases. Each test should use a unique correlation ID and harmless repository task.

Step 3: establish the allowed baseline

On the managed device, apply requireSSO, refresh policy, authenticate with the authorized test account, and start a remote session. Verify the session is hosted by the intended device and cannot silently switch to another machine.

Run a read-only task such as listing a synthetic test directory. Record start time, host device identifier, identity, organization, policy revision, approval prompts, and end state. Avoid screenshots containing tokens, personal notifications, or unrelated repositories.

Step 4: verify blocked paths

Repeat with the unmanaged device, an identity outside the authorized organization, and an expired SSO session. The remote-control request should fail clearly before meaningful workspace access occurs.

Confirm that retrying does not fall back to an unrestricted local or cloud path without telling the user. The error should not expose internal policy contents, tenant identifiers, or device-management details beyond what is necessary to remediate access.

Step 5: test disabled and enabled modes

Set the value to disabled, refresh the managed device, and verify both new sessions and alternate entry points are blocked. Test from the desktop interface, mobile control surface, and any supported handoff flow used by your team.

Then test enabled. Remember that GitHub documents a separate enterprise policy controlling whether remote control is available at all. If the broad policy denies access, the device setting must not override that denial.

Step 6: test policy precedence and drift

Create a controlled conflict between a server-managed value and a device-delivered value only in the lab. Record the effective result and compare it with GitHub’s managed-settings documentation and your deployment design.

Disconnect the device from the network, change policy centrally, and test only if your security team approves offline behavior testing. Reconnect and measure how long enforcement takes. Report this as an observation for the tested build rather than a universal guarantee.

Step 7: revoke an active session

Start an allowed synthetic session, then disable remote control or revoke the test identity’s SSO authorization. Observe whether the current session stops, loses control privileges, or continues until a boundary. Record the exact behavior and elapsed time.

If immediate termination is a requirement but not documented, treat the result as a policy-design question rather than inventing expected product behavior. Define compensating controls such as device isolation, token revocation, or manual session termination.

Step 8: validate evidence and privacy

Useful evidence includes timestamp, correlation ID, device-management status, anonymized device ID, identity class, policy revision, delivery source, decision, and session state. Redact usernames, repository names, SSO assertions, tokens, IP addresses, and screen content not required for reproduction.

Cross-check client evidence with enterprise, identity-provider, and device-management records. A green client message alone does not prove that the intended policy made the decision.

Step 9: define rollout and rollback

Pilot with a small group of managed QA devices. Require passing results for allowed, blocked, stale-policy, wrong-identity, revoked-session, and conflicting-setting cases. Monitor denials and unexpected access attempts after rollout.

Rollback should restore the previous approved copilot-settings.json or enterprise value, force a policy refresh, and rerun RC-01 through RC-05. Keep human security approval for any expansion of remote-control access.

Common mistakes

  • Testing only the happy path: include unmanaged devices and wrong organizations.
  • Ignoring the broad enterprise policy: device settings work alongside it.
  • Assuming file presence means enforcement: inspect the effective value and behavior.
  • Skipping in-flight revocation: test what happens to an active session.
  • Using production workspaces: keep the pilot synthetic and non-sensitive.
  • Sharing raw logs: redact identity, device, repository, and token data.

Official sources