Windows 11 26H1 Canary Signals Platform First ARM Silicon Enablement

Microsoft's Canary Channel quietly flipping the visible OS label to Windows 11, version 26H1 is the clearest signal yet that Microsoft is separating platform enablement from the familiar consumer feature cadence — and that split has immediate implications for OEMs, enterprises, developers, and anyone tracking the return of Arm‑powered, NPU‑centric Windows devices.

Background​

Microsoft published an official Canary‑channel announcement confirming the arrival of Insider Preview Build 28000 and explicitly stated that “26H1 is not a feature update for version 25H2 and only includes platform changes to support specific silicon.” That language reframes 26H1 as a platform baseline rather than the next general consumer feature release. Concurrently, Microsoft’s partner guidance for hardware certification — the Windows Hardware Compatibility Program (WHCP) and matching HLK playlists — shows that Build 28000 is the compliance baseline for whatever devices and silicon Microsoft intends to support on 26H1. In short: the build exists so OEMs and silicon partners can factory‑image and certify devices that need deeper OS plumbing than the mainstream 25H2/Germanium branch provides. Two consistent themes emerge in the reporting and community telemetry:

• 26H1 appears engineered to enable the next wave of Arm‑first laptops that rely on larger NPUs and new driver/firmware contracts.
• Independent outlets and industry trackers tie the first wave of 26H1 devices to Qualcomm’s Snapdragon X2 family (and similar high‑end Arm silicon), although Microsoft’s Canary note avoids naming specific vendors. Treat the Snapdragon linkage as strong industry reporting rather than an explicit Microsoft statement.

---

What 26H1 actually is — and what it isn’t​

Platform baseline, not a broad release​

26H1’s public changelog is deliberately thin: Microsoft’s Canary notes list a small set of general improvements and fixes and then add the platform caveat. The hard work is under the hood — kernel plumbing, scheduler and power policy changes, DCH driver packaging and NPU runtime hooks — all the kind of engineering that OEMs need preinstalled and validated on factory images. This is why Microsoft released new HLK/WHCP guidance specifically for 26H1.

Device eligibility and servicing​

Microsoft’s messaging makes two operational points explicit:

• Existing Intel/AMD devices remain on the mainstream 25H2 servicing baseline and will not be forced onto 26H1.
• 26H1 will be used for a narrow set of new devices (early reports point to Snapdragon X2‑based Copilot+ laptops). That implies manufacturers will ship devices preloaded with 26H1, and enterprises must treat those machines as a separate image/supported SKU in their lifecycle plans.

---

Why Microsoft is doing this: the engineering case​

Modern SoCs for premium mobile PCs are no longer incremental in nature. They introduce:

• heterogeneous cores and new scheduling requirements;
• significantly larger on‑die NPUs and new model runtime/attestation workflows;
• updated ISP/media pipelines, Wi‑Fi 7 stacks, and different firmware semantics.

Those foundational changes often require kernel and runtime adaptations that are risky to graft into an existing servicing baseline without causing regressions across millions of devices. Creating a dedicated, device‑targeted platform branch lets Microsoft and partners co‑validate deep changes while preserving stability for the majority of the installed base. This is a pragmatic engineering move that reduces day‑one regressions on hardware that needs the new plumbing.

---

What to expect in practice​

For consumers​

• If you already own a Windows PC, no action is required. Microsoft’s official messaging insists the 25H2 track remains the mainline feature path, and 26H1 will not be broadly pushed to existing devices.
• If you’re shopping for a new Copilot+ Arm laptop marketed around on‑device AI performance (Snapdragon X2), those units may ship with 26H1 preinstalled. Early retail windows reported by industry sources point toward spring 2026 shipments for first wave products.

For enterprises and IT​

Enterprises must treat 26H1 devices as a distinct class in their deployment and certification plans. That includes:

• Establishing a pilot ring for 26H1 devices and testing imaging, policy, and update flows before procurement at scale.
• Validating endpoint security agents (AV, EDR), VPNs, MDM/Intune profiles, disk encryption, and business apps on Bromine/Build 28000 images.
• Requesting OEM documentation on servicing/rollback paths and HLK certification status for targeted hardware.

For developers and ISVs​

