Windows 11 Upgrades Leave 802.1X Wired Policy Missing dot3svc

A growing number of enterprise IT teams and system administrators are again reporting that Windows 11 feature updates can leave machines without wired network access by removing or emptying the C:\Windows\dot3svc\Policies folder — the place Windows stores the Wired AutoConfig (802.1X) policy files — requiring manual intervention or Group Policy reapplication before systems can authenticate to corporate networks. The claim, published in community and trade coverage and echoed in a Windows Report item shared by a reader, lines up with months of field reports from administrators who say upgrades or in-place feature updates sometimes reset or fail to migrate 802.1X configuration, leaving desktops and laptops offline until the client is able to re‑acquire policy from Active Directory or Intune.

Background / Overview​

Windows uses the Wired AutoConfig service — the dot3svc (Wired AutoConfig) service — to perform IEEE 802.1X authentication on Ethernet interfaces. In managed networks that require 802.1X on wired ports, dot3svc depends on policy files placed under C:\Windows\dot3svc\Policies (usually .pol files) and on Group Policy or MDM‑delivered configuration to set the authentication method (for example EAP‑TLS) and certificate validation options. If the policy files are missing or the service cannot read them, the client will either fall back to default authentication (often PEAP/MS‑CHAPv2) or fail authentication entirely, producing the familiar “connected / no internet” or “no network access” symptoms on otherwise healthy hardware. Microsoft documents dot3svc as the service responsible for wired 802.1X authentication.
This is not the first time Windows updates and upgrades have destabilized 802.1X on enterprise networks. Microsoft and the Windows ecosystem have seen multiple 802.1X‑related regressions over the last several years — including Wi‑Fi (WLANSVC) problems caused by specific KBs that were later rolled back via Known Issue Rollback (KIR) — but the specific behavior administrators are reporting today is distinct: an apparent migration failure during a feature update or image upgrade that results in the policy files themselves being missing or emptied, rather than a simple in‑memory config or service startup failure.

---

How the problem presents itself in the field​

Typical symptom set​

• After an in‑place upgrade or feature update, a device cannot authenticate on corporate Ethernet ports configured for 802.1X. The network stack often shows the NIC as “connected” but with no network access.
• The same device may also lose the wired 802.1X profile, forcing administrators to rely on Wi‑Fi (if available) to reestablish connectivity and pull down policy.
• Examination of the file system reveals the C:\Windows\dot3svc\Policies folder is empty or missing the expected .pol files, even though the registry still references policy entries and machine certificates remain installed.
• Running gpupdate /force while the device is already network‑connected often reprovisions the missing files and restores connectivity. Administrators report that restarting the Wired AutoConfig service (dot3svc) after resetting a migration flag also triggers a reimport.

When it happens​

Community reports span:

• Major version upgrades (Windows 10 → Windows 11 feature upgrades), and
• Upgrades between Windows 11 yearly feature updates (for example, 23H2 → 24H2/25H2), and
• Some cumulative update scenarios as part of larger enterprise imaging workflows.

That pattern — upgrade/feature install → missing policy files → offline until policy reapply — is documented repeatedly by administrators in independent threads and troubleshooting logs.

---

Technical deep dive: what’s stored in dot3svc and why losing it matters​

The Wired AutoConfig service (dot3svc) drives 802.1X at Layer 2 and reads local policy artifacts that represent machine and user authentication profiles. These artifacts typically include:

• .pol files in C:\Windows\dot3svc\Policies containing serialized network profiles and EAP configuration,
• Registry entries under the dot3svc key that point to policy GUIDs and migration markers, and
• Machine certificates and trusted root certificates used for EAP‑TLS or related authentication methods.

If the .pol artifacts vanish or are not migrated properly during an upgrade, the dot3svc service has no profile to apply; machines revert to default behaviors that may not match enterprise configuration and so fail authentication. Microsoft documentation and service guidance make clear dot3svc is the system component responsible for wired 802.1X and that misconfiguration or absent policy blocks Layer‑2 access on authenticated networks.
Why would an upgrade remove or fail to migrate these files? The most likely technical root causes (derived from community troubleshooting, observed behavior, and how Windows setup migrates policy during in‑place upgrades) are:

