The hidden ticket cost of every security control you ship

The best security control I ever deployed generated 61 tickets in nine days.

It was a good control. Defensible, documented, sailed through review. It also touched a permission that a lot of ordinary utilities need, and I hadn't pre-approved any of them, so the entire company spent a week and a half discovering that their screenshot tool had stopped working and nobody had told them why.

Security approved the change in twelve minutes. The support bill took two months to pay off.

That gap is the thing I want to talk about. Not whether controls are worth it, because mostly they are. The problem is that the cost of a control lands on a completely different team than the one that decided to ship it, at a completely different time, and almost nobody writes that cost down in advance.

The five-minute baseline that locks everyone out

The single most reliable way to generate a ticket flood on a Mac fleet is to take a security benchmark's default ruleset and deploy it without tailoring.

I say that with confidence because the failure modes are consistent enough to be a genre. Deploying an untailored baseline has broken SSH access, because a rule disables it by default. It has disabled iCloud for people who were still actively relying on it. It has forced smart-card-only login onto devices that have never met a smart card. And it has replaced the login banner with stock text falsely claiming the machine is the property of a government agency, which is a fun email to receive from a new hire on day one.

The canonical version of the story goes like this. An admin builds a CMMC Level 2 baseline in about five minutes, which is genuinely how long the tooling takes. It feels great. Real progress, finally. They ship it untested to a group of testers, and the testers cannot log in at all, because the baseline silently enabled smart-card-only authentication and there are no smart cards anywhere in the building.

Some numbers to calibrate how much surface area you're touching. A fresh out-of-box Mac with zero remediation applied still scores around 38% compliant against a CIS Level 2 benchmark, so you are moving 62 percentage points, not turning on a switch. A single benchmark can carry more than 100 individual rules; one I looked at recently referenced 115 separate checks. The generated remediation scripts run to tens of thousands of lines.

One team did the honest experiment and wrapped a full CIS Level 1 benchmark, 94 checks, as a custom compliance policy just to see what their production fleet actually looked like. 46 of 94 came back not compliant. Their conclusion is the most useful sentence in this whole area: strict security and day-to-day usability are in genuine tension, and an organization has to consciously pick where on that line it wants to sit rather than enforcing every available check because the check exists.

I used to think that framing was a cop-out. Then I spent a quarter arguing about a screen-lock timeout with a team of hardware engineers who ran multi-hour simulations, and I understood.

Permission prompts are the support bill nobody forecasts

This is where the real volume comes from, and it's the part security reviews consistently underestimate, because it looks like a UI detail rather than a control.

Apple's privacy framework deliberately resists full automation, even for managed fleets. Some permissions are considered sensitive enough that a human being must physically click, no matter what your management posture is. That's a design position, not a gap waiting to be filled by a better profile.

Concretely: camera and microphone can only ever be pre-DENIED by policy. Never pre-approved. You can take them away and you cannot grant them, so every user, on every app, always clicks.

Screen recording sits in a middle tier. Policy can lower the bar so that a non-admin user is allowed to grant it, which normally requires admin rights, or policy can flatly ban it even for admins. What policy cannot do is silently pre-approve it.

Here's the scenario that puts a human on the phone. A user with broad privacy concerns goes through System Settings and turns off every permission they can find, including ones IT tried to pre-arrange. Two weeks later they join a meeting, click share screen, and nothing happens, because sharing your screen is gated by screen-recording permission. They call the help desk from the meeting. You get to explain the platform's privacy architecture to somebody whose client is watching a frozen slide.

Screen recording is one of the most common permission cases precisely because Apple's definition is broad. It covers literal capture, and it also covers anything that detects screen geometry. Menu-bar management utilities need it. Multi-monitor and display-link tools need it. A huge amount of software that nobody thinks of as screen-recording software silently needs this permission and generates first-run friction the moment it's installed.

The misconfiguration that eats an afternoon. Modern applications are almost never a single binary. There's the app, plus helper tools, plus a background daemon, plus an updater. The most common mistake in permission scoping is granting access to the visible app rather than the helper process that actually performs the sensitive action, which leaves the real requester blocked while your profile reports success. The symptom is a user who says "it still doesn't work" and an admin who is certain it should.

The security point worth saying loudly. Scope permissions by code-signature-derived requirements, not bundle identifiers. A bundle ID is an unenforced string that anybody can claim. Nothing whatsoever stops a rogue application from declaring itself com.microsoft.teams and inheriting whatever you granted to that identifier. Only a code requirement string, pulled from the app's actual signature, gives you any cryptographic guarantee about what you just approved.

