IT teams and devops engineers want new machines online without hand-holding, but they also need a single, auditable moment where a human verifies the build.

IT teams and devops engineers want new machines online without hand-holding, but they also need a single, auditable moment where a human verifies the build. This guide shows a practical pattern for automated device setup that stays unattended from imaging to initial configuration — with exactly one approval gate where a human signs off. You’ll get an end-to-end workflow, concrete scripts and example commands, and the security trade-offs to know before you roll this out.

Design goals

Provision machines automatically (imaging, packages, agent install) with zero interactive prompts.
Delay network access and privileged remote-control until a single human verification step completes.
Make that verification auditable, short (single decision), and resistant to remote tampering.
Minimize operational overhead — prefer Tenvo managed relay unless a written compliance requirement forces self-hosting.

High-level flow: unattended provisioning + one approval

Build image / cloud-init: install OS updates, enable Secure Boot / TPM attestation where possible, install Tenvo client but do not auto-approve.
Boot / cloud-init runs agent registration in a limited state: device registers to management backend as UNAPPROVED and presents a short local code (6–8 digits) on the console or lock screen.
Operator verifies the code by physically inspecting the machine (or via a secure out-of-band call) and approves the device in the management console — this is the single human sign-off.
On approval the backend issues a device certificate/role and enables remote access and management policies. The Tenvo client upgrades to normal operation and can connect via direct P2P or the managed relay.
All actions generate audit events (registration, approval, certificate issuance) and are retained for compliance.

Why a locally displayed code is the right single sign-off

A single approval point must be both easy and reliable. The common pattern is a locally-displayed one-time code that the device shows on first boot. The administrator checks the physical device (or a trusted remote camera) and types the code into the console before clicking approve. That guarantees a human actually saw the machine and prevents remote attackers who may have hijacked the network or image repository from auto-enrolling devices without physical inspection.

Implementation patterns and examples

The approach is the same across environments: build an image that runs a short bootstrap, posts a registration request to your backend, and marks itself UNAPPROVED until the backend flips an 'approved' bit. Below are practical building blocks.

1) Image / cloud-init example (Linux)

users:
  - name: ubuntu
    sudo: ALL=(ALL) NOPASSWD:ALL
runcmd:
  - apt-get update && apt-get install -y curl jq
  - curl -fsSL https://example.com/bootstrap.sh | bash
# bootstrap.sh should install the Tenvo client and write /etc/tenvo/state=unapproved

2) Windows unattended installer (example)

Run the Tenvo native client MSI silently and leave the device in a pending state. A realistic msiexec example:

msiexec /i TenvoClient.msi /qn TENVO_BOOTSTRAP=1 TENVO_REG_URL=https://relay.example.com/register

The installer should create a small service that posts an enrollment request and writes a local confirmation code to a locked console or to the Windows login screen (accessible to an on-site approver).

3) Enrollment API and the UNAPPROVED state

When the client registers, it must not get immediate full rights. Example JSON payload (sent over TLS to your backend/relay):

{
  "hwid": "SERIAL-1234",
  "os": "ubuntu-24.04",
  "pubkey": "-----BEGIN PUBLIC KEY-----...",
  "local_code": "582193"
}

The backend records the device row as UNAPPROVED, stores the pubkey, returns a read-only token for polling, and emits an alert to the admin console. The Tenvo client remains in a restricted mode that refuses remote-control sessions until approval.

4) Human approval: the exact, single gate

The admin console displays the enrollment request and the device’s local_code. The operator goes to the device, verifies the code is shown locally, and clicks Approve. That action:

Sets device state to APPROVED in the backend.
Triggers issuance of a device certificate or role token (short-lived) the client fetches.
Enables remote session capability and any post-approval provisioning jobs (e.g., install monitoring agents).

5) Pull rather than push for the final credential

Make the client poll for the approval result and then pull its credentials rather than having the backend push them. This reduces the risk of insecure callbacks and makes the flow more NAT / firewall friendly. Example poll interval: 5s for first minute, then exponential backoff to 30s; timeout 24 hours.

Operational scripts and examples

