This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Before you create a provisioning XML that will change security settings, you must take several things into consideration, including certificates and the level of access that you want to allow.

For information about security policies that can be configured for Windows Mobile devices see Security Policiesand Security Policy Settings.

For considerations for provisioning XML that is not security related, see Provisioning XML Considerations.


Do you want to allow unsigned .cab files to be installed on the device?

Yes or no. The Unsigned CABS Policy determines whether unsigned .cab files can be installed on the device.

For more information, see Security Policy Settings.

Do you want to allow unsigned programs or unsigned packages to run?

Yes or No. The Unsigned Applications Policy determines whether unsigned applications are allowed to run on a device. This policy determines the level of access assigned to an unsigned application. Single-tier mode allows full access to all programs, whereas two-tier mode allows full access only to programs signed by a privileged certificate.

For more information, see Security Policy Settings.

If Yes, consider the following:

  • Do you want user confirmation before installing or running unsigned programs?

    The Unsigned Prompt Policy configures whether the user is prompted to accept or reject unsigned .cab, theme, .dll, and .exe files.

    For more information, see Security Policy Settings.

Ensure that you have the appropriate signing certificates.

You may need two signing certificates. It is highly recommended that you install at least one privileged and one standard certificate.

Know the b64-encoded certificates used on the device. This information will be used to verify that applications are signed with privileged certificates before allowing access to device system files and APIs.

The root certificate used for SSL is generally not required because root certificates of all well-known Certification Authorities (CAs) are already in the root store.

The following table shows common questions about certificates.

Consideration Description

Which certificates are needed on the device?

OEMs, mobile operators, and application developers use certificates to sign applications and files that run onWindows Mobile devices.

All OEMs and mobile operators currently include the Mobile2Market standard certificates on the devices they ship. Most OEMs and mobile operators also include the Mobile2Market privileged certificates.

For more information, see Signing an Application or Cabinet File for Release to the Public.

How are certificates installed and removed in the ROM?

Only privileged processes can install certificates. Therefore, the device manager (the OEM or mobile operator) must set up a developer program that can be used to install certificates if Market-2-Market certificates are not available.

Do you want your Windows Mobile Standard device to have greater flexibility in how applications are allowed to run on the device?

The Privileged Application policy specifies which security model, one tier or two tier, is implemented on the device.

This policy applies only to Windows phones.

The following table describes this security model.

Security model Description

One tier

Distinguishes between signed and unsigned applications.

Applications are either allowed to run or not allowed to run.

Two tier

Distinguishes between Privileged and Normal applications:

  • Signed applications running privileged can access every aspect of the device.

  • Signed applications running Normal cannot access some registry keys and some system APIs.

For more information about security models, see Windows Mobile Device Security Model.

Security Policies and Roles

Security roles determine access to Windows Mobile device resources. The security role is based on the message origin and how the message is signed.

For information about security roles, see Security Roles.

Consider the following before changing security policies or roles. You may need to use this information when creating the provisioning XML file to change policies or roles.

Who should have the role of device manager?

The Manager role allows unrestricted access to system resources. If the device is bootstrapped to allow over-the-air (OTA) client provisioning, the TPS server has the Manager role.

You can use the Grant Manager Policy to grant system administrative privileges (Manager role) to other security roles without modifying metabase role assignments. For more information, see Security Policy Settings .

The Metabase configuration service provider is set to the Manager role by default. Changing this role could elevate privileges, making the metabase less secure.

Who should have the role of AuthenticatedUser?

You can use the Grant User Authenticated Policy to grant AuthenticatedUser privileges to other security roles. For more information, see Security Policy Settings.

What level of permission do you want to require for creating, modifying, and deleting a privileged proxy?

The Trusted WAP proxy policy specifies the level of permission required to create, modify, or delete a privileged proxy.

WAP proxies are configured using the PXLOGICAL characteristic inside of a WAP provisioning document. A WAP proxy is privileged when the TRUST parm is specified inside of the PXLOGICAL characteristic.

For more information, see Security Policy Settings.

Do you want applications to automatically run from an MMC card?

The Auto Run policy identifies whether applications stored on a multimedia card (MMC) will automatically run when inserted into a device.

For more information, see Security Policy Settings.

Do you want to identify which DRM rights messages are accepted on a Windows Mobile Professional or Windows Mobile Classic device?

The DRM Security policy identifies which DRM rights messages are accepted by the DRM engine based on the role assigned to the message. DRM5 is required for all Windows Mobile Professional and Windows Mobile Classic devices and is used by Microsoft Reader and other applications to authenticate DRM5 secured content. File-Based Digital Rights Management (FDRM) describes a systematic approach to protecting digital-based content for files such as audio, video, and image files.

The default policy limits the messages processed by the FDRM engine and requires that rights are sent from a source privileged or authorized by a network's privileged push gateway.

For more information, see Security Policy Settings.

Do you want to set the maximum number of times a user is allowed to try a WAP user PIN-signed OTA provisioning message?

The Message Authentication Retry Number Policy identifies the maximum number of times the user is allowed to try authenticating a Wireless Application Protocol (WAP) OMA Client Provisioning user PIN-signed message.

For more information, see Security Policy Settings.

Do you want to want to limit the OTA OMA Client Provisioning messages based on the security roles assigned to message?

OTA provisioning policy identifies which OTA OMA Client Provisioning messages the Push Router sends to the configuration host based on the roles assigned to the messages. The Configuration Host is the component that is responsible for loading and unloading Configuration Manager.

For more information, see Security Policy Settings.

Which policies are relevant for themes and ring tones?

The security policies in Windows Mobile Standard allow only the manager of the phone to make changes to the configuration and installed software, including sound files such as ring tones.

The Unsigned Themes policy indicates whether theme files can be installed on a device. The theme files are used for processing Home screens.

Unsigned Prompt policy indicates whether a user is prompted to accept or reject unsigned files such as themes.

For more information about these policies, see Security Policy Settings.

See Also