Intel ICPS Driver May Trigger OneNote and Microsoft 365 IPv6 Connection Resets

CircleID reported the findings on October 7, 2026. They come from a detailed incident report, an Intel Community post dated October 2, and a public evidence repository. No formal advisory from Intel or Microsoft has appeared so far. The technical detail, however, is specific enough to check against your own machines.

What the driver is reportedly doing​

The researcher's account centres on one kernel component. In the Intel Community post, the problem driver is IntcCo11X64.sys version 11.5.11.19, the "Intel Connectivity Traffic Control Callout Driver." It runs under the service INTCCoSvc and ships with ICPS 40.25.926.0. It works through Windows Filtering Platform (WFP) callouts on the outbound IPv6 transport and IP packet layers.

According to CircleID, the researcher's packet captures show the Intel driver letting the initial TCP handshake to proceed with a valid IPv6 Flow Label, then changes the field to zero in subsequent packets. The forum post describes the pattern this way:

• The SYN leaves the machine carrying the label that the Windows stack assigned.
• Every ACK and data segment after it goes out with the label set to 0.
• In one baseline capture, none of 42 post-handshake packets kept the original label.

The Samsung Community version of the report says the same thing. It states that the preinstalled ICPS build rewrites the IPv6 Flow Label of every TCP packet after the handshake.

Why one 20-bit field can break a connection​

The IPv6 header contains a 20-bit Flow Label field, and IPv4 has nothing equivalent. RFC 6437, the IETF's flow label specification, says a label of zero means a packet is unlabeled. It also says that once a non-zero label is set, it is expected to reach the destination unchanged. The RFC explicitly encourages using the label for stateless load distribution.

RFC 7098 applies the same idea to server load balancing. It says the label should be set to a constant value for a given traffic flow (such as an HTTP connection), and that this consistency is what makes it useful for load balancing.

In the researcher's diagnosis, Microsoft's edge relies on exactly that consistency. The tracking issue states that Microsoft's Azure Front Door hashes on the label, so those packets reach a different node and the connection is reset. The forum post offers supporting evidence: the SYN-ACK arrived with a hop limit of 47 and the RST with a hop limit of 49. The researcher reads that as two different machines answering.

A simpler way to picture it: you check in at a hotel desk, and halfway through your stay your room key gets reprogrammed for another floor. The new floor's staff has never heard of you and asks you to leave.

That load-balancer explanation is the researcher's analysis. Microsoft has not confirmed it in any material reviewed for this story. Treat it as a well-argued hypothesis backed by packet evidence, not as a vendor-confirmed root cause.

Section summary: On one Samsung laptop, the Intel driver appears to keep the flow label intact through the handshake and then zero it. Load balancers that hash on the label then send the rest of the connection to a server that never saw it start.

Symptoms: how this looks to users​

What makes this bug unpleasant is how it misleads people. The tracking issue lists OneNote desktop can't sync, Microsoft 365 sign-in fails with ERR_CONNECTION_RESET, and other sites reset too.

The forum post adds more detail:

• On the researcher's machine, between 60% and 100% of new IPv6 connections to Microsoft's edge were reset within one round trip. That covered OneDrive, OneNote and Microsoft 365 sign-in.
• OneNote desktop failed to sync for nearly three weeks, starting September 13, 2026. Notebooks opened as empty shells.
• Disabling ICPS restored syncing straight away.

IPv4 is not affected. As the evidence repository notes, IPv4 is unaffected, which is why the web and phone versions kept working and nobody could explain the failure. A help desk that sees OneNote working on a phone and in a browser will reasonably blame the desktop client. It might reset the cache, repair Office or reinstall. The researcher says none of those steps could have found this defect. A Microsoft support escalation reportedly ran for five weeks without identifying the cause.

Windows Update and the OEM catalog​

CircleID reports that the researcher's driver installation logs show Windows Update delivering ICPS build 40.25.926.173 on May 10, May 14 and June 13, 2026. Those dates come from the researcher's own logs, not from Microsoft. If they are accurate, removing the software once may not be enough.

The investigation also looked at Microsoft's Update Catalog. It found potentially affected ICPS packages listed under Samsung, Lenovo, VAIO, ASUS, HP, Dynabook and Huaqin. The researcher counted 1,086 ICPS entries from 19 companies, and only one matched the newer build that tested clean.