• Prioritize Arm64 native builds where practical and ensure graceful fallbacks for missing NPU acceleration.
• Validate kernel‑mode and privileged components (anticheat, DRM, device drivers) early on Bromine images and with OEM test hardware.
• Expect that some serviceable features might be gated to hardware that ships with the Bromine baseline at launch and plan communications accordingly.

---

Strengths of Microsoft’s approach​

• Reduced day‑one risk for OEMs: shipping devices with a validated OS image that includes the necessary driver and runtime plumbing reduces the likelihood of crippling launch‑day regressions.
• Faster hardware enablement: OEMs can meet product windows for new silicon without waiting for a broad servicing cycle. This can make high‑NPU Copilot+ devices commercially viable on schedule.
• Preserves stability for the broad base: by not forcing these deep platform changes onto existing PCs, Microsoft reduces the blast radius of risky kernel or scheduler modifications.

---

Risks and friction points​

• Fragmented servicing and support: Running multiple platform baselines in the same calendar year increases test complexity for cumulative updates and patches. Enterprises must maintain distinct validation matrices for 25H2 and 26H1 devices.
• Perception of feature gating: If device‑first enablement means certain on‑device AI features are visible only to buyers of specific hardware, Microsoft must manage messaging carefully to avoid perceptions of exclusivity or unfair gating.
• Compatibility regressions: Third‑party kernel drivers, EDR/AV suites, VPNs, anticheat, and low‑level management agents are historically susceptible to breakage from platform shifts. Early validation windows will be essential.
• Operational overhead: Enterprises with mixed fleets (x86 + new Arm devices) will need to maintain separate golden images, patch verification cycles, and support playbooks for 26H1 SKUs.

---

The other headline: anti‑“slop” tools and the rise of debloat modules​

Parallel to Microsoft’s platform work, the Windows customization ecosystem has continued to evolve. A notable development is the addition of dedicated AI‑removal modules to popular “debloat” utilities. FlyOOBE — a widely used setup/customization utility — released version 2.4 with an AI‑cleaning module called Slopilot, and it optionally integrates with community tooling like RemoveWindowsAI. Tech outlets warn these tools can be powerful but risky.

What these tools actually do​

• Use combinations of registry changes, Appx removal, and component blocking to disable or remove first‑party AI components (Copilot, Recall, Input Insights, AI features in inbox apps).
• Integrations with community repos automate deeper cleanups but can lead to false positives with AV or break future updates if Microsoft changes the component delivery mechanisms.

Why this matters​

The proliferation of opt‑out tooling is a symptom of user friction around the pace and volume of AI features being embedded into Windows. Merriam‑Webster’s 2025 selection of “slop” as Word of the Year — and internal Microsoft comments about moving beyond “slop vs. sophistication” — underline a broader product and reputational challenge: users complaining about low‑value, noisy AI output are taking matters into their own hands.

---

Security and support tradeoffs with debloat tooling​

Third‑party removal of system components creates real tradeoffs:

• Security risks: Disabling telemetry or security‑adjacent components can reduce visibility into compromises and may trigger antivirus or protection engines.
• Update fragility: Changing package manifests or removing system Appx packages can cause Windows Update to fail or to reinstall components in unexpected ways.
• Supportability: Corporate environments should avoid ad‑hoc removal of Microsoft components unless formally validated and documented — unsigned or unsupported modifications can void vendor support agreements.

Practical guidance for those tempted to use debloat tools:

• Prefer supported UI toggles and enterprise policies where available.
• If you must run a cleanup utility, test it in a VM or a disposable lab image first.
• Keep full backups and golden images to restore quickly.
• Re‑enable Tamper Protection and other endpoint defenses after maintenance.

---

A practical checklist: how to prepare (for different roles)​

Consumers​

• Confirm your current Windows version via Settings → System → About or winver.
• If you value stability, avoid installing Canary builds or community scripts on a daily‑use machine.
• If trying a new Arm Copilot+ laptop, plan to validate key apps and drivers during the return period.

IT administrators​

• Identify any procurement plans for Snapdragon X2 or other prospective 26H1 devices. Request OEM servicing and HLK certification artifacts.
• Create a pilot ring and validate imaging, MDM profiles, disk encryption, VPN, SSO, and EDR/AV agents on Bromine images.
• Document and automate rollback workflows (images and reinstall media) for Canary‑based or factory‑imaged devices.

Developers / ISVs​

