Deep Clean and Secure Delete on macOS: APFS, FileVault, Snapshots

On a modern Mac, secure deletion is a key destruction problem, not an overwriting problem. Apple removed Secure Empty Trash because it could not guarantee deletion on flash storage, and internal storage on Apple silicon and T2 Macs is always encrypted. Check FileVault, remove Time Machine local snapshots, then use Erase All Content and Settings before handing a Mac on.

Key takeaways

• Apple removed Secure Empty Trash in OS X El Capitan v10.11 because it could not guarantee secure deletion on systems "such as those with flash storage" (CVE-2015-5901).
• Disk Utility offers no secure erase options for SSDs, and the diskutil secureErase manual page says this kind of erase "is no longer considered safe."
• On Apple silicon and T2 Macs, internal APFS volumes are encrypted whether FileVault is on or off. FileVault adds your password to what protects the key.
• Erasing on those Macs means the Secure Enclave deletes keys, which Apple says "renders the volume cryptographically inaccessible."
• Erase All Content and Settings needs macOS Monterey 12 or later on Apple silicon or T2. Older Intel Macs use the Recovery erase and reinstall route.
• Time Machine local snapshots can keep deleted files for 24 hours or longer. List them with tmutil listlocalsnapshots /.
• iCloud Drive, iCloud Photos, backup disks and escrowed recovery keys all sit outside a local erase.
• External drives get no Secure Enclave protection. Encrypt them from first use.

Why did Secure Empty Trash and multi pass erase go away?

Secure Empty Trash and Disk Utility's multi pass erase came from the era of spinning disks, where writing over a file's exact sectors destroyed the old magnetic pattern.

Apple's security content note for OS X El Capitan v10.11 is the primary record of why the Finder option went away. Under the Finder entry (CVE-2015-5901, applying to Mac OS X v10.6.8 and later), Apple says there was a problem guaranteeing secure deletion "on some systems, such as those with flash storage", and that it was fixed by removing the option. That is the only reason Apple has published.

The underlying cause is flash behaviour. An SSD controller writes new data to fresh cells, updates a mapping table and retires the old cells for later cleanup, and it keeps spare blocks the operating system cannot address. An overwrite request may land somewhere else entirely, leaving the original in a retired block.

The diskutil manual page that ships with macOS says so next to the secureErase verb: "This kind of secure erase is no longer considered safe." It blames "wear-leveling, block-sparing, and possibly-persistent cache hardware," and gives the modern answer: "The modern solution for quickly and securely erasing your data is encryption."

Disk Utility kept overwrite passes where they still work. Its guide describes a Security Options slider "available only for some types of storage devices," and states: "With a solid-state drive (SSD), secure erase options are not available in Disk Utility." Apple's advice for SSDs is to turn on FileVault from the start.

How does APFS on SSD store and delete data?

Apple's Apple File System Reference describes two design choices that matter for deletion.

The first is copy on write. Physical objects "are modified by writing the copy to a new location on disk," and the container keeps checkpoints holding its state "at past points in time." This gives crash protection and cheap snapshots and clones, and it means APFS itself prefers writing to new places over overwriting old blocks.

The second is snapshots. While a snapshot exists, the blocks it references stay allocated even if you delete every file that used them. That is why emptying the Trash does not always free space, and why Time Machine local snapshots matter here.

So when you delete a file, APFS removes the directory entry and frees extents once no snapshot or clone points at them. The bits may persist in freed blocks, snapshot blocks or retired flash cells. On an unencrypted disk that could be recoverable. On an encrypted volume it is ciphertext, only as readable as its key is available.

The reference also says hardware encryption "is used for internal storage on devices that support it, including macOS (with T2 security chip) and iOS devices," while software encryption "is used for external storage." That split drives most of the advice below. The public reference is dated 2020 and documents only software encryption.

How do FileVault and the Secure Enclave make erase a key destruction step?

Apple Platform Security explains the key hierarchy in its page on volume encryption with FileVault. Here is the chain in plain terms.

