Connect a Machine

Connect a machine when an existing computer needs to become a governed Cerberus resource instead of a direct connection target. This workflow makes the machine visible, checks readiness, and prepares it for assignment.

Use this workflow when enrolling or approving a Windows machine. For Linux, Kubernetes, terminal, or other targets where the Windows Agent is not installed, follow agentless access instead.

Choose a connection path

• Windows Agent: The machine supplies service, heartbeat, and local-readiness signals. Follow the Windows path below.
• Gateway or agentless access: Linux, Kubernetes, terminal, and targets where the Windows Agent cannot be installed use the gateway or an already reachable deployment path. Gateway installation and target reachability remain deployment responsibilities.

Prerequisites

• Windows 10/11 and administrator approval during service installation.
• HTTPS egress to the Cerberus panel and identity sign-in.
• A workspace role that can approve the pending machine and create the required assignment.

Steps

1. Open the workspace resource area.
2. Open the pending Windows device or machine enrollment screen.
3. Download the Windows Agent package approved by your deployment’s published release channel. Do not use a development preview for a production resource.
4. Approve the Windows service installation and complete the Agent identity sign-in.
5. Review the pending record’s machine name, version, last heartbeat, and workspace match.
6. Approve the record only after the workspace is confirmed.
7. Wait for current service, heartbeat, and ready-state signals.
8. Complete resource metadata and assign the person, protocol, role, and duration.
9. Confirm readiness before launching the first session.

The panel exposes the pending record, workspace match, last heartbeat, version, and readiness state. Labels may vary by deployment; use the visible record and its durable resource identity rather than a hostname guess.

After connection, use manage access to review assignment, role, duration, and policy before opening a session.

Readiness checks

If launch stays blocked, check:

• the machine was seen recently,
• private reachability is healthy,
• the local account state is ready,
• the resource is assigned to the right person,
• policy allows the selected session type.

Result

The machine appears as a governed resource. People work through assignment and browser sessions instead of shared connection material.

The Windows Agent carries machine-readiness and health signals. Local-account preparation, password rotation, and protocol preparation depend on deployment and policy; they are not implied for an agentless resource.