Windows 11 25H2 Clean Install: The Fastest, Safest Setup (and the 5 Defaults You Must Change)

Was this helpful?

You don’t reinstall Windows because life is going great. You reinstall because boot times became a ritual, updates are acting haunted, or a “quick tweak” turned your laptop into a space heater with opinions.

This guide is the clean install process I’d hand to an on-call SRE who needs a Windows 11 25H2 machine back in service today—fast, stable, and boring. Boring is good. Boring is uptime.

The mindset: treat your PC like production

A clean install isn’t a spiritual cleanse. It’s a controlled change window. You’re going to:

  • Define what “good” looks like (boot time, battery life, stability, update behavior).
  • Preserve what matters (licenses, keys, data, recovery options).
  • Minimize variables (known-good media, predictable drivers, measured changes).
  • Log what you did (because Future You will be woken up by Past You).

Windows 11 is perfectly capable of being fast and stable. But you must stop letting defaults make decisions on your behalf—especially defaults optimized for consumer engagement, not reliability.

Quick facts and historical context (so the weird makes sense)

These are the little bits of history that explain why Windows installs behave the way they do:

  1. Windows “feature updates” replaced the old service pack era. Instead of SP1/SP2, Windows shifted to semiannual-style upgrades; that’s why “in-place upgrades” exist as a first-class path.
  2. UEFI displaced legacy BIOS over a decade-long transition. The modern GPT partition scheme and the EFI System Partition are why your boot process looks “invisible” compared to older MBR installs.
  3. Secure Boot was pushed by the industry to reduce bootkits. It’s a real security win—until you start dual-booting or using unsigned option ROMs.
  4. TPM became a policy line in the sand with Windows 11. It’s not just “security theater”; it enables measured boot and stronger key protection for features like BitLocker.
  5. NVMe changed storage expectations. Windows install workflows used to assume spinning disks and AHCI; now you can bottleneck on firmware quirks, drivers, or misaligned partitions instead of raw throughput.
  6. Fast Startup is a relic of the “make HDD boots feel better” era. On modern systems it can cause weirdness (dual boot, BitLocker, driver states) while saving seconds you don’t need.
  7. Windows Update became a driver distribution channel. Great for reach, risky for workstation determinism—especially for GPUs, Wi‑Fi, and audio stacks.
  8. Telemetry became a core design assumption. Not unique to Microsoft, but it impacts privacy posture and sometimes performance when you’re resource-constrained or debugging.

Before you wipe: the non-negotiable preflight

If you skip preflight, you’ll spend your install day hunting for a Wi‑Fi driver on your phone like it’s 2009. Do this first.

1) Decide your install goal

  • “Fastest stable workstation”: minimal apps, conservative drivers, avoid vendor bloat, lock down update behavior.
  • “Gaming box”: more aggressive GPU updates, but you still want a clean baseline and a rollback plan.
  • “Corporate / managed”: align to policy, enable BitLocker, verify recovery escrow, keep install deterministic.

2) Back up like you mean it

You want two copies of anything you can’t replace: one local (external SSD), one remote (NAS/cloud). Verify at least one restore action, not just a copy.

3) Collect the stuff you’ll need when the network isn’t working

  • Wi‑Fi and Ethernet drivers (especially for newer chipsets).
  • GPU driver package (optional, but useful if Windows Update behaves).
  • Storage controller / RAID / VMD drivers if your platform uses them.
  • BitLocker recovery key plan (where it will be stored).
  • App installers you know you’ll need (password manager, browser, VPN client).

4) Inventory your hardware and current state

If you’re troubleshooting a slow system, capture baseline info before the wipe so you can confirm improvement and spot regressions.

Build install media that doesn’t betray you

Most “clean installs” fail for boring reasons: bad USB sticks, flaky ports, corrupted media, or the wrong firmware mode. Use a name-brand USB drive. Avoid the one you found in a conference tote bag.

Joke #1: USB sticks have two states: “brand new” and “contains the only copy of something important.” Choose accordingly.

Media creation strategy (practical and safe)

  • Preferred: Use Microsoft’s media creation flow from a trusted Windows machine.
  • When you’re on Linux/macOS: Write the ISO carefully; verify checksums if you have them; test boot on the target device before you commit to wiping.
  • For corporate fleets: standardize on one method; randomness is the enemy of repeatability.