That number needs care. Catalog entries do not show how many PCs installed a package, whether every listed package has the same defect, or how many users actually saw failures. CircleID says this directly. The catalog finding points to a possible distribution problem. It does not measure how many devices or users are affected.

The October 7 A/B test​

On October 7, the researcher tested two builds on the same Samsung laptop against 34 sites:

That is a large improvement. Still, it is one device, one network (native IPv6 in Japan over NTT FLET'S IPoE) and the researcher's own choice of endpoints.

Intel's download page does list ICPS 50.26.623.243 for Windows 10 64-bit and Windows 11. It describes the release only as including "functional updates" and does not mention IPv6 or flow labels. The only basis for calling this build a fix is the researcher's test.

The timeline also moved quickly. On October 3, the evidence repository said No vendor fix yet. The newer build was tested only after that.

Earlier reports​

This problem may be older than this year's investigation. An Intel Community thread titled "Intel Connectivity Network Service is causing the ipv6 flowtable attribute set to 0" includes a reproduction PowerShell script. Its author notes that you must have ipv6 enable on nic (wireless/ethernet either one is fine).

The researcher's repository says Intel closed the inquiry for lack of a response. It also says Similar reports go back to 2021. The researcher's materials don't agree on when Intel was first told. One says September 2025 and another says November 2025. Either way, the mechanism appears to have been reported to Intel roughly a year ago. The incident page also says HP EliteBook users in that thread reported Microsoft 365 and SharePoint resets, and that one organization said Windows Update put the software back after they removed it.

How to check your own PC​

The researcher published a quick screening test. Run it in PowerShell:

1..10 | ForEach-Object { curl.exe -6 -sS -o NUL -w "%{http_code}`n" [Microsoft OneDrive Dev Center | APIs and app development](https://api.onedrive.com/) }

According to the tracking issue, Connection was reset errors on a PC that has ICPS installed point to this bug. This is a community diagnostic, not an official Intel or Microsoft tool. A clean result on one network does not rule the problem out on another, and the test needs working IPv6 to mean anything.

If you see resets, write down your laptop model, the installed ICPS version and your Windows build before you change anything.

Workarounds, and their risks​

The researcher's workaround. The forum post suggests stopping and disabling four services in services.msc:

• INTCCoSvc
• Intel Dynamic Bandwidth Management
• Intel Connectivity Network Service
• IntelConnect Service

The researcher's own testing explains why all four are listed. Stopping only the Dynamic Bandwidth Management service did not help: 1 of 10 connections succeeded. Stopping the callout driver together with the ICPS services gave 10 of 10 successful connections, with every label intact.

Installing Intel's generic build. Be careful with this one. Intel says ICPS is meant only for selected Intel Evo or vPro platforms (12th Gen Core or newer) with supported Intel Wi-Fi 6/6E or Wi-Fi 7 adapters. It requires Intel Wi-Fi and Management Engine drivers. Intel also recommends checking with your PC maker before installing generic software, because OEMs sometimes customize drivers.

Disabling IPv6. This is the bad option. CircleID points out that users who disable IPv6 to get things working are treating the symptom, when the real problem is software on the endpoint. IPv6 deployment loses ground every time that happens.

For IT admins: If your fleet includes Intel Evo or vPro laptops from the brands named above, add a flow-label check to your playbook for "intermittent Microsoft 365 resets." Watch whether Windows Update reinstalls ICPS after you remove it. Push your OEM account reps for a corrected package.

The bigger picture​

This is ultimately about software that changes network behavior without telling anyone. The researcher argues that Intel shipped an always-on kernel-level packet modifier that users never asked for and can't see, that OEMs preinstalled it, and that Windows Update signed and redistributed it.

To be fair to the vendors, the evidence so far comes from one investigator's detailed work, with supporting reports from earlier forum threads. Intel's newer build appears to fix the behavior even though its release notes say nothing about it. A vendor statement could still add context, such as which hardware IDs are actually affected.

Whatever happens next, the takeaway is clear. When a well-meaning "performance" driver breaks a basic rule of the protocol, the result is broken sync, confused help desks and a bit more distrust of IPv6. The flow label is supposed to stay unchanged from the first packet to the last, and on this evidence it is time to update the drivers that change it.