• A migration path that expects to import policy from an old path or archive but does not correctly rehydrate local policy files when the device cannot talk to the domain at the time of the final boot.
• Setup or the OOBE sequence clearing the dot3svc migration flag without completing the import step, leaving the system in a “migration done” state while the physical policy files remain absent.
• Image customizations or security hardening that alter permissions, symbolic links, or junctions in C:\Windows\dot3svc causing setup to skip it during file copy or migration.
• Race conditions in the final step of the upgrade sequence where dot3svc starts before the migration or GPO processing completes, causing state corruption or overwrites.

Community engineers have zeroed in on a small set of reproducible actions: forcing the dot3svc migration to run (by manipulating a registry migration flag) and then restarting the service frequently restores the policies and brings the machine back online — which strongly suggests the issue is a skipped or incomplete migration step rather than permanent, unrecoverable data loss. However, because the root cause is triggered during privileged system updates, it’s visible mainly to administrators doing in‑place upgrades at scale.

---

Evidence, corroboration and what the record shows​

• Multiple independent system administrator threads documented the same pattern: empty or missing C:\Windows\dot3svc\Policies after upgrade and restored network connectivity after a Group Policy update or script run that resets a migration flag then restarts dot3svc. These reports are consistent across several months and across upgrade paths.
• Microsoft’s official documentation confirms the role and runtime requirements of dot3svc, making clear that missing policies will interfere with 802.1X. While Microsoft has previously acknowledged and rolled back problematic updates that caused 802.1X connectivity issues on Wi‑Fi (notably the December 2023 KB incident fixed via Known Issue Rollback), there is not yet a public Microsoft support article at the time of writing that explicitly acknowledges a global bug where upgrade operations erase or empty C:\Windows\dot3svc\Policies during Windows hat absence is notable and means the community evidence is currently the primary signal for this specific behavior.
• In forums and community archives we also see practical, reproducible workarounds being used by admins in task sequences and upgrade scripts — typically a small PowerShell snippet that resets the dot3svc migration marker and restarts the service. Those snippets have a consistent effect of reimporting policy when the machine is online, suggesting the migration logic is present but sometimes not executed at the right time in the upgrade workflow.
• Internal community threads within enterprise environments (captured in the reader’s uploaded discussion materials) echo the same troubleshooting steps and note that copying .pol files from a recovery image without addressing the migration flag frequently fails; the successful approach is to trigger the migration/restart flow or to force a Group Policy refresh once network access is available.

Caveat: because much of the evidence is community‑sourced (enterprise admins, internal forums, and sysadmin Reddit threads) rather than a consolidated Microsoft support bulletin for this exact symptom set, the claim that every instance originates from the same Windows bug needs to be treated with caution. Different upgrade paths, OEM drivers, third‑party security products and imaging tools can influence behavior; however, the reproduction pattern and multiple independent confirmations make a strong operational case that the problem is real and widespread in particular upgrade scenarios.

---

Practical mitigation steps (what to do now)​

If you are planning a Windows 11 upgrade at scale, or you are troubleshooting machines already afflicted, take these prioritized, pragmatic steps. Each step is safe to attempt in a controlled environment; treat any registry changes or scripts as part of a tested upgrade task sequence.

• Pre‑upgrade: Identify whether your wired network enforces 802.1X and which authentication method (EAP‑TLS, PEAP‑MS‑CHAPv2, etc.) you use. If possible, provision a temporary non‑802.1X maintenance VLAN for upgrade and imaging operations so endpoints can finish migration and policy retrieval after the feature update.
• Add a post‑upgrade automation step in your SCCM/MDT/Intune task sequence to run the migration reset script and restart the dot3svc service. A commonly used PowerShell approach that community engineers report as effective is:
  

  for ($i = 1; $i -le 3; $i++) {
    New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\dot3svc\MigrationData' -Name 'dot3svcMigrationDone' -Value 0 -PropertyType DWORD -Force -ErrorAction SilentlyContinue
    Restart-Service -Name dot3svc -ErrorAction SilentlyContinue
    Start-Sleep -Seconds 30
  }

  This resets the migration marker and restarts the service, allowing the client to re‑import policy. Test and adapt the loop timing for your environment.
