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

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

With WIP, organizations can define precise directives that determine which apps can open company documents, if copying content to the clipboard and paste it into another context, or if it crashes altogether. Thanks to its integration with device management (MDM) and application management (MAM), WIP is versatile in BYOD scenarios and on fully managed devices, minimizing the impact on the user's personal data.

What is Windows Information Protection (WIP)

In essence WIP is a set of features Windows solutions aimed at protecting corporate information on desktops, portable, tablets, and phones that the organization manages through MDM or, where applicable, only at the app level with MAM. Starting in Windows 10, version 1607, these capabilities allow you to enforce protection policies on corporate data without interfering with or damaging the user's private files.

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

For MDM-enrolled devices, the typical flow is clear: the user registers the device on the organization's platform and the administrator delivers the directives through 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 installing those apps The user receives the associated policy.

When the device is unenrolled from MDM or the user uninstalls MAM-managed apps, administrators can selectively delete corporate data of the team. This access revocation affects files encrypted under WIP, eliminating the risk of sensitive documents are exposed beyond the company's control.

How WIP works on applications

If an application is in the policy's allow list, all data generated under a business context is subject to protection: this may mean that if the user's access is revoked, lose access to that app's corporate data. This logic fits with purely business apps, but not with those that users use for both work and personal activities.

For those cases, Microsoft recommends developing enterprise-enabled applications (enlightened/enterprise-enabled), capable of intelligently distinguishing between what is corporate and what is personal. This way, the app applies the policy only to what is appropriate and preserves integrity of the user's private data, avoiding inconveniences such as unnecessary prompts or unjustified blocks.

Additionally, by enabling an app with the WIP APIs, it is possible personalize the experience- For example, if the policy allows pasting business data into a personal document, the app can avoid asking each time and display it instead. own informative messages when it detects certain user actions.

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

Apps not enabled for enterprise: when and how

If you are going to create one line of business (LOB) application intended for corporate use only, you may not need to enable it with the WIP APIs. However, it is a good idea to test it under policy to confirm that works correctly and does not accidentally encrypt the user's personal files such as metadata, images, or other auxiliary resources.

In the case of Windows desktop applicationsIt's good practice to launch the app, use it, unenroll the device from MDM, and verify that it can be launched again. If any critical files are encrypted by WIP and become inaccessible, the application might not startAfter testing, it's recommended that you add the compatibility flag to your project so that Windows can protect your business data for you and not interfere with your personal data:

MICROSOFTEDPAUTOPROTECTIONALLOWEDAPPINFO
EDPAUTOPROTECTIONALLOWEDAPPINFOID
BEGIN 0x0001
END

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

To UWP applications that will fall within the scope of a MAM policy, enabling them is essential. While not always required in MDM, in environments with organization consumers, it is difficult to predict which management system will be used, so enable the app ensures that it will work correctly in both contexts.

Integration with Microsoft Enter ID and Workplace Join (WPJ)

WIP integrates with the Microsoft Sign In ID service for both the user and the device, during enrollment and policy download. On personal devices, it is used Workplace Join (WPJ): 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, is registered in MDM. In general, 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 be linked to Entra ID and be administered with MDM. A practical detail: standard (non-administrator) users can perform MAM registration directly, which simplifies adoption.

Users can add their Entra account from a compatible app (for example, applications of Microsoft 365 current) or from Settings in Account > Access work or schoolThis workflow helps WIP determine the corporate context to implement appropriate protection on a day-to-day basis.

Types of applications under WIP and how they behave

To protect user-owned apps on personal devices, WPJ limits WIP enforcement to two categories: enabled applications (capable of differentiating between corporate and personal data) and compatible apps (which inform Windows that they do not handle personal data, and therefore Windows can protect business content on their behalf).

Compliant applications must include self-protection marking information in their resources, so that Windows knows that it can apply WIP to the company data they process, without affecting the rest. This mark is the same as that indicated for desktop apps and guarantees a consistent behavior in MAM deployments.

Prepare your Microsoft Entra tenant for MAM

MAM registration requires the provider to publish their management application in the Microsoft Gallery. Typically, the same cloud-based management app is used for both MDM and MAM; if it already exists for MDM, you must update it with the URLs registration and the MAM-specific terms of use.

