What a Factory Reset Removes and What It Leaves Behind

A factory reset removes your files, apps, settings and local accounts, and on modern encrypted devices it does that mainly by destroying the keys that unlock the data. It leaves behind firmware, boot and recovery partitions, cloud accounts and their backups, anti theft locks, management enrolment and, on routers, the installed firmware version. Treat a reset as a data wipe, not a full rebuild.

That distinction decides whether a reset is the right tool. Before you sell a phone, a reset on an encrypted device is usually enough. After a suspected compromise, it may not be, because the places attackers use for persistence are exactly the places a reset does not touch. This post walks through the mechanism on Windows, macOS, iPhone and iPad, Android, Chromebook and home routers, then maps it to NIST SP 800-88 so you can explain the decision to an auditor.

Key takeaways

• On iPhone, iPad, Apple silicon Macs, modern Android phones and BitLocker or FileVault protected PCs, a reset is effectively a cryptographic erase: the data blocks may remain, but the keys that decrypt them are destroyed.
• On an unencrypted device, a reset is closer to deleting file pointers. Windows offers a "clean data" option that overwrites more, but Microsoft itself says it does not meet government and industry erasure standards.
• Firmware in SPI flash, the EFI System Partition, recovery environments, SD cards and in some cases eSIM profiles can survive a reset. So do your cloud backups, synced passwords and the device's link to an Apple Account, Google Account or management service.
• Activation Lock and Factory Reset Protection are designed to survive a reset. That is a feature for theft protection and a trap for resale.
• In NIST SP 800-88 Rev. 2 terms, a manufacturer reset counts as Clear. A properly implemented cryptographic erase counts as Purge.
• Malware that lives in firmware or the boot partition can survive a reset. Documented cases include the LoJax UEFI rootkit (2018) and the BlackLotus bootkit (2023).
• After a reset, the hard work is re-provisioning: credentials, tokens and project dependencies. Rebuild from lockfiles, not from memory.

A factory reset, platform by platform

The table below summarises what the vendor documentation says each reset does. The sections that follow explain each row.

What happens at the storage level when you reset

Windows: reinstall, then optionally clean

Microsoft's "Reset your PC" page describes two choices. "Keep my files" reinstalls Windows and keeps personal files but removes apps and settings. "Remove everything" reinstalls Windows and removes personal files, apps and settings, and Microsoft describes it as suited to giving away or selling a PC. You can then pick "Cloud download", which fetches a fresh copy of Windows with current updates, or "Local reinstall", which uses files already on the PC and may not include the latest updates.

Under "Remove everything" there is a "Clean data" option. Microsoft says it removes files and cleans the drive, takes longer, and makes removed files harder to recover. The same page carries an important caveat: the erasure "does not meet government and industry data erasure standards." That sentence matters if you are writing a disposal procedure. A plain "Remove everything" without clean data on an unencrypted disk leaves data that recovery tools can often find.

If the device uses BitLocker, Microsoft asks you to have the BitLocker recovery key ready, and a reset started from the Windows Recovery Environment requires it. The page also warns that the screen can stay black for a long time, sometimes over 15 minutes, and that restarting manually can make the reset fail.

One more date matters for anyone resetting older machines: Microsoft's page notes that support for Windows 10 ended on 14 October 2025. A reset reinstalls the same unsupported operating system. It does not bring the device back into support.

Mac: discard the keys, keep macOS

Apple's support page for erasing a Mac says Erase All Content and Settings removes "all of your data, settings, and apps" while keeping the currently installed macOS, then restarts into the setup assistant. It requires macOS Monterey 12 or later and either Apple silicon or the Apple T2 Security Chip.

Apple's deployment guide explains the mechanism: erasing "obliterates all the keys in effaceable storage" and makes user data cryptographically inaccessible. On Apple silicon it also resets security settings to Full Security, and it removes any additional volumes. Older Intel Macs without a T2 chip do not get this option; for them you erase the disk in Disk Utility and reinstall macOS, and how much that protects depends on whether FileVault was on.

iPhone and iPad: the same key hierarchy

The Apple Platform Security guide describes the design. Each file gets its own key, file keys are wrapped by class keys, and the file system key is also wrapped by an "effaceable key" held in Effaceable Storage. Apple defines Effaceable Storage as "a dedicated area of NAND storage, used to store cryptographic keys, that can be addressed directly and wiped securely." The guide is explicit that this key does not add confidentiality. It exists so the device can be erased fast: destroying it "renders all files cryptographically inaccessible." The key wrapping key also changes every time a user erases the device.