• If a device is already offline after an update, try these in order:
• Connect the device to a non‑802.1X port (a wired guest VLAN or Wi‑Fi with internet access).
• Run gpupdate /force to pull down policy from Active Directory (or trigger MDM sync if the device is MDM managed).
• If gpupdate is not feasible, run the migration reset script above and restart dot3svc.
• As a stopgap, include the migration flag reset in the OS provisioning SetupComplete.cmd or as a final step in your imaging/touchless upgrade sequence so the migration runs after the device first boots with network connectivity. Many admins report success placing the script at the end of a task sequence.
• Inventory and driver hygiene: Ensure NIC drivers are from the OEM and up to date in your image; avoid mixing driver updates from Windows Update at the time of a major feature upgrade unless validated. Driver quirks during the final setup phase can change timing of network stack initialization and contribute to migration race conditions.
• If you rely on certificate‑based authentication (EAP‑TLS), double‑check certificate auto‑enrollment and machine certificate availability as part of preflight checks; certificates are frequently present, but clients sometimes fail to present them correctly until migration completes.

Important operational note: scripts that alter HKLM must be run with administrative privileges and only after thorough testing in a staging environment. If you are uncertain, run these steps on a handful of pilot machines first.

---

Enterprise policy choices: what to change in your upgrade plan​

• Pause widespread feature updates until the upgrade path is validated in your environment. Use Windows Update for Business safeguards or your WUfB/WSUS policies to control the cadence of upgrades.
• Include a network connectivity validation step in your upgrade task sequences. If the machine cannot reach domain controllers or MDM endpoints at the time migration should happen, don’t declare the upgrade finished — defer finalization until connectivity is ensured.
• Consider delivering the wired 802.1X profile via MDM (Intune) as a complement to Group Policy. Several admins report that MDM‑delivered profiles will re‑apply when the device regains internet access even if AD connectivity is transient. That said, moving to MDM is not a silver bullet and requires change control and testing.

---

What Microsoft has said (and what it hasn’t)​

Microsoft has a documented history of acknowledging certain 802.1X connectivity regressions caused by specific updates and using Known Issue Rollback (KIR) to remediate them — notably December 2023 events where affected KBs caused Wi‑Fi clients to fail authentication and Microsoft deployed a KIR while advising enterprise mitigations. Those public KIR fixes demonstrate Microsoft’s operational route for high‑impact connectivity regressions. However, at the time of writing there is no public Microsoft support bulletin explicitly stating that feature updates are globally wiping the C:\Windows\dot3svc\Policies folder during upgrades; instead the observable pattern is reported through enterprise community threads and field troubleshooting. This distinction matters: Microsoft has an established remediation path for update‑induced regressions, but this specific migration artifact (missing .pol files) appears primarily in community telemetry and administrator reports rather than in a single consolidated Microsoft KB.
Because of that gap in vendor confirmation, organizations should treat this issue as a realistic operational risk backed by multiple independent sightings — and plan accordingly — while monitoring Microsoft’s official Windows health pages, KB articles and commercial support channels for an official acknowledgement and KIR if one becomes necessary.

---

Risks and secondary impacts​

• Business continuity: Machines that cannot join the corporate LAN are effectively stranded for many maintenance operations that assume network access (domain GPOs, certificate renewal, software distribution). In large organizations, even a small percentage of failing upgrades can spike helpdesk tickets dramatically.
• Security posture: Administrators may be tempted to disable 802.1X enforcement or to revert to weaker authentication temporarily; both actions increase attack surface. The correct fix is to ensure migration completes or to provision profile delivery in a robust, tested way — not to weaken network controls.
• Imaging complexity: If task sequences have to be altered to include migration scripts, those changes must be validated in phased rollouts; rushed changes can introduce other regressions.
• Cloud and remote management interplay: Machines upgraded off‑network (for example, at remote sites with no direct AD connectivity) are more susceptible because those clients cannot complete a domain‑based policy migration without a path to pull the artifacts from a policy source. MDM strategies can mitigate but require planning.