Firmware settings: UEFI, Secure Boot, TPM, and the gotchas

Spend five minutes here and save yourself two hours later.

UEFI vs Legacy (CSM)

Install Windows 11 in UEFI mode on a GPT disk. Legacy/CSM installs still exist, but they’re a liability: harder BitLocker posture, uglier recovery, and more ways to get stuck with the wrong boot chain.

Secure Boot

Enable it unless you have a specific technical reason not to (custom bootloaders, older expansion cards, certain dual-boot setups). If you disable it “temporarily,” document that, because temporary settings have a strong tendency to become permanent.

TPM

Enable TPM 2.0. If your firmware uses Intel PTT or AMD fTPM, that’s fine. Your goal is a working TPM-backed security stack, not purity.

Storage mode: AHCI, RAID, VMD

If your BIOS has an option like Intel VMD/RAID, be deliberate. VMD can hide NVMe devices behind a controller requiring drivers during install. That’s fine if you have those drivers; it’s a mess if you don’t.

The clean install, step-by-step (no drama)

This is the core workflow. It’s intentionally conservative: we optimize for correctness first, speed second, cosmetics never.

Step 1: Boot from USB in UEFI mode

Use the firmware boot menu (often F12/F8/ESC/DEL depending on vendor). Pick the entry that explicitly says UEFI.

Step 2: Network decision during setup

If you want a more deterministic setup, consider installing with no network initially. This reduces driver churn and surprise Microsoft account prompts. You can connect later when you’re ready.

Step 3: Partitioning (where people accidentally erase their future)

If you are dedicating the disk to Windows: delete all partitions on the target disk and let Setup create the standard GPT layout. If you are dual-booting or preserving a data partition: stop and plan the layout first. “I’ll just shrink it later” is how people lose weekends.

Step 4: First boot: do less

Get to the desktop. Don’t install five apps, three driver suites, and a registry “optimizer” before you’ve even validated the base OS. You need a clean baseline you can trust.

Driver strategy: stable beats “latest”

Here’s the blunt truth: “latest driver” is not a reliability strategy. It’s a hobby.

Recommended driver order

  1. Chipset / platform drivers (from the OEM or chipset vendor).
  2. Storage / RST / VMD (only if your platform needs them).
  3. GPU (from NVIDIA/AMD/Intel, unless corporate policy says OEM-only).
  4. Network (Wi‑Fi/Ethernet) if Windows didn’t install a good one.
  5. Audio, Bluetooth, peripherals last.

Windows Update as a driver source

Use Windows Update for most drivers except when you need determinism: audio stacks and GPUs can regress in entertaining ways. If your machine is revenue-adjacent, pin the known-good versions and treat driver updates like change requests.

The 5 Windows 11 defaults you must change

These are the defaults that most reliably cause performance jitter, privacy drift, or stability surprises. Change them early, while the system is clean.

1) Disable Fast Startup (yes, still)

Why: It’s hybrid hibernation. It can preserve bad driver state, complicate BitLocker flows, and create confusion during troubleshooting (“I shut down!” No, you didn’t). On NVMe, the speed gain is usually not worth it.

2) Set Windows Update to stop “optional” drivers from sneaking in

Why: Driver updates via Windows Update can be fine, until they aren’t. The worst failures look like “random” Wi‑Fi drops, audio crackling, or GPU black screens. That’s not random; that’s a driver.

3) Turn off consumer experiences / suggestions / junk apps

Why: They add background activity, change the UI unexpectedly, and create noise in enterprise images. Your workstation is not a billboard.

4) Fix your power plan (especially on laptops)

Why: Balanced is usually okay, but OEM “smart” modes can throttle under load or keep boosting until the fan sounds like it’s negotiating with physics. Pick a plan that matches your workload.

5) Enable BitLocker (after verifying TPM and recovery key handling)

Why: Lost laptops are not theoretical. BitLocker is table stakes. But you only enable it once you’re sure the system boots cleanly and you know where the recovery key will live.

Practical tasks with commands (and how to decide from the output)

