Skip to content

Device Security Standard (BYOD baseline & attestation)

Purpose. Defines the minimum security configuration every device used for Soon work must meet, and how Soon verifies it. Soon is fully remote and all endpoints are privately owned (BYOD) — there is no company-issued hardware and no MDM. This standard plus the quarterly attestation in §4 is the compensating control that makes endpoint security verifiable without agent software on personal machines. Satisfies A.8.1 (user endpoint devices), A.8.7 (malware), A.6.7 (remote working) and SOC 2 CC6.8.

Status: DRAFT. Baseline agreed; the first attestation round has not yet run.

1. Why this approach

Full MDM on a personally-owned device is disproportionate for a four-founder company and raises legitimate privacy concerns (a personal laptop is not company property). Soon therefore uses a documented baseline + verifiable self-attestation instead of an enforcement agent, backed by the strongest real mitigation: every production system requires MFA and/or SSO, so a stolen device alone grants no access.

This is a deliberate, risk-accepted decision, recorded in the Risk Assessment Report (R-01, R-02).

1.1 Internal decision note — why no MDM (2026-08-08)

Not for external distribution. Kept so the decision is defensible and revisitable, rather than looking like an oversight.

Decision. Soon will not deploy MDM or EDR at this time. Endpoint assurance is provided by this standard's baseline plus the quarterly verifiable attestation in §4.

Why. Four founders, all on privately-owned Macs. Enforcement agents on personal hardware are intrusive (an MDM can wipe or inventory a personal device), and in the Netherlands imposing that on a personal machine is a genuine privacy and employment-law question rather than a simple procurement one. Meanwhile the actual risk a stolen laptop creates is unauthorised access to Soon systems — and that is already controlled centrally by MFA/SSO, which does not depend on the device at all.

Options considered.

Option Verdict
MDM (Kandji, Mosyle, Intune) The right answer for company-owned devices — enforces settings and enables remote wipe. Rejected for now: personal hardware, ~4 devices, disproportionate. Jamf Now was discontinued, so the "free tier" route no longer exists.
Tailscale Misfit for this control — it is a network/VPN layer, not device management. It cannot enforce FileVault or wipe a device. (It is, however, a good option for private database access — see ISMS-DOC-A05-37-1.)
osquery (+ Fleet) Read-only telemetry: it can report that FileVault is off but cannot enforce anything, and needs a server plus agent rollout. Our §4 attestation obtains the same facts with no infrastructure.
Build our own agent Rejected. Writing a root-level agent for personal laptops, plus a server and alerting, to replace a ~€4/device product is high effort, ongoing maintenance and less credible to an assessor than a known tool or an honest attestation.
Baseline + verifiable attestation (chosen) Proportionate, no software on personal devices, and produces real evidence (command output + screenshots) rather than a self-declared checkbox.

What we accept. Configuration drift between quarterly attestations is not detected automatically, and Soon cannot remotely wipe a lost personal device. Both are accepted at current size and stated openly in the System Description §7 — an assessor is far more comfortable with a documented, justified limitation than with a claim of managed endpoints that the evidence would contradict.

Trigger to revisit — adopt MDM when any of these occur: 1. The first company-owned device is purchased (MDM becomes straightforward — it is our hardware); 2. The first non-founder employee joins; 3. A customer contract or auditor finding requires managed endpoints; 4. Headcount reaches ~10, where attestation stops scaling.

At that point adopt a lightweight MDM (Kandji is the current front-runner for a Mac-only fleet) and retire the attestation process. Reviewed at least annually by the ISM.

2. The baseline — every device, always

# Requirement Why
1 Full-disk encryption on (macOS FileVault) A lost laptop must not expose data
2 Screen lock ≤ 5 minutes, password required on wake Unattended-device access
3 OS and browser auto-update on; security updates within 14 days Known-vulnerability exposure
4 Firewall on Reduce local network attack surface
5 Built-in malware protection enabled (macOS XProtect/Gatekeeper; do not disable) A.8.7
6 Credentials only in Enpass — never in files, notes, browsers-without-a-master-password, or chat A.5.17
7 No customer personal data stored locally — work in the platform; delete local exports immediately after use A.8.12, GDPR minimisation
8 Device not shared with family/others for Soon work; separate account if a machine is shared A.8.1
9 Report loss/theft within 24 hours via Slack #Security or security@soon.works A.6.8
10 Automatic backup enabled (e.g. Time Machine/iCloud) with encryption Availability

Mobile devices used for Soon email/Slack/MFA must have a passcode or biometric lock, auto-update on, and remote-wipe available (Find My / equivalent).

3. Leavers & lost devices

  • On leaving, access is revoked centrally (per the User Access Management Process) — the primary control, since Soon cannot wipe a personal device. The leaver must delete all local Soon data and confirm in writing (Termination Checklist).
  • On loss/theft: report immediately → revoke sessions and rotate credentials → remote wipe if the owner has it enabled → handle as a security event under the Incident Response Procedure.

4. Quarterly attestation — how we verify (the evidence step)

Self-declaration alone is not evidence. Each quarter every device user runs the check below and submits the output plus a screenshot. This produces objective proof of items 1–4 without any agent installed.

# macOS — run in Terminal, paste the full output into the attestation record
echo "== FileVault =="        ; fdesetup status
echo "== Screen lock =="      ; sysadminctl -screenLock status 2>&1
echo "== Auto-update =="      ; defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist AutomaticCheckEnabled 2>/dev/null; softwareupdate --history | tail -3
echo "== Firewall =="         ; /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
echo "== Gatekeeper =="       ; spctl --status
echo "== OS version =="       ; sw_vers

Record per person per quarter: date · name · device (model/OS) · command output · screenshot of the Security & Privacy settings pane · confirmation of items 5–10. Store per the Evidence Collection & Management Procedure; log the round in the Evidence Register under A.8.1. A device that fails any item is remediated before the record is accepted.

5. Roles

  • ISM (Olaf) — owns this standard, runs the quarterly round, keeps the records, decides when MDM is adopted.
  • Every device user — meets the baseline continuously, attests quarterly, reports loss within 24h.
  • Platform (Thomas) — maintains the central access controls (MFA/SSO) that make a lost device non-catastrophic.

Change log

Version Date Author Comments
0.1 2026-08-08 ISMS First draft — BYOD baseline (10 requirements), the compensating-control rationale for having no MDM, the quarterly verifiable attestation (with the macOS check commands), leaver/lost-device handling, and the trigger to adopt MDM.