Config Profile: FileVault, Key Escrow, and Firewall as One Baseline

Overview

The disk-encryption baseline profile deployed across the Mac fleet at Infoblox. One profile, several payloads: FileVault enforcement, recovery key escrow to Jamf Pro, the built-in firewall, and login window and screensaver policy.

Why these are one profile and not four

They look like separate controls. They aren’t — they’re one outcome with four failure modes, and splitting them across profiles means they can be scoped inconsistently and drift apart.

FileVault without escrow is a liability, not a control. Encrypt every disk, don’t capture the recovery keys, and the first time someone forgets a password or leaves abruptly, the data is gone. Not “temporarily inaccessible” — gone. You will have successfully protected the data from your own company. Escrow is what makes encryption survivable, and it has to be in place before encryption is enforced, or you generate keys nobody holds.

Encryption without a locking screen protects the wrong threat. FileVault defends a powered-off machine. The realistic risk for a laptop fleet is one left unlocked in a coffee shop — an attended, running, decrypted machine. Screensaver and login window policy is what covers the state the device is actually in all day.

The firewall rides along because it’s the same conversation with the same scope and there’s no reason to make it a second deployment.

The result: a device is either compliant with all of it or visibly compliant with none of it. There’s no partial state where encryption is on but the key was never captured — which is the exact gap that turns up during an audit.

What it does

Enforces FileVault with the recovery key escrowed to Jamf Pro, enables the built-in application firewall, and sets login window and screensaver behavior — with the profile marked non-removable, so a user with admin rights can’t unload the baseline from System Settings.

The escrow detail that bites people

Key escrow depends on the redirection profile being present when encryption is enabled. Enforce FileVault first and you produce encrypted machines whose keys never made it to the JSS — and nothing about that state is obvious, because the device reports as encrypted and compliant while being unrecoverable.

Finding those afterward means checking escrow status per device rather than trusting the encryption flag, and remediating means prompting each user to re-issue their key. Ordering the deployment correctly is dramatically cheaper than fixing it later.

Outcome

A single scoped baseline covering encryption, recoverability, network filtering and physical-access protection across the fleet, contributing to the compliance posture that took device compliance from 82% to 98%.

Lessons Learned

Group controls by the outcome they produce, not by the settings pane they live in. Encryption and key escrow are technically separate payloads and operationally the same control — separating them creates a state where you are compliant on the dashboard and unrecoverable in reality. Any control whose safety net is a different profile will eventually be deployed without its safety net.

Paired with the secure token extension attribute, which reports which accounts can actually unlock an encrypted disk — the thing FileVault compliance reporting doesn’t tell you.