1. Every APFS volume gets a volume encryption key (VEK). File contents and metadata on the volume are encrypted with it, using AES-XTS.
2. The VEK is wrapped by a key encryption key (KEK).
3. On Macs with Apple silicon or a T2 chip, all of this key handling "occurs in the Secure Enclave; encryption keys are never directly exposed to the CPU."
4. All VEKs are also wrapped with a media key. Apple says the media key exists for fast secure deletion rather than extra confidentiality, and that on Apple silicon and T2 Macs its erasure is guaranteed through the Secure Enclave.

With FileVault off, Apple says the volume "is still encrypted but the volume encryption key is protected only by the hardware UID in the Secure Enclave." So an Apple silicon or T2 Mac never writes your data to flash in plaintext. With FileVault on, the KEK is protected by "a combination of the user's password and hardware UID," so holding the Mac is not enough to read it.

Turning FileVault on encrypts "all existing files and any further data written," and an anti replay mechanism "helps prevent the old key (based on hardware UID only) from being used to decrypt the volume." The old UID only key path is retired, not left lying around.

Erasure follows directly: "When deleting a volume, its volume encryption key is securely deleted by the Secure Enclave," and "Erasing the media key in this manner renders the volume cryptographically inaccessible." Nothing is overwritten. The ciphertext stays on the flash, but without the key it is noise.

Apple's general Data Protection page describes the same pattern across Apple devices: the file system key is wrapped by "an effaceable key stored in Effaceable Storage," that key exists to be erased quickly, and "The key-wrapping key changes every time a user erases their device." That page is not Mac specific, so treat it as the design principle and the FileVault page as the Mac statement. The Secure Enclave page also lists Erase All Content and Settings as an anti replay boundary, so old keys cannot be brought back into use after an erase.

Intel Macs without a T2 chip are different. Apple says Intel Macs without a T1 chip or Secure Enclave "don't use dedicated silicon for FileVault keys." FileVault there is software encryption, and the disk is not encrypted at all unless FileVault was turned on. Any plaintext written before that may still be on the SSD, out of reach of key destruction.

Is FileVault on by default now?

Apple's documents differ, so check rather than assume. The Data Protection overview in Apple Platform Security says that on macOS 26.4 or later FileVault is on by default, with an opt out. The macOS 27 User Guide still describes FileVault as something you turn on, while noting that on Apple silicon or T2 Macs "your data is encrypted automatically." The commands below give a definite answer for your machine.

How do you check FileVault status and the recovery key arrangement?

Open System Settings, then Privacy and Security, then FileVault. Apple's guide says you must be an administrator to set it up, and that when you turn it on you choose between letting your iCloud account unlock the disk or creating a recovery key. If you choose a recovery key, Apple says to "keep a copy of the key somewhere other than your encrypted startup disk." Apple also warns that if you forget your login password and cannot reset it, and you also lose the recovery key, "your files and settings will be lost forever."

From Terminal, these read only commands answer the main questions. fdesetup status can run without root; Apple's manual page says "some status related commands can be run from a non-root session," while most others need root.

# Is FileVault on, off, or still encrypting?
fdesetup status

# Exit code 0 and "true" if FileVault is on, 1 and "false" if off
fdesetup isactive

# Does this Mac have a personal recovery key? (needs admin)
sudo fdesetup haspersonalrecoverykey

# Is an institutional recovery key installed? (needs admin)
sudo fdesetup hasinstitutionalrecoverykey

# Which users can unlock the disk at startup? (needs admin)
sudo fdesetup list

# Per-volume view, including a FileVault line for each APFS volume
diskutil apfs list

To confirm that the recovery key you wrote down is the right one, sudo fdesetup validaterecovery prompts for it and returns "true" if it matches. The manual page gives the expected format as six groups of four characters.

For managed Macs, Apple's Managing FileVault page notes that a personal recovery key can be escrowed with a device management service, that institutional recovery keys are "no longer recommended," and that a Secure Token is "a wrapped version of a key encryption key (KEK) protected by a user's password." A Bootstrap Token, escrowed to the management service, can grant Secure Tokens to users who log in on macOS 11 or later.

This matters because NIST SP 800-88r2 says cryptographic erase "should not be trusted" on media whose keys were backed up or escrowed unless you know how and where those copies are kept. On a Mac the media key lives in the Secure Enclave and is erased there, so a recovery key that unwrapped the old KEK unlocks nothing after an erase. Retire those records anyway when the Mac leaves. Our posts on checking whether FileVault is on and on choosing between iCloud and a recovery key go deeper on the choice itself.