---

Recommendations for vendors and Microsoft​

• Microsoft: publish a supported KB or guidance on dot3svc migration behavior during in‑place upgrades and feature updates, including whether Known Issue Rollback is applicable and the exact documented recovery steps for admins encountering empty C:\Windows\dot3svc\Policies. A small, documented API or built‑in migration retry that triggers automatically once the device gains network connectivity would remove the need for fragile workarounds.
• OEMs / imaging vendors: ensure that your task sequence templates include a validated dot3svc migration step when targeting enterprise cuX for wired access; coordinate driver availability to avoid network stack timing issues during the final setup phase.
• Enterprise security teams: test feature updates in a lab environment that mirrors your production conditional access and 802.1X deployment. Treat 802.1X‑protected subnets as critical upgrade validation zones.

---

Conclusion​

The pattern — feature updates leaving C:\Windows\dot3svc\Policies empty and breaking wired 802.1X authentication until administrators force a migration or reapply Group Policy — is neither hypothetical nor isolated. Multiple independent administrator reports, task sequence variants and practical workarounds demonstrate a reproducible failure mode in certain upgrade scenarios that reliably impacts managed networks using wired 802.1X. While Microsoft has a track record of fixing update‑caused network regressions with Known Issue Rollback when they are acknowledged, there is at present no single, clear Microsoft KB that publicly documents a global issue of policy file deletion during Windows 11 feature updates — which leaves IT teams to rely on operational mitigations and targeted scripting to keep upgrades on schedule.
If you run a managed Windows estate with wired 802.1X enforced: plan your upgrades conservatively, include a dot3svc migration reset and restart as a standard post‑upgrade step in your task sequence, validate on pilot devices, and avoid restructuring imaging processes mid‑migration. Treat this issue as a foreseeable operational risk and prepare your helpdesk scripts and automation now — doing so will substantially reduce disruption when the next feature update reaches your machines.

---

Source: Windows Report https://windowsreport.com/windows-1...rnet-by-wiping-dot3svc-folder-for-some-users/

 

[ChatGPT]

A recurring regression in Windows 11 in-place feature updates is again knocking enterprise machines offline by removing the wired 802.1X policy files that the OS needs to authenticate to corporate switches, leaving upgraded endpoints isolated until administrators physically intervene to reapply Group Policy or restore missing artifacts.

Background​

What administrators are seeing​

Across multiple community threads and IT pro support forums, administrators report that after in-place upgrades — notably between yearly Windows 11 feature releases such as 23H2→24H2 and the more recent 23H2→25H2 path — the folder C:\Windows\dot3svc\Policies is empty or missing the expected .pol files that represent wired 802.1X profiles. When those files are absent, the Wired AutoConfig service (dot3svc) has no local policy artifacts to present to a switch port enforcing IEEE 802.1X, and the client either fails authentication or falls back to an unusable default. The symptom commonly reported is “connected” at the NIC level but no network access — the machine is effectively offline for domain communications until remedied.

Why that folder matters​

Windows’ Wired AutoConfig (service name dot3svc) consumes serialized policy files (commonly .pol) under C:\Windows\dot3svc\Policies to configure per-interface EAP settings (for example, EAP-TLS or PEAP/MS-CHAPv2), certificate validation, and machine/user authentication behavior. If those files are not present or are corrupted, the supplicant has no instructions for machine-authentication flows and cannot complete port-based authentication on switches that require 802.1X at Layer 2. Microsoft documents the role of the Wired AutoConfig service in 802.1X processing; missing policies therefore translate directly to an inability to authenticate.

---

How the regression unfolds (technical profile)​

Typical upgrade flow and failure window​

• An IT team initiates an in-place feature update (for example, 23H2 → 25H2) via Windows Update, WSUS/MECM, or a manual installer.
• The upgrade completes and the machine boots into the updated feature release.
• At first boot the system’s network stack reports an Ethernet connection, but authentication to the switch port fails. The machine shows “no network access” and cannot reach domain controllers.
• Investigation finds C:\Windows\dot3svc\Policies either empty or missing .pol profiles that were previously pushed via Group Policy.
• Running gpupdate /force (while the machine is attached to a network path that does not require 802.1X, or via a remediation VLAN) re-pulls the policy and restores the .pol files; restarting or reinitializing dot3svc applies them. Connectivity returns.

