Threat modelling for freelancers and small studios on a shared Mac

Threat modelling has a reputation for being a formal exercise with diagrams. It does not have to be. It is four questions: what are you protecting, who might see it, what happens if they do, and what would actually stop them. Answered honestly, for a real working setup, it usually takes half an hour and rules out most of the security advice you have been ignoring.

Here is that exercise for the situation a lot of independent people are actually in: one or two Macs, sometimes shared, sometimes taken to a client site, holding work that belongs to other people.

What you are protecting

Be specific. “My files” is not an answer you can act on. In a small studio the material that carries real consequences is usually a short list.

• Client material under NDA — unreleased work, brand assets, product photography, anything with an embargo date attached.
• Contracts, invoices and correspondence, which contain other people's addresses, rates and bank details as much as your own.
• Credentials that are not in a password manager: API keys in a config file, a signing certificate, an exported key, a .env you copied from a client repository.
• Source material you were trusted with and cannot re-obtain — interview recordings, scans, drafts, footage of people who agreed to one specific use.
• Your own identity documents, tax records and anything you would rather not explain to whoever borrows the machine.

Notice that most of the harm here is to third parties. That is the part freelancers routinely underweight. Losing your own files is annoying; leaking a client's unreleased campaign is a contract problem and a reputation problem in one.

Who realistically sees it

Rank these by how likely they are, not by how dramatic they sound. In practice the order looks something like this.

1. 01Someone who shares the machine. A partner, a housemate, a family member, a colleague at a shared desk. No malice required — a spotlight search for a filename, a glance at a Finder window, a folder opened by accident.
2. 02The machine leaving your control briefly. A repair shop, a borrowed laptop for a presentation, a Mac left unlocked in a co-working space.
3. 03Loss or theft. Almost always opportunistic and about the hardware, but the disk goes with it.
4. 04A second user account on the same Mac that you set up years ago and stopped thinking about.
5. 05Backups and drives. The old external disk in a drawer with two years of everything on it, which has never been encrypted and never been wiped.
6. 06A targeted attacker with the skill and motivation to go after you specifically. Real, but rare, and the mitigations are different in kind.

Everything above the last item is ordinary and undramatic, and that is where nearly all real incidents come from. A threat model that spends all its energy on the last item and none on the first is a hobby, not a plan.

What FileVault already covers, and what it does not

Turn on FileVault. It is the single highest-value thing on this list and it takes one visit to System Settings. Full-disk encryption protects a Mac that is off or fully shut down: a stolen machine, a drive pulled out of a dead laptop, a disk sent for recycling.

What it does not do is separate anything while you are logged in. Once you have unlocked the Mac, the entire disk is readable by your session — and by anyone sitting at it, and by every application you have granted disk access to. On a machine that other people use, or that you hand over unlocked, FileVault is not part of the picture at all. That is the specific gap a vault fills: it keeps a body of material sealed even while the machine is running and logged in, and open only in the window where you are actually using it.

A setup that holds up

• Separate user accounts for separate people, always. Sharing one login is the root cause of most of the incidents on the list above.
• FileVault on, with the recovery key stored somewhere that is not the machine.
• Client material in a vault rather than in ~/Documents. Mount it when you sit down to that project, eject it when you are done, and let the auto-lock catch the times you forget.
• Credentials in a password manager. A vault is for files; a password manager is for secrets you type. Do not use one as the other.
• One place for everything sensitive, not five. Scattered copies are what make an eventual clean-up impossible.
• Backups that are encrypted too, and a periodic look at what is on the old drive in the drawer.

Being honest about the limits

A vault does not protect an unlocked, mounted volume on a machine somebody else is using. It does not protect against something already running on your Mac with your permissions. It does not undo a file you emailed to the wrong address, and it does not help with the copy of the same material sitting in a client's own shared drive with sharing set to anyone-with-the-link.

What it does is reduce how much of your work is exposed by default, at any given moment, to anyone who ends up in front of your machine. For an independent professional holding other people's material on a computer that is not always exclusively yours, that is the risk that actually shows up — and it is a mitigable one.