Depending on the architecture of the company, there may be one or two suppliers: If MAM and MDM are served by the same person, a single administration application will suffice; if they are different, they will need to be configured two applications In Entra ID, one for MAM and one for MDM. This keeps the enrollment paths and policy distribution separate in each case.

MAM Enrollment: Protocol, Authentication, and Example

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

An example of provisioning XML for MAM it 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 probe node is not defined (Poll), the device will perform the check every 24 hours by default, which sets the pace of policy updates 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 with There based on customer feedback, it is therefore advisable to review the current documentation before deploying.

Regarding blocking controls, MAM supports MDM-like policies using the area Policy CSP DeviceLock and the CSP PassportForWork. It is not recommended to combine EAS and MAM policies on the same device, but if this happens, Windows evaluates whether the MAM policies comply with EAS and, if so, notifies compliance to allow mail synchronization.

If the device does not comply, EAS may apply its own policies (requires administrator rights) and the effective set will be a superset of both. If a device with EAS is later enrolled in MAM, the two policy groups 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 of client certificates.

Windows does not support applying MAM and MDM simultaneously on the same device. If the administrator allows it, users can migrate from MAM to MDMTo do this, you need to configure the MDM detection URL in the CSP. DMClient; After the MDM policies have been handed over and fully implemented, the MAM policies are retired.

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

When the MAM device is ready for switching, the user will see the link "Enroll in device management only" in Settings > Accounts > Work or school access. Selecting it and entering credentials will enable registration move to MDM and the user's Microsoft account is not affected.

Citrix XenMobile Management: WIP Policy and Settings

In XenMobile (Citrix), WIP —previously called Enterprise Data Protection (EDP)— is managed as a device policy for Windows 10/11. It is possible to define the applications with WIP and the level of demand, 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 (they do not access company data) or exempt (They can read company data but not create or modify it.) Additionally, the policy supports three protection modes: Silent (audit without blocking), Replace (warns and allows cancellation) and Block (prevents insecure sharing), next to the option Disabled.

To exclude apps with known compatibility issues, Microsoft provides a AppLocker XML recommended. When imported into XenMobile, it is combined with the desktop and store app settings within the policy that is pushed to the device, helping to avoid conflicts in real-life 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 ask for a password and generate a .cer and a .pfx; then, in the XenMobile console, import the .cer file under Settings > Certificates and apply it to Windows 10/11 devices. With the policy in place, you'll see WIP icons in apps and files, and if the user tries to copy or save protected content to an unprotected location, they will appear warnings or blocks depending on the level of demand.

WIP with Dropbox for teams

WIP can be combined with the desktop app of Dropbox on Windows 10 or later. After setting up your device, add Dropbox to your account. allowed list from business management software: the application synchronizes encrypted files within your organization's WIP-managed domain.

New files added to Dropbox accounts from computers with WIP will be protected by defaultSyncing 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 can't use, will not sync. This integration is only available in team accounts from Dropbox.

Compatibility, requirements and practical notes

Remember that WIP applies to Windows 10, version 1607 or later, and that its support is integrated into the system. In personal environments, it is common for the user do not register the device In MDM, MAM makes the difference by controlling specific apps and providing them with policies without managing the entire team.

To add a secondary Microsoft work account and register the device in WPJ, the user can do so from Microsoft 365 apps or from Settings > Accounts > Access to work or school. This action establishes the corporate identity on the computer, allowing WIP to classify and protect traffic, files, and operations consistently.

Binary marking and AppLocker example

Marking binaries as Allowed for WIP (EDP) tells Windows that it can protect business data on behalf of the app without interfering with personal data. An example of a flag on resources is the one shown above (EDPAUTOPROTECTIONALLOWEDAPPINFO), and you can also manage the scope with rules. AppLocker 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 serve to understand how integrate AppLocker with WIP in an application control strategy, precisely defining which binaries can process corporate data and under what conditions.

WIP offers a realistic balance between security and productivity: Allows IT to set clear policies around 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 flagging, and flexible administration is a solid foundation to start with.