Introduction
Administrator protection is a new Windows 11 platform security feature that aims to protect the admin users on the device while still allowing them to perform the necessary functions which may require use of admin level permissions. This article provides the guidelines and best practices for applications running on Windows to elevate more securely with administrator protection enabled.
As Windows application developers, this article will guide you through best practices for using elevation in your applications and leveraging the new layer of security provided by administrator protection. This provides guidelines on what changes you need to make in your applications to make them compatible with administrator protection and help avoid breakages.
As IT professionals and technical users you will learn how the new administrator protection feature offers a more secure environment to run your applications, and how to navigate the changes effectively.
How administrator protection increases security
Applications are most vulnerable to attacks when operating with elevated privileges. In an elevated context, applications possess extensive abilities to alter configurations and implement systemwide changes, which can affect the overall security of the device. Running applications as admin increases the risk from malware infiltration. If malicious code is executed while elevated, it can capture tokens and then have an opportunity to move laterally within an organization, leading to a widespread compromise. Recent statistics from
Microsoft Digital Defense Report 2024 indicate that token theft incidents, which abuse user privileges, have grown to an estimated 39,000 per day.
The administrator protection feature is designed to enhance security by minimizing the risks associated with elevated privileges. It safeguards users by providing just-in-time administrator privileges, incorporating Windows Hello to enhance both security and user convenience. Running applications with administrator protection enabled is crucial for maintaining a robust security posture.
Key design highlights
Administrator protection brings in a paradigm shift in user access control (UAC) architecture for admin users. It enforces the Principle of Least Privilege which brings in transparency for the elevations.
- New security boundary with separate profile: Administrator protection uses a hidden, system-managed, profile-separated local user account to create the isolated admin token. This helps ensure that user-level malware cannot access and compromise the code running in the elevated context, thus making elevation a security boundary. Application developers please note: This System Managed Administrator Account (SMAA) has a different security identifier (SID).
- Just-in-time admin token: The admin token which is required to perform system tasks is generated from SMAA. This token is non-persistent and created just in time to perform elevation and is discarded once the task is completed. The whole cycle repeats itself when the user tries to perform another task which requires admin privileges.
- Removal of auto-elevation: Auto-elevation refers to allowing certain Windows processes and applications to automatically gain elevated privileges without prompting the user to consent. This can be exploited to perform User Access Control (UAC) bypass attacks where malware may misuse admin privileges to install an unwanted application on the device or for changing device security configuration thus compromising the security. With administrator protection, all auto-elevations in Windows are removed and users need to interactively authorize every admin operation. This helps ensure that the user stays in full control and that admin privileges are not abused.
- Windows Hello integration: Administrator protection is recommended to be used in conjunction with Windows Hello. This further enhances security while providing a convenient authentication experience with face, fingerprint or PIN.
Running applications elevated
Without administrator protection, an admin user would receive two access tokens upon logon – a full privilege, “elevated” administrator token with admin group set to “Enabled” and a restricted, “unelevated” access token with admin group set to “DenyOnly”. Now, when an application is launched elevated with this split-token administrator model, both “halves” of the user share a common profile. Despite each token being appropriately restricted in its use, both restricted and admin-level processes could access shared resources such as the user file system and the registry. This could be abused to perform classic UAC bypasses, such as the registry key manipulation and environment variable overloading attacks.
When an application is run elevated with administrator protection enabled, it is elevated using the profile separated SMAA. As separate-but-linked accounts, each with its own profile, file system directories, registry hives are no longer shared. This design mitigates the classic UAC bypass attacks as well as allows for the tokens to be created on-demand and discarded just as quickly, thus limiting exposure of the privileged token to the lifetime of the requesting process.
Understanding this new design is crucial for both app developers and technical users to ensure that it does not regress the functionality of their application when the same application is run elevated. The profile separated elevation implemented by administrator protection utilizes the same security principles as implemented by over-the-shoulder elevation for standard users in Windows. Running your application compatibly with administrator protection also helps ensure that it will run compatibly with a standard user (user without administrative privileges).
The following behavior may be observed when an application is run elevated with administrator protection enabled:
- Files created by apps when running elevated and saved in library folders (e.g. Documents, Pictures, Videos), will be saved into corresponding library folders of SMAA profile by default. If the user is using an app from an elevated context which needs to access a file created from the unelevated context, they will need to navigate to the unelevated library folders.
- When running elevated, default registry hive for the current user will map to SMAA user’s registry hive instead of primary user’s registry hive.
- Any application specific configuration like background color or font applied by the regular user will not be automatically applied to the SMAA profile, and vice versa.
- Users may see more elevation prompts due to the removal of auto-elevations.
Recommendations
The following are general guidelines and best practices for installing and running applications with administrator protection:
Application installation
- Per-user application installations should be run unelevated. Install all executables, applications and packages unelevated. This includes Win32 installers like setup.exe and package installers like MSIX or AppxBundle.
- For installing Store applications, use the UI based installation whenever available. Preferably install from an unelevated context. If necessary, you can install elevated too.
- If you need to install using API based Store apps they should be installed unelevated using the catalogID.
- For app developers: If installer elevation is absolutely necessary, then avoid placing app binaries under user profile folder. Use %ProgramFiles% for 64-bit apps or %ProgramFiles(x86)% for 32-bit installs on a 64-bit system. A better option is to use MSIX packaging since that allows for elevation too and manages the installation location itself.
- For app developers: While installing as unelevated, don’t install using %LOCALAPPDATA%, since that’s also under %USERPROFILE%. Instead, create a directory in %ProgramData% and place your app there, if the app needs to be shared between elevated and unelevated callers.
- For app developers: Refrain from switching context from within the application during installation and continue to install either elevated or unelevated.
- For app developers: If the files created in the elevated context need to be accessed by the unelevated user (for example, log files using file explorer) then you need to store that file in the unelevated profile’s file directory. Avoid sharing files between elevated and unelevated context from your application.
Launching and running an application
- Always run applications as non-elevated unless there is a specific task you intend to perform that needs elevation.
- If you are required to run the app in both elevated and non-elevated mode, you will need to duplicate your application settings like theme, background, widgets etc., across the two elevated and non-elevated modes.
For example, when you change the theme to dark in the unelevated Notepad, the change will not be reflected automatically in the elevated Notepad. If you need parity you will need to make the change manually.
- Any file you create while running your application non-elevated, which needs to be saved in library folders should be saved in the regular user’s library folders, so that they are easy to retrieve when running the application non-elevated. If the files are stored in the library folders of elevated user profile, you will have to run the application elevated to access those files again.
- For app developers: Accessing the user registry (HKCU hive) and user registered COM classes should be in the context for the same user.
- For app developers: Since users will mostly be running app unelevated, apps need to be designed for granular use of elevated privileges, rather than elevating “up-front”.
- For app developers: With administrator protection enabled there will not be any silent elevations; your application will request authentication at every elevation. To improve user experience, remove dependency on auto-elevation from your applications.
Using elevation
- Run your apps with least privilege. Reduce and if possible, eliminate the need to elevate your apps.
- Consider using system accounts and services-based design to manage processes that need to run elevated.
General troubleshooting guidelines
- If you are not seeing the toggle to enable administrator protection in the Account protection section in Windows Security settings, make sure you are on a supported build.
- Supported editions: Windows 11 Home, Windows 11 Professional, Windows 11 Enterprise and Windows 11 Education
- Supported builds at GA: 24H2+ (Servicing build number will be communicated)
- Preview builds: Windows Insider Program. Canary channel #27718+ Coming soon to Dev Channel
- Not supported in Windows Server editions, Windows 365 Cloud PC or Azure Virtual Desktop editions, Windows 10 or other legacy editions.
- If you enable administrator protection by toggling the switch on Windows security settings but you are not prompted with Windows Hello when you try to elevate, try the following:
- Reboot the device.
- Ensure Windows Hello is enabled on the device.
- If your IT admin has informed you that administrator protection has been enabled on your device, but you are not prompted with Windows Hello when you try to elevate, try the following:
- To test if administrator protection is enabled on the device:
- Launch command prompt as an administrator
- Type in the command “whoami”
- You will see the profile as “ADMIN_”
- Your device already has administrator protection enabled on which you have installed an application from an elevated context. If the application is not able to launch even after you have uninstalled administrator protection, you may need to reinstall your application.
Case study: Running Visual Studio with administrator protection
We recommend running Visual Studio as an unelevated user whenever possible. However,
installation and certain development, building, debugging, profiling and deployment scenarios require elevated permissions.
In scenarios where Visual Studio is required to run elevated and the Windows administrator protection feature is enabled there are incompatibilities and Visual Studio is not supported in such a configuration. However, many scenarios continue to work and most of the incompatibilities are minor, but there are some incompatibilities that could block certain scenarios.
When running Visual Studio elevated with administrator protection enabled, you’ll notice some behavioral differences caused by the use of per user locations as illustrated in the examples below. The list below isn’t exhaustive and ultimately you will need to test your scenarios that require elevated Visual Studio with administrator protection enabled.
- Extensions are typically per user and are by default installed into a location that’s specific to the user who installed the extension. As such per user extensions won’t be accessible from Visual Studio running as elevated with administrator protection enabled.
- Various settings in Visual Studio are stored in per user locations and those settings will be different between Visual Studio running elevated or not. However, several settings are roamed and will be based on the user account that is signed into Visual Studio (see: Synchronize settings across multiple computers - Visual Studio (Windows) | Microsoft Learn).
- In places where the default path includes the signed in user, such as in the new project dialog, Visual Studio will use the admin’s account which might not be accessible when not elevated.
Whenever Visual Studio 2022 is running as an elevated process the top right of the IDE will contain a badge “Admin” as show in the screenshot below.
Conclusion
Administrator protection is an upcoming security feature in Windows 11, offering robust security and user privilege management to help the user stay in control of changes to their Windows device. By requiring user authorization for administrative tasks, it helps safeguard the system from unauthorized changes and malware, enhancing overall device security. A seamless integration with
modernized Windows Hello helps provide a secure and convenient way to authorize the use of admin privileges.
Our goal is to enable administrator protection by default in Windows very soon. This feature is available now to Windows Insiders. We encourage you to try out your applications with administrator protection enabled and provide us with your
feedback.
Securing the present, innovating for the future
Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience.
The updated
Windows Security book and Windows Server Security book are available to help you understand how to stay secure with Windows. Learn more about
Windows 11,
Windows Server and
Copilot+ PCs. To learn more about Microsoft Security Solutions, visit our
website.
Bookmark the
Security blog to keep up with our expert coverage on security matters.
Also, follow us on LinkedIn (
Microsoft Security) and X (
@MSFTSecurity) for the latest news and updates on cybersecurity.
