What is Windows Information Protection (WIP) and how to apply it in your company

Windows Information Protection (WIP) is a technology included in Windows 10 and later versions that helps prevent data leaks without disrupting daily work. Simply put, it allows you to separate and protect corporate data on both personal and business devices, controlling how that data is shared, copied, or moved between applications and networks.

With WIP, organizations can define precise policies that determine which apps can open company documents, whether copying content to the clipboard and pasting it in another context is allowed, or whether it should be blocked altogether. Thanks to its integration with Device Management (MDM) and Application Management (MAM), WIP is versatile in BYOD scenarios and fully managed devices, minimizing the impact on users' personal data.

What is Windows Information Protection (WIP)

Essentially, Windows Information Protection (WIP) is a set of Windows features designed to protect corporate information on desktops, laptops , tablets, and phones that the organization manages via MDM or, where appropriate, only at the application level with MAM. Since Windows 10, version 1607, these capabilities allow for the application of protection policies to corporate data without mixing or damaging user files.

Using MDM or MAM, an administrator defines the list of allowed applications and the rules for data usage. If an app is included in the policy, everything it creates or manipulates within the corporate context is subject to the defined restrictions: for example, copying and pasting from a company document to a personal one can be blocked or require a warning to the user, and elements such as access to VPN networks or sharing between apps are also controlled.

On devices enrolled in MDM, the typical flow is straightforward: the user registers the device on the organization's platform, and the administrator delivers the policies via Microsoft Intune or System Center Configuration Manager (SCCM). For unenrolled devices (BYOD), MAM allows policies to be applied directly to specific apps, so that when the user installs those apps, they receive the associated policy.

When a device is deactivated from MDM or the user uninstalls apps managed with MAM, administrators can selectively erase corporate data from the device. This revocation of access affects files encrypted under WIP, eliminating the risk of sensitive documents being exposed outside of company control.

How WIP works on applications

If an application is on the policy's allow list, all data generated within a business context is subject to protection. This can mean that if a user's access is revoked, they lose access to that application's corporate data. This logic applies to purely business apps, but not to those that users use for both work and personal activities.

For these cases, Microsoft recommends developing enterprise-enabled applications , capable of intelligently distinguishing between corporate and personal data. This way, the app applies the policy only where appropriate and preserves the integrity of the user's private data, avoiding annoyances such as unnecessary prompts or unjustified blocks.

Furthermore, by enabling an app with the WIP APIs, it is possible to customize the experience : for example, if the policy allows pasting business data into a personal document, the app can avoid asking every time and instead display its own informational messages when it detects certain user actions.

For developers, there are specific guides: UWP applications in C# and desktop applications in C++ can rely on WIP's technical documentation to implement context detection, data labeling, and compliance with IT-defined rules.

Apps not enabled for enterprise: when and how

If you're creating a line-of-business (LOB) application intended solely for corporate use, you might not need to enable it with the WIP APIs. Even so, it's advisable to test it under policy to confirm it functions correctly and doesn't accidentally encrypt user files such as metadata, images, or other auxiliary resources.

For Windows desktop applications , it's good practice to launch the app, use it, unenroll the device in MDM, and verify that it can be launched again. If any critical files are encrypted by WIP and become inaccessible, the application might not start . After testing, it's recommended to add the compatibility flag to the project so that Windows protects your business data and doesn't interfere with your personal data.

MICROSOFTEDPAUTOPROTECTIONALLOWEDAPPINFO
EDPAUTOPROTECTIONALLOWEDAPPINFOID
BEGIN 0x0001
END

This marking is not mandatory for policies deployed via MDM , but it is mandatory in MAM scenarios , where management is applied to specific applications without registering the entire device.

For UWP apps that will fall under the scope of a MAM policy, enabling them is essential. While not always required in MDM, in environments with enterprise consumers it's difficult to predict which management system will be used, so enabling the app ensures it will function correctly in both contexts.

Integration with Microsoft Enter ID and Workplace Join (WPJ)

WIP integrates with the Microsoft Entra ID identity service for both the user and the device during enrollment and policy downloads. On personal devices, Workplace Join (WPJ) is used : the user adds their work or school account as a secondary account, keeping their personal account as the primary one, and the device is registered with WPJ.

If the device joins a Microsoft Entra ID, it's enrolled in MDM . Generally, a device with a personal account as the primary account is considered a personal device and should be registered with WPJ; corporate devices, on the other hand, must join an Entra ID and be managed with MDM . A practical detail: standard users (non-administrators) can enroll in MAM directly, simplifying adoption.