These tasks assume you’re in Windows after install. Use Windows Terminal (Admin) when needed. Every task includes: command, example output, what it means, and the decision you make.

Task 1: Confirm Windows version/build (sanity check)

cr0x@server:~$ cmd.exe /c ver
Microsoft Windows [Version 10.0.26100.1882]

What it means: You’re seeing the kernel/build number. Confirm you’re actually on the intended Windows 11 release family for your environment.

Decision: If the build is not what you expected, stop and confirm your ISO/media and update path before installing drivers and apps.

Task 2: Verify UEFI boot mode (avoid legacy installs)

cr0x@server:~$ powershell -NoProfile -Command "(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control' -Name PEFirmwareType).PEFirmwareType"
2

What it means: 2 indicates UEFI. 1 indicates legacy BIOS mode.

Decision: If you see 1, consider reinstalling in UEFI mode (especially before enabling BitLocker or deploying broadly).

Task 3: Check Secure Boot state

cr0x@server:~$ powershell -NoProfile -Command "Confirm-SecureBootUEFI"
True

What it means: Secure Boot is enabled and functioning.

Decision: If False or an error appears, fix firmware settings now—before you start hardening and enabling disk encryption.

Task 4: Confirm TPM presence and readiness

cr0x@server:~$ powershell -NoProfile -Command "Get-Tpm | Select-Object TpmPresent,TpmReady,ManagedAuthLevel | Format-List"

TpmPresent       : True
TpmReady         : True
ManagedAuthLevel : Full

What it means: TPM is present and usable for BitLocker and other protections.

Decision: If TpmPresent is false or not ready, fix firmware/TPM provisioning before enabling BitLocker.

Task 5: Confirm disk partition style is GPT

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Select-Object Number,FriendlyName,PartitionStyle,Size | Format-Table -Auto"

Number FriendlyName        PartitionStyle Size
------ ------------        -------------- ----
0      NVMe Samsung 990    GPT            1024 GB

What it means: GPT is in use, which aligns with UEFI and modern recovery expectations.

Decision: If it’s MBR on a modern system, strongly consider reinstalling (or convert carefully, but reinstall is usually safer for a “clean” baseline).

Task 6: Check whether BitLocker is enabled (or safely enable later)

cr0x@server:~$ powershell -NoProfile -Command "Get-BitLockerVolume -MountPoint C: | Select-Object MountPoint,VolumeStatus,ProtectionStatus,EncryptionPercentage | Format-List"

MountPoint           : C:
VolumeStatus         : FullyDecrypted
ProtectionStatus     : Off
EncryptionPercentage : 0

What it means: Disk is not encrypted yet. That’s fine right after install if you’re still validating.

Decision: Enable BitLocker once drivers are stable and you’ve verified recovery key storage.

Task 7: Disable Fast Startup (reliability over tiny boot wins)

cr0x@server:~$ powercfg /h off
Hibernation has been disabled.

What it means: Disables hibernation and, by extension, Fast Startup.

Decision: If you rely on hibernate, don’t do this. Otherwise, keep it off and enjoy fewer “ghost” boot states.

Task 8: Verify current power scheme and switch deliberately

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

What it means: Balanced is active.

Decision: If you need consistent performance (build servers, audio production, heavy compiles), consider High performance. If you need battery life, keep Balanced but disable vendor “eco” nonsense that tanks responsiveness.

Task 9: Check which drivers are installed (spot the “helpful” ones)

cr0x@server:~$ pnputil /enum-drivers | findstr /i "nvidia intel amd realtek"
Published Name : oem42.inf
Original Name  : nv_dispig.inf
Provider Name  : NVIDIA
Class Name     : Display
Driver Version : 31.0.15.5212

Published Name : oem18.inf
Original Name  : netrtwlane.inf
Provider Name  : Realtek
Class Name     : Net
Driver Version : 2024.1.319.1

What it means: You can see which vendors and versions are present.

Decision: If Windows Update installed a GPU/network driver that correlates with instability, you now have the exact INF identity to roll back or replace.

Task 10: Check device status for unknown devices (missing drivers)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice | Where-Object {$_.Status -ne 'OK'} | Select-Object Class,FriendlyName,InstanceId,Status | Format-Table -Auto"