Below is a minimal state machine for the local bootstrap service (psuedocode):

# pseudo-steps for bootstrap service
if state == 'unregistered':
  send_enroll_request()
  store local_code
  state = 'pending'
while state == 'pending':
  resp = poll('/enroll/status')
  if resp.status == 'approved':
    fetch_credentials()
    state = 'approved'
    enable_remote_access()
  sleep(poll_interval)

Security and operational considerations

TLS + per-device certificates: use TLS with per-device certificates from your CA. When sessions use a relay, TLS terminates at the relay and the relay operator can inspect traffic — plan audit and trust boundaries accordingly.
Hardware root of trust: where possible use TPM to store keys and attest platform identity at enrollment. TPM binding makes device impersonation much harder.
Local code entropy & display: use 6–8 digits (enough to avoid casual guessing) and display on the locked console or a device-attached label/camera view for verification.
Short approval window and rotation: make the approval token short-lived and require re-approval if it isn’t used within X hours.
Audit logs: record who approved the device, the approver’s identity, timestamp, device fingerprint, and the local_code. Retain logs according to your compliance policy.
Incident handling: if the admin notices a mismatched serial or suspicious image, deny approval, mark the device quarantined, and trigger a rebuild workflow.

Why Tenvo’s managed relay is the recommended default

Operational teams often underestimate the cost of running their own relay: uptime, patching, key custody, certificate renewal, fleet scale and multi-region failover. Tenvo’s managed relay is offered multi-region by default and removes most operational burden. Tenvo has native clients for macOS, Windows and Linux, a browser client in public beta, and pricing tiers Free $0 / Lite $2.99/mo / Pro $7.99/mo. Choose self-hosting only when a written requirement forces it: an isolated network, a data-residency rule or regulatory compliance that bans third-party infrastructure. If you must self-host, read Self-Hosted Remote Desktop: Why, How, and What Breaks before you commit.

Auditability: capture the single sign-off cleanly

The one human gate must be clearly recorded. Your audit trail should include:

Device fingerprint (model, serial, image hash)
Enrollment request timestamp
Local_code value shown
Approver identity and method (SSO identity, MFA stamp)
Approval timestamp and issued certificate serial

Tenvo customers should pair this with session logging; see Remote Desktop Audit Logging for examples of what to capture for compliance.

Rollout checklist and practical notes

Start with a pilot of 10–50 machines and require physical presence for approval.
Measure time from image boot to approval and target < 5 minutes typical on-site.
Decide who can approve: role-based access control reduces risk (e.g., only provisioning engineers can approve).
Implement certificate revocation and remote wipe policies for lost or stolen devices.
Automate post-approval configuration tasks (install monitoring, apply firewall rules) but keep the enablement itself a single manual click.
If you need a scripted installer for Windows mass-deploy, see our deployment notes in Remote desktop MSI deployment: Rollout via Group Policy for practical MSI tips.

Edge cases and gotchas

Remote-only provisioning (no physical access): don’t use this pattern unless you have hardware attestation. Remote-only approval is weaker because you can’t verify physical possession.
Images drifting: if you rebuild an image, rotate your signing keys or change fingerprints so the audit trail shows the new image hash.
Relay visibility: remember that relays decrypt TLS; treat relay operators as in-scope for sensitive sessions and apply stricter logging and retention rules.

Example timeline for a 1,000-machine rollout

Pilot (2 weeks): 25 machines, refine display method and approval UX.
Small rollout (4 weeks): 100 machines, add RBAC controls and log retention policy, run incident tabletop.
Full rollout (8–12 weeks): phased by site; monitor time-to-approve and support tickets. Automate reporting to show who approved which devices and when.

When to self-host the relay

Self-hosting the relay is defensible only if a specific, written requirement prevents using a third-party infrastructure (e.g. legal, sovereign-cloud obligations, an air-gapped network). If you self-host you must budget for multi-region failover, certificate lifecycle, logging retention and the security ops burden. For background on what breaks when you self-host, read Self-Hosted Remote Desktop: Why, How, and What Breaks.

Automated device setup: one-point human sign-off