What does Erase All Content and Settings do on Apple silicon and T2 Macs vs older Intel Macs?

Erase All Content and Settings is the Mac equivalent of a phone reset. Apple describes it as a way to "quickly and securely erase all of your data, settings, and apps" while keeping the macOS version already installed. It requires macOS Monterey 12 or later and a Mac with Apple silicon or an Apple T2 Security Chip.

The steps from Apple's support article:

1. Back up first, or move your files to another Mac.
2. Open System Settings, then General, then Transfer or Reset. On macOS Monterey the option is in System Preferences instead.
3. Click Erase All Content and Settings.
4. Enter your macOS user password, then your Apple Account password. Apple says the process signs you out of Apple services.
5. Confirm. Ignore any prompt to sign back in to your Apple Account or iCloud.

The Mac restarts, activates and opens the setup assistant as if new. If the Mac is leaving you, Apple says not to continue setup; hold the power button until it turns off. Apple also advises running Repair Assistant first on a repaired Apple silicon Mac with macOS 26 or later, and removing any Boot Camp Windows partition with Boot Camp Assistant if you are told other volumes must be erased.

It is fast because the Secure Enclave discards keys instead of overwriting hundreds of gigabytes. Apple's Data Protection page says the metadata key is created "when the operating system is first installed or when the user completes Erase All Content and Settings."

Intel Macs without a T2 chip do not get the option. Apple's sell or give away article gives the older route: sign out of your Apple Account and iMessage, start from macOS Recovery, erase with Disk Utility, reinstall macOS, quit setup with Command Q, and reset NVRAM, which "clears user settings from memory and restores certain security features that might have been altered." If you can use Erase All Content and Settings, Apple says "you don't have to complete any of the other steps."

What do Time Machine local snapshots keep, and how do you list and remove them?

This is the step people miss. Apple's "About Time Machine local snapshots" article explains the behaviour when Time Machine is set up:

• Time Machine takes a snapshot of the startup disk "approximately every hour" and keeps hourly snapshots for 24 hours.
• It keeps a snapshot of your last successful Time Machine backup until space is needed.
• On macOS High Sierra 10.13 or later, "another snapshot is saved before installing any macOS update."
• "Your Mac counts the space used by snapshots as available storage," and Time Machine "automatically deletes snapshots as they age or as space is needed for other things."

So a file deleted this morning can still be read by anyone who can unlock your Mac until its snapshot ages out. That matters for a Mac you keep using or share, not for a locked FileVault Mac in a thief's hands.

List snapshots

# Local Time Machine snapshots on the startup volume
tmutil listlocalsnapshots /

# Just the creation dates, formatted YYYY-MM-DD-HHMMSS
tmutil listlocalsnapshotdates /

# Every APFS snapshot on the Data volume, including non Time Machine ones
diskutil apfs listSnapshots /System/Volumes/Data

diskutil apfs listSnapshots shows all APFS snapshots on a volume, with UUID, name and XID. Other software, including backup tools and system updates, can create snapshots too, so this view is wider than the Time Machine one.

Remove snapshots the supported way

Apple's article gives a GUI method: turn off automatic backups in Time Machine settings (on macOS Ventura 13 or later, set Backup Frequency to Manually), "wait a few minutes to allow local snapshots to be deleted," then turn automatic backups back on.

Remove snapshots from Terminal

Warning: deleting snapshots is permanent. You lose the ability to recover files from those points in time, and if a snapshot is your only copy of something, it is gone. Check what you are deleting first, and make sure you have a current Time Machine backup on an external disk if you want one.

# 1. Check: list what exists and note the exact dates
tmutil listlocalsnapshotdates /

# 2. Delete the local snapshots for one specific date
sudo tmutil deletelocalsnapshots 2026-10-23-091500

# 3. Or delete all local Time Machine snapshots on the startup disk
sudo tmutil deletelocalsnapshots /

# 4. Confirm they are gone
tmutil listlocalsnapshots /