This is why erasing an iPhone takes seconds rather than the hours a full overwrite of flash storage would need. The encrypted blocks still exist physically. Without the key, they are noise.

Android: file based encryption and discarded keys

Google's help page says a factory reset "erases all your data from your phone", including apps and their data, and that anything stored in your Google Account can be restored afterwards. It asks you to keep the battery above 70 percent, stay online, and wait 24 hours after a recent Google Account password change. The reset can take up to an hour.

The storage mechanism is file based encryption. The Android Open Source Project documentation says Android 7.0 and higher supports file based encryption, and that all devices launching with Android 10 and higher are required to use it. Keys are managed by vold, stored encrypted on disk and protected with a Keystore key "not exposed outside the TEE." Where KeyMint supports rollback resistance, file based encryption keys can be securely deleted; without it, Android falls back to a weaker deletion mechanism. The AOSP page does not describe the factory reset path in detail, so the accurate summary is this: on a device that launched with Android 10 or later, user data is encrypted, and a reset discards the keys that protect it. On older devices, or devices whose maker shipped weaker implementations, the guarantee is weaker.

Chromebook: Powerwash

Google's Powerwash page says a reset erases all user data on the hard drive, including the Downloads folder, plus settings and apps. It says most non-user device information is erased too, but "a few diagnostic and operational pieces of data" are kept. Files in Google Drive or on external storage are not touched. The shortcut is to sign out, press Ctrl + Alt + Shift + R, choose Restart and then Powerwash.

Routers: a configuration reset, not a firmware reset

A home router reset, through the pinhole button or the admin page, restores the factory default configuration: admin password, Wi-Fi names and keys, port forwards, DNS settings. On most consumer routers it does not reinstall or verify the firmware. The firmware version running before the reset is the version running after it. If that firmware is outdated, you now have an outdated router with default settings. If it was tampered with, the tampering is still there. Behaviour varies by vendor, so check your vendor's own documentation, but plan on the reset touching configuration only.

CISA's home network guidance covers the two steps that do matter: change the router's administrator password, since default credentials "may be readily available on the internet", and check the manufacturer's website to confirm you run the latest firmware.

Why a reset on an encrypted device is a cryptographic erase, and when it is not

NIST SP 800-88 Rev. 2, published in September 2025, defines cryptographic erase as "a purge sanitization technique in which key sanitization is applied to one or more keys providing confidentiality protections for the encrypted target data, making recovery of the decrypted target data infeasible." That is exactly what Apple's Effaceable Storage design and Android's key deletion do.

NIST also lists the conditions that make cryptographic erase trustworthy, and each one maps to a way a reset can fall short:

1. The data was encrypted from the start. If a Windows PC never had BitLocker on, or an Intel Mac never had FileVault on, there are no keys to destroy. The reset becomes a reinstall over readable data.
2. The keys are strong and well generated. NIST, citing ISO/IEC 27040, asks for at least 128 bit security strength and random number sources with enough entropy. Federal agencies must use FIPS 140 validated modules to rely on this.
3. No copy of the key lives elsewhere. NIST warns that if the key "exists outside of the ISM, there is a possibility that the key can be used in the future to recover encrypted data." A BitLocker recovery key stored in a Microsoft account, a directory service or a password manager is such a copy. So is a FileVault institutional recovery key. The reset is only a cryptographic erase if those copies are also deleted, or if you are confident the device's data key was rotated.
4. No unwrapped key is still in memory. NIST notes that unwrapped keys in volatile memory or in an encryption engine may require "a hard reset or powering off" to clear.

The NCSC's guidance on secure sanitisation agrees in practical terms. On devices with encryption such as BitLocker or FileVault, a factory reset "deletes the encryption keys, making the data unreadable", which gives a satisfactory level of assurance for most devices, while the NCSC is careful to say this "cannot guarantee" all user data is unreadable.

What survives a factory reset

A reset targets the user data partition. A modern device has many other places that store state. NIST SP 800-88 makes the general point: a desktop computer can contain "a hard drive, motherboard, RAM, and ROM", and each may need its own sanitisation method.

Firmware and UEFI variables

