Windows 11 OOBE and hardware bypass status

Why these bypasses exist

Windows 11 introduced hardware requirements that Windows 10 never had: TPM 2.0, Secure Boot, a supported CPU model, 4 GB RAM, and 64 GB storage. Microsoft enforces these checks during both Windows Setup and OOBE.

In most enterprise and lab environments, these checks are obstacles rather than security improvements. Common scenarios where bypasses are necessary:

• Legacy hardware labs. Testing environments with older servers or desktops that lack TPM 2.0 chips. The machines run Windows 11 fine; they just fail the chip check.
• VMs without virtual TPM. Many VM environments — older Hyper-V configurations, bare-metal Proxmox setups without proper TPM passthrough — do not expose a TPM to guests. Enabling virtual TPM for thousands of VMs is impractical in some environments.
• Image testing on reference hardware. When you are building and testing a golden image on a build VM that differs from your deployment targets, Setup hardware checks can block the build step even though the deployment targets meet the requirements.
• Offline OOBE in enterprise deployments. The NRO (Network Required for OOBE) check forces users to connect to the internet and sign in with a Microsoft account. Every enterprise deployment that needs local accounts requires bypassing this.

These bypasses are not exploits. They are registry keys that Microsoft's own Windows Setup reads. They are documented in Microsoft's OEM documentation. The builder surfaces them as toggles so you do not have to look them up every time.

Current bypass status

TPM 2.0 check (BypassTPMCheck)

Windows 11 requires a TPM 2.0 chip to be present and enabled in BIOS/UEFI firmware. During Windows Setup (in the windowsPE phase), Setup reads the HKLM\SYSTEM\Setup\LabConfig registry hive before evaluating hardware. If BypassTPMCheck=1 is present, the TPM requirement is skipped.

The most common scenarios requiring this bypass: virtual machines without a virtual TPM configured, older physical servers that have a TPM 1.2 chip but not TPM 2.0, and bare-metal lab hardware where enabling TPM in BIOS is blocked by IT policy or firmware limitations.

How the builder emits this

When you enable the TPM bypass toggle, the builder adds a <RunSynchronousCommand> in the windowsPE pass that writes the registry key before Setup evaluates hardware requirements:

reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassTPMCheck /t REG_DWORD /d 1 /f

This runs via cmd /c as a synchronous command during WinPE, before disk formatting or image application begins.

Does this affect deployed machines?

No. The LabConfig key only affects Setup. Once Windows is installed and running, this key has no effect on the running OS. Feature updates in Windows Update may re-check TPM status and display a warning banner, but the installed system continues to function.

Secure Boot check (BypassSecureBootCheck)

Windows 11 requires Secure Boot to be enabled in UEFI firmware. Secure Boot prevents unauthorized bootloaders from running before Windows loads, providing a chain of trust from firmware to OS. For machines where Secure Boot cannot be enabled — older BIOS-based hardware, dual-boot configurations, some hypervisors with custom boot chains — this bypass allows Setup to proceed.

Common scenarios: legacy BIOS hardware being upgraded from Windows 10 to Windows 11, VMs using SeaBIOS or OVMF without Secure Boot keys configured, test environments where dual-boot with Linux requires Secure Boot disabled.

How the builder emits this

reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassSecureBootCheck /t REG_DWORD /d 1 /f

Emitted in the same windowsPE synchronous command block as the TPM bypass. Multiple bypasses are combined into a single script block ordered by the builder.

RAM check — 4 GB minimum (BypassRAMCheck)

Windows 11 requires 4 GB of RAM. On machines with 2 GB or 3 GB, Setup blocks installation. The BypassRAMCheck=1 registry key skips this check.

This bypass is primarily for lab and test scenarios. A production deployment on a machine with under 4 GB of RAM will be slow and unstable. The bypass is appropriate when: you are testing the OS installation process itself, not the usable system; you are deploying lightweight Windows to embedded or kiosk hardware where RAM is constrained but the use case does not require normal desktop performance; or you are a hypervisor allocating small amounts of RAM to many VMs for automation testing.

How the builder emits this

reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassRAMCheck /t REG_DWORD /d 1 /f

CPU check (BypassCPUCheck)

Windows 11 maintains an approved CPU list. Intel CPUs from the 8th generation and later, and AMD Ryzen 2000 series and later, are on the list. Older Intel Core i7-7xxx or AMD Ryzen 1xxx series CPUs are not, despite being fully capable of running Windows 11 without issues for most workloads.