Per the tmutil manual page, a date removes that date's local snapshots "on all mounted disks," and a disk removes all local Time Machine snapshots on it. tmutil thinlocalsnapshots instead reclaims a given number of bytes by thinning.

Deleting snapshots frees blocks; it does not overwrite them. On an encrypted volume that is fine. The goal is to stop deleted files being readable through the file system on an unlocked Mac. Backups on an external Time Machine disk are separate copies; tmutil delete with -d and -t removes specific ones and needs root and Full Disk Access.

What about iCloud Drive, Optimised Storage and Photos "Recently Deleted"?

A local erase only reaches local storage. Several Apple features mean copies of your files live somewhere else.

iCloud Drive. Apple's macOS User Guide says that with Desktop and Documents Folders on, those folders "are moved into iCloud Drive," and with Optimize Mac Storage, "Your Mac can automatically store documents in iCloud when more space is needed." A file may exist only in iCloud, or survive there and on other signed in devices after you delete it locally. Erasing the Mac deletes nothing from iCloud.

iCloud Photos. Optimize Mac Storage "stores smaller versions of your photos on your Mac" and "keeps the original, full-size photos in iCloud." Deleting the local library does not touch those originals.

Photos Recently Deleted. Deleted items wait in Recently Deleted; Apple says "After 30 days, they're permanently deleted." To remove them sooner, open Recently Deleted under Utilities, unlock it and use Delete All. Check other devices yourself rather than assuming sync did it.

Treat cloud data as a separate decision. Moving to a new Mac? Confirm your data arrived there before you sign out and erase the old one.

Deep cleaning a Mac you will keep using

To remove sensitive leftovers from a Mac you will keep, such as an old client project or a database dump, follow how APFS actually behaves:

1. Confirm FileVault with fdesetup status. On an Intel Mac without T2, turn it on now.
2. Find the data. du -sh ~/* 2>/dev/null | sort -h shows where space goes; also check ~/.npm, ~/.cache and ~/Library/Caches.
3. Delete and empty the Trash, knowing this removes directory entries, not data.
4. Delete cloud copies in iCloud Drive or any other sync service.
5. Remove local snapshots as shown above.
6. Deal with backup disks that hold the same files.
7. Rotate exposed secrets. If the files held tokens, SSH keys or passwords, deletion does not revoke them.

Skip free space overwrites on an SSD. diskutil secureErase freespace still exists, but Apple's manual page says it is no longer considered safe, and on a FileVault volume the freed blocks are ciphertext anyway.

What should you do with an external drive or USB stick on a Mac?

Apple's FileVault page says: "Encryption of removable storage devices doesn't utilize the security capabilities of the Secure Enclave." External drives get software encryption keyed from a password you choose. So:

• Encrypt from first use. Format new external drives as APFS (Encrypted), which Apple describes as "Uses the APFS format and encrypts the volume." A drive that only ever held ciphertext is safe to erase later.
• Know the cross platform trade off. Apple lists MS-DOS (FAT) "for Windows volumes that are 32 GB or less" and ExFAT for those "over 32 GB." Neither is encrypted.
• Hard disks can still be overwritten with Disk Utility's Security Options slider, where it appears.
• Flash that once held plaintext is the hard case. Nothing in Disk Utility or diskutil can promise those cells are gone. For sensitive data, destroy the device.

Walkthrough: erase and encrypt an external drive

Warning: the commands below destroy everything on the target disk. Picking the wrong disk identifier can wipe your startup disk or a backup. Disconnect every external drive you do not intend to erase, and check the identifier twice before running the erase.

# 1. Check: list only external physical disks
diskutil list external physical

# 2. Check: confirm size, name, protocol and that it is the disk you expect
diskutil info disk4

# 3. Erase the whole disk with a GUID partition map and one APFS volume
#    (replace disk4 with the identifier you confirmed in steps 1 and 2)
diskutil eraseDisk APFS Backup GPT disk4

# 4. Find the new APFS volume (it lives in a synthesized container disk)
diskutil apfs list

# 5. Turn on encryption for that volume; you will be asked for a passphrase
diskutil apfs encryptVolume disk5s1 -user disk

# 6. Confirm the volume reports FileVault: Yes (encrypted)
diskutil apfs list

The encryptVolume ... -user disk form comes from the diskutil manual page. In the GUI, Disk Utility lets you pick APFS (Encrypted) and set a password in one step. Store the passphrase somewhere other than the drive.

Which commands need Full Disk Access or admin rights?

macOS has two gates: administrator rights (sudo) and Full Disk Access, a privacy permission granted to the app you run commands from. The tmutil manual page says "Several, but not all, verbs require root and Full Disk Access privileges." Add Terminal under System Settings, Privacy and Security, Full Disk Access.

If a command fails with "Operation not permitted", grant Full Disk Access to Terminal before trying anything more drastic.

How does each step map to NIST SP 800-88 Clear and Purge?

NIST published SP 800-88 Revision 2, Guidelines for Media Sanitization, in September 2025. It supersedes Revision 1 from December 2014. Its three methods:

• Clear applies logical techniques to "all user-addressable storage locations" for protection against simple, non invasive recovery, typically through standard read and write commands "or using a menu option to reset the device to the factory state."
• Purge applies physical or logical techniques to make recovery "infeasible using state-of-the-art laboratory techniques," while leaving the media potentially reusable. NIST lists cryptographic erase as a purge technique and says it is "noteworthy in its ability to rapidly sanitize target data."
• Destroy makes recovery infeasible and leaves the media unusable.

NIST's cryptographic erase has preconditions. Citing ISO/IEC 27040, it says no sensitive data should have been stored on the media in plaintext, and "all copies of the target cryptographic keys must be able to be sanitized." For very long lived secrets it warns that future cryptographic weaknesses could make leftover ciphertext a concern.

Apple does not describe its features in NIST terms. The table is our mapping, not a certification.

Common mistakes

• Trusting the Trash. Emptying it frees directory entries. On an unlocked Mac, local snapshots can still hold the files for up to a day, and longer for the last backup snapshot.
• Running free space overwrite tools on an SSD. Apple's manual page says this is no longer considered safe. It wears the drive and still misses remapped blocks.
• Assuming FileVault is on. Apple silicon encrypts the disk regardless, but FileVault decides whether your password protects the key. Run fdesetup status.
• Erasing before checking the cloud. Erase All Content and Settings does not delete iCloud Drive or iCloud Photos data. Decide what happens there first.
• Forgetting the backup disk. A Time Machine disk holds every version of the files you just deleted. Treat it as sensitive media in its own right.
• Formatting a USB stick ExFAT and calling it safe. ExFAT is for compatibility, not confidentiality. Encrypt files before copying, or use APFS (Encrypted) when only Macs will read it.
• Picking the wrong disk in diskutil. Always run diskutil list external physical and diskutil info first, and unplug drives you are not erasing.
• Not rotating secrets. A perfect erase does not revoke tokens or keys that lived on the Mac.

Where Safeguard fits, honestly

Safeguard is a software supply chain security platform. It does not erase drives, manage Macs, check FileVault, scan for malware, or protect endpoints, and nothing in the steps above depends on it. The connection is narrower. A Mac used for development is part of your software supply chain: it holds lockfiles, global package installs, old SDKs, Homebrew formulae and container images. After a deep clean or a full erase, you rebuild that environment by reinstalling dependencies, and that is when old vulnerable versions quietly return. Scanning each project on the rebuilt Mac with the Safeguard CLI, or through the local runner and offline mode, shows which component versions you just pulled and which known vulnerabilities apply, before that machine starts building and shipping code again. Our post on the Safeguard CLI as a security aware coding assistant covers that workflow in more detail.

FAQ

Does emptying the Trash on a Mac permanently delete files?

No. It removes the files from the file system's directory, but the data can remain in freed blocks and in Time Machine local snapshots until they age out. On an encrypted volume that data is ciphertext, so the practical risk is to an unlocked Mac, not a locked one.

Why can't I find Secure Empty Trash on my Mac?

Apple removed it in OS X El Capitan v10.11. Its security notes say it could not guarantee secure deletion on some systems, such as those with flash storage, and list the change under CVE-2015-5901. FileVault encryption is the replacement approach.

Is it safe to sell a Mac after Erase All Content and Settings?

On a Mac with Apple silicon or a T2 chip running macOS Monterey 12 or later, Apple describes it as a way to "quickly and securely erase" data, settings and apps. It works by having the Secure Enclave discard keys. Sign out of your Apple Account through the process, check what remains in iCloud, and stop at the setup assistant.

Do I need FileVault if my Mac already encrypts the SSD?

Yes, in most cases. Without FileVault, Apple says the volume key is protected only by the hardware UID, so whoever holds the powered Mac can boot it and read the data. FileVault ties the key to your password as well.

How do I delete Time Machine local snapshots on a Mac?

The supported GUI route is to turn off automatic backups, wait a few minutes, and turn them back on. From Terminal, list them with tmutil listlocalsnapshotdates / and remove them with sudo tmutil deletelocalsnapshots / or a specific date. Deletion is permanent.

Can deleted files be recovered from a Mac SSD?

From an encrypted APFS volume after an erase that discarded the keys, Apple says the data is cryptographically inaccessible. From an unencrypted SSD, such as an older Intel Mac that never used FileVault, fragments may survive in cells software cannot address, which is why overwriting is no longer trusted.

How do I securely wipe a USB stick on a Mac?

If the stick was always APFS (Encrypted), erasing it discards the key and is enough. If it ever held sensitive files in plaintext, Disk Utility offers no secure erase for flash media, and physical destruction is the dependable option. For new sticks, encrypt from first use.

Does erasing my Mac delete my iCloud data?

No. Erase All Content and Settings signs you out of Apple services and erases local data. Files in iCloud Drive and photos in iCloud Photos remain in your account until you delete them there.

Which Macs support Erase All Content and Settings?

Macs with Apple silicon or an Apple T2 Security Chip running macOS Monterey 12 or later. Other Intel Macs use the older route: start from macOS Recovery, erase with Disk Utility and reinstall macOS.

Is Disk Utility's multi pass erase still useful?

Only for spinning hard disks. Apple says secure erase options are not available for SSDs in Disk Utility, and the Security Options button appears only for devices it can securely erase.

Fix it without waiting for upstream

A wiped or rebuilt Mac does not rebuild its software from memory: it pulls the same open source dependencies, toolchains and container images back from package registries, and any vulnerable version pinned in a lockfile comes back with them. The fit here is indirect, since nothing below touches disks or keys, but the moment after a clean install is exactly when dependency hygiene matters most.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos erase a disk or touch FileVault. They show the software side of a cleaned or rebuilt Mac once it is back in use. To try the CLI yourself, download Safeguard and follow the CLI setup guide.

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. On a freshly erased Mac, the same flow catches a vulnerable version that came back with the first npm install.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. After Erase All Content and Settings, this is how you get dependency inventory and vulnerability checks running again on the rebuilt Mac while project code stays on that machine.

Click through it at your own pace, or open it full screen.

The third demo shows the desktop app sending work to a computer running the CLI, with each command approved before it runs. If you look after several rebuilt Macs for a small team, that approval step keeps a person in charge of what runs on each one.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Apple Support: Erase your Mac and reset it to factory settings
• Apple Support: What to do before you sell, give away, trade in, or recycle your Mac
• Apple Support: About the security content of OS X El Capitan v10.11
• Apple Support: About Time Machine local snapshots
• Disk Utility User Guide: Erase and reformat a storage device
• Disk Utility User Guide: File system formats
• Apple Platform Security: Encryption and Data Protection overview
• Apple Platform Security: Volume encryption with FileVault in macOS
• Apple Platform Security: Managing FileVault in macOS
• Apple Platform Security: The Secure Enclave
• Apple Platform Security: Data Protection overview
• Apple Platform Security: Data Protection
• Apple Developer: Apple File System Reference (PDF)
• macOS User Guide: Protect data on your Mac with FileVault
• macOS User Guide: Use iCloud Drive to store documents
• Photos User Guide: Delete photos and recover deleted ones
• Photos User Guide: Optimize storage in Photos on Mac
• NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization
• NIST SP 800-88 Rev. 2 (PDF)
• Manual pages installed with macOS 27: man tmutil, man diskutil, man fdesetup

Last reviewed: 23 October 2026. macOS features and defaults change between releases; check the linked Apple pages and the manual pages on your own Mac for the latest behaviour.