Edge cases: certificate store and private keys​

In addition to lost .pol files, several administrators have reported that some in-place upgrades (particularly when migrating from older, long-standing images) can break access to machine certificates or the private keys required by EAP-TLS, or in rare cases remove certificate entries entirely. Those failures prevent EAP-TLS from completing even after policies are repushed, because Windows cannot access the private key bound to the certificate. Microsoft community threads include first-person reports of certificate loss after upgrades; these are consistent with long-standing, historically documented upgrade/migration edge cases where keys and registry mappings are not migrated correctly. Treat these reports as confirmed by multiple operators in the field, but note they vary by image age, deployment tool, and pre-upgrade patch level.

---

Scope and operational risk​

Who is affected​

• Enterprises that enforce wired 802.1X at the switchport and rely on Group Policy or MDM (Intune) to deliver machine-authentication profiles.
• Laptops or desktops upgraded in-place (not freshly imaged) where the upgrade path touches dot3svc artifacts.
• Organizations using EAP-TLS (machine certificate) authentication are at higher risk because a certificate or key migration failure compounds the missing-policy problem.

Why this is dangerous at scale​

• The failure creates a classic “bootstrap” problem: an upgraded system cannot contact domain controllers to receive Group Policy, and Group Policy is the mechanism that normally restores the missing profiles.
• Large fleets upgraded en masse without mitigation planning can produce simultaneous offline endpoints that require hands-on remediation — plugging devices into non-802.1X ports or physically visiting desks to reapply policies and/or reinstall certificates.
• If machine certificates are lost or private keys become inaccessible, automated re-enrollment may be needed; this can require administrative interactions or CA-side operations, increasing remediation time and support overhead.

---

What the public record says (corroboration)​

• Community reports: Numerous threads on r/sysadmin, r/Intune and other forums document the missing C:\Windows\dot3svc\Policies behavior after in-place feature updates, including administrators who solved the problem by copying a saved Policies folder back into place and restarting dot3svc or by running gpupdate /force once the device was on a non-802.1X port.
• Microsoft community answers: Multiple Microsoft Q&A threads show users reporting 802.1X configuration loss after upgrades and receiving community-sourced mitigations (non-802.1X remediation port + gpupdate), but there is not yet a clear, official KB article that describes an intentional change that deletes policy files during upgrades.
• Historical support precedent: Microsoft’s older support guidance for wired 802.1X issues includes restarting the dot3svc service as a workaround for authentication failures in particular update scenarios — an acknowledged mitigation for some 802.1X failure modes, even though it does not address deleted policy files.
• Independent trade coverage: Community and trade outlets have documented similar upgrade regressions in recent Windows servicing cycles and the recurring pattern of 802.1X regressions tied to upgrades. Treat community reporting as high-quality signals but not the same as an official Microsoft patch note.

---

Confirmed mitigations and recommended workarounds​

The most reliable, repeatable mitigations reported by administrators and validated in practice are procedural and deployment-oriented. Below are concrete controls you should put in place before any mass rollout.

Short-term, last-mile fixes (what to run when a machine is offline)​

• Attach the machine to a port that does not require 802.1X (remediation VLAN or guest VLAN).
• Log in with cached credentials (if necessary).
• Run: gpupdate /force /target:computer. Wait for Group Policy to reapply.
• If policies do not reappear, verify the presence of .pol files in C:\Windows\dot3svc\Policies and restart the Wired AutoConfig service:
• sc stop dot3svc
• sc start dot3svc
  This restart can trigger the service to pick up newly-applied policies.

Pre-upgrade controls (strongly recommended)​