• Prioritize Arm64 native builds or test via Arm64 emulation containers.
• Validate privileged components and kernel‑mode drivers early on Bromine images.
• Provide clear customer guidance if certain features require device‑specific hardware or Bromine‑based images.

---

What remains uncertain (and how to read signals)​

• Microsoft’s blog made it clear 26H1 is a platform-only flight, but it did not name specific silicon partners in that announcement. Industry reporting strongly links Snapdragon X2 to the first wave, but until OEMs publish device shipping pages or Microsoft explicitly details the first carriers, treat device‑vendor specifics as credible but not official.
• Timing: multiple outlets and community trackers forecast first shipments of 26H1 devices in spring 2026 (March–April windows), with the broad H2 2026 feature release (26H2) expected to carry user‑facing changes to the wider installed base later in the year. Those timelines are plausible based on Qualcomm/OEM announcements and Insider telemetry but remain subject to schedule shifts.
• The permanence of this model: Microsoft may use device‑targeted platform branches as a recurring pattern when silicon generations demand deep OS changes, or it may treat 26H1 as a one‑off. Future behavior will be shaped by partner feedback, update complexity, and customer sentiment.

---

Critical analysis — strategic implications for Microsoft and the ecosystem​

Microsoft’s decision to gate platform upgrades to a device‑targeted branch is technically defensible and operationally pragmatic: it reduces the likelihood of regressions on the broad installed base while enabling OEMs to ship cutting‑edge hardware. That alignment is essential if Windows wants to remain competitive in premium Arm laptops that tout on‑device AI capabilities and long battery life.
However, this path raises nontrivial governance, UX, and market risks:

• If consumers perceive a two‑tier Windows experience — an Arm NPU‑rich subset with early agentic features versus a mainstream branch that receives those features later — Microsoft must manage expectations tightly. Messaging and retail communication must be crystal clear to avoid backfire.
• Enterprises face real operational costs. Mixed fleets are already complex; adding a separate platform SKU means more test matrices, more gold images, and additional helpdesk triage scenarios. That burden will be felt most by organizations that refresh hardware at scale.
• The growth of anti‑AI or anti‑slop debloat tooling is a concrete signal that a segment of the Windows base is willing to trade convenience for control. Microsoft must decide whether to make opt‑out easier in supported ways or to accept that community scripts will continue to fill that gap — with the attendant support and security tradeoffs.

---

Bottom line​

Windows 11, version 26H1 (Build 28000) is real, officially framed as a platform release for specific silicon, and backed by targeted WHCP/HLK guidance for partners. The decision to ship an OEM‑first Bromine baseline is a pragmatic engineering solution to real hardware and runtime constraints; it enables day‑one device readiness for high‑NPU Arm laptops while insulating the broader Windows base from risky low‑level changes. But the approach is not without costs: expect short‑term servicing fragmentation, increased validation burdens for IT and ISVs, and a visible debate over the pace and governance of embedded AI features — a debate that community debloat tools are already answering in their own way. Proceed cautiously if you manage fleets, test thoroughly if you develop for Arm silicon, and, if you’re a consumer, buy the hardware you need now rather than chasing early Canary promises.

---

Final recommendations (concise, actionable)​

• Enterprises: treat 26H1 devices as a separate SKU; pilot before procurement and demand HLK/WHCP proof from OEMs.
• Developers: add Arm64 test coverage and validate privileged components on Bromine/Build 28000 early.
• Consumers: if you value stability, remain on 25H2 and wait for 26H2; if buying a new Copilot+ laptop, verify return policies and test key workflows.
• Anyone tempted by debloat tools: validate in a VM first, backup images, and be prepared for AV false positives and update fragility.

Microsoft’s Canary announcement and the surrounding industry reporting mark an inflection point: Windows is actively accommodating a new class of Arm silicon and on‑device AI, and it’s doing so by reshaping how platform code is staged and delivered. That technical pragmatism should be welcomed — provided partners, ISVs, and customers are ready for the operational realities it creates.

---

Source: Neowin https://www.neowin.net/amp/microsof...ng-soon-anti-slop-tools-for-windows-and-more/

 

[ChatGPT]

Microsoft’s Canary preview has quietly flipped the version string to Windows 11, version 26H1, but this is not the next consumer feature release — it’s a platform-first engineering baseline built to enable next‑generation silicon and OEM device images rather than a mass feature update for existing x64 PCs.

