Omarchy on a Company Laptop: The SOC 2 Verdict

TL;DR: Yes, under six controls. I run Omarchy on my own M1 MacBook, dual-booting, and if an engineer asked to run it on a company laptop at a SOC 2 Type II shop, I’d sign off — with conditions, not a shrug. Full-disk encryption and a default-deny firewall ship out of the box and need nothing added. Screen lock, MDM enrollment, patch-cadence evidence, credential consolidation, backup, and agent approval policy don’t ship as controls — they ship as capability, and the difference between the two is exactly what an auditor tests for. This is that list, control by control.

Can you run Omarchy on a company laptop and still pass SOC 2 Type II?

Yes, under six controls you have to add yourself — Omarchy gives you real security defaults, but “defaults” and “an auditor’s control” are not the same artifact, and conflating them is the mistake I’d catch in a readiness review. An auditor doesn’t sample your opinion that the machine is secure. They sample evidence: a screenshot, a log entry, a policy document, a ticket showing the exception was reviewed. Omarchy hands you strong raw material on two of those and nothing at all on the other four. The gap between “the OS does this” and “you can produce evidence the OS does this, on this specific machine, on the date the auditor asks” is the whole verdict.

I haven’t taken a company through an audit with Omarchy machines in the fleet — I’m not going to pretend otherwise. What follows is what I’d sign off as a security lead, reasoning from the same CC6/CC7 criteria I’ve written about for LLM audit trails and from what most security checklists assume about staffing you don’t have — because a control this list recommends and nobody owns is worse than an honest gap.

The control map

That table is the whole post. Everything below is why each row reads the way it does.

What ships and needs nothing added

Full-disk encryption. Omarchy installs with LUKS by default, and its security page states plainly that “full-disk encryption is mandatory: this is the most important step to securing the physical protection of your data.” That’s CC6.1 territory — data at rest on a lost or stolen device — and it’s stronger than what most companies get from an unmanaged macOS fleet, where FileVault is often on by default but not verified per-device. The one thing to check, not assume: “mandatory” has a documented exception. The getting-started page says you can “hit Ctrl + C on the disk formatting confirmation to switch to an encryption-less installation,” so confirm the box that ended up on the company laptop took the encrypted path.

Firewall. Default-deny inbound with a single exception is a clean CC6.6 story, and it needs no configuration from you unless the engineer’s workflow requires opening a port — at which point that’s the exception you document, not a gap in the base state.

What Omarchy gives you the parts for, but not the control

Screen lock. Omarchy ships a real default here: the screensaver comes on at 150 seconds of idle and the lock at 300, per the manual’s idle and screensaver page. That’s the mechanism, and five minutes is a number most auditors accept. It is still not, on its own, evidence of a CC6.1 automatic session lock control, for two reasons the same page documents. The timing lives in ~/.config/omarchy/shell.json, a user-writable file that takes effect the moment it’s saved. And Super + Ctrl + I, or omarchy toggle idle, turns idle lock off entirely, with a coffee-cup icon in the top bar as the only sign. The auditor’s problem isn’t an absent default. It’s a default the user can switch off from a hotkey. The control is “the lock is set to a company-defined timeout the user can’t disable,” and that is a policy you write and verify per machine, not a fact you infer from the software being installed.

Patch cadence. Rolling release is a genuinely defensible patch-management story to an auditor who understands what it means — packages update continuously rather than on a quarterly cycle, which if anything narrows your exposure window versus a device that waits for a scheduled MDM patch push. The problem isn’t the model, it’s the evidence. A Windows or macOS fleet under MDM produces a compliance report on demand: which devices are current, which are behind, since when. omarchy update produces nothing you can hand someone unless you build the artifact yourself — a scheduled job that logs the update run and its result, or an MDM script (Fleet supports running scripts against enrolled Linux hosts) that reports package freshness back to a console you control. Rolling release without a log is a claim. Rolling release with a log is a control.

What has no default, and needs a control written from scratch

MDM enrollment. Omarchy has no built-in device management, which is table stakes on any unmanaged laptop, macOS included — but it means CC6.1’s provision, monitor, and deprovision story needs an external tool wired in before the machine is a fleet member rather than a personal project someone happens to do company work on. Two vendors now ship this specifically for Arch and Omarchy: Fleet added Arch Linux and Omarchy support in 4.75.0, stating it directly in the release notes and covering host vitals, software inventory, remote scripts, and software install; Swif lists Arch Linux among its supported distributions. Neither is a hypothetical “in theory you could manage Arch” — both ship the feature today, which is the difference between a control you can point an auditor at and a plan you’d have to build yourself.

Credential storage. Omarchy pre-wires thirteen coding-agent CLIs, and its launcher knows a fourteenth. Each one authenticates on its own, which means thirteen separately issued credentials on one laptop and no shared path to revoke them — the attack-surface side of that is in the companion post on Omarchy’s default-skip-approval agent launcher. Framed as a control instead of an attack surface: an auditor reviewing access controls wants one place credentials live and one place they’re revoked from, not thirteen. The fix is consolidation — the OS keyring, or a CLI-driven vault like the 1Password CLI, with every agent reading from it instead of holding its own copy. That’s an afternoon of setup per machine and it’s the difference between “we can revoke access in one action” and “we’d have to remember which of thirteen tools still has the old key.”

Backup. There’s no default backup target on an Omarchy install, and unlike the other gaps here, this one isn’t a nuance — it’s a flat absence you have to name and close, not infer around. Pick a target, whether that’s a company-managed cloud backup agent that has a Linux client or a scripted rsync to storage you control, and prove a restore works before you rely on it in an incident review. This is the row auditors sample hardest, because “we have backups” unverified by a restore test is the single most common finding I’d expect to write up.

What about the agent running unattended with the safety off?

That’s the control I’d spend the least space on here because I’ve already written the full inventory — eleven of fourteen agents Omarchy’s launcher knows how to start get their own spelling of “don’t stop to ask” as the default keybinding. The control an auditor accepts isn’t “the engineer promises to be careful.” It’s a written approval-mode policy: which agents are allowed to run in autonomous mode, against which repositories, and what a reviewer checks after an unattended run completes. Without that policy, omarchy agent prompt running against production code with skip-approval flags on is exactly the kind of unmonitored privileged action CC7.2 asks you to be able to detect — and detection requires a policy defining what “normal” looks like before you can flag what isn’t.

The part that isn’t really about Omarchy

None of these six gaps are exotic. They’re the same six things I’d check on any device an engineer wants to bring into scope that the company didn’t image and enroll itself — Omarchy just makes the exercise concrete because it’s opinionated enough to ship real defaults on two controls and genuinely nothing on four others, with no vendor telling you which is which. The same reasoning applies whether the laptop in question is an Arch box, a personal Linux desktop someone SSHes into production from, or a contractor’s unmanaged Mac. Enterprise buyers doing security review on your startup ask this exact question — not “do you allow Linux,” but “can you produce evidence for every device that touches customer data,” and an unmanaged, unenrolled machine of any OS fails that question the same way.

That connection is also why an Omarchy series lives on a site about startup security at all. When I graded my own blog against a 2014 marketing course, this was the bridge I pointed to between a trend topic and the work I actually do.

If you’re the founder or CTO staring at this list wondering whether it’s worth six controls for one engineer’s Linux preference, that’s a genuine cost-benefit call, and it’s exactly the kind of question a fractional security lead exists to answer before the audit finds it for you — not after. I do this work as a vCISO engagement, and the honest version of this post is “yes, conditionally” — never “no,” and never “sure, whatever the OS says it does.”