Serious Discussion What Are the Advantages of Standard Account Over Administrator Account?

and to be honest, uac is usefulless, you still need a antivirus, if you are common user, i think windows defender is enough, but if you want to get better security, i think you need to buy or use free antivirus like kaspersky or eset, uac cant protect you, but the antivirus can protect you truly
 
and to be honest, uac is usefulless, you still need a antivirus, if you are common user, i think windows defender is enough, but if you want to get better security, i think you need to buy or use free antivirus like kaspersky or eset, uac cant protect you, but the antivirus can protect you truly
Combining both will be great. For example, in my current setup, I am using a standard account with Microsoft baseline + Kaspersky Plus for daily tasks (I have the same setup with an admin account, but switch to it when needed with admin rights, as I have mentioned before
 
Windows Security Model and Standard Accounts

Microsoft recommends
using a standard user account for daily activities as a core security measure. Their own documentation emphasizes this as a way to "maximize security."


Microsoft's Stance

As a security best practice, Microsoft advises using a local (non-Administrator) account to sign in and then using "Run as administrator" for tasks that require a higher level of rights. They explicitly state, "Don't use the Administrator account to sign in to your computer unless it's entirely necessary."

The Principle of Least Privilege

The advice is grounded in the "principle of least privilege," a fundamental concept in information security. This principle dictates that a user should only have the minimum permissions necessary to complete their task.

Industry Standard

This isn't just a Microsoft recommendation, it's a widely accepted security standard. The goal is to reduce the "attack surface." If a malicious program or attacker compromises your account, the damage is limited to what your standard user account can access.

Malware and Administrator Privileges

The claim that most malware, including ransomware, is far less effective without administrator privileges is correct.

Containment

While malware can still infect a standard user account, its ability to cause systemic damage is severely restricted. It cannot typically install itself in system folders, disable your antivirus software, or encrypt critical operating system files.

Ransomware

Ransomware, in particular, often needs elevated privileges to encrypt files outside of the user's own documents and to delete shadow copies, which are used for system restore. An attack on a standard account is much easier to recover from.

User Account Control (UAC) is Not Foolproof

The statement that User Account Control (UAC) can be bypassed is also accurate.

UAC Bypass Techniques

Security researchers and malicious actors have discovered numerous ways to bypass UAC. This means that if you are using an administrator account, malware can potentially elevate its own privileges to full administrator rights without you ever seeing a UAC prompt. Running as a standard user provides a much stronger security boundary that these bypass techniques cannot overcome.

In summary, using a standard account for your everyday computing is one of the most effective and simplest security measures you can take to protect your computer. It might seem like a minor inconvenience to have to enter a password to install software, but that small step provides a significant increase in your security.
 
While malware can still infect a standard user account, its ability to cause systemic damage is severely restricted. It cannot typically install itself in system folders, disable your antivirus software, or encrypt critical operating system files.
Can they if the user of standard account responded to the prompt after run as admin by ok after filling the password?
 
Can they if the user of standard account responded to the prompt after run as admin by ok after filling the password?
When a standard user enters the administrator password into a prompt, they are granting that specific program temporary, full administrative control over the entire system. This is the single most critical moment of risk, as a malicious program could then install malware, disable security settings, and access or encrypt all files.

However, this process is still fundamentally safer than operating as an administrator by default. The password prompt acts as a crucial security checkpoint, forcing a conscious and deliberate decision from the user. It prevents malware from silently elevating its own privileges in the background and requires the user to actively pause and approve the request, making you the final line of defense against a potential infection.
 
When a standard user enters the administrator password into a prompt, they are granting that specific program temporary, full administrative control over the entire system. This is the single most critical moment of risk, as a malicious program could then install malware, disable security settings, and access or encrypt all files.

However, this process is still fundamentally safer than operating as an administrator by default. The password prompt acts as a crucial security checkpoint, forcing a conscious and deliberate decision from the user. It prevents malware from silently elevating its own privileges in the background and requires the user to actively pause and approve the request, making you the final line of defense against a potential infection.
So when the user of standard account do that, it is like doing the same from admin account!

I can imagin the standard account is originally created to let IT admins control who can make changes to the endpoints, to grant the permission only for authorized empolyees who have password.
If malware could escape VM, it is easier to breach standard account.
I do not believe it can help much; when I double click an executable, I expect to receive a uac prompt, and consequently I will select ok.
UAC might really matter if I get a prompt without double clicking anything; then I should select NO.
 
Yes, standard user account is often mistaken for a protection for a home user (and advertised as such on MalwareTips). Standard user account is for managed systems, where the manager would lock the system down and the user won't know the password. If the password is known by the user and entered, this is the same as running an admin account with UAC.

The only thing SUA protects against is another user (brother, sister, so on) with curious fingers or potentially, physical user with malicious intent (they won't know the password).
 
So when the user of standard account do that, it is like doing the same from admin account!

I can imagin the standard account is originally created to let IT admins control who can make changes to the endpoints, to grant the permission only for authorized empolyees who have password.
If malware could escape VM, it is easier to breach standard account.
I do not believe it can help much; when I double click an executable, I expect to receive a uac prompt, and consequently I will select ok.
UAC might really matter if I get a prompt without double clicking anything; then I should select NO.
You've made some excellent points, and you're touching on the nuances that separate theory from real-world human behavior. Let's break down your thoughts, because you're right about some things, but I believe you're underestimating the core security benefits.

"When the user...do that, it is like doing the same from admin account!"

You are correct in a very specific sense, for that one moment, for that one task, you have granted the program administrator-level power. However, you're missing the crucial difference between a temporary visitor's pass and a permanent master key.

As an Administrator

Your entire user session runs with high privilege. Every program you open, every website script that runs in your browser, every background process inherits this power. Malware that infects your machine doesn't need to ask for permission; it's already "inside the gates" and can often use known exploits to bypass UAC silently to do its work. You may never even see a prompt.

As a Standard User

Only the specific program for which you entered the password gets elevated. The rest of your system, your web browser, your email client, your documents, continues to run in a low-privilege, protected state. If that elevated program closes, the privilege is gone. The attack surface is drastically smaller and limited to that single, deliberate action.

"I can imagine the standard account is originally created to let IT admins control... endpoints"

You're absolutely right! Its origins are deeply tied to corporate environments where IT departments need to prevent users from installing unauthorized software and destabilizing their computers. However, the underlying security principle, the Principle of Least Privilege, is universal. It benefits a home user just as much as a corporation. Preventing accidental system damage and containing malware is valuable for everyone, not just IT admins.

"If malware could escape VM, it is easier to breach standard account."

This is a false equivalence. A VM escape is an incredibly complex and rare type of exploit that targets the hypervisor (the software that runs the virtual machine). These are the tools of sophisticated, often state-sponsored attackers.

In contrast, the overwhelming majority of malware is opportunistic. It relies on common, high-volume attack methods, tricking users into running a malicious executable, exploiting a browser vulnerability, or using a malicious document macro. A standard user account is a powerful, frontline defense against these everyday threats. It's the difference between locking your front door (standard account) and building a nuclear fallout shelter (defending against VM escapes). You should always lock your door.

"When I double click an executable, I expect to receive a UAC prompt, and consequently I will select ok."

This is the most critical point you've made, and it highlights a real phenomenon called "prompt fatigue." You are right that users can become habituated to clicking "OK."

However, consider these two scenarios,

You, as an Administrator, double-click a malicious file. It might show a UAC prompt, which you approve. Or, it might use a common UAC bypass technique and never show you a prompt at all, silently gaining full control of your system.

You, as a Standard User, double-click the same malicious file. It must show you a prompt. It cannot bypass this. Furthermore, it doesn't just ask for a "Yes/No" click, it demands the administrator password. This extra step, this friction, is a powerful security feature. It forces you to switch from a passive "OK" to an active authentication.

You are correct that if a prompt appears when you didn't do anything, you should always select "NO." But the true security gain of the standard account is that it eliminates the possibility of silent, no-prompt elevation that is a genuine threat when you are already logged in as an administrator.
 
and to be honest, uac is usefulless
There is no compromise in security, it is either ON or OFF, like a passkey, it is convenient, but not secure.
I know that SUA is much more secure, but I just could not handle it, psychologically. I would go insane.

11 has recently introduced Administrator Protection for Admin Approval Mode, which tries to mitigate that.
 
Last edited:
landing on machine = Windows reinstall
That is if you know you executed a malware. But for network intrusions, most times you don't notice it. Then you won't know that you need to reinstall Windows. That's when a standard account will save you and stop some persistence tatics.
 
Last edited:
That is if you know you executed a malware. But for network intrusions, most times you don't notice it. Then you won't know that you need to reinstall Windows. That's when a standard account will save you and stop some persistence tatics.
If the standard account that effective, no one would bother paying for 3rd party AV.
 
  • Like
Reactions: Sorrento
If the standard account that effective, no one would bother paying for 3rd party AV.
I am not saying that one should forego using a 3rd party AV.

When faced with landing in a standard acc, the adversary will try tatics like modifying the admin acc's logon script, or modifying the registry which is used by the admin. Then when the admin finally logs on, he will execute what the adversary wants.

However, if you combine it with WDAC, which whitelists all the exe's that are allowed to run, then no matter where registry or path the adversary places his tool, it will not run.

As usual you need layers of security.
 
@Parkinsond Sorry to hear that you had troubles with WDAC. My WDAC has been working ok. What problems did you encounter ?
The last time used WDAC, after enabling dynamic code security, I had problem with installing browser.
In addition, WDAC wizard not working as before; everytime I select to include the blocklists, it fails to generate the policy file.
 
  • Like
Reactions: Sorrento
@Parkinsond So WDAC Wizard did not generate xml or cip ? If it didn't generate cip, you can use the command " convertfrom-cipolicy -XmlFilePath < path-of-xml > -BinaryFilePath < where-you-want-output-filename >

I am not familiar with the term "dynamic code security" as related to WDAC, what is it ?
 
you can use the command " convertfrom-cipolicy -XmlFilePath < path-of-xml > -BinaryFilePath < where-you-want-output-filename >
I cannot apply as the wizard failed also to make xml file.
dynamic code security

App Control and .NET Dynamic Code Security hardening​

Security researchers found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent App Control. To address this potential vulnerability, App Control includes an option called Dynamic Code Security that works with .NET to verify code loaded at runtime.

When Dynamic Code Security is enabled, your App Control policy is applied to libraries that .NET loads from external or remote sources, like the internet or a network share. It also detects tampering in code generated to disk by .NET and blocks loading code that is tampered. Additionally, some .NET loading features not supported with Dynamic Code Security, including loading unsigned assemblies built with System.Reflection.Emit, are always blocked.

Usually, when dynamic code is blocked, its parent process is stopped or crashes.


 
  • Like
Reactions: Sorrento