Background / Overview​

Microsoft published Insider Preview Build 28000 to the Canary Channel and deliberately clarified that “26H1 is not a feature update for version 25H2 and only includes platform changes to support specific silicon.” That line is the fulcrum for understanding what 26H1 actually is: a device‑targeted, platform enablement branch rather than the usual H2 Windows feature wave. The Canary flight is already carrying a handful of visible UI refinements — several items that were previously trialed in Dev/Beta and 25H2 previews — but Microsoft’s public messaging and the build numbering (Build 28000 and related 28020.x flights) make the point clear: 26H1 exists to give OEMs and silicon partners a validated OS baseline they can ship on factory images for hardware that requires low‑level OS changes. This shift matters because modern PC SoCs — particularly Arm‑based designs with large NPUs, mixed core topologies, and different firmware/attestation models — can require kernel, driver, scheduler, power‑management, and runtime plumbing changes that are difficult or risky to graft onto a servicing baseline used by billions of existing devices. Microsoft’s approach preserves the mainstream Windows feature cadence (25H2 → 26H2) while letting OEMs ship devices with the platform work already baked in.

---

What 26H1 is — and what it isn’t​

A platform baseline, not a general feature update​

• What it is: A platform‑only release that updates low‑level OS components to support new silicon and driver models. It’s being tested in the Canary Channel as Build 28000 and subsequent builds in the 28020 series.
• What it isn’t: A consumer-facing, mass‑deployed feature update. Microsoft states explicitly that 25H2 remains the main branch for features and that 26H1 is for specific hardware enablement.

Why Microsoft took this route​

• New chips (notably recent Qualcomm Snapdragon families and rumored Arm client designs) introduce runtime and firmware behaviors that touch the Windows kernel, scheduler, driver models, and on‑device AI runtimes. Supporting these safely often means shipping a validated OS image to OEM partners rather than rolling those changes into the servicing baseline used by billions of PCs. The Canary 26H1 work appears expressly intended to solve that problem.

Delivery model: enablement package vs. full OS replacement​

Microsoft has been using enablement-style packaging in recent years where new code is staged in cumulative updates and unlocked through a lightweight activation package that flips the version identifier. The practical result is shorter installs and smaller downloads for end users when a full feature update does roll out. While 26H1’s Canary preview shows a new version string, Microsoft’s messaging implies that the platform baseline will be delivered to device SKUs that require it, often as factory images. The customer‑facing enablement path for mainstream PCs will likely remain centered on the annual H2 feature update (26H2).

---

What’s visible in the Canary previews (Build 28000 / 28020.x)​

Although the branch is platform-first, recent Canary flights have enabled numerous user‑facing refinements — many of which had previously been visible in 25H2 previews. These items are rolling out via Microsoft’s controlled feature gating, so not every Insider will see every feature immediately. The most notable visible changes reported in the Canary builds include:

• Mobile Devices settings — a new Settings page to pair and manage smartphones from Windows. Windows can use paired mobile phones as cameras or to surface files directly into File Explorer.
• Xbox Full Screen Experience (FSE) expansion — the console‑style, game‑first interface that reduces background work and provides a dedicated gaming shell has been extended to more handheld and desktop devices. This mode prioritizes performance and integrates Xbox experiences in a full‑screen layout.
• File Explorer dark mode and UX polish — dialogs (copy/move/delete), progress views, error/replacement prompts and chart/progress visuals now have a more consistent dark mode treatment. Hovering over items in Explorer Home surfaces quick actions like “Open file location” and contextual Copilot prompts in eligible regions.
• Drag Tray and Nearby Sharing improvements — the Drag Tray now supports multi‑file sharing, smarter app suggestions, and direct placement into destination folders; a setting controls whether the Drag Tray appears for Nearby Sharing flows.
• Click to Do redesign (Copilot+ hardware gating) — context menus for large images and tables become more proactive, presenting direct actions like Copy, Save, Share, Summarize and local AI processing where supported; some capabilities are staged for Copilot+ devices with on‑device AI.
• Settings agent and inline adjustments — the Settings app can surface recommendations and inline action controls right from the search field on Copilot+ PCs; when a setting can’t be changed, Windows will explain why.
• Studio Effects for external webcams — Windows Studio Effects can now be applied to external USB webcams and toggled from Settings or quick settings.
• Desktop Spotlight context options — right‑click options like “Learn more about this background” and “Next desktop background” appear for Spotlight wallpaper.
• Keyboard and cursor settings migrated from Control Panel — settings such as keyboard character repeat rate and cursor blink rate were moved into the modern Settings UI; HID keyboard backlight controls were also improved.
• Pens with haptics — pens that support haptic feedback can now deliver tactile responses for interactions like moving or docking windows.
• Bug fixes — a series of fixes for File Explorer, Task Manager behavior, Settings, Windows Update and sign‑in issues were included; notable fixes included correcting a Task Manager background process bug.

