# fdesetup

> Query and manage FileVault full disk encryption, users, and recovery keys.

fdesetup configures and reports on FileVault full disk encryption. Some status verbs are available to any user, while most management verbs require root and authentication with a FileVault user's password or a recovery key. An attacker can use fdesetup to determine whether the disk is encrypted and how recovery is configured, perform an authenticated restart that bypasses the FileVault unlock screen, generate a new personal recovery key, grant an attacker-controlled account FileVault unlock rights, or disable FileVault entirely.

- Page: https://loobins.io/binaries/fdesetup/
- Author: Brendan Chamberlain (@infosecB)
- Created: 2026-11-07
- Tactics: Persistence, Defense Impairment, Credential Access, Discovery, Impact

## Paths

- `/usr/bin/fdesetup`

## Example Use Cases

### Determine FileVault status and recovery configuration

Check whether FileVault is enabled and whether the host supports authenticated restarts without root. With root, an attacker can also list FileVault-enabled users and determine whether personal or institutional recovery keys exist.

```bash
fdesetup status
fdesetup isactive
fdesetup supportsauthrestart
sudo fdesetup list -extended
sudo fdesetup haspersonalrecoverykey
sudo fdesetup hasinstitutionalrecoverykey
```

- Tactics: Discovery
- Tags: oneliner, bash, filevault

### Bypass the FileVault unlock screen on the next restart

Perform an authenticated restart, which stores an unlock key in memory so the system boots directly to the login window without requiring the FileVault password. Using -delayminutes -1 arms the bypass for the next user-initiated restart instead of rebooting immediately, so services that need the data volume unlocked, such as SSH or remote management, come back up after the reboot.

```bash
sudo fdesetup authrestart -delayminutes -1
```

- Tactics: Persistence, Defense Impairment
- Tags: oneliner, bash, filevault

### Generate a new personal recovery key

Replace the existing personal recovery key with a newly generated key printed to stdout. The attacker gains a key that can unlock the disk, and any previously escrowed key no longer works, which can prevent the organization from recovering the host.

```bash
sudo fdesetup changerecovery -personal
```

- Tactics: Persistence, Credential Access, Impact
- Tags: oneliner, bash, filevault

### Grant an attacker-controlled account FileVault unlock rights

Add an existing local account, such as one created with sysadminctl or dscl, as a FileVault user so it can unlock the disk at boot. Authentication with an existing FileVault user's password or the recovery key is required.

```bash
sudo fdesetup add -usertoadd backdoor
```

- Tactics: Persistence
- Tags: oneliner, bash, filevault, users

### Disable FileVault

Decrypt the boot volume and disable FileVault, removing at-rest protection for the data on the host.

```bash
sudo fdesetup disable
```

- Tactics: Defense Impairment, Impact
- Tags: oneliner, bash, filevault

## Detections

- Command-line detection: fdesetup with authrestart, changerecovery, removerecovery, add, or disable arguments outside of approved MDM or management tooling
- Process execution detection: fdesetup status, list, or has*recoverykey executed by a script interpreter or an unsigned process
- MDM telemetry: FileVault recovery key escrow change or FileVault disabled event reported by the MDM server

## Resources

- [Volume encryption with FileVault in macOS - Apple Platform Security](https://support.apple.com/guide/security/volume-encryption-with-filevault-sec4c6dc1b6e/web)
- [Security Implications of fdesetup authrestart on FileVault-Enabled Macs - Apple Developer Forums](https://developer.apple.com/forums/thread/774703)