The UEFI or BIOS firmware sits in SPI flash on the motherboard, not on the disk. No operating system reset touches it. Secure Boot databases and other UEFI variables also live in that non volatile store. NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), exists because this layer needs its own protect, detect and recover controls: mechanisms for "protecting the platform against unauthorized changes", "detecting unauthorized changes that occur" and "recovering from attacks rapidly and securely." A reset does none of those things for firmware.

The EFI System Partition and recovery partitions

On Windows PCs the EFI System Partition holds the boot manager and loader files. The Windows Recovery Environment usually lives on its own recovery partition. Microsoft's Autopilot Reset documentation notes that resets depend on WinRE being configured and enabled, and points to reagentc.exe for checking it. A reset is performed by these components, so it reuses them rather than rebuilding them from scratch. That is fine on a healthy machine. It is the wrong assumption on a machine that might be compromised at the boot layer.

eSIMs and SD cards

Apple's guide to preparing an iPhone for a new owner says to choose to erase the eSIM profile when the erase asks. If you choose to keep it, the profile stays. On Android, Google's device management API exposes this as explicit flags: WIPE_EXTERNAL_STORAGE will "additionally wipe the device's external storage (such as SD cards)", and WIPE_ESIMS removes eSIMs on company owned devices. The existence of those flags tells you the default wipe does not always include them. Take the SD card out before you sell an Android phone, and erase it separately.

Cloud accounts, backups and synced data

Apple's page is direct: erasing the device does not delete your iCloud content. Google says data stored in your Google Account can be restored after a reset. Chromebook files in Google Drive are untouched. The same applies to browser sync, password manager vaults and any SaaS session token that was synced or backed up.

This cuts both ways. It is why you can restore your life onto a new phone. It is also why a reset does nothing about a compromised account. If an attacker has your session tokens or your account password, wiping the laptop leaves them in place.

Management enrolment and device identity

Microsoft documents Windows Autopilot Reset as keeping the device's Microsoft Entra ID connection, Intune enrolment, Wi-Fi details, provisioning packages and SCEP certificates. Apple's deployment guide describes management services triggering Erase All Content and Settings remotely with the EraseDevice command. Google's Chrome Enterprise help says users can re-enrol devices that were wiped or factory reset, and the Powerwash page says users cannot reset a work or school Chromebook themselves.

The pattern is consistent: organisation owned devices are designed to come back under management after a reset. A personal reset will not free a corporate device, and should not.

Your BitLocker or FileVault recovery key copies

Covered above, but worth repeating as its own item. The recovery key you saved is a key outside the device. Delete stale escrowed keys for devices you dispose of, or record that the device's key was rotated by the reset.

Activation Lock and Factory Reset Protection

Both are anti theft features designed to survive an erase.

Apple describes Activation Lock as a feature of Find My that is "designed to prevent anyone else from using your iPhone or iPad if it's ever lost or stolen." It turns on with Find My and links your Apple Account to the device on Apple's activation servers. Turning it off requires your Apple Account password. Apple's guide for preparing a device for a new owner says erasing turns off Find My and Activation Lock, but if Find My is still on you may need your Apple Account credentials. A buyer should not take the device until setup shows the "Hello" screen; if setup asks for the previous owner's Apple Account, the device is still locked to them.

On Android, Google's reset page describes the same idea without naming it: after a reset you must enter security information that shows you or someone you trust performed the reset, and you need to know your Google Account username and password before you start. That is Factory Reset Protection. Its existence is confirmed in Google's management API, where the PRESERVE_RESET_PROTECTION_DATA wipe flag will "preserve the factory reset protection data on the device", and factoryResetDisabled controls whether users can reset from Settings at all.

The practical consequence: always remove the device from your account before handing it over. A buyer holding a locked phone has a paperweight, and you have an awkward support conversation.

Chromebook Powerwash and enterprise enrolment

On a personal Chromebook, Powerwash is a complete user reset. The first Google Account to sign in afterwards becomes the owner account.

On a managed Chromebook the rules change. Google's help says users can't reset a work or school Chromebook, and directs them to their administrator to wipe and re-enrol the device. Google's enrolment documentation says enrolled devices follow organisation policies until they are wiped or deprovisioned, and that users can re-enrol devices that were wiped or factory reset. If you buy a used Chromebook that still expects an organisation sign in, the previous owner has not deprovisioned it, and only they can fix that.

Can malware survive a factory reset?

Ordinary malware cannot. It lives in user data or in the operating system partition, and a reset either destroys the keys or reinstalls the OS. That covers the overwhelming majority of real infections, which is why a reset is a reasonable step for a commodity infection on a personal device.

