Security overview
SwingShift keeps three things apart: your employees' Windows data, the night-mode workloads, and the outside world. This page explains how, and what we need from you.
Security model
| Requirement | How it's met |
|---|---|
| Employee data never touched | The Windows disk is never mounted in Linux. The agent reads only idle time and process names. |
| Workload data stays on site | Night nodes have no internet route, the controller is on-prem, and no telemetry goes to SwingShift by default. |
| Stolen box reveals nothing | LUKS2 with TPM2 + Tang. The recovery key is held by your IT team. |
| Tamper-evident boot | Secure Boot, TPM PCR binding, a signed read-only image and a BIOS admin password. |
| No data left between jobs | The GPU is reset and scratch space wiped each morning. Each job runs in its own container. |
| Traceability | An append-only audit log of jobs, nodes and admin actions. |
| Least vendor access | Support only through customer-approved remote sessions. No standing vendor access. |
Windows agent
A signed Windows service, installed by MSI and deployable through Intune, SCCM or Group Policy. It talks only to your on-prem controller, over mutual TLS. A machine switches to night mode only when all of these hold, re-checked every five minutes:
- The time is inside the configured night window (default 7:00 pm–5:30 am, plus weekends).
- There has been no keyboard or mouse input for at least 30 minutes.
- No process on the site's deny list (CAD, simulation, render, backup) is running.
- GPU utilization has been under 5% for 15 minutes.
- No Windows Update reboot is pending and no maintenance window is active.
- The machine is on AC power, wired to the network, and can reach the controller.
- The employee has not opted out for tonight.
A signed-in user gets a cancellable five-minute warning. The agent then sets a one-time firmware boot to night mode and hibernates Windows. The only Windows changes are full hibernate and that one boot entry. The agent never reads user files, captures screens or keystrokes, or changes BitLocker settings.
Night-mode OS
- A minimal, headless RHEL-compatible Linux 9.x image on its own dedicated NVMe drive.
- UEFI Secure Boot with the distribution's signed shim and kernel.
- A read-only, image-based root filesystem that is updated only as a whole signed image, never patched in place.
- Workloads run in rootless Podman containers with SELinux enforcing. No privileged containers.
- No local logins and SSH disabled. The break-glass key is held only by your IT team.
- The Windows disk is never mounted. The NTFS driver isn't installed, and a udev rule plus SELinux policy enforce this.
- Logs are forwarded to the controller and contain only IDs, timings and errors, never job content.
Encryption & keys
The night drive is LUKS2-encrypted and unlocks automatically only when both of these agree (Clevis with a threshold of 2):
- The machine's own TPM, sealed to the Secure Boot state (PCR 7) and the Linux boot chain. A changed bootloader or disabled Secure Boot breaks unlock.
- Your on-prem Tang key server. If the machine isn't on your site network, it doesn't unlock.
A recovery passphrase is generated for each box at install and escrowed with your IT team, never with SwingShift. Tang keys rotate every 90 days by default. Wiping a box means destroying its key slots and removing it from the controller.
BitLocker stays on the Windows drive with separate keys. On some hardware, a one-time firmware boot can trigger a BitLocker recovery prompt when BitLocker is bound to boot-order PCRs. We validate every workstation model before deployment and recommend a PCR 7-only BitLocker profile.
Network
Night-mode nodes reach only the controller's address and port. The local firewall (nftables) blocks DNS and all internet traffic, and we ask you to enforce the same with a VLAN or firewall rule. Air-gapped sites receive image updates and models only as signed offline bundles. Models in the registry are signed and versioned, and nodes verify their checksums on every load.
Morning failsafes
Every workstation must be back in Windows, resumed and usable, by your start time. Every failure path ends in Windows. Night mode sets "next boot = Windows" as soon as it starts, so any later crash, power loss or reset lands back in the day OS.
| Failure | Response |
|---|---|
| Linux fails to boot or unlock | The firmware default is Windows, so the next power cycle resumes Windows. |
| Node agent hangs | A hardware watchdog reboots the box into Windows. |
| Hand-back deadline missed | The controller forces a power cycle via vPro/AMT 15 minutes after the deadline. |
| Windows resume fails | IT is alerted with the machine name before staff arrive. |
| Controller down | Nodes finish their current job, then return to Windows on a local timer. |
| Employee arrives early | A power-button press triggers an immediate hand-back, in under 3 minutes. |
Audit
The controller keeps an append-only, exportable log of who submitted what, which machine ran it, when, and every admin action. Prompt and output text are not stored unless you explicitly enable it.
What we need from you
- Written sign-off from IT and security, and a written notice to employees (we provide a template). Check labor agreements or works councils where they apply.
- A VLAN or firewall rule that gives night-mode machines no internet route.
- A small server or VM for the controller (8 vCPU, 32 GB RAM, 2 TB SSD).
- BitLocker recovery keys escrowed before install.
- Per machine: an NVIDIA pro GPU (Ampere or newer, at least 16 GB), UEFI with Secure Boot and a BIOS admin password, TPM 2.0, wired Ethernet, Wake-on-LAN or vPro, and a free slot for a dedicated NVMe drive.
Acceptance tests
Every release must pass these tests on at least two different workstation models before it reaches a customer:
- 30 consecutive nights of Windows → night mode → Windows with zero missed mornings.
- Windows resumes with an open CAD file, browser and Office documents intact.
- No BitLocker recovery prompt across 30 cycles on each hardware model.
- No switch while a deny-listed process runs or a user is active. Tonight's opt-out is honored.
- Network cable pulled, or Secure Boot disabled: the night drive does not unlock.
- No internet route from inside a job container. The Windows disk can't be mounted from Linux, even by root.
- Power loss mid-night, or controller offline all night: every box still returns to Windows on time.
- An early power-button press returns the box to Windows in under 3 minutes.
- The audit log shows every job with its submitter, node, and start and end times.
Compliance roadmap: SOC 2 Type I and a NIST 800-171 control mapping for regulated customers.
Have your security team's questions ready?
We'll walk through the design with your IT and security leads in a 30-minute call before anything is installed.