The FAT/FAT32 (File Allocation Table) filesystem used in 9.x editions of Windows didn't support the use of access control lists. Therefore, there were no strict means of controlling access to specified files and registry keys for a set of defined users. All users were effectively administrators. There were some methods for controlling what users could do, but it was far from what was available in more sophisticated operating systems of the time.

Ease of use has always been one of Windows strong selling points, and the wide choice of applications has helped it become the most prevalent OS on the desktop.

Windows NT, which spawned Windows 2000, XP, Vista, and Windows 7 has many fundamental differences from DOS-based Windows. However, the most important point in this discussion is its use of NTFS—a filesystem that is considerably more reliable and flexible than FAT and supports the concept of access control. This provides NT-based systems with a foundation that can be secured and protected according to a user's role. Along with other features such as a stable kernel, the ability to assign users with system privileges, and computers with system policy, NT provided the stability and security features required from a true business-grade operating system.

NT had no built-in equivalent to the switch user (su) command in Unix, so it was common that all users would be assigned to the administrators group on any one system, or at a minimum power users, which was essentially the same as administrators with a few less privileges. This started the trend on Windows NT, despite a sound security model being in place, for all users to run with administrative privileges. The future merger of the NT line and DOS-based 9.x versions of Windows ensured that the practice of running with administrative privileges would be entrenched for years to come.

An unfortunate side effect was that application developers commonly ran with administrative privileges, meaning that their applications would not run correctly under a standard user account. Even to this day, there is much debate about secure application development and resistance from developers who refuse to work without administrative privileges.

Though the Windows NT 4 Resource Kit did include a tool called SU (Switch User,) similar to the Unix command-line tool, it was a separate product. Windows 2000 introduced for the first time a built-in command called runas that allows users to run an application under the context of a different user account without logging off. The runas command is an equivalent of the Unix su command and is facilitated through the secondary logon service. This new command-line tool and service were intended for administrators, in the hope that they would use a standard user account for everyday use, and elevate applications only when administrative access was required. It suffices to say that this never caught on. One of the biggest annoyances of runas is that it can't be used to launch Explorer or certain control panel applets, without using messy workarounds.

runas isn't limited to administrators, but for daily use its implementation is simply too clumsy and wouldn't gain user acceptance in most environments. Another major drawback of runas is that if a standard user needs to run an application under the context of another account, then all the access rights the standard user has to the network and local filesystem are lost if not shared with the elevated user. runas is best used in contexts where a standard user will elevate using an account that has access to all necessary resources, for example, when a sysadmin elevates from their standard user account to Domain administrator.

In Windows Vista and Server 2008, network drives mapped in one security context are not visible to processes running under a different account in the same logon session, regardless of the permissions assigned to the network drive. This behavior can, however, be changed by adding a REG_DWORD entry to the registry called EnableLinkedConnections, with a value of 1 under HKLM\Software\Microsoft\Windows\CurrrentVersion\Policies\System and rebooting the system. runas has several command-line options, known as switches, which can be used to change the way elevated programs are launched. The /netonly switch allows users to retain access to resources on the local machine as specified by their primary account, but gives permission to networked resources according to the privileges of the account specified in the runas command. This can be useful for certain tasks where local administrative access is not required. Other switches such as /noprofile and /env allow users to control whether their own user profile or environmental variables will be used. While runas from the command line is likely the most convenient way for system administrators to use the full array of features, holding Shift while right-clicking on an executable file presents runas in the context menu.

If Windows 2000 was designed for business, then XP was a revolution for home users, finally merging the 9.x and NT range, thereby providing everyone with the security and stability of the NT kernel. This wasn't without its challenges, and to address problems with applications that weren't designed to run on NT, Microsoft created the Application Compatibility Toolkit (ACT). ACT allows businesses to scan their networks, creating an inventory database of installed applications. Programs can then be tested, and if necessary, any problems resolved with the use of application compatibility shims (fixes). ACT comes with a series of predefined shims, several of which can be used to solve problems with applications that weren't designed to run as a standard user.

XP also includes new Group Policy settings called Software Restriction Policy (SRP). While not intended to directly address Least Privilege Security problems, SRP does allow system administrators to dictate that given applications must run as a standard user. This is useful where users have to run with administrative privileges, but you want to restrict applications, such as Internet Explorer, to standard user privileges, minimizing the risk if users surf websites that host malware or browser exploits.

While it has always been, in theory, possible for corporate users to run as a standard user on NT-based operating systems, it was always difficult and unrealistic for home users, largely because Windows wasn't designed with this in mind. Ease of use always prevailed over security.

For the first time, Microsoft tried to go some way to change this situation with the introduction of User Account Control (UAC) in Vista. Much derided and misunderstood, UAC is a collection of technologies designed to make it easier for users to run with Least Privilege Security and to persuade developers to design applications that work without administrative privileges. Before Windows Vista, many routine tasks required elevation of privilege. User Account Control addresses this problem by changing system privileges to allow standard users to change the time zone, power schemes, and other previously restricted settings. User Account Control includes file and registry virtualization that transparently diverts write operations for protected areas of the filesystem and registry to the user's profile, allowing applications that don't comply with the Windows security model to function correctly without any modification.

Finally, and most controversially, UAC prompts users before they're allowed to make any changes to the system that require administrative privileges. This behavior can be configured in several different ways depending on the organization's requirements. UAC have been criticized for being too ubiquitous, thereby increasing the chances that users will simply agree to elevation without considering the risks. Despite Microsoft's efforts to make it easier to run as a standard user, by default, the first account in Vista is an administrator, albeit protected by UAC. If users opt to create additional accounts, they are prompted to assign standard user privileges, though this is not mandatory.

Descriptions of UAC from Microsoft have been somewhat contradictory. One of UAC's original design goals was to make it a security boundary, providing a sandbox where privilege cannot be elevated without the user's explicit consent. However, after Vista's release Microsoft acknowledged that it was a security feature, and not a boundary when running in Admin Approval Mode, implying that it could be compromised and wasn't designed to be impenetrable.

Using least privilege concepts, Microsoft has tightened the security of system services. To reduce the attack surface, Vista's system services run with a minimum set of privileges. The service control (sc) command-line tool lets system administrators query and change the system privileges assigned to services. The following example shows how to use the command to determine what privileges are granted to the Remote Procedure Call (RPC) service:

sc qprivs rpcss

The following output shows just three privileges:

[SC] QueryServiceConfig2 SUCCESS
SERVICE_NAME: rpcSs
PRIVILEGES : SeChangeNotifyPrivilege : SeCreateGlobalPrivilege : SeImpersonatePrivilege

Microsoft has attempted to improve UAC in Windows 7 by making it quieter and more configurable. While there is no doubt that UAC is more configurable in Windows 7, it is for you to decide whether or not it is improved. The default user in Windows 7 is still a Protected Administrator, but the UAC settings are not as stringent as those in Vista. Windows 7 provides users with a less annoying experience, but with the prospect that their systems could be silently compromised. When designing UAC for Windows 7, Microsoft endeavored to strike the right balance between usability and security. Windows 7 gives users more control over UAC behavior, and the new features can also be configured in Group Policy.

Professional, Enterprise, and Ultimate SKUs of Windows 7 include XPM (XP Mode), which is intended to help smaller businesses migrate to Windows 7, while alleviating application compatibility concerns. It includes a license to run a virtualized instance of Windows XP and a new version of Virtual PC, which can integrate applications running inside a virtual machine with the Windows 7 desktop—blurring the line between installed and virtualized programs. Microsoft provides a managed version of XPM for larger organizations called Microsoft Enterprise Desktop Virtualization (MED-V).