Malware designed for persistence below the operating system is different. Two documented cases show the two layers.

Firmware: LoJax, 2018. Security researchers published research on 27 September 2018 describing LoJax, which they called the first UEFI rootkit found in the wild, attributed to the Sednit group. It was written into the SPI flash that holds the UEFI firmware. The researchers said the persistence method "will not only survive an OS reinstall, but also a hard disk replacement." Removal meant reflashing the chip with a clean firmware image specific to the motherboard, or replacing the motherboard.

Boot partition: BlackLotus, 2023. Microsoft's incident response team published guidance on 11 April 2023 for BlackLotus, a UEFI bootkit that exploits CVE-2022-21894 to bypass Secure Boot. It writes malicious boot files into the EFI System Partition and locks them. Microsoft's remediation advice was that an infected device be "removed from the network and reformatted (both the OS partition and EFI partition)", or restored from a known clean backup that includes the EFI partition. Microsoft also noted that deploying it requires privileged or physical access first.

The lesson is not that every reset is suspect. It is that a reset only reaches the layers it was designed to reach. If your threat model includes an attacker who had administrator access and a reason to persist, a reset is not enough on its own. You need to reinstall from known good media with the EFI partition rebuilt, update the firmware from the vendor, and in the most serious cases replace the hardware.

How to verify a reset actually happened

A progress bar is not evidence. Check state after the reset.

For organisations, NIST SP 800-88 Rev. 2 says verification for non destructive methods can be done "by checking the completion status of the tools and identifying errors, anomalies, and the health of the ISM", and that elaborate sampling of contents after Clear or Purge is not necessary unless policy requires it. Record the method, the date, the person and the result. That record is what an auditor asks for.

Which reset to use: after a suspected compromise vs before resale

How a reset maps to NIST SP 800-88 Clear, Purge and Destroy

NIST SP 800-88 Rev. 2 replaced Rev. 1 (December 2014) in September 2025. Its three methods map to reset options like this.

Two details from the standard are worth knowing. First, NIST says manufacturer resets still meet the definition of Clear "as long as the device interface available to the user does not facilitate retrieval of the original data." Second, it warns that multi pass overwrite habits from the hard disk era give "very little confidentiality protection" on SSDs with overprovisioning, because wear levelling keeps old data in cells the host cannot address. For flash storage, cryptographic erase or a device sanitize command is the right Purge technique.

For the controls side of this, see our post on NIST 800-53 MP-6 media sanitization.

Step by step: resetting and rebuilding a developer laptop

A developer laptop is a special case because it carries credentials and toolchains that reach production. Here is a runbook for a laptop being reissued or rebuilt after a suspected compromise.

1. Inventory before you wipe

Record what needs to come back and what needs to be revoked. List the repositories you work in, the package manager configs that point at private registries, and the tokens on disk. Our post on which files on a developer laptop hold credentials covers the usual locations.

# Note which repositories you have locally and whether each has a lockfile
find ~/code -maxdepth 3 -name .git -type d | sed 's#/.git##' > repos.txt
for r in $(cat repos.txt); do
  ls "$r"/package-lock.json "$r"/yarn.lock "$r"/pnpm-lock.yaml \
     "$r"/poetry.lock "$r"/requirements*.txt "$r"/go.sum 2>/dev/null
done

Push any unpushed branches. Do not back up ~/.npmrc, ~/.pypirc, ~/.docker/config.json, cloud CLI credential folders or SSH private keys to restore later. You will issue fresh ones.

2. Check encryption state

If the disk is encrypted, the reset becomes a cryptographic erase. If it is not, plan for a Purge step.

# Windows, elevated prompt
manage-bde -status C:
reagentc /info

# macOS
fdesetup status
profiles status -type enrollment

3. Reset with the built in tool

On Windows, use Settings, System, Recovery, Reset this PC, Remove everything, Cloud download, and turn on Clean data. On a Mac with Apple silicon or T2, use System Settings, General, Transfer or Reset, Erase All Content and Settings. If you are on a managed device, ask IT to send the wipe so enrolment is preserved.

4. For a suspected boot level compromise, go further

A reset reuses the existing boot and recovery partitions. After a suspected targeted compromise, reinstall from freshly downloaded installation media instead, and let the installer delete and recreate all partitions on the system disk, including the EFI System Partition. Then update the firmware from the device maker's official support site.

