My computing career goes back to when Windows 3.1/3.11 was the dominant desktop OS and slowly being replaced by just-launched Windows 95. Novell NetWare was at its peak for file and print services and slowly losing market share to Windows NT. The enterprise was in a bit of a free-for-all when it came to security as the internet was certainly not as ubiquitous, so firewalls weren’t as common. Authentication could be touchy depending on what backend you were connecting to (NetWare, NT, Banyan VINES, or others), and in many environments you had multiple logins. Endpoint security, or just “antivirus” as it was referred to then, was gaining traction from vendors like ESET, McAfee, Norton, and Trend Micro but was far from widely adopted. And as much as admins may have tried to lock down desktops, if you were using the common OSes (DOS, Windows-on-DOS, OS/2, or even Mac), getting around those restrictions like hidden directories, kiosk menus, or even CMOS passwords meant having a floppy disk and a little knowledge.

Today, we have learned our security lessons and have layered security from the application servers down to the browsers on the endpoint, and everything is much better protected.

<Pause here for giggles from security analysts who know how unsecure computing environments still are.>

Putting aside the laughter, the ability to secure the enterprise has improved, but one legacy practice that’s held on within the Windows endpoint space is running locally as administrator. Initially, this was just how Windows operated. Local users had full control of the endpoint, and even if they didn’t, working around those restrictions was easy. But since Windows 2000, there was a clear division between user and admin roles. This doesn’t mean an end user could easily run in user-only and operate effectively. Many applications weren’t written well for just the user space and needed either higher-level permissions or even full admin rights because they made system-level changes. Updates to apps usually required administrative permissions to install. Because of convenience and flexibility, many organizations allowed users to run as admins locally to enable users to install whatever applications they needed to do their job.

That last piece is what’s held on the longest. Poorly written apps, while still existing, have very little need to run in the admin space; modern app updates either use a background service update or don’t need admin permissions; and with the move to SaaS and web-based apps, requiring local admin rights in Windows has diminished except for the flexibility. Letting users run as a local admin on their workstations is still common in many enterprises for the simple fact that controlling the delivery and installation of applications is time-consuming for the IT and security operations teams and end users. Testing applications and updates is also time-consuming, and maintaining application catalogs for the diversity of needs for even a 1,000-user business can be a full-time job. It’s easier to provide the mandatory and common production applications and let the users run whatever ancillaries they choose, hoping the EPP/EDR/XDR platform will catch all the bugs that may pop up in the apps.

The problem with this approach is that when a hacker compromises that user account, they can take up residence in that endpoint and run tools that will not trigger normal threat detection policies such as PowerShell and Command Prompt, WMI or rundll32.exe, or remote desktop tools. They have residence in the enterprise, so they can take their time to slowly probe for other weaknesses, establish residence on endpoints that are more vulnerable and less likely to be monitored for compromise (such as unsecured IoT devices), or, with the spread of AI tools and agents, utilize the local AI functions on that endpoint to collect more data that could be beneficial to them.

Security leaders need to recognize that allowing users to be local admins on their corporate endpoints is a security gap that needs to be closed. Privilege identity management solutions can help you identify where users have too much access and monitor and control this. Allowlisting solutions or app control functions within your endpoint security solutions can let you manage and monitor which apps are allowed to run on the endpoints. And as more applications move to web and SaaS, this should be easier than ever to achieve.

Forrester clients who want to dive deeper into this topic and discuss what approaches they should take to close this gap can schedule an inquiry or guidance session with me.