• Backup the on-device Policies folder on every target before upgrade:
• mkdir D:\preupgrade\dot3svc\Policies
• xcopy C:\Windows\dot3svc\Policies D:\preupgrade\dot3svc\Policies /E /H
• If using imaging/task-sequence delivery (SCCM/MECM), insert a post-upgrade step to:
• Restore the backed-up Policies folder (if the upgrade removed it).
• Restart dot3svc.
• Run gpupdate /force.
• If you rely on Intune, consider converting the wired profile deployment from legacy GPO-delivered .pols into Intune XML-based wired profiles (or retain a script-based agent that can reapply the XML at OOBE), recognizing Intune deployments require internet reachability to work pre-login.

Deployment sequencing (pilot and phased rollout)​

• Identify a pilot group of devices (representative hardware models and images).
• Run the upgrade with the pre-upgrade backup and the post-upgrade restoration step in place.
• Validate wired authentication, certificate availability, and domain-join health for at least 48–72 hours before expanding to the next ring.
• If any pilot device shows private-key or certificate access problems, capture the machine’s event logs (WLAN-AutoConfig / Wired-AutoConfig and System/App logs) and escalate to your PKI team for re-enrollment options.

Automated remediation examples for MECM / Task Sequence​

Use a post-OS-install step (Run Command Line) that:

• Copies the saved Policies folder back to C:\Windows\dot3svc\Policies.
• Runs: sc stop dot3svc && sc start dot3svc
• Runs: gpupdate /force /target:computer
  Numbered task-sequence steps make this idempotent and safe to rerun. Administrators who embedded this into task sequences report the device re-authenticates during the task sequence and becomes reachable before final user handoff. Community threads provide exemplar scripts and confirmed success in production pilots.

---

Hardening and preflight checklist for enterprise rollouts​

• Audit your fleet: enumerate machines that rely on wired 802.1X and identify those that use machine certificates (EAP-TLS). Prioritize these for manual staging.
• Pre-enroll a remediation VLAN or physical non-802.1X switch ports in every office and test reachability from a patched machine.
• Ensure backup and restore of C:\Windows\dot3svc\Policies (or convert to Intune-based deployment with pre-boot internet access).
• Test certificate re-enrollment processes with your CA: confirm you can programmatically revoke and reissue machine certificates if private keys fail to migrate.
• Train desk-side support and field technicians to perform the simple three-step recovery: plug into remediation port → gpupdate /force → restart dot3svc (or restore policies) and verify connectivity.

---

What Microsoft has and hasn’t said (and what that means)​

• Microsoft’s release-health pages and official KBs document many upgrade regressions and include known-issue rollbacks when a broad class of devices is affected. However, at the time of writing there is no single, official Microsoft KB article explicitly describing an intentional or known behavior of “feature upgrade deletes C:\Windows\dot3svc\Policies for all upgraded machines.” Community reports and Microsoft Q&A posts are the primary public evidence for this specific, repeatable upgrade migration failure. Administrators should therefore treat the condition as a serious operational regression observed in the field but not yet documented as a supported Microsoft design change with remediation steps in a KB article.
• Microsoft Q&A threads contain user reports and community replies recommending the remediation steps noted above; in some cases Microsoft community moderators have recommended using gpupdate or re-enrolling certificates. Those responses are practical but not the same as a formal engineering acknowledgement or targeted patch.

Caution: multiple community posts report that Microsoft told them the behavior may be “by design” (a migration to temporary per-interface profiles with the expectation that gpupdate will repopulate settings). That explanation — if true — still creates an operational outage when the device cannot reach a DC to receive policies. Until Microsoft publishes a clear engineering note and a safe automatic remediation (for example, a Known Issue Rollback or a KB), treat the behavior as a regression for operational planning.

---

Practical playbook for IT teams (step-by-step)​

• Immediately pause any mass automated upgrade waves for endpoints that rely on wired 802.1X and machine-certificate authentication.
• Identify and tag those endpoints in SCCM/Intune so they’re excluded from auto-apply rings until mitigations are added.
• For each tagged endpoint, snapshot or copy C:\Windows\dot3svc\Policies to an external (secured) file share or USB before upgrade.
• Add a post-upgrade task to your task sequence:
• Restore Policies folder if missing.
• sc stop dot3svc
• sc start dot3svc
• gpupdate /force /target:computer
• Validate that the machine authenticates and can reach a domain controller. If the machine certificate is cannot be used, re-enroll the device certificate using your CA’s automated process or a managed script.
• After a successful pilot of at least 48–72 hours, expand the ring. Maintain a runbook for field technicians to perform quick physical remediation.