The CPU check is the bypass most commonly needed by teams deploying to 2018–2019 era hardware that is otherwise in good shape: Intel Core i5-8xxx, i7-8xxx, or i9-8xxx on enterprise workstations that companies standardized on. Those machines are not yet due for replacement, are not underpowered, and run Windows 11 without problems. The CPU list cutoff is a Microsoft support boundary, not a technical requirement.

How the builder emits this

reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassCPUCheck /t REG_DWORD /d 1 /f

Storage check — 64 GB minimum (BypassStorageCheck)

Windows 11 requires 64 GB of available storage. On machines with smaller drives — 32 GB eMMC storage common in budget laptops, older tablets, or thin clients — Setup blocks installation. This bypass skips that check.

Like the RAM check, this is primarily a lab and kiosk scenario. Windows 11 can technically install on smaller storage, but the user experience on a near-full drive is poor. Use this bypass when you are testing installation procedures or deploying to locked-down kiosk devices where the Windows footprint is managed and controlled through cleanup scripts.

How the builder emits this

reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassStorageCheck /t REG_DWORD /d 1 /f

All five hardware bypasses (TPM, Secure Boot, RAM, CPU, storage) write keys to the same LabConfig hive. The builder combines them into a single <RunSynchronousCommand> block in the correct order so they all run before Setup evaluates hardware.

Internet connectivity / Microsoft Account — BypassNRO

"NRO" stands for Network Required for OOBE. Windows 11 wants you on the internet during setup so it can prompt you for a Microsoft Account. Enterprise deployments using local accounts have to skip that prompt. Microsoft has fought this bypass for four years now; the method that works changes every release.

What works on 24H2 (build 26100), today

The legacy BypassNRO.cmd + registry-write trick is dead. Microsoft removed %WINDIR%\System32\OOBE\BypassNRO.cmd in KB5055523 (early 2025). The registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\BypassNRO can still be written, but nothing reads it anymore.

The current working bypass is a combination of documented oobeSystem fields plus a pre-created local account. These fields have been the reliable path for years; the registry-write trick was always a shortcut, never the supported one:

<!-- oobeSystem pass, Microsoft-Windows-Shell-Setup -->
<OOBE>
  <ProtectYourPC>3</ProtectYourPC>
  <HideEULAPage>true</HideEULAPage>
  <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
  <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
</OOBE>
<UserAccounts>
  <LocalAccounts>
    <LocalAccount wcm:action="add">
      <Name>admin</Name>
      <Group>Administrators</Group>
      <Password>
        <Value>...</Value>
        <PlainText>false</PlainText>
      </Password>
    </LocalAccount>
  </LocalAccounts>
</UserAccounts>

How to enable it in the builder

1. Open Section 4 — User Accounts and define a local administrator (any username works; the default is admin). Without this, OOBE will still stop on the account-creation screen.
2. Open Section 6 — OOBE Bypass and turn on "Skip Microsoft Account prompt". That emits the four OOBE fields above.

That's it. There's no toggle in Section 7 — the dead BypassNRO registry write was removed from the builder on 2026-06-11. The same intent is covered by the two steps above.

What changed (build-by-build)

• 21H2–22H2: Direct registry write to OOBE\BypassNRO=1 in windowsPE. Worked alone.
• 22H2: Microsoft blocked the keyboard-entry "OOBE\BYPASSNRO" command at the OOBE Shift+F10 prompt. Automated unattend method still worked.
• 24H2 / build 26100: KB5055523 deleted BypassNRO.cmd. The reg-write-only method died. The HideOnlineAccountScreens + LocalAccount combination continues to work and is now the recommended path.

Maintenance commitment

Every Windows 11 feature update has the potential to break one or more of these bypasses. This page is reviewed and updated when:

• A new Windows 11 feature update reaches general availability.
• A reader reports a bypass stopped working on a specific build.
• Microsoft's documentation or public statements indicate a change.

The in-tool bypass toggles show the same confirmed-through build number as this page. The label reads "Confirmed working through build NNNNN" or "May not work past build NNNNN" depending on status.

If you find a bypass has changed status on a build not listed here, the project repository accepts issues and pull requests. The field schema and the builder emitter both live in the repo.