Class  FriendlyName            InstanceId                                         Status
-----  ------------            ----------                                         ------
Other  PCI Device              PCI\VEN_8086&DEV_A0EF&SUBSYS_...                    Error

What it means: There’s at least one device without a working driver.

Decision: Identify the hardware (VEN/DEV IDs) and install the correct OEM/chipset driver package before blaming Windows for performance or battery issues.

Task 11: Confirm TRIM is enabled (SSD performance hygiene)

cr0x@server:~$ fsutil behavior query DisableDeleteNotify
NTFS DisableDeleteNotify = 0  (Disabled)
ReFS DisableDeleteNotify = 0  (Disabled)

What it means: 0 means TRIM is enabled (despite the confusing wording).

Decision: If it’s 1, investigate why (policy, old imaging practices). Fix it unless you have a specialized storage setup that requires disabling TRIM.

Task 12: Check Windows Update health quickly

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WU.log; Write-Output $env:TEMP\WU.log"
C:\Users\admin\AppData\Local\Temp\WU.log

What it means: You generated a readable Windows Update log file path.

Decision: If updates fail or loop, open the log and look for driver install failures, content download errors, or servicing stack issues before you start “resetting Windows Update” by ritual.

Task 13: Measure boot performance (don’t guess)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime"
LastBootUpTime
--------------
2/5/2026 9:12:44 AM

What it means: You can confirm whether your “reboot” actually rebooted (Fast Startup off helps) and correlate issues with boot cycles.

Decision: If the timestamp doesn’t change after a “shutdown,” you’re not actually shutting down—recheck Fast Startup and hibernate behavior.

Task 14: Identify top startup impact apps (remove offenders)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_StartupCommand | Select-Object Name,Command,Location | Format-Table -Auto"

Name                  Command                                      Location
----                  -------                                      --------
OneDrive              "C:\Program Files\Microsoft OneDrive\..."     HKCU:Run
VendorControlCenter   "C:\Program Files\OEM\ControlCenter.exe"      HKLM:Run

What it means: You’re seeing what launches at login and where it’s defined.

Decision: Keep security tooling and essential drivers. Remove “control centers” that add telemetry, popups, and background CPU unless you truly need the features.

Fast diagnosis playbook: find the bottleneck in minutes

When a fresh Windows 11 install feels slow, the problem is usually one of five things: storage, drivers, thermal/power behavior, background updates, or malware/adware. Here’s how to triage without wandering.

First: confirm you’re not chasing a ghost state

  • Check Fast Startup/hibernate: if shutdown isn’t a real shutdown, your “repro steps” are contaminated.
  • Confirm the system actually rebooted: use LastBootUpTime (Task 13).

Second: check storage and memory pressure

  • Disk at 100%? Could be indexing, Defender scan, or a driver issue. NVMe should not be pegged for no reason once idle.
  • Low RAM? If you’re at 90%+ constantly, you’re paging. Paging makes everything look like “Windows is slow.”

Third: validate driver health

  • Look for devices not OK (Task 10).
  • Spot Windows Update-provided GPU/network drivers (Task 9).
  • Check event logs for driver crashes (see Common mistakes).

Fourth: thermal and power throttling

Laptops especially can “optimize” themselves into molasses. If performance tanks on AC power, that’s usually a vendor power profile or firmware issue, not Windows.

Fifth: background work (updates, indexing, cloud sync)

Right after install, Windows does a lot: updates, Store app provisioning, OneDrive sync, indexing. Let it finish, then measure again. If it never finishes, you have a stuck component worth investigating.

Three corporate mini-stories (painful, true-to-life)

Mini-story 1: The incident caused by a wrong assumption

A finance team got new laptops. The rollout plan was “clean install Windows, join domain, encrypt, ship.” Straightforward—until the first user returned a device that wouldn’t boot after a routine firmware update.

The imaging tech assumed Secure Boot was enabled because “Windows 11 requires it.” They never verified it post-install. On a subset of units, Secure Boot was disabled by an OEM firmware profile. The machines booted fine—until the firmware update flipped some defaults, and BitLocker decided it was looking at a different boot environment.

