“Certified for Windows Vista” Software Logo Requirements

Critical to the success of User Account Control is having software that works well for standard users and administrators, without excess prompts. Since User Account Control is such a central part of Windows Vista, User Account Control compatibility is one of the key requirements to display the Certified for Windows Vista Logo on software.

v 1.1 of the Certified for Windows Vista Software Logo Technical Requirements is available now.  Our goal in sharing this information on our blog is to make sure that any ISV’s reading this are aware of the requirements so that they have ample time to make their product compliant and to give our customers confidence that there will be a great supply of software that works well for standard users and UAC.

Some of the key requirements that relate to User Account Control and running as a standard user:

·         Make sure the application works well for standard users, unless it is something truly designed to be run only by system administrators such as disk partitioning software.  If the program has admin and non-admin components the main application should still be run as a standard user and administrative features should be moved to a separate executable.

·         Every .exe file included with an application must have an embedded manifest that defines its execution level. Such as: 

<requestedExecutionLevel level="asInvoker|highestAvailable|requireAdministrator" uiAccess="true|false"/>

Note, including the manifest file will disable File and Registry Virtualization for the application. So the application has to work well for a standard user without relying on virtualization.

·         Executable files with .EXE, .DLL, .SYS, .DRV, .OCX, .CPL, or .SCR extensions must be signed with an Authenticode certificate.

·         Installers must not assume that the person who starts the installation is the one who finishes the installation. For example if your program allows per user and all user installations, a standard user should be able to start the install, but it should prompt for admin credentials if the user chooses the all users option.

·         If the installer uses a boostrapper/chainer, it must include an embedded manifest that designates the desired execution level for the installer. 

Another big change in the Certified for Windows Vista logo requirements is that applications must be independently tested by a Microsoft approved testing vendor before they are granted logo certification.  A draft of the test cases that will be used to verify compliance are posted here.

We’ve also provided a number of resources to help developers make their software Windows Vista and User Account Control compatible, including:

·         Developer Best Practices and Guidelines for Applications in a Least Privileged Environment

·         Microsoft Standard User Analyzer

·         Windows Vista Jumpstart Toolkit

Learn more about the Certified for Windows Vista Software Quality Logo program including how to enroll your company’s software at http://www.isvinnovationportal.com/windowsvista.

When developers release software that meets the Certified for Windows Vista requirements, users will experience even fewer User Account Control prompts than they are seeing on beta versions today. And the Windows Vista team will continue to minimize the number of OS-generated prompts and help make as many legacy programs as possible work without prompting to ensure a good User Account Control experience in the final release.

 - Alex Heaton
   User Account Control Product Manager

Comments (11)

  1. PatriotB says:

    If I remember correctly, even the logo guidelines for Windows 2000 called for compatibility with least-privileged user accounts.  Still didn’t seem to help things any. 🙁

  2. David Hopwood says:

    I might as well ask this again:

    Is it intended to be guaranteed that an app, running under UAC, that knows the Adminstrator password cannot use any admin privileges without a prompt? I didn’t get an answer to this when I asked on a previous blog entry. Note that UAC and UIPI are not sufficient for this unless they also affect network protocols that use Windows account passwords for authentication.

  3. John says:


    I have an ASP (not an ASP.NET) application accessing Sql Server 2005 database installed in Vista Beta 2 (Build : 5384). I am unable to access my application in server. UAP is blocking my application. I dont want to change system level UAP configuration using msconfig or secpol.msc.

    Can any one suggest me some idea to change application level UAP configuration, so that I can access by ASP application.

    Thanks in Advance.


  4. UAC says:

    In response to David Hopwood’s question, sorry for the delay.

    We don’t guarantee that the Secure Desktop prevents malware from tricking the user into providing their password. And we don’t guarantee that there is no risk if a program knows the username and password of an administrator account. Though, If a piece of malware was attempting to steal user credentials on a large scale it should be detected by an up-to-date anti-malware program, including Windows Defender, which will be included in Windows Vista to detect and remove spyware and other unwanted software.  

    It also worth noting that only a small percentage of customers could be tricked by this. By default, administrators will be given the consent prompt which does not request a password. And most standard users will not know the password to enter.

    For customers that want to eliminate this potential risk, we have developed a high security mode that is compliant with the requirements of the Common Criteria standard. To enable this Group Policy, go to Computer Configuration, Administrative Templates, Windows Components, Credential User Interface, and enable Require trusted path for credential entry. When this setting is enabled, instead of displaying the credentials dialog, Windows will first prompt the user to type Control+Alt+Delete, then Windows will switch to the secure desktop to accept the users credentials.  

    There is always a balance between security and usability. In this case, we believe the risk is not great enough that it justifies making the user experience more complicated for all users, as this policy change does. But we have developed the functionality for those that require it.

    – Alex

  5. UAC says:

    John, can you tell us more about what your application is trying to do, what specific action is causing the error, and what is the error message? Is this application just .asp pages in the inetpub directory? Or are there .dlls / components used?

    – Alex

  6. John says:

    Hi Alex,

    Thanks for your response.

    My ASP application is accessing data from Sql Server 2005 database (It is just .asp pages in the inetpub directory). When I log in as Administrator, my application is working fine.

    I added my domain account (domainjohn) in the Administrators group and I logged  in as domainjohn. When I access my application in the server, it is giving me the following error. (But, I can able to access my application in the client.)

    Microsoft SQL Native Client error ‘80004005’

    SQL Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].

    When I disable UAP, it is working fine in server and client irrespective of the logged in account (either administrator or domainjohn)


  7. David Hopwood says:

    Thanks for the information about the "Require trusted path for credential entry" option.

    I have to say that I disagree with the decision not to make this option the default (when credentials are required). If elevations requiring Administrator permissions are so frequent that the need to press Ctrl-Alt-Del would be a significant usability problem, then the real problem is the frequency of elevations.

  8. Alex says:

    John, sorry for the slow reply. Probably the database requires the users to be in the administrators group. The way UAC works it strips out the users administrator credential from their access token. If you explicitly give your domain account access to the database (instead of adding the administrators group) it should work.

    Is that doing able in your environment? Give it a try and least for your account and see if it works. If it does not work then please post the line of code that causes the failure.

    – Alex

  9. Rick says:

    Executable files with .EXE, .DLL, .SYS, .DRV, .OCX, .CPL, or .SCR extensions must be signed with an Authenticode certificate.

    Regarding the above statement, if my software uses third party activex and standard VB components, do I need to sign every of the activex dll ocx?


  10. Yves says:

    Can I have an answer:

    If my application is "Certified for Windows Vista, Windows Defender won’t block it in Auto Start (For example : ‘run’ in registry) ?



  11. Sumeet says:

    My application is a mobility application. We have our own credential provider, in which we launch our application. It appears the createProcess() doesn’t like to launch manifested exes with <requestedExecutionLevel> tag. Any pointer ?

     Sumeet:  I assume you’re running normally and want to start a process that is manifested with requireAdministrator?  In that case, try ShellExecute or ShellExecuteEx instead of CreateProcess.


     — Aaron

Skip to main content