On Linux machines or for drives you are retiring, an NVMe sanitize command is the Purge option.

Warning: the commands below permanently destroy all data on the target drive. They cannot be undone. Run them only from a live USB environment, only on a drive you have positively identified, and only after confirming your backups.

First, confirm the device path. Check the model and serial number against the physical drive you mean to erase.

# Identify drives: confirm model, serial and size before anything else
lsblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINTS
sudo nvme list
# Check which sanitize operations the controller supports (read only)
sudo nvme id-ctrl /dev/nvme0 -H | grep -i -A4 "sanicap"

Only after you have confirmed that /dev/nvme0 is the right controller:

# DESTRUCTIVE: cryptographic erase sanitize on the confirmed controller
sudo nvme sanitize /dev/nvme0 --sanact=4
# Watch progress until it reports completion
sudo nvme sanitize-log /dev/nvme0

--sanact=4 requests a crypto erase sanitize; --sanact=2 requests block erase. Support varies by drive, which is why you read the sanicap field first. If the drive reports no sanitize support, use the drive maker's own tool or physically destroy the drive.

5. Rebuild from lockfiles, not from memory

Once the machine is clean, reinstall toolchains from official sources and restore projects from their lockfiles, so you get the versions you shipped rather than whatever is latest today.

# Node: install exactly what the lockfile pins
npm ci
# Python: install pinned, hashed requirements
pip install --require-hashes -r requirements.txt
# Go: verify module checksums against go.sum
go mod verify
# Java with Maven: resolve offline only if your local repository is trusted
mvn -B dependency:go-offline

Then check each project for known vulnerabilities before you start work again. With the Safeguard CLI that is safeguard scan --dir ., which writes results as JSON under ./output. Our developer laptop hygiene checklist for package managers covers the registry and config side.

6. Issue fresh credentials

Generate new SSH keys, new package registry tokens, new cloud CLI sessions. Revoke the old ones centrally, even if you believe they never left the machine. The reset destroyed the local copies. It did nothing to the copies an attacker may already hold. For the organisational version of this step, see the developer laptop offboarding checklist.

Common mistakes

• Resetting before signing out. Activation Lock or Factory Reset Protection then blocks the next owner, and you may not be able to fix it remotely without your credentials.
• Assuming "Remove everything" sanitises an unencrypted disk. Without encryption or the clean data option, the reset leaves recoverable data. Microsoft says even clean data is not a standards grade erase.
• Running multi pass overwrite tools on an SSD. NIST warns this gives very little protection on flash with overprovisioning. Use cryptographic erase or a sanitize command.
• Forgetting the SD card and the eSIM. Both can sit outside what the default wipe covers.
• Keeping stale recovery keys. An escrowed BitLocker key for a sold PC is a copy of a key outside the device, which NIST says undermines cryptographic erase.
• Treating a reset as account recovery. A wiped laptop does not log an attacker out of your email, your source host or your cloud console. Rotate credentials from a clean device.
• Resetting a router and stopping there. The firmware is unchanged. Update it, change the admin password and replace devices the vendor no longer supports. See our home router security checklist.
• Restoring the whole old disk image onto the clean machine. That restores the problem. Restore documents and project source, then rebuild tools and dependencies.
• Destroying evidence you needed. If there may be a legal or insurance process, image the disk before you wipe it.

FAQ

Does a factory reset delete everything permanently?

On a modern encrypted phone, tablet or Apple silicon Mac, it makes your data cryptographically inaccessible by destroying the keys, which NIST classes as Purge when done correctly. On an unencrypted computer it does not: data can remain recoverable unless you also use a sanitize command or destroy the drive.

Can a factory reset remove a virus?

It removes almost all ordinary malware, because that malware lives in the user or operating system partition. It does not remove firmware rootkits like LoJax or bootkits that persist in the EFI System Partition like BlackLotus. Those need firmware reflashing or a full reinstall that rebuilds the boot partition.

Does a factory reset remove my Google Account or Apple Account?

It removes the account from the device's storage, but the device stays linked through Factory Reset Protection or Activation Lock until you sign out or remove it from your account. Your cloud data stays in your account and is not deleted by the reset.

Is a factory reset enough before selling my phone?

For a phone with encryption, which includes every iPhone and Android phones launched with Android 10 or later, yes, provided you sign out first, remove it from Find My or your Google Account, erase the eSIM and take out any SD card.