Now you have a field failure: laptop boots to recovery, user doesn’t have the BitLocker recovery key, and the helpdesk is trying to talk them through recovery screens over the phone. The laptop is effectively a paperweight.

The fix was boring: a checklist item to validate Secure Boot and TPM readiness before enabling BitLocker, and an escrow process to ensure recovery keys existed and were retrievable. The lesson wasn’t “don’t encrypt.” The lesson was “assumptions don’t scale.”

Mini-story 2: The optimization that backfired

An engineering group wanted faster build times on Windows workstations. Someone discovered that disabling real-time protection and turning off a bunch of background services made their local benchmarks look great.

They standardized these “performance tweaks” in a provisioning script. It worked for a week. Then they started getting intermittent failures: builds that couldn’t fetch dependencies, VPN clients that refused to connect, and mysterious certificate errors. Not constant—just enough to ruin everyone’s day.

Root cause: the script aggressively disabled services that were dependencies for networking and security components. A few machines also picked up adware via a “driver updater” tool (don’t do that), and with defenses reduced, it stuck around. Now the “faster” machines had unstable DNS resolution and random proxy settings.

They rolled back the tweaks and replaced them with a measured approach: exclude build directories from scanning (where appropriate), use local package caches, and stop treating the OS like an obstacle course. They got most of the speedup, none of the chaos.

Mini-story 3: The boring but correct practice that saved the day

A small IT team managed a mixed fleet: desktops, mobile workstations, a few special snowflake lab PCs. They had one rule that sounded unglamorous: every clean install must produce a short “machine birth certificate.”

It included: Windows build number, firmware version, storage model, Secure Boot status, TPM status, BitLocker status, and the exact GPU driver version. The tech attached it to the ticket and stored it with the asset record.

Months later, a vendor driver update caused blue screens on a particular NIC model. The team didn’t have to guess which machines were affected or scramble to reproduce the issue. They filtered assets by NIC driver version, froze updates on that class, and rolled back drivers where needed.

No heroics. No weekend outage. Just a paper trail and the quiet satisfaction of not being surprised in production.

Common mistakes: symptom → root cause → fix

This is the section you read when things are going sideways.

1) Symptom: installer can’t see the NVMe drive

Root cause: BIOS storage mode is VMD/RAID and Windows Setup lacks the controller driver.

Fix: Either (a) load the correct storage driver during setup, or (b) switch firmware storage mode to AHCI (only if you’re sure you don’t need RAID/VMD). Reboot into installer and retry.

2) Symptom: random Wi‑Fi drops after install

Root cause: Windows Update-installed Wi‑Fi driver regression or OEM power management quirks.

Fix: Install the OEM-tested Wi‑Fi driver package; consider disabling aggressive power saving for the adapter. Validate with several sleep/wake cycles.

3) Symptom: shutdown is slow, or “shutdown” still feels like sleep

Root cause: Fast Startup (hybrid shutdown) or hibernate interactions.

Fix: Disable hibernation (powercfg /h off) if acceptable; confirm real reboots via LastBootUpTime.

4) Symptom: high disk usage (100%) for hours on a fresh install

Root cause: Windows Update downloads/installs, Defender scans, indexing, Store app provisioning, or a failing SSD/driver.

Fix: Give it time initially. If it persists, check update logs, verify TRIM status, inspect event logs for disk/controller errors, and confirm you’re on a stable storage driver.

5) Symptom: black screen or flicker after installing GPU driver

Root cause: Conflicting GPU drivers (OEM vs vendor), Windows Update racing you, or a bad driver version.

Fix: Disconnect from network during driver install, use a known-good driver, and prevent Windows Update from injecting alternate versions mid-flight.

6) Symptom: BitLocker recovery prompt after firmware update

Root cause: Secure Boot/TPM measurements changed; recovery key not available; firmware toggled settings.

Fix: Ensure recovery keys are escrowed. Verify Secure Boot and TPM readiness before enabling BitLocker; suspend BitLocker before firmware updates in managed environments.

7) Symptom: system feels “fast but unstable” after tweaking services

Root cause: Disabling critical services breaks dependencies; security posture collapses; random failures appear.