---

Why this keeps recurring (analysis)​

• The pattern suggests a migration/mapping bug in the upgrade process that either fails to preserve serialized dot3svc policy files or intentionally replaces them with temporary per-interface profiles that are only valid if the machine can immediately reach a policy source. In either case, the result is identical in practice: no usable local policy to complete 802.1X machine auth at first boot.
• Differences in results between fresh images and long-lived installs point to a timing/registry-migration interaction where legacy registry-to-file mappings or private-key ACLs are not migrated cleanly if the pre-upgrade patch level or imaging baseline is old. That explains why some freshly-imaged devices survive the same upgrade while older, long-lived devices lose certificates or keys. Community evidence and Microsoft Q&A reports back this interpretation; it’s consistent with historical upgrade edge cases around key migration and service dependency changes.

---

Risks and the path forward​

Immediate operational risk​

• If left unmitigated, enterprises risk pockets of users entirely cut off from domain services, potentially across multiple sites. Recovery is manual and time-consuming when private-key or certificate re-enrollment is required.

Strategic risk​

• This class of regression erodes confidence in “in-place” upgrades for heavily locked-down corporate estates. Organizations that can’t accept the operational risk may need to prefer staged rebuilds or reimages (where policy and certificates are enrolled post-image) until Microsoft provides a definitive fix.

What IT leaders should demand from vendors​

• Clear Microsoft engineering acknowledgement (a KB/release-health entry) describing root cause, impacted upgrade paths, and targeted fixes.
• A Known Issue Rollback or patch that preserves dot3svc policy artifacts across migrations, or a documented and supported migration path that guarantees a working temporary profile on first boot (without needing domain access).
• Tooling guidance for bulk recovery and scripting patterns that Microsoft support endorses.

---

Caveats and unverifiable claims​

• Some trade and blog posts have suggested that national cyber authorities (for example, CISA) have issued formal advisories about this specific dot3svc deletion behavior. At the time of publication, we could not find a CISA advisory explicitly tied to deletion of C:\Windows\dot3svc\Policies; organizations should not rely on an assumed government advisory in planning. Always validate advisory status against official agency portals. If you see a claim that “CISA has ordered mitigation,” verify via the agency’s published KEV/advisory pages.
• Community-sourced explanations that Microsoft “intentionally removed the policy files by design” are plausible (and have been reported by administrators who opened cases), but they remain contradictory to the reality that the behavior causes outages when Group Policy cannot be pulled. Until Microsoft publishes engineering intent, treat “by design” as an insufficient and operationally unacceptable explanation.

---

Closing assessment and recommendations​

This is an operationally significant regression that has recurred across Windows servicing cycles; the evidence is consistent across multiple, independent administrator reports and Microsoft community threads. The functional impact — loss of wired 802.1X authentication and, in some cases, machine-certificate access — is severe for environments that lock down switchports with 802.1X and rely on Group Policy for configuration.
Actionable recommendations for IT teams:

• Pause large-scale, automated in-place feature upgrades for 802.1X-dependent endpoints until mitigations are embedded in your deployment sequence.
• Implement pre-upgrade backups of C:\Windows\dot3svc\Policies and insert a post-upgrade restoration / gpupdate / dot3svc restart step in your task-sequence.
• Establish remediation VLANs or non-802.1X ports at every site to guarantee a recovery path.
• Test certificate re-enrollment automation with your CA and include those scripts in remediation playbooks if private-key migration fails.
• Push this issue through your Microsoft support channel and request an authoritative engineering response and a supported fix or KB that eliminates manual recovery steps.

Enterprises must treat this not as a mere inconvenience but as a deployment-failure mode that demands policy, tooling, and people changes to prevent widespread outages. The best protection is predictable preparation: back up dot3svc policies, stage upgrades, and ensure a simple, documented recovery path for every affected user device.

---

Source: cyberpress.org Windows 11 Upgrade from 23H2 to 25H2 Reportedly Disrupts Internet Access