Auditing Windows Delivery Optimization: The Peer-to-Peer Update Surface Nobody Locks Down

Windows Delivery Optimization turns every endpoint into a P2P update peer. Here is how it widens your attack surface, leaks bandwidth and metadata, and how to audit and lock it down.

Delivery Optimization (DO) is one of the most invisible services in Windows. It was introduced in Windows 10 to solve a real problem: instead of every machine pulling the same multi-gigabyte cumulative update from Microsoft's CDN over your WAN link, DO lets endpoints share update payloads with each other over the LAN — and, by default, with peers across the public internet. Almost nobody configures it. It ships on, it works quietly, and it quietly turns every workstation into a content distribution node. From a security engineer's chair, that default is worth a hard look.

What Delivery Optimization actually does

DO runs as the DoSvc service and brokers downloads for Windows Update, Microsoft Store apps, Defender definition updates, Office click-to-run, and increasingly Intune-delivered Win32 apps. When a machine needs a payload, it asks Microsoft's DO cloud service which peers already hold the blocks it needs, then pulls those blocks directly from other machines. The peering scope is governed by DODownloadMode:

0 (HTTP only) — no peering; classic CDN download.
1 (LAN) — peer only with machines on the same NAT/subnet.
2 (Group) — peer within a defined group (AD site, domain, or a custom Group ID).
3 (Internet) — peer with any machine on the public internet. This is the consumer default on many SKUs.
99 (Simple) / 100 (Bypass) — DO disabled or bypassed entirely.

The single most important audit question is: which mode is each endpoint running? A fleet sitting on mode 3 is exchanging update blocks with strangers.

Why this is a security problem, not just a bandwidth one

The integrity story is genuinely good: DO verifies every block against Microsoft-signed hashes, so a malicious peer cannot inject tampered update content — a bad block is simply discarded and refetched. That is the reassuring part, and it is worth stating plainly. The real risks live around the edges:

Metadata and network mapping. To peer, a machine advertises which content it holds and negotiates with other peers. On mode 3 that conversation reaches the internet, exposing outbound connections and timing that help an observer infer patch levels and fleet composition.
Unexpected outbound/inbound flows. DO opens listener ports (TCP 7680 for peer traffic, UDP 3544 for Teredo when internet peering is on). Firewall reviewers who don't know DO exists see mystery listeners and either ignore them or punch holes to "fix" update failures.
Cache as a staging area. The DO cache under C:\Windows\SoftwareDistribution\DeliveryOptimization holds large opaque files. It is not an exploit by itself, but it is exactly the kind of trusted, ignored directory attackers like to hide artifacts near.
Data exfiltration cover. P2P update chatter is legitimate background noise. The more of it you allow, the easier it is for malicious traffic to blend in.

Auditing the current state

Windows ships a PowerShell module for DO. Start with what each machine is actually doing:

Get-DeliveryOptimizationStatus | Format-Table FileId, BytesFromPeers, BytesFromHttp
Get-DeliveryOptimizationPerfSnap

Then confirm the configured mode and the effective policy. The registry is the source of truth when a GPO or Intune policy is applied:

Get-DOConfig -Verbose
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization" /v DODownloadMode
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DeliveryOptimization\Config"

If DODownloadMode is absent, the OS is using its SKU default — which you should treat as "internet peering possible until proven otherwise." Also check whether the listener is live:

Get-NetTCPConnection -LocalPort 7680 -ErrorAction SilentlyContinue

A sane hardening baseline

DO is useful — don't reflexively kill it and drag your WAN back to 2015. Right-size the peering scope instead:

Never run mode 3 on managed endpoints. Set DODownloadMode to 1 (LAN) for flat networks or 2 (Group) with an explicit DOGroupId for multi-site orgs. Reserve 0 for isolated/high-security machines that must not peer at all.
Pin the peering boundary. With mode 2, set DORestrictPeerSelectionBy = 1 (subnet) or 2 (local peer discovery only) so "Group" can't silently widen.
Confirm the firewall matches intent. If you're on mode 0/1, TCP 7680 and Teredo should not be reachable from outside the local segment.
Cap the cache and age. DOMaxCacheSize / DOMaxCacheAge keep the trusted-but-opaque directory from ballooning.

Delivery Optimization is a case study in "secure by verification, risky by default scope." The bytes are safe; the reach is the problem. Shrink the reach and you keep the WAN savings without the internet-facing peer surface.

Where WinSentinel fits

WinSentinel treats DO as a first-class audit target rather than a footnote. On any single machine, the free agent reads the effective DODownloadMode, peer-selection restriction, listener state, and cache configuration, then flags mode 3 and any unexpected 7680/Teredo exposure as findings — with the exact registry remediation inline. That is full power on one box, no limits, all modules included.

Across an organization, the Pro tier's central node rolls those per-machine findings into a fleet view: which sites drifted back to internet peering after a reimage, which endpoints opened a peer listener they shouldn't have, and whether your DO baseline holds after every Patch Tuesday. When a node regresses to mode 3, you get a drift alert instead of discovering it in a firewall log six months later. Configuration this quiet is exactly the kind that benefits from continuous, automated auditing — because nobody is ever going to notice it by hand.