How to Set Up Windows 11 Without a Microsoft Account (2026 Edition)

If you've tried to do a clean install of Windows 11 recently, you've probably hit the same wall I have: the setup wizard demands a Microsoft account before it'll let you proceed. No skip button. No "I'll do this later" link. Just a login screen standing between you and your freshly formatted machine.

This has been a pain point for years, and it's gotten more restrictive over time. Whether you're imaging machines for a dev lab, setting up a build server, or just want a local account on your personal rig, you shouldn't need to authenticate with a cloud service to use an operating system you already paid for.

Let's fix it.

Why Microsoft Forces an Account During OOBE

The setup screen you're stuck on is called OOBE — the Out-of-Box Experience. Starting with Windows 11, Microsoft removed the local account option from OOBE for both Home and Pro editions.

The technical reason? OOBE checks for an active network connection and, if one exists, routes you through the Microsoft account flow. The entire flow is driven by a set of OOBE scripts and provisioning steps that assume cloud identity. If the network is available, there's no UI path to create a local account.

This matters for developers because:

• CI/CD build agents shouldn't be tied to a personal Microsoft account
• VM templates become harder to generalize when they're married to a specific identity
• Lab machines shared across a team don't need OneDrive sync and personalization
• Privacy-conscious setups shouldn't require phoning home during install

Method 1: The BYPASSNRO Registry Trick

This is the most well-known workaround and has worked reliably for me across multiple Windows 11 versions. When you hit the network connection screen during setup:

:: This modifies the registry to tell OOBE that network isn't required
OOBE\BYPASSNRO

The machine will reboot and restart OOBE. This time, you'll see an "I don't have internet" option on the network screen. Click it, then click "Continue with limited setup", and you'll get the local account creation flow.

What's actually happening under the hood

The OOBE\BYPASSNRO command is a shortcut that runs a script located at C:\Windows\System32\OOBE\BypassNRO.cmd. All it does is set a registry key:

:: The actual registry modification that BYPASSNRO performs
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 1 /f

This tells the OOBE process to allow skipping the network requirement. It's not a hack — it's a built-in Microsoft mechanism. The fact that it exists but isn't exposed in the UI tells you a lot about the internal tension around this requirement.

Method 2: Disconnect the Network

The simplest approach, and the one I use most often when setting up VMs:

For Hyper-V specifically, here's how to script it:

# Remove network adapter before first boot so OOBE can't force online setup
$vmName = "Win11-BuildAgent"
Get-VMNetworkAdapter -VMName $vmName | Remove-VMNetworkAdapter

# Start the VM — OOBE will offer local account setup
Start-VM -Name $vmName

# After setup completes, re-add the network adapter
Stop-VM -Name $vmName
Add-VMNetworkAdapter -VMName $vmName -SwitchName "Default Switch"
Start-VM -Name $vmName

This is my preferred method for automated VM provisioning because it's deterministic — no registry edits, no reboots mid-setup.

Method 3: Use an Answer File (Unattended Install)

If you're deploying multiple machines, the proper way to handle this is with an autounattend.xml file. Drop it on the root of your USB installer and Windows will read it automatically.

Here's a minimal answer file that creates a local account:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="oobeSystem">
    <component name="Microsoft-Windows-Shell-Setup"
               processorArchitecture="amd64"
               publicKeyToken="31bf3856ad364e35"
               language="neutral"
               versionScope="nonSxS">
      <OOBE>
        <!-- Skip the Microsoft account requirement entirely -->
        <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
        <HideLocalAccountScreen>false</HideLocalAccountScreen>
        <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
        <ProtectYourPC>3</ProtectYourPC>
      </OOBE>
      <UserAccounts>
        <LocalAccounts>
          <LocalAccount wcm:action="add">
            <Name>devuser</Name>
            <Group>Administrators</Group>
            <Password>
              <Value>changeme</Value>
              <PlainText>true</PlainText>
            </Password>
          </LocalAccount>
        </LocalAccounts>
      </UserAccounts>
    </component>
  </settings>
</unattend>

A few notes on this approach:

• Change the password immediately after first login — this file sits in plaintext on your install media
• The ProtectYourPC value of 3 disables the "recommended settings" prompt
• This works for both Home and Pro editions
• You can generate more complex answer files using the Windows System Image Manager (SIM) from the Windows ADK

Method 4: Rufus USB Creator

If you use Rufus to create your bootable USB (and honestly, you should — it's the best tool for the job), it has a built-in option to bypass the Microsoft account requirement.

When you start creating the USB, Rufus will show a dialog with Windows customization options. Check "Remove requirement for an online Microsoft account" and it'll patch the installer image for you.

This is the approach I recommend for anyone who isn't comfortable with command prompts during setup or answer files.

Prevention: Bake It Into Your Provisioning

If you manage multiple Windows machines, don't solve this problem manually every time. Here's what I'd recommend:

• For VMs: Script the network adapter removal as shown above, or use Packer with an answer file to build golden images
• For physical machines: Keep a Rufus-prepared USB drive in your toolkit, or maintain a custom answer file on a USB stick
• For MDT/SCCM deployments: Add the BypassNRO registry key to your task sequence before the OOBE phase
• For dev teams: Document your chosen method in your team wiki — this catches everyone off guard at least once

The Bigger Picture

There's been growing internal and external pushback on these mandatory account requirements. Reports suggest that even people within Microsoft think the current approach is too aggressive, particularly for power users and IT professionals.

The frustrating part is that local accounts still work perfectly fine after setup. You can create them, switch to them, use them daily. The restriction is purely in the OOBE flow. It's a friction point designed to funnel users into the Microsoft ecosystem, and it catches developers and sysadmins in the crossfire.

Until this changes officially, at least we have reliable workarounds. The BYPASSNRO trick and answer file method have survived multiple Windows 11 updates, and the Rufus approach is about as foolproof as it gets.

Pick the method that fits your workflow, automate it if you can, and move on to the actual work. Life's too short to fight with setup wizards.