Users can add their Entra account from a compatible app (such as current Microsoft 365 apps ) or from Settings under Account > Work or school access . This workflow makes it easier for WIP to determine the corporate context and apply appropriate protection on a daily basis.

Types of applications under WIP and how they behave

To protect user-owned apps on personal computers, WPJ limits the application of WIP to two categories: enabled apps (capable of differentiating between corporate and personal data) and compliant apps (which inform Windows that they do not handle personal data, and therefore Windows can protect corporate content through them).

Compatible applications must include self-protection marking information in their resources so that Windows knows it can apply WIP to the company data they process without affecting other data. This marking is the same as that used for desktop apps and ensures consistent behavior in MAM deployments.

Prepare your Microsoft Entra tenant for MAM

MAM enrollment requires the provider to publish their management application in the Microsoft Entra gallery. Typically, the same cloud-based management app is used for both MDM and MAM; if an existing app already exists for MDM, it must be updated with the MAM-specific enrollment URLs and terms of use.

Depending on the company's architecture, there may be one or two providers : if the same provider serves both MAM and MDM, a single management application will suffice; if they are different, two applications will need to be configured in Entra ID, one for MAM and one for MDM. This keeps the enrollment paths and policy distribution separate for each case.

MAM Enrollment: Protocol, Authentication, and Example

MAM enrollment is based on the MAM extension of the [MS-MDE2] protocol and supports Microsoft Entra Federated ID as its authentication method . There are differences compared to MDM: there is no MDM discovery, the APPAUTH node in DMAcc CSP is optional, and neither a client authentication certificate nor [MS-XCEP] is used ; instead, the client uses an Entra token , and synchronization sessions are established over one-way TLS/SSL with server authentication.

An example of provisioning XML for MAM could be:

<wap-provisioningdoc version="1.1">
  <characteristic type="APPLICATION">
    <parm name="APPID" value="w7" />
    <parm name="PROVIDER-ID" value="MAM SyncML Server" />
    <parm name="NAME" value="mddprov account" />
    <parm name="ADDR" value="http://localhost:88" />
    <parm name="DEFAULTENCODING" value="application/vnd.syncml.dm+xml" />
  </characteristic>
</wap-provisioningdoc>

If a polling node is not defined , the device will perform the check every 24 hours by default, which sets the policy update rate in this management mode.

Supported CSPs and Device Lock/EAS Policies

WIP supports a specific set of CSPs (Configuration Service Providers) and blocks the rest in MAM scenarios; this list may change over time based on customer feedback, so it's advisable to review the current documentation before deploying.

Regarding blocking controls, MAM supports policies similar to MDM using the DeviceLock area of ​​the Policy CSP and the PassportForWork CSP . Combining EAS and MAM policies on the same device is not recommended, but if it occurs, Windows evaluates whether the MAM policies comply with EAS and, if so, reports compliance to allow mail synchronization.

If the device does not comply, EAS can apply its own policies (requires administrator rights ), and the effective policy set will be a superset of both. If a computer with EAS later enrolls in MAM, both policy sets will coexist, again with a combined effect.

Policy synchronization and switching from MAM to MDM

MAM policy synchronization is modeled after MDM , but the client uses Microsoft Entra tokens to authenticate to the service during synchronization cycles. This approach simplifies device-side authentication and reduces dependencies on client certificates.

Windows does not support applying MAM and MDM simultaneously on the same device. With administrator permission, users can migrate from MAM to MDM . This requires configuring the MDM discovery URL in the DMClient CSP ; after the migration and full application of the MDM policies, the MAM policies are rolled back.

Normally, removing WIP policies from the device revokes user access to protected documents (selective deletion) , unless the EDP.RevokeOnUnenroll setting is set to false. To prevent this deletion when switching from MAM to MDM, the administrator must ensure that: both policies (MAM and MDM) support WIP, the EDP Enterprise ID is identical in MAM and MDM, and EDP.RevokeOnMDMHandoff is set to false.

When the MAM device is ready for the switch, the user will see the "Enroll in device management only" link in Settings > Accounts > Work or school access. Selecting this link and entering credentials switches the enrollment to MDM , and the user's Microsoft Entra account remains unaffected.

Citrix XenMobile Management: WIP Policy and Settings

In XenMobile (Citrix), WIP—formerly called Enterprise Data Protection (EDP) —is managed as a device policy for Windows 10/11. It's possible to define which apps are subject to WIP and the level of enforcement, with a base list of common apps and the option to add more manually.