These visible features mirror reporting in the community and press while the platform plumbing quietly prepares for upcoming silicon. That duality — visible UX polish atop a platform baseline — explains why Canary now reads like a hybrid: still engineering‑centred, but with user‑facing polish under controlled rollout.

---

The hardware story: who 26H1 is being prepared for​

The Canary notes are explicit that 26H1 is designed to support “specific silicon.” Independent reporting, industry timing, and OEM briefings consistently point to Qualcomm’s next‑generation Snapdragon X2 family as a primary target; additional reporting and rumor mills have named NVIDIA’s anticipated N1/N1X client efforts as another possible target. It is important to note that Microsoft’s blog did not list vendors by name — the linkage to specific chips is an industry inference informed by vendor roadmaps and reported OEM device timelines. Treat vendor attributions as well‑supported but not Microsoft‑certified unless later confirmed. Why this matters technically:

• NPUs and on‑device AI runtimes require signed manifests, attestation hooks, and privileged runtime drivers that often need kernel and driver model changes.
• Heterogeneous core topologies (big/little or mixed microarchitectures) benefit from scheduler and governor improvements.
• Power and thermal envelopes for new designs can require tuned power management and governor policies in the OS.
• Driver and firmware signing/attestation workflows can change how drivers are installed and validated at factory and in the field.

A platform baseline like 26H1 gives OEMs a validated OS image to factory‑flash and support day‑one capabilities (for example, local AI processing on Copilot+ devices) instead of relying on post‑ship servicing that might be riskier for deep kernel and firmware changes.

---

Risks, trade‑offs, and open questions​

Fragmentation and servicing complexity​

Splitting platform plumbing into a device‑gated baseline introduces a more complex servicing landscape. Devices that ship with the 26H1 baseline may follow differentiated update and rollback paths compared with 25H2 devices. IT teams and OEMs must validate update behaviors and test image rollback procedures to avoid procurement surprises.

Compatibility and driver regressions​

Platform changes touching kernel scheduling, power governors, and driver models increase the risk surface for regressions. While factory‑validated images mitigate day‑one issues for the shipped device, cross‑vendor drivers and legacy peripherals could exhibit unexpected behavior on the new platform until driver authors update their stacks.

Security and privacy considerations for AI features​

Features that expand local AI processing, agents in Settings, Click to Do enhancements, and Copilot integrations alter data‑flows and increase the need for clear consent models. Microsoft’s early previews include gating and opt‑ins for agentic features, but enterprises should treat these as experimental until hardened controls and enterprise policy mechanisms are available.

Device exclusivity and user perception​

If certain features are tied to Copilot+ hardware or to devices shipped with the 26H1 baseline, consumers may perceive an artificial feature split between machines. Microsoft and OEMs must communicate clearly about which capabilities require specific silicon or factory images to avoid confusion and backlash. Historical precedence shows that perceived exclusivity can become a PR front that must be carefully managed.

Unverified vendor claims​

Multiple outlets and community threads speculate about NVIDIA N1/N1X or other vendors being immediate targets for Bromine/26H1; however, Microsoft’s Canary notes do not name specific silicon partners. These attributions remain plausible and supported by industry timing, but they must be flagged as speculative until confirmed by Microsoft or the relevant OEMs.

---

What this means for different audiences​

Consumers and prosumers​

• If you run a current Intel/AMD or existing Arm PC, there is no urgency: 25H2 remains the main feature baseline and your device will not automatically receive 26H1. For most users, the only practical impact is that new Copilot+ or Snapdragon X2 devices sold in 2026 may ship with distinct, prevalidated platform behavior.

Windows Insiders and enthusiasts​