And the asymmetry that should drive your whole approach: once permission has been denied, by a user's click or by a policy rule, there is no remote or scripted way to flip it back on. None. You cannot fix this from a terminal, you cannot fix it from your MDM, and the database that stores it is protected from you by System Integrity Protection. Pre-approval is worth roughly ten times what remediation is worth, because remediation doesn't really exist.

Encryption's actual support cost

Full-disk encryption is one of the most commonly audited technical controls and one of the least examined.

Start with the ticket cost, because it's simple and predictable. After three failed password attempts at the pre-boot screen, the device prompts for a recovery key. That prompt is explicitly the mechanism by which most day-to-day password resets get resolved on encrypted machines. Every password your users forget converts into a recovery-key request handled by a human, which means your encryption program is permanently also a key-escrow service desk, whether you budgeted for one or not.

Then there's the self-inflicted one, which I love in the way you love a story that happened to somebody else.

Teams that disable password-based SSH in favor of key-based authentication, which is correct security practice by almost any standard, later discover that Apple's remote FileVault recovery over SSH is explicitly built around password authentication for that account. They have opted themselves out of a remote recovery path they never knew they had. So when a machine strands itself at the pre-boot screen, somebody has to physically walk to it and type a recovery key. In one case that walk ended in a basement.

Now the part that surprised me most. On any Apple silicon Mac, the internal drive's APFS volumes are hardware-encrypted at all times, regardless of whether FileVault is toggled on. Turning FileVault on does not newly encrypt an unencrypted disk on modern hardware. It layers additional user-derived keys onto an already-encrypted volume, which raises protection against a specific threat model: someone who has valid credentials. The drive-pulled-out-and-read-on-another-machine threat model is already satisfied by every shipping machine, out of the box, checkbox untouched.

That matters for how you argue about it. If your written requirement is "if this drive is removed and read elsewhere, is the data protected," a stock Mac already passes. If the requirement additionally covers "protected against an attacker holding valid account credentials," then FileVault is your control and you should enforce it. Plenty of organizations are spending real audit effort on a checkbox that means less on current hardware than they assume, and the honest move is to know which of those two things you're actually buying.

The controls that fail because nobody told you

Offboarding is the least technical item in this article and produces some of the most expensive findings.

The pattern: a contractor stops working. Nobody tells IT, because HR never triggered an offboarding workflow for someone who was never in the HR system as an employee. The device sits unreturned and unmanaged. Not for weeks. For years, until an audit surfaces a machine that hasn't checked in for two years and somebody has to write down what happened to it.

There is no clever engineering fix for this. It's a process seam between two departments, and process seams are where audit findings live.

Your pre-deployment ticket forecast

Before any control ships, answer these in writing. It takes twenty minutes and it's the single highest-return thing on this list.

1. Who loses access, and how do they find out? Name the specific population. If the answer to the second half is "they won't," stop and fix that first.
2. What does the failure look like on screen? Blocked applications under the new endpoint-security blocking give the user nothing at all. The app bounces once in the Dock and dies. No dialog, no explanation. That is a "my Mac is broken" ticket, filed by someone who is being completely honest.
3. Which permissions does this touch, and can they be pre-approved at all? Camera and microphone cannot be. Screen recording cannot be silently granted. Plan for clicks you don't control.
4. Which binary actually needs the grant? The app, the helper, the daemon, or the updater. Check before you write the profile, not after the ticket.
5. Is scoping done by code requirement or bundle ID? If it's bundle ID, redo it.
6. What's the recovery path if this is wrong? For denied permissions there is no remote un-deny. Know that going in.
7. Which deviations are we taking, and why? Risk-based deviations from a benchmark default are a sanctioned mechanism, not cheating. Allowing AirDrop, raising a failed-login threshold from 5 to 10, keeping audit logs 30 days instead of 60. Write each one into the generated documentation with a rationale so an auditor can see the deviation was deliberate.
8. Who is on shift the day after? Pick the day. Not Friday.

Run it against a small pilot group before the pilot group is your executive team. The five-minute baseline story exists because the step everybody skips is the cheap one.

The thing I'd tell a security lead over coffee

Every control has two prices. The obvious one is engineering time, which gets estimated, tracked, and celebrated when it comes in under budget. The other price is measured in confused people, and it gets paid by the help desk, in increments, for months, in a currency nobody reports on.

I don't think the answer is fewer controls. I've watched what happens without them and it's worse. The answer is that whoever proposes a control should be the one who writes down what tickets it will create, and should have to read the actual numbers afterward.

That single habit changes the conversation more than any tooling decision. It turns "security versus usability" from a values argument into an arithmetic one, and arithmetic arguments are the only kind that ever actually get resolved.