Microsoft shipped Windows 11 Insider Preview Build 26220.6772 to the Dev Channel, and its release notes confirm a significant shift: the removal of \"known mechanisms\" for creating a local account during the out-of-box experience (OOBE). The long-standing Shift+F10 command-line tricks—including the BYPASSNRO script and the start ms-cxh:localonly URI—no longer work in current preview images. For everyday users, this means the easiest path through setup now requires an internet connection and a Microsoft account sign-in.

What actually changed

The concrete technical changes in Build 26220.6772 target the interactive first-boot setup for consumer editions of Windows 11. According to Microsoft's advisory, the update removes \"local-only commands\" that let users skip the Microsoft account sign-in screen. Hands-on testing by multiple outlets and community members confirms two specific workarounds are neutralized:

  • oobe\\BYPASSNRO: Invoked via Shift+F10 and typing the command, this script forced a \"limited setup / I don't have internet\" branch that allowed local account creation. In the current build, it either does nothing, restarts the OOBE, or loops the user back to the Microsoft sign-in gate.
  • start ms-cxh:localonly: A simpler one-liner that opened a hidden local-account creation dialog. It is now ignored or triggers a restart.

Microsoft paired this crackdown with a narrow concession: a new SetDefaultUserFolder.cmd helper can be run from the same Shift+F10 command prompt to set a custom profile folder name (up to 16 Unicode characters) before signing in with a Microsoft account. That resolves a longstanding annoyance for users who dislike the auto-generated C:\\Users\\<username> folder name, but it does not restore the offline local-account path.

The changes apply to Insider Preview builds in the Dev (26220) and Beta (26120) channels. They are not yet in stable production releases, and Microsoft's notes emphasize that the removals target consumer OOBE—enterprise provisioning methods like Windows Autopilot, Intune, unattend.xml files, and image-based deployment remain unaffected.

What it means for you

For mainstream consumers

The most frictionless path is completing OOBE with a Microsoft account and an active internet connection. This aligns with Microsoft's broad push toward cloud-backed services: BitLocker recovery keys saved to an MSA, OneDrive folder backup, settings sync, and Windows Hello cloud recovery all depend on an online identity. For users already invested in Microsoft 365 or OneDrive, the change may feel seamless. For anyone who simply wants a working PC with minimal fuss, signing in with an MSA is now the default—and arguably the simplest—route.

For privacy-minded users and hobbyists

The removal of in-OOBE command-line escapes raises the friction for those who prefer a local account to limit data sharing or avoid Microsoft-branded apps and ads. Pre-built ISOs from Microsoft no longer offer a simple \"I don't have internet\" detour. However, local-only setups are still achievable with deliberate preparation:

  • Preconfigured installation media: Tools like Rufus can inject an autounattend.xml answer file that creates a local account during setup, bypassing the MSA prompt entirely. This requires building custom media but yields a repeatable, offline result.
  • Post-setup account switching: Complete OOBE with a disposable Microsoft account, then create a local administrator user inside Windows. After logging in with that local account, you can delete the temporary MSA user. Many hobbyists have used this workaround for years, and it remains viable in the current build.

For refurbishers and small resellers

Organizations that refurbish devices en masse without enterprise tooling now face a higher operational cost. A manual process of signing in with a temporary MSA per machine, then deleting it, doesn't scale well. The durable solution is moving toward image-based or scripted unattended installation workflows—pre-building a local-account configuration into the installation media from the start.

For IT and managed environments

Enterprises using modern deployment tools will see little disruption. Autopilot, Microsoft Deployment Toolkit, System Center Configuration Manager, and unattend.xml files all support deterministic local- or domain-account creation and are explicitly outside the scope of Microsoft's OOBE changes. IT teams should validate their images against the latest Insider builds to catch any regressions, but the underlying provisioning mechanisms remain intact.

How we got here

The trend toward an account-first OOBE has been building for years. Windows 10 originally allowed a local account during setup with a clear \"Offline account\" option. Windows 11 Home and Pro gradually narrowed that path: first by requiring an internet connection for Home edition, then by hiding the local account option behind multiple clicks and prompts. Workarounds like the BYPASSNRO script became community staples because they let users reclaim the older, simpler flow.

Microsoft's rationale for closing these escapes is pragmatic. The company's release notes state that some bypass methods \"inadvertently skip critical setup screens, potentially causing users to exit OOBE with a device that is not fully configured for use.\" Enforcing sign-in and connectivity ensures that BitLocker recovery keys are backed up, Windows Hello is configured, and security and privacy settings are explicitly addressed. There's also a commercial dimension: an MSA-first device is more likely to engage with OneDrive storage plans and Microsoft 365 subscriptions, though Microsoft has not cited revenue as a motivation.

The changes in Build 26220.6772 arrive just as Windows 10 nears its end of support, funneling more users toward Windows 11 and, by extension, this tightened setup flow. It's part of a larger industry shift toward cloud-integrated operating systems where an online identity is no longer optional but foundational.

What to do now

Your ideal response depends on your role and priorities. Here's a practical checklist:

If you want a local account on a single PC:

  1. Quick route: Use a throwaway Microsoft account to complete OOBE. Immediately after reaching the desktop, create a new local administrator user (Settings > Accounts > Other users > Add account > I don't have this person's sign-in information > Add a user without a Microsoft account). Log in with that new local account, then delete the temporary MSA user. Check Privacy & Security settings to disable ad personalization and telemetry to your comfort level.
  2. Pre-built route: Before installing, use a tool like Rufus to create a Windows 11 USB drive with local-account options enabled. Select the \"Remove requirement for an online Microsoft account\" and \"Create a local account with username\" settings when building the media. This automates the bypass and gives you a local-only setup from the start.
  3. Advanced route: Write your own autounattend.xml answer file that sets up a local account. Place it at the root of the installation USB, and Windows will honor it during setup. This is overkill for a single PC but worth learning if you frequently reinstall.

If you manage many devices:

  • Adopt or extend image-based deployment with an answer file that defines local (or domain) accounts. Validate against Insider builds regularly.
  • If using Autopilot or Intune, confirm your configuration profiles still deliver the desired account type; these remain unaffected.
  • For custom deployment scripts, test against Build 26220 to ensure no hidden dialogs block automated flows.

If you're privacy-conscious but not technical:

  • Stick with the throwaway Microsoft account method. During OOBE, choose minimal privacy settings, decline optional data collection, and don't enable OneDrive backup. After creating your local admin account, double-check that BitLocker hasn't been silently activated without a recovery key backup—if it has, you can suspend protection or ensure the key is stored locally.

What to watch next

Insider builds are an experimentation layer. Microsoft has historically tested stricter OOBE defaults in Dev and Beta channels, then adjusted based on telemetry and feedback before shipping to stable releases. The approach could land as-is in the next major Windows 11 feature update, be softened with a visible \"limited experience\" opt-out, or even be pulled if public backlash mounts.

Community workarounds will inevitably surface—perhaps registry hacks or new URI handlers—but they will exist in a constant cat-and-mouse game. The durable, long-term path for anyone who insists on a local-first device is to adopt supported provisioning methods rather than relying on ephemeral OOBE tricks. For enterprise users, that means Autopilot or unattend.xml; for consumers, it means learning to build a custom installer or accepting a brief Microsoft account login followed by a cleanup.

The practical truth remains constant: the era of the effortless, one-line OOBE bypass is ending. But a local account is still attainable—it just requires a plan.