Certification requirements for Windows Desktop Apps (no admin rights because of apps)
Welcome!
The Windows platform supports a broad ecosystem of products and partners. Displaying the Windows logo on your product represents a relationship and a shared commitment to quality between Microsoft and your company. Customers trust the Windows brand on your product because it ensures that it meets compatibility standards and performs well on the Windows platform. Successfully passing Windows App Certification allows for your app to be showcased in the Windows Compatibility Center and you may display the certification logo on your site.
The Windows App Certification Program is made up of program and technical requirements to help ensure that third-party apps carrying the Windows brand are both easy to install and reliable on PCs running Windows. Customers value stability, compatibility, reliability, performance, and quality in the systems they purchase. Microsoft focuses its investments to meet these requirements for software apps designed to run on the Windows platform for PCs. These efforts include compatibility tests for consistency of experience, improved performance, and enhanced security on PCs running Windows software. Microsoft compatibility tests have been designed in collaboration with industry partners and are continuously improved in response to industry developments and consumer demand.
The Windows App Certification Kit is used to validate compliance with these requirements and replaces the any previous versions of the kit used to validate on Windows 7, Windows 8 or Windows 8.1. The Windows App Certification Kit is one of the components included in the Windows Software Development Kit (SDK) for Windows 10.
App eligibility
For an app to qualify for Windows 10 Desktop App Certification it must meet the following criteria and all the technical requirements listed in this document.
- It must be a standalone app
- It must run on a local Windows 10 PC
- It can be a client component of a certified Windows Server app
- It must be code and feature complete
- It must not communicate with Windows Store apps via local mechanisms, including via files and registry keys, except in the supported enterprise scenarios
- It must not jeopardize or compromise the security or functionality of the Windows system
- It must have a unique name and must not be trademarked by others
- All external components must be certified separately or be compliant with the Windows App Certification Kit
- It must have an opt-out option for any bundled apps
If the desktop app is submitted to the anti-virus and/or anti-spyware (i.e., antimalware) products category, it must comply with the ANTIMALWARE PLATFORM GUIDELINES. The WINDOWS 10 ANTIMALWARE API LICENSE AND LISTING AGREEMENT must have been signed and in effect before submission. The partner must be a member of, or have researchers that are members of and in good standing in one the organizations listed in the agreement. The functionality must be certified on Windows 10 by one the organizations listed in the agreement. The app must have been tested at least once in the last 12 months, and certified for detection and cleaning.
1. Apps are compatible and resilient
The times when an app crashes or stops responding cause much user frustration. Apps are expected to be resilient and stable and eliminating such failures helps ensure that software is more predictable, maintainable, performant and trustworthy.
- 1.1 Your app must not take a dependency on Windows compatibility modes, AppHelp message, and or any other compatibility fixes
- 1.2 Your app must have a compatibility manifest, and use the appropriate GUIDs for the supported versions of Windows
- 1.3 Your app must be DPI-aware by using the application's assembly manifest rather than by calling SetProcessDPIAware
- 1.4 Your app must not take a dependency on the VB6 runtime
- 1.5 Your app must not load arbitrary DLLs to intercept Win32 API calls using HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.
2. Apps must adhere to Windows security best practices
Using Windows security best practices will help avoid creating exposure to Windows attack surfaces. Attack surfaces are the entry points that a malicious attacker could use to exploit the operating system by taking advantage of vulnerabilities in the target software. One of the worst security vulnerabilities is the elevation of privilege.
Note that tests 2.1 2.6 are applicable only for desktop apps tested on Windows 7, Windows 8 or Windows 8.1.
- 2.1 Your app must use strong and appropriate
- to secure executable files
- 2.2 Your app must use strong and appropriate
- to secure directories
- 2.3 Your app must use strong and appropriate
- to secure registry keys
- 2.4 Your app must use strong and appropriate
- to secure directories that contain objects
- 2.5 Your app must reduce non-administrator access to services that are vulnerable to tampering
- 2.6 Your app must prevent services with fast restarts from restarting more than twice every 24 hours
Note: Access should only be granted to the entities that require it.
The Windows App Certification Program will verify that Windows Attack Surfaces are not exposed by verifying that ACLs and Services are implemented in a way that does not put the Windows system at risk.
3. Apps support Windows security features
The Windows operating system has many features that support system security and privacy. Apps must support these features to maintain the integrity of the operating system. Improperly compiled apps could cause buffer overruns that can, in turn, cause denial of service or allow malicious code execute.
- 3.1 Your app must not use AllowPartiallyTrustedCallersAttribute (APTCA) to ensure secure access to strong-named assemblies
- 3.2 Your app must be compiled using the /SafeSEH flag to ensure safe exceptions handling
- 3.3 Your app must be compiled using the /NXCOMPAT flag to prevent data execution
- 3.4 Your app must be compiled using the /DYNAMICBASE flag for address space layout randomization (ASLR)
- 3.5 Your app must not Read/Write the Shared PE Sections
4. Apps must adhere to system restart manager messages
When users initiate shutdown, they usually have a strong desire to see shutdown succeed; they may be in a hurry to leave the office and just want their computers to turn off. Apps must respect this desire by not blocking shutdown. While in most cases, a shutdown may not be critical, apps must be prepared for the possibility of a critical shutdown.
- 4.1 Your app must handle critical shutdowns appropriately
- In a critical shutdown, apps that return FALSE to WM_QUERYENDSESSION will be sent WM_ENDSESSION and closed, while those that time out in response to WM_QUERYENDSESSION will be terminated.
- 4.2 A GUI app must return TRUE immediately in preparation for a restart
- WM\_QUERYENDSESSION with LPARAM = ENDSESSION\_CLOSEAPP(0x1). Console apps can call SetConsoleCtrlHandler to specify the function that will handle shutdown notifications. Service apps can call RegisterServiceCtrlHandlerEx to specify the function that will receive shutdown notifications.
- 4.3 Your app must return 0 within 30 seconds and shut down
- WM\_ENDSESSION with LPARAM = ENDSESSION\_CLOSEAPP(0x1). At a minimum, app should prepare by saving any user data and state the information that is needed after a restart.
- 4.4 Console apps that receive the CTRL\_C\_EVENT notification should shut down immediately 4.5 Drivers must not veto a system shutdown event
Note: Apps that must block shutdown because of an operation that cannot be interrupted should explain the reason to the user. Use ShutdownBlockReasonCreate to register a string that explains the reason to the user. When the operation has completed, the app should call ShutdownBlockReasonDestroy to indicate that the system can be shut down.
5. Apps must support a clean, reversible installation
A clean, reversible, installation allows users to successfully manage (deploy and remove) apps on their systems.
- 5.1 Your app must properly implement a clean, reversible installation
- If the installation fails, the app should be able to roll it back and restore the machine to its previous state.
- 5.2 Your app must never force the user to restart the computer immediately
- Restarting the computer should never be the only option at the end of an install, uninstall or update. Users should have the opportunity to restart later.
- 5.3 Your app must never be dependent on 8.3 short file names (SFN) 5.4 Your app must never block silent install/uninstall 5.5 Your app installer must create the correct registry entries to allow successful detection and uninstalls
- Windows inventory tools and telemetry tools require complete information about installed apps. If you are using an MSI-based installer, MSI automatically creates the registry entries below. If you are not using an MSI installer, the installation module must create the following registry entries during installation:
- DisplayName
- InstallLocation
- Publisher
- UninstallString
- VersionMajor or MajorVersion
- VersionMinor or MinorVersion
- 5.6 The app must remove all of its entries from Add/ Remove Programs upon uninstall
6. Apps must digitally sign files and drivers
An Authenticode digital signature allows users to be sure that the software is genuine. It also allows one to detect whether a file has been tampered with, such as if it has been infected by a virus. Kernel-mode code signing enforcement is a Windows feature known as code integrity (CI), which improves the security of the operating system by verifying the integrity of a file each time the image of the file is loaded into memory. CI detects whether malicious code has modified a system binary file. Also generates a diagnostic and system-audit log event when the signature of a kernel module fails to verify correctly.
- 6.1 All executable files (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) must be signed with an Authenticode certificate
- 6.2 All kernel mode drivers installed by the app must have a Microsoft signature obtained through the Windows Hardware Certification program. All File System filter drivers must be signed by Microsoft.
- 6.3 Exceptions and Waivers
- Waivers will be considered only for unsigned third-party redistributables, excluding drivers. A proof of communication requesting a signed version of the redistributable(s) is required for this waiver to be granted.
7. Apps don't block installation or app launch based on an operating system version check
It is important that customers are not artificially blocked from installing or running their app when there are no technical limitations. In general, if apps were written for Windows Vista or later versions of Windows, they should not have to check the operating system version.
- 7.1 Your app must not perform version checks for equality
- If you need a specific feature, check whether the feature itself is available. If you need Windows 7, check for Windows 7 or later (>= 6.2). This way, your detection code will continue to work on future versions of Windows. Driver installers and uninstall modules should never check the operating system version.
- 7.2 Exceptions and Waivers will be considered for apps meeting the criteria below:
- Apps that are delivered as one package that also run on Windows 7, Windows 8, and Windows 8.1, and need to check the operating system version to determine which components to install on a given operating system.
- Apps that check only the minimum version of the operating system (during install only, not at runtime) by using only the approved API calls, and that properly list the minimum version requirement in the app manifest.
- Security apps (antivirus, firewall, etc.), system utilities (for example, defrag, backups, and diagnostics tools) that check the operating system version by using only the approved API calls.
8. Apps don't load services or drivers in safe mode
Safe mode allows users to diagnose and troubleshoot Windows. Drivers and services must not be set to load in safe mode unless they are needed for basic system operations of such as storage device drivers or for diagnostic and recovery purposes, such as anti-virus scanners,. By default, when Windows is in safe mode, it starts only the drivers and services that came preinstalled with Windows.
- 8.1 Exceptions and Waivers
- Drivers and services that must be started in safe mode require a waiver. The waiver request must include each applicable driver or service writing to the SafeBoot registry keys, and describe the technical reasons why the app or service must run in safe mode. The app installer must register all such drivers and services using these registry keys:
- HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network
Note: You must test these drivers and services to ensure that they function in safe mode without any errors.
9. Apps must follow User Account Control guidelines
Some Windows apps run in the security context of an administrator account, and apps often request excessive user rights and Windows privileges. Controlling access to resources enables users to be in control of their systems and protect them against unwanted changes. An unwanted change can be malicious, such as a rootkit taking control of the computer, or be the result of an action made by people who have limited privileges.. The most important rule for controlling access to resources is to provide the least amount of access standard user context necessary for a user to perform his or her necessary tasks. Following user account control (UAC) guidelines provides an app with the necessary permissions when they are needed by the app, without leaving the system constantly exposed to security risks. Most apps do not require administrator privileges at run time, and should be just fine running as a standard-user.
- 9.1 Your app must have a manifest that defines execution levels and tells the operating system what privileges the app requires in order to run
- The app manifest marking only applies to EXEs, not DLLs. This is because UAC does not inspect DLLs during process creation. It is also worth noting that UAC rules do not apply to Microsoft services. The manifest can be either embedded or external.
- To create a manifest, create a file with the name <app_name>.exe.manifest and store it in the same directory as the EXE. Note that any external manifest is ignored if the app has an internal manifest. For example:
- <requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess=""true|false""/>
- 9.2 Your app s main process must be run as a standard user (asInvoker).
- Any administrative features must be moved into a separate process that runs with administrative privileges. User facing apps, such as those accessible through the program group on the Start-Menu, and requiring elevation must be Authenticode signed.
- 9.3 Exceptions and Waivers
- A waiver is required for apps that run their main process with elevated privileges (requireAdministrator or highestAvailable). The main process is identified as the user s entry point to the app. Waivers will be considered for the following scenarios:
- Administrative or system tools with execution level set to highestAvailable, and/or requireAdministrator
- Only Accessibility or UI automation framework app sets the uiAccess flag to true to bypass the user interface privilege isolation (UIPI). To properly start app utilization, this flag must be Authenticode signed, and must reside in a protected location in the file system, namely Program Files.
10. Apps must install to the correct folders by default
Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user
- 10.1 Your app must be installed in the Program Files folder by default
- For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.
- 10.2 Your app must avoid starting automatically on startup
- For example, your app should not set any of the following;
- Registry run keys HKLM and, or HKCU under Software\Microsoft\Windows\CurrentVersion
- Registry run keys HKLM, and or HKCU under Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Start Menu AllPrograms > STARTUP
- 10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData 10.4 Your app s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\\<username>\\AppData 10.5 Your app must never write directly to the "Windows" directory and or subdirectories
- Use the correct methods for installing files, such as fonts or drivers.
- 10.6 Your app must write user data at first run and not during the installation in per-machine installations
- When the app is installed, there is no correct user location in which to store data. Attempts by an app to modify default association behaviors at a machine level after installation will be unsuccessful. Instead, defaults must be claimed on a per-user level, which prevents multiple users from overwriting each other's defaults.
- 10.7 Exceptions and Waivers
- A waiver is required for apps that write to the global assembly cache (GAC) .NET apps should keep assembly dependencies private, and store it in the app directory unless sharing an assembly is explicitly required.
11. Apps must support multi-user sessions
Windows users should be able to run concurrent sessions without conflict or disruption.
- 11.1 Your app must ensure that when running in multiple sessions either locally or remotely, the normal functionality of the app is not adversely affected
- 11.2 Your app s settings and data files must not persist across users
- 11.3 A user s privacy and preferences must be isolated to the user s session
- 11.4 Your app s instances must be isolated from each other
- This means that user data from one instance is not visible to another instance of the app. Sound in an inactive user session should not be heard in an active user session. In cases where multiple app instances use shared resources, the app must ensure that there is not a conflict.
- 11.5 Apps that are installed for multiple users must store data in the correct folder(s) and registry locations
- Refer to the UAC requirements.
- 11.6 User apps must be able to run in multiple user sessions (Fast User Switching) for both local and remote access 11.7 Your app must check other terminal service (TS) sessions for existing instances of the app
Note: If an app does not support multiple user sessions or remote access, it must clearly state this when launched from this kind of session.
12. Apps must support x64 versions of Windows
As 64-bit hardware becomes more common, users expect app developers to take advantage of the benefits of 64-bit architecture by migrating their apps to 64-bit, or that 32-bit versions of the app run well under 64-bit versions of Windows.
- 12.1 Your app must natively support 64-bit or, at a minimum, 32-bit Windows-based apps must run seamlessly on 64-bit systems to maintain compatibility with 64-bit versions of Windows
- 12.2 Your app and its installers must not contain any 16-bit code or rely on any 16-bit component
- 12.3 Your app s setup must detect and install the proper drivers and components for the 64-bit architecture
- 12.4 Any shell plug-ins must run on 64-bit versions of Windows
- 12.5 App running under the WoW64 emulator should not attempt to subvert or bypass Wow64 virtualization mechanisms
- If there are specific scenarios where apps need to detect whether they are running under the WoW64 emulator, they should do so by calling IsWow64Process.
Conclusion
As these requirements evolve, we will note the changes in the revision history below. Stable requirements are critical to doing your best work, so we will aim to ensure the changes we do make are sustainable and continue to protect and enhance your apps.
Thank you again for joining in our commitment to delivering great customer experiences.
Revision history
| Date | Version | Revision description | Link to document |
|---|---|---|---|
| Dec 20, 2011 | 1.0 | Initial draft of document for Preview. | |
| Jan 26, 2012 | 1.1 | Update to section #2. | 1.1 |
| May 31, 2012 | 1.2 | Added summary test results | 1.2 |
| Jun 29, 2012 | 3.0 | Windows 8 final document | 3.0 |
| Jun 18, 2013 | 3.1 | Windows 8.1 document | 3.1 |
| Feb 20, 2014 | 3.2 | Internal update | |
| Mar 18, 2014 | 3.3 | Windows 8.1 Update 1 | 3.3 |
| July 29, 2015 | 10 | Windows 10 Update | 10 |
Learn more about desktop app certification
| Requirement | Description |
| Compatibility and resiliency | Crashes & hangs are a major disruption to users and cause frustration. Apps are expected to be resilient and stable, eliminating such failures helps ensure that software is more predictable, maintainable, performant and trustworthy. User facing app entry point must be manifested for compatibility, as well as declaring the right GUID. User facing app entry points must be manifested for HIGH-DPI awareness and that the proper APIs are being called to support HIGH-DPI. For more information see: |
| Adhere to Windows Security Best Practices | Using Windows security best practices will help avoid creating exposure to Windows attack surfaces. Attack surfaces are the entry points that a malicious attacker could use to exploit the operating system by taking advantage of vulnerabilities in the target software. One of the worst security vulnerabilities is the elevation of privilege. For more information see: |
| Support Windows Security Features | The Windows operating system has implemented many measures to support system security and privacy. Applications must support these measures to maintain the integrity of the OS. Improperly compiled applications could cause buffer overruns that in turn could cause denial of service or make malicious code execute. For more information see the BinScope tool reference. |
| Adhere to System Restart Manager Messages | When users initiate shutdown, in the vast majority of cases, they have a strong desire to see shutdown succeed; they may be in a hurry to leave the office and "just want" their computers to turn off. Apps must respect this desire by not blocking shutdown. While in most cases, a shutdown may not be critical, apps must be prepared for the possibility of a critical shutdown. |
| Clean Reversible Installation | A clean, reversible, installation allows users to successfully manage (deploy and remove) apps on their systems. For more information see, How to: Install Prerequisites with a ClickOnce Application. |
| Digitally sign files and drivers | An Authenticode digital signature allows users to be sure that the software is genuine. It also allows one to detect whether a file has been tampered with, for example, if it has been infected by a virus. Kernel-mode code signing enforcement is a Windows feature known as code integrity (CI), which improves the security of the operating system by verifying the integrity of a file each time the image of the file is loaded into memory. CI detects whether malicious code has modified a system binary file. Also generates a diagnostic and system-audit log event when the signature of a kernel module fails to verify correctly. |
| Do not block installation or app launch based on operating system version check | It is important that customers are not artificially blocked from installing or running their app when there are no technical limitations. In general, if apps were written for Windows Vista or later releases, they should have no reason to check the operating system version. For more information see, Operating System Versioning. |
| Do not load Services and Drivers in Safe Mode | Safe mode allows users to diagnose and troubleshoot Windows. Unless needed for basic operations of the system (for example, storage device drivers) or for diagnostic and recovery purposes (for example, anti-virus scanners), drivers and services must not be set to load in safe mode. By default, the safe mode does not start most drivers and services that did not come preinstalled with Windows. They should remain disabled unless the system requires them for basic operations or for diagnostic and recovery purposes. For more information see: |
| Follow User Account Control (UAC) Guidelines | Some Windows app run in the security context of an administrator account, and many require excessive user rights and Windows privileges. Controlling access to resources enables users to be in control of their systems against unwanted changes (An unwanted change can be malicious, such as a rootkit stealthily taking over the machine, or an action from people who have limited privileges, for example, an employee installing prohibited software on a work computer). The most important rule for controlling access to resources is to provide the least amount of access standard user context necessary for a user to perform his or her necessary tasks. Following UAC guidelines provides app with the necessary permissions when needed, without leaving the system constantly exposed to security risks. For more information see: |
| Install to the Correct Folders by Default | Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app to the location they choose. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. For more information see, Summary of Install/Uninstall Requirements. |
| Support Multi-User Sessions | Windows users should be able to run concurrent sessions without conflict or disruption. For more information see, Remote Desktop Services Programming Guidelines. |
| Support x64 versions of Windows | As 64-bit hardware becomes more prevalent, users expect app developers to take advantage of the benefits of 64-bit architecture by migrating their apps to 64-bit, or that 32-bit versions of the app run well under 64-bit versions of Windows. |