What does a factory reset not erase on Windows?

It does not touch the UEFI firmware or its variables, it reuses the existing recovery environment, it leaves cloud copies of your data and BitLocker recovery keys where they are, and on managed devices it can keep enrolment. Without the clean data option, deleted files on an unencrypted drive can be recoverable.

Does a factory reset update or downgrade firmware?

No. On computers, phones and routers, a reset does not install, roll back or verify firmware. You update firmware separately from the vendor.

What is the difference between a factory reset and a cryptographic erase?

A factory reset is a user facing operation that returns the device to its default state. A cryptographic erase is a sanitisation technique that destroys encryption keys. On encrypted devices the first is implemented using the second. On unencrypted devices it is not.

Does a router factory reset remove hackers?

It removes malicious configuration changes, such as altered DNS settings or added port forwards. It does not remove a compromise in the firmware itself. Reset, then install the latest firmware from the vendor and set a new admin password.

Does NIST SP 800-88 accept a factory reset?

Yes, as the Clear method, as long as the normal interface cannot retrieve the original data. For Purge, NIST points to cryptographic erase and dedicated sanitize commands, with conditions on key strength and on no key copies existing outside the device.

Where Safeguard fits

Safeguard does not reset devices, manage endpoints, scan firmware or detect malware, and nothing in this post depends on it. The connection is narrower and practical. A developer laptop is part of your software supply chain, and the expensive part of a reset is the rebuild: getting every project back with the dependency versions you actually ship, rather than whatever resolves today. Safeguard's CLI scans a repository, container image or SBOM file for vulnerable dependencies, and the local runner does that on your own machine, pushing only encrypted results, so a freshly rebuilt laptop can confirm its projects are clean before work resumes. Our post on how the local runner and offline mode work covers the details. If you build products, the same logic applies one level down: firmware, bootloaders and wireless stacks ship as components, and they belong in the SBOM you keep for each release.

Fix it without waiting for upstream

A reset wipes a machine, but the rebuild pulls every dependency again, and any vulnerable version pinned in a lockfile comes straight back. The same applies to the open source components inside firmware, drivers and appliance images you build, which is why dependency hygiene still matters here even though the reset itself is outside Safeguard's scope.

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

These demos show the rebuild side of a reset, not the reset itself. If you want to try them on a freshly set up machine, you can download Safeguard and follow the CLI docs.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. On a rebuilt laptop, that is the first check you run across restored projects before you start committing again, and the scan happens locally.

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

This demo is a real CLI session: you ask it to fix the lodash CVE in a repository, it reads the finding and advisory, asks before each command, moves lodash to 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies when a lockfile you restored after a reset pins a version that has since picked up a known vulnerability.

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

This demo is a real Android session that sends work to a computer running the CLI and approves each command on the phone with Allow once, Allow for turn or Deny. While a laptop is mid rebuild, it lets you keep a human approval on every command the assistant runs.

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

For the resale side of this topic, see factory resetting smart devices before selling or giving them away, buying a second hand smart device safely and what iPhone Stolen Device Protection changes.

Quick check

Sources

• Microsoft Support: Reset your PC
• Microsoft Learn: Windows Autopilot Reset
• Microsoft Security Blog: Guidance for investigating attacks using CVE-2022-21894, the BlackLotus campaign (11 April 2023)
• Apple Support: Erase your Mac and reset it to factory settings
• Apple Support: Preparing your old iPhone or iPad for a new owner
• Apple Support: Activation Lock for iPhone and iPad
• Apple Platform Deployment: Erase Apple devices
• Apple Platform Security: Data Protection overview
• Apple Platform Security: Data Protection
• Apple Platform Security: Effaceable Storage
• Google Android Help: Reset your Android device to factory settings
• Android Open Source Project: File-based encryption
• Android Management API: Policies reference
• Android Management API: WipeDataFlag
• Google Chromebook Help: Reset your Chromebook to factory settings (Powerwash)
• Google Chrome Enterprise Help: Enroll ChromeOS devices
• NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization (September 2025)
• NIST SP 800-88 Rev. 2, full text (PDF)
• NIST SP 800-193: Platform Firmware Resiliency Guidelines (May 2018)
• NCSC: Secure sanitisation of storage media
• MITRE ATT&CK: LoJax (S0397)
• CISA: Home Network Security

Last reviewed: 23 October 2026. Reset behaviour changes between operating system versions; check the linked vendor pages for your exact version.