• The Canary Channel is the place to test platform plumbing, but it carries typical Canary instability: unexpected crashes, Start menu regressions, sleep/shutdown issues, and possible driver incompatibilities. Use a spare machine or VM if you want to explore 26H1 builds. Microsoft has warned that leaving Canary often requires a clean OS reinstall.

OEMs and silicon partners​

• 26H1 gives OEMs a validated OS baseline for factory imaging and day‑one feature support on silicon that cannot be reliably enabled on the 25H2 servicing stream. Partners will need to coordinate firmware, DCH driver stacks, and model runtime attestations with Microsoft to ensure stable shipping builds. Validate update paths and rollback scenarios in internal test labs.

Enterprise IT and system administrators​

• Treat 26H1 devices as separate SKU images for procurement testing. If you plan to buy Copilot+ or new Arm PCs in 2026, include test plans for management tooling, group policy, patching cadence, third‑party agent compatibility, driver handling, and security posture. Conservative fleets should remain on 25H2 until 26H2 ships as the mainstream feature update.

---

Practical guidance: how to evaluate or test 26H1​

• Decide your risk tolerance. Canary builds are experimental; run them on a non‑production machine or VM.
• Join the Windows Insider Program and choose the Canary Channel. For Home users this is free; enterprise environments should not enroll production machines.
• Snapshot and backup before testing. Canary builds can require a clean reinstall to return to lower rings; maintain full backups.
• If you manage devices you plan to purchase, pre‑validate OEM images. Ask OEMs for documentation outlining servicing paths for devices shipping with the 26H1 baseline.
• Monitor driver and security advisories closely. Low‑level platform changes can have cascading effects on drivers, firmware, and security tools; track vendor updates.

---

Strengths and strategic upside​

• Faster time to market for new silicon. OEMs can ship devices with a certified OS image that incorporates required kernel and runtime plumbing, reducing day‑one patching risk.
• Better on‑device AI experiences at launch. When hardware ships with the platform baseline, local AI features that require NPU runtimes and attestation can be enabled on day one with less friction.
• Reduced risk for the broader installed base. Separating platform plumbing from the mainstream servicing baseline avoids destabilizing updates for the many existing PCs still running 25H2.

---

Potential downsides and long‑term risks​

• Fragmented servicing and update matrices could complicate enterprise patching and OEM support. IT teams will need clear maps showing which devices follow which servicing channels.
• Perceived exclusivity of features tied to Copilot+ or specific silicon could alienate some customers unless Microsoft and OEMs communicate transparently about requirements.
• Increased testing burden for ISVs and driver authors who must ensure compatibility across multiple platform baselines. Lower-tier vendors with limited QA resources may be left behind unless tooling and guidance are strong.

---

Final assessment and recommendations​

Windows 11 26H1 — as surfaced in Canary Build 28000 and related 28020.x previews — is best read as a pragmatic engineering move that separates deep platform enablement work from the mainstream feature servicing track. It enables OEMs and silicon partners to ship devices that rely on kernel, driver and runtime changes without exposing the entire installed base to potentially destabilizing low‑level updates. The visible UX refinements in Canary are useful and noteworthy, but they are secondary to the core purpose: hardware enablement and platform validation. For mainstream users and IT managers, the practical advice is simple:

• Stay on 25H2 for stable feature servicing and wait for 26H2 (the annual H2 release) for broad feature availability.
• If you plan to buy Copilot+ or Snapdragon X2 devices early in their life, insist on OEM documentation for update/rollback behavior and include those SKUs in pilot programs.
• If you are an Insider or enthusiast, try Canary builds on disposable hardware and closely monitor known issues like Start menu scrolling and power/sleep problems noted in early flights.

Finally, treat vendor attributions (for example, NVIDIA N1/N1X participation) as informed but not officially confirmed until Microsoft or the vendors publish explicit product or partner guidance. The Canary announcement is explicit about scope; market inference fills in likely hardware targets — but those inferences should be followed up with vendor/OEM confirmation before acting on them for procurement or development roadmaps.

---

Windows 11 26H1 is a technical pivot: a discrete platform baseline to let Windows support a new wave of heterogeneous silicon without upending the mass servicing model. The visible feature polish in Canary gives a useful preview of where user experiences are headed, but the real story is under the hood — kernel, driver, runtime, and firmware plumbing built for day‑one hardware compatibility and safer launches.

---

Source: PCWorld Windows 11 26H1 preview build gets missing features from 25H2