Applications can be marked as Allowed (read, create, and update company data), Denied (do not access company data), or Exempt (can read company data but cannot create or modify it). Additionally, the policy supports three protection modes: Silent (audits without blocking), Override (warns and allows override), and Block (prevents insecure sharing), along with the Disabled option.

To exclude apps with known compatibility issues, Microsoft provides a recommended AppLocker XML file . When imported into XenMobile, it's combined with the desktop and store app settings within the policy sent to the device, helping to avoid conflicts in real-world scenarios.

Key settings that can be configured in XenMobile for WIP:

• Protected domain names: Domains used by the user identity (the first acts as the primary business identity). Separated by "|".
• Data Recovery Certificate: DRA (EFS) certificate distributed via MDM to recover data from encrypted files; essential if you want unlock content in case of contingency.
• Network domain names: company perimeter domains; traffic to these domains is considered protected by WIP.
• IP ranges: corporate IPv4/IPv6 ranges; WIP treats them as safe destinations for share data.
• The IP range list is authoritative: If enabled, prevents automatic IP detection by Windows.
• Proxy servers: outbound proxies for enterprise resources; necessary to secure consistent access when the client is behind a proxy.
• Internal proxy servers: proxies used to connect to cloud resources; traffic via these proxies is treated as governance.
• Cloud resources: List of cloud resources protected by WIP, with optional assignment to an internal proxy.
• Revoke WIP certificate upon unregistration: revokes or retains local encryption keys upon unsubscribing.
• Show overlay icons: overlays the WIP icon over business files and corporate-only apps in Home.

To create the data recovery certificate (policy requirement), on the server with the XenMobile console, open a command prompt in any folder and run:

cipher /r:ESFDRA

The wizard will prompt for a password and generate a .cer and a .pfx file ; then, in the XenMobile console, import the .cer file under Parameters > Certificates and apply it to Windows 10/11 devices. With the policy in place, you'll see WIP icons on apps and files, and if the user attempts to copy or save protected content to an unprotected location, warnings or blocks will appear depending on the security level.

WIP with Dropbox for teams

WIP can be combined with the Dropbox desktop app on Windows 10 or later . After setting up the device, add Dropbox to the allow list of your enterprise management software: this will allow the application to sync encrypted files within your organization's WIP-managed domain.

New files added to Dropbox accounts from teams with WIP will be protected by default . Synchronization works normally as long as the Dropbox account is associated with a domain with valid access; if the file belongs to a domain that the account cannot use, it will not sync . This integration is only available for Dropbox team accounts .

Compatibility, requirements and practical notes

Remember that Windows IP applies to Windows 10, version 1607 or later , and that its support is integrated into the system. In personal environments, it's common for users not to enroll their devices in MDM; this is where MAM makes a difference by controlling specific apps and assigning them policies without managing the entire device.

To add a Microsoft work account as a secondary account and register the device with Workplace Gateway (WPJ), the user can do so from Microsoft 365 apps or from Settings > Accounts > Work or school access . This action establishes the corporate identity on the device, allowing WIP to consistently categorize and protect traffic, files, and operations.

Binary marking and AppLocker example

Marking binaries as Allowed for WIP (EDP) tells Windows that it can protect business data on behalf of the application without interfering with personal data. An example of this marking on resources is shown above (EDPAUTOPROTECTIONALLOWEDAPPINFO), and you can also manage the scope with AppLocker rules in XML.

An illustrative AppLocker rule snippet that combines editor and path rules might look like this, with a default rule that allows everything, a rule that denies WordPad, and a rule that allows Notepad:

<RuleCollection Type="Exe" EnforcementMode="Enabled">
  <FilePathRule Name="(Default Rule) All files" Description="" UserOrGroupS Action="Allow">
    <Conditions>
      <FilePathCondition Path="*" />
    </Conditions>
  </FilePathRule>
  <FilePublisherRule Name="WORDPAD.EXE, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupS Action="Deny">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="WORDPAD.EXE">
        <BinaryVersionRange LowSection="*" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Name="NOTEPAD.EXE, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupS Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="NOTEPAD.EXE">
        <BinaryVersionRange LowSection="*" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
</RuleCollection>

Although these examples are generic, they help to understand how to fit AppLocker with WIP into an application control strategy, precisely defining which binaries can handle corporate data and under what conditions.

WIP offers a realistic balance between security and productivity : it allows IT to establish clear policies for data, apps, and networks, respects user personal space, and integrates with Entra ID, MDM/MAM, and tools like XenMobile and Dropbox. If you need to protect information without slowing down your teams, this combination of policies, app tagging, and flexible management is a solid foundation to start with.