Ensure All User Storage APFS Volumes Are Encrypted

What the APFS encryption audit does

This Automox Worklet™ audits macOS endpoints for user-created APFS storage volumes and reports any container that is not protected by FileVault encryption. The Worklet runs diskutil apfs list, isolates volumes tagged with “No specific role” (the APFS marker for a user-created data container rather than a system, Preboot, Recovery, or VM role), and reads the FileVault field returned by diskutil info for each one.

If any user volume returns a FileVault value other than “Yes”, the evaluation script echoes the offending container name and exits 1, which is the signal Automox uses to schedule remediation and flag the endpoint as non-compliant. Volumes carrying a system role are intentionally skipped, because they are governed by the boot volume’s FileVault state, not by per-volume encryption.

The Worklet is FixNow compatible, so you can run a one-shot audit across the macOS fleet from the Automox console and read the results in the activity log without waiting for the next scheduled policy run. You can also schedule it as a recurring policy to keep the audit running continuously against developer laptops, lab Macs, and any endpoint where additional APFS containers are likely to appear.

Why audit APFS volume encryption

FileVault on the boot volume does not cover side partitions. A developer who adds an APFS container for a sandbox VM, a researcher who carves out a scratch volume for data sets, or an admin who creates a separate volume for time-sensitive log capture all produce unencrypted user containers that sit outside the protection of the system FileVault setting. The data at rest on those containers is recoverable by anyone with physical access to the disk, which is the exact scenario FileVault is meant to prevent. CIS Benchmark 2.6.1 for macOS, NIST 800-53 SC-28, PCI-DSS 3.4, and HIPAA §164.312(a)(2)(iv) all require encryption of stored data, and none of them grant an exception for non-boot APFS volumes.

Unencrypted APFS volumes appear for predictable reasons. A developer runs diskutil to carve a second volume for VM scratch space and skips the -E flag, a backup utility creates a sparse bundle next to Macintosh HD with default settings, a refurbished Mac mini comes off the imaging bench with a data volume that was never encrypted because FileVault only covered the boot volume. The Worklet runs diskutil apfs list on each cycle, parses the Encrypted: Yes/No field for every volume in the local container, and reports the per-volume state so unencrypted volumes surface before they become a HIPAA, PCI-DSS Requirement 3.5, or forensic incident finding.

How APFS encryption auditing works

1. Evaluation phase: The Worklet sets IFS to a newline and runs diskutil apfs list, then pipes through grep -A1 “(No specific role)” to find user containers and parses the Name field with cut and awk. For each container it runs diskutil info “${container}”, greps the FileVault line, and trims the leading whitespace. If FileVault returns anything other than “Yes”, the script echoes the container name with “appears to be unencrypted” and exits 1. If the loop completes with every user volume marked Yes, or if no user-created volumes are present, the script exits 0.

2. Remediation phase: The remediation script walks the same set of user containers and prints which volumes are encrypted and which are not, then exits cleanly so Automox surfaces the per-volume detail in the activity log rather than blocking the policy on a partial state. The actual flip from unencrypted to encrypted for a side APFS container requires user-context credentials and is intentionally not destructive in this Worklet. Pair the audit results with a FileVault enablement Worklet, a JAMF policy, or an MDM configuration profile to apply encryption to the flagged volumes, then rerun the audit to confirm compliance.

APFS encryption audit requirements

• macOS endpoint running 10.13 High Sierra or later with APFS as the on-disk format (diskutil apfs list returns empty on HFS+ only systems)

• Root or sudo context for the Automox agent so diskutil info can read the FileVault status on every container (the default agent context already meets this)

• FileVault available on the endpoint; Apple Silicon and T2-equipped Intel Macs encrypt by default at the hardware layer, while pre-T2 Intel Macs require FileVault to be enabled in System Settings or via MDM

• Pair with a separate FileVault enablement workflow (sudo fdesetup enable, MDM configuration profile, or JAMF policy) when the audit flags volumes that need remediation

• Audit evidence collection: capture system_profiler SPStorageDataType and fdesetup status output alongside the Worklet run identifier for change-control records

Expected APFS encryption posture after the audit

An endpoint with no user-created APFS containers exits the audit with “No user created volumes present” in the activity log and exit code 0. An endpoint with one or more user-created containers, all reporting FileVault “Yes”, also exits 0 and produces no remediation work. An endpoint with at least one user container reporting anything other than “Yes” exits 1, names the specific container in the log, and surfaces in the Automox console as non-compliant so the remediation queue can act on it.

Validate the audit results from a target endpoint with diskutil apfs list to enumerate all containers, diskutil info <volume> | grep FileVault to read the per-volume state, fdesetup status to confirm the boot-volume FileVault state, and system_profiler SPStorageDataType for a full storage inventory. Run the Worklet in FixNow mode for immediate per-endpoint results, or schedule it on a daily or weekly cadence to keep the macOS fleet under continuous APFS encryption audit.