CDM and the Windows Push Notification Services (WNS)

This article explains how CDM uses Microsoft's Windows Push Notification Services (WNS), what Microsoft is responsible for, what our cloud service IAM Notify knows and does not know, and what you can do to harden the Windows environment.

How WNS works at a high level

WNS is a Microsoft-hosted notification broker. The Windows device does not expose a public listener that our service or Microsoft calls directly. Instead, the Windows client obtains a channel from Microsoft and maintains communication with Microsoft over outbound HTTPS. When our service later needs to signal that something has changed on a specific drive, it sends the notification to Microsoft's WNS cloud endpoint, and Microsoft routes that notification to the correct Windows device and application.

WNS is not an inbound service opened on the machine. The trust boundary sits at Microsoft’s cloud notification infrastructure, not at a hosted endpoint on the device.

1. WNS uses outbound HTTPS rather than inbound machine access

The Windows device communicates with Microsoft over outbound HTTPS. This matters because it means there is no need to open an inbound connection directly to the machine in order to deliver a notification. The device participates in the WNS system by requesting and refreshing a notification channel from Microsoft and by receiving notifications through Microsoft's own service path.

From a security perspective, this is an important distinction. The device is not publishing a reachable endpoint on the network, instead, the device running CDM is using standard outbound web connectivity to Microsoft infrastructure, and Microsoft is responsible for brokering delivery to the right application instance.

Microsoft describes WNS as a cloud-based notification service for Windows apps and documents that apps request a notification channel from WNS before notifications can be sent. For more information, see Windows Push Notification Services (WNS) overview on Microsoft Learn.

2. Every app instance receives a time-limited channel URI

When CDM loads, it requests a WNS channel from Microsoft. Microsoft returns a channel URI. This channel URI is a long, non-guessable identifier that represents a route through Microsoft's WNS cloud infrastructure to a specific app instance on a specific machine for a limited amount of time.

It is important to be clear about what this URI is and what it is not:

• It is not a URL that points to the machine.

• It is not a direct socket or inbound listener on the device.

• It is a Microsoft-managed cloud endpoint that WNS uses for message routing.

• It is temporary and must be refreshed periodically by the application.

Microsoft do not publish exact lifetime for the token issued within the URI. However, it's documented that they:

1. Are short-lived

2. Can expire at any time

3. Must be treated as ephemeral tokens

In practical terms, the channel URI functions like a temporary routing address inside Microsoft's notification platform. Our cloud service stores that routing address and uses it later if it needs to notify the application that a change has happened on a subscribed drive.

Our service never has any information on what changes, including but not limited to (names, metadata, content, or user data). The only information we have is a remote storage endpoint identifier; we know something has changed on driveId, but we don't know what.

3. Microsoft validates the sender before accepting the notification

Before Microsoft will accept a push notification for delivery through WNS, the sender must authenticate. In our implementation, the sending service is IAM Notify. IAM Notify authenticates using our registered Azure application to send WNS notifications. This is a part of the trust model: Microsoft does not simply relay messages from any unauthenticated caller.

4. End-to-end flow in our implementation

The full sequence below shows what happens from CDM launch through to a 'check for change' request after receiving a notification:

1. CDM starts and after its normal routines will request a WNS channel from Microsoft.

2. Microsoft returns a channel URI for that app instance.

3. When the application detects that a local drive or a specific endpoint in dynamic drive is in use, the user subscribes for change notifications on that remote endpoint and passes this along with the channel URI to IAM Cloud.

4. When a change occurs in the remote drive, it informs IAM Notify that something on the specific remote endpoint has changed.

5. At that point, IAM Notify knows that something changed on the remote endpoint, it also knows all channel URIs (CDM instances) that have registered to receive a notification for this endpoint.

6. IAM Notify sends an authenticated notification request to Microsoft WNS for every registered client associated with that endpoint and tenant.

7. Microsoft WNS validates the sender, accepts the request, and routes it through Microsoft's own cloud infrastructure.

8. The Windows Push Notification Service on the device informs CDM and it will then perform a delta to get the latest information to show the user.

This design keeps the push message itself small and removes business data flowing through the notification channel.

5. Hardening the Windows environment

WNS itself already relies on Microsoft-managed authentication, app identity, and outbound connectivity. Even so, customers that want tighter control can harden the device and network so that the environment is restricted to approved applications and approved Microsoft endpoints.

Restrict which applications can run

The most effective control is to use Windows Defender Application Control (WDAC), AppLocker, or other application controlling software so that only approved, signed applications are allowed to execute. This matters because if an unapproved application cannot run, it cannot request its own notification channel and cannot participate in WNS on that machine.

• Allow only approved publishers or approved packaged apps.

• Block unknown or unapproved applications from running.

• Prefer publisher-based rules for managed enterprise deployment.

Restrict outbound network access to WNS

Firewall or proxy policy can be used to allow outbound HTTPS access only to the Microsoft WNS endpoints required by approved clients. This helps verify that notification traffic is going only to Microsoft's infrastructure and not to arbitrary third-party destinations.

• Allow outbound HTTPS to the Microsoft WNS endpoint patterns documented by Microsoft.

• Log and monitor outbound traffic to those endpoints.

• Use proxy or firewall policy to enforce least privilege network access where appropriate.

Practical hardening summary: Restrict which applications can execute, restrict which Microsoft endpoints can be reached, protect cloud-side sender credentials, and monitor both registration and delivery behavior.

6. References:

• Windows Push Notification Services (WNS) overview: Microsoft overview of WNS, app channels, and cloud-based delivery.

• Push notification quickstart: Microsoft guidance on requesting a channel URI and sending notifications.

• Send a notification request with WNS: Microsoft documentation covering WNS request format and authenticated sending.

• Windows Defender Application Control: Microsoft documentation on restricting which applications can run.

• WNS firewall allowlist configuration: Microsoft guidance for network allow-listing of WNS traffic.

In summary, our use of WNS is a brokered, outbound, cloud-routed notification model. The device talks to Microsoft, our service talks to Microsoft, and Microsoft is responsible for securely delivering the signal to the correct application instance. The notification is a prompt to re-check the drive, not a carrier for user content.