Fix: Revert service tweaks. Optimize surgically (startup apps, specific exclusions, driver updates), not with scorched-earth scripts.

Checklists / step-by-step plan

Clean install checklist (the sane path)

  1. Backups verified: restore at least one file from your backup target.
  2. Collect drivers offline: Wi‑Fi/Ethernet, chipset, storage, GPU (as needed).
  3. Firmware set: UEFI on, Secure Boot on, TPM enabled, storage mode confirmed.
  4. Install media tested: boot the USB and reach the first setup screen before wiping.
  5. Install Windows: delete partitions only on the correct disk; let Setup create GPT partitions.
  6. First boot validation: confirm UEFI mode, Secure Boot, TPM ready.
  7. Apply driver strategy: chipset first, then GPU/network, then everything else.
  8. Run Windows Update: OS updates first; be cautious with optional driver updates.
  9. Change the 5 defaults: Fast Startup off, driver update control, consumer junk off, power plan set, BitLocker planned/enabled.
  10. Baseline snapshot: record build number, key driver versions, and security state.

Post-install hardening checklist (practical, not paranoid)

  • Enable BitLocker once stable; confirm recovery key storage.
  • Turn on firewall (leave it on unless you like mystery inbound traffic).
  • Remove startup cruft; keep only what you need.
  • Set a restore/recovery strategy: System Restore on (where appropriate) and a periodic image backup.

Joke #2: If you don’t write down your recovery key plan, Windows will invent one for you. Its plan is “panic later.”

FAQ

1) Is a clean install actually faster than an in-place upgrade?

Often, yes—mostly because it removes accumulated drivers, startup apps, shell extensions, and half-uninstalled security tools. But if your bottleneck is firmware, thermals, or a failing SSD, a clean install won’t save you.

2) Should I install Windows 11 with the network disconnected?

For a deterministic baseline, yes. It reduces surprise driver injection and account friction. Connect once you’ve validated UEFI/Secure Boot/TPM and you’re ready to control driver order.

3) Do I need OEM recovery partitions?

Not for a clean install strategy. OEM recovery partitions can be useful for warranty workflows, but they’re not a replacement for real backups and known-good install media.

4) When should I enable BitLocker?

After the machine boots cleanly, you’ve validated TPM readiness, and you know exactly where the recovery key will be stored and how you’ll retrieve it.

5) Should I let Windows Update install “optional” driver updates?

Not automatically. For GPUs, Wi‑Fi, and audio, prefer known-good versions unless you’re solving a specific issue. Optional drivers are a change event; treat them like one.

6) What’s the safest partitioning approach on a single-drive PC?

Let Windows Setup create partitions automatically on an empty disk. Manual partitioning is fine if you know why you’re doing it (dual boot, dedicated data volume), but mistakes are expensive.

7) Can I convert MBR to GPT instead of reinstalling?

Sometimes, yes, but the cleanest “clean install” outcome is still: UEFI + GPT from the start. If you’re already wiping, don’t carry technical debt forward.

8) How do I know if performance issues are drivers vs hardware?

Drivers usually show as instability: device errors, event log warnings, flicker, audio pops, network drops. Hardware issues show as persistent errors under load: disk errors, thermal throttling, unexpected shutdowns. Measure, don’t guess.

9) What’s one thing you’d never install on a fresh system?

“Driver updater” utilities and registry cleaners. They optimize by replacing known components with unknown ones, which is not a trade you want on a machine you rely on.

Conclusion: what to do next

A clean install is successful when the system is predictable: stable drivers, measured updates, security posture you can explain, and a performance baseline you can defend.

Next steps:

  1. Run the practical tasks above and record the outputs that matter (UEFI, Secure Boot, TPM, GPT, driver inventory).
  2. Change the five defaults early and deliberately.
  3. Let Windows finish its background work, then measure again.
  4. Make a recovery plan now: BitLocker key handling + backups you’ve tested.

Paraphrased idea (attributed): “Hope is not a strategy.” — often cited in engineering/operations culture (commonly attributed to General Gordon R. Sullivan).

← Previous
Windows Search Indexing Eating Your SSD: Tune It Properly
Next →
Proxmox Security: The 5 Access Mistakes That Turn Your Lab Into a Breach

Leave a comment