I work at a company with a staff of about 1000+. We currently have programming development staff that work on web based projects (approx 50 people).

Recently due to security concerns our IT and Security department implemented a restriction no longer allowing local admin access on machines . The entire company runs Windows OS for both workstations and servers. I completely agreed with the decision to remove admin, honestly I thought it was long overdue (as the company deals with patient data and requires HIPAA compliance). Unfortunately I believe they took the decision too far. I assumed a subgroup or AD group would be created for users that legitimately needed admin access to do their job (EX my programming team) something like a Tech group that would retain admin access. However this was not the case, the only group created a specific Admin group for Network and Help Desk staff.

The main problem is, as web developers we run programs that require local admin access and unfortunately can't do our job without them running as admin. Example programs include Visual Studio for ASP.NET web development, MAMP for local development, composer, etc. I believe the main reason these programs need admin access is because they need to run and modify local IIS, command line, etc.

Basically there was short notice of when the local admin access was removed. After about 2 days of the development team being dead in the water in terms of being able to work and me and other team leaders basically yelling and screaming at the IT staff to come up with a solution they finally conceded and found a third party program that works as a pass through allowing the administrators to create the ability for certain programs to run as admin even though we don't have local admin access.

Unfortunately, this program we use for local admin access is incredibly buggy and unreliable and not from a reputable source and there doesn't seem to be much for alternatives out there. (I would prefer not to disclose the program we use.)

My question is, is it typical to not allow Programmers/Developers local admin access at a company or corporation? And if it is common practice to do so, then how do developers run the programs they need as local admin?

A little more information on our network environment (not that it really relates to the question I just thought I'd add this):

  1. We use AppBlocker to block programs not on an approved list
  2. We use an email security blocker that does things like scan and convert attachments to PDF, etc.
  3. We have at least 2 major antivirus programs on all workstations.
  4. The network and it's servers very segregated, users only have access to certain servers, folders, and databases that they legitimately need access to.
  • 193
    A company policy that encourages friction between IT and Development is a risky policy. If there is one group of people that could seriously undermine the IT department's security efforts, it will be the developers. A good company policy would aim at having IT and Development combine their collective knowledge to reinforce the overall security. Forcing IT to put up barriers for Development is counterproductive to this result. Given enough incentive, people will start looking for creative workarounds. Creative workarounds from developers will be detrimental towards overall security.
    – Jacco
    Commented Jul 16, 2018 at 8:47
  • 115
    Having two separate antivirus programs on a system will almost certainly do more harm than good. You'll get a negligible increase in detection, whilst doubling your exposure to vulnerabilities in the AV software itself, as well as significantly slowing down the affected systems.
    – James_pic
    Commented Jul 16, 2018 at 13:03
  • 4
    Not the same question but very related, I was on the other side (the IT side of things, and IT people often do not agree with such a crazy policy either): security.stackexchange.com/questions/135359/…
    – grochmal
    Commented Jul 16, 2018 at 14:12
  • 24
    I don't think you really want to ask if it's "typical". But rather is it justifiable, and what are the cost/benefits? In my experience it's somewhat common for large organizations to try this. The costs are rather high, and it drastically affects productivity for Developers, but the "security people" normally don't care because it's surrounded in an SEP field (Somebody Else's Problem). If you want to get rid of this, you're unlikely to win trying to find that this isn't typical, but rather that it's EXPENSIVE. Companies hate expensive. Commented Jul 16, 2018 at 14:30
  • 53
    @Jacco Not to mention the cognitive dissonance between not trusting a developer with their own machine and simultaneously trusting them to develop custom code to be run on the company's servers and that processes sensitive end user information. If they can't keep a virus off their machine without protections, I don't think I'd want them developing my applications that I could be fined for not doing properly.
    – jpmc26
    Commented Jul 16, 2018 at 23:40

19 Answers 19


Here's one data point from a software company that has an interest in security. I know this is common in similar organisations.

There is a number of networks. They are physically separated and airgapped, run different colour-coded network cables.

Each employee has an 'administration' machine, which can connect to the Internet (via a proxy) for doing email etc. All users are strictly locked down, and there's strict device and access control.

In addition to this, each developer has an 'engineering' machine. This has full admin access, and the user can do whatever they like. However it is connected only to the engineering network (no route to the Internet).

In most software development contexts this could be seen as extreme, but in orgs that have conflicting requirements of high security and developer freedom, this is a common solution.

To answer your question, yes it is common to allow developers admin access, but this doesn't always mean admin access to a machine that could cause information security issues.

  • 24
    +1, some development teams in our company use the same practice. Although we don't air-gap the development network. We handle it using VLANs.
    – Philipp
    Commented Jul 16, 2018 at 10:58
  • 87
    Hm, the development machines not having any internet connection seems a rather severe restriction. Commented Jul 16, 2018 at 23:41
  • 12
    @Nelson: How can you vet that what you're copying over the USB stick is safe? While you obviously need to allow copying from administration to engineering; would you allow copying to the administration machine? Because if you allow both, the data exchanged on a stick is as safe as the data exchanged on a physical network cable (directly between the two machines), it's just a slower process.
    – Flater
    Commented Jul 17, 2018 at 13:16
  • 53
    This is not a decision to make lightly. There will be a considerable impact on development. Not saying it's impossible to do, just pointing out some of the consequences. From technical things such as nuget/npm packages (you won't have realtime access to the public feeds and will need to copy everything manually), but also more trivial issues (developers can't copy/paste from StackOverflow anymore. And let's be real here, we all do it, even if we agree that vetting the code is necessary (which imo, it is), manually having to type the whole thing is not going to be conducive to efficient work).
    – Flater
    Commented Jul 17, 2018 at 14:37
  • 17
    Having to buy a second pc/laptop for the employees seems like a rather expensive way to make people less productive
    – J_rite
    Commented Jul 18, 2018 at 13:51

In my experience, it is common for developers to have admin access on their own machines. It is also common for them not to have admin access on their own machines. However, in the latter situation some accommodation is generally made so they can get their jobs done without too much friction.

One very common accommodation is access to a Hypervisor on the workstation (whether some version of VMWare or the Hyper-V that comes with Windows), along with the specific permissions needed to create and destroy VMs within that hypervisor as needed (Hyper-V/VMWare), including creating VMs where they have admin rights to the guest OS. Typically some of these VMs will be long-lived, even if they don't run all the time, where it's rarely a question of needing to prepare an entire VM from scratch just to do what should be a quick test for something that needs administrator privileges.

The Hypervisor may or may not be configured to allow internet access for it's VMs; I've seen it both ways, though personally I strongly favor that internet access should be allowed... at least for the types of development with which I have most experience. But internet access, when granted, can and should at minimum be configured to force VMs into a dedicated vlan, separate from the rest of the corporate network. I'm not sure this is possible to enforce directly via Hyper-V or VMWare, but you can use 802.1x on the ports for many network switches to prevent access to certain vlans from unauthorized machines, including devloper VMs. Then you can give a little tutorial to developers about how to set a vlan tag in a VM and let them know what vlan tags will be permitted on their switch port. I've also seen this enforced via training merely as a policy edict, rather than via technical measures, with perhaps the occasional friendly audit to encourage compliance and make sure devs know it's important.

And, of course, this coincides with providing developers with machines sufficiently powerful to run multiple VMs at one time.

  • This sounds like a good solution - a very good solution - but I don't have enough Windows admin-foo to know if it actually works that way (specific privileges or rights to spin up VMs without having general local admin privs) - so IMO this answer could be much improved with links to some documentation/white papers/cookbook items/or such that confirm this.
    – davidbak
    Commented Jul 16, 2018 at 20:59
  • 1
    @davidbak Better? Commented Jul 17, 2018 at 2:02
  • Yes, great link! Ben Armstrong is the guy to go to! Plus the detail on the VLAN stuff.
    – davidbak
    Commented Jul 17, 2018 at 2:33
  • @davidbak I've worked on a machine with a hypervisor (VirtualBox) installed while having no admin rights
    – anna328p
    Commented Jul 18, 2018 at 9:14
  • 1
    VMs also provide other benefits for the developers. One physical computer can host several VMs, running different OS versions, or versions of the software under test. As they are disposable, it is easier to repeat tests by reverting to a chosen checkpoint.
    – Raedwald
    Commented Aug 9, 2018 at 19:43

I work for a fairly large investment management firm (~6000 employees) and developers are one of the groups that we approve for local admin access. We tell them not to install any software, as that is handled by local desktop/software compliance.

We also have a Developers AD Group that allows members to change the execution policy on their machines without requiring local admin.

  • 6
    This does not answer the question. It does not give any explanation if or why this would be "typical".
    – Tom K.
    Commented Jul 16, 2018 at 14:43
  • 8
    @TomK. It answers the actual question, which is "Why is my organization making my life very, very hard, for seemingly no good reason, and what can I do about it?". The OP is clearly trying to fit this (quite frankly bizarre and paranoid) practice into his world view. People are trying to point out how their organizations have balanced the paranoid security people with the real life needs of Developers. Commented Jul 16, 2018 at 18:08
  • 4
    @Steve - unfortunately that is as misguidedly extreme a view as that you get from some extreme security folks. It's not paranoid to protect organisations from insider threat. In fact for many it is the biggest threat to their existence.
    – Rory Alsop
    Commented Jul 17, 2018 at 9:45

In my experience allowing and disallowing local admin access is common, just as common as dirty workarounds for the latter. - So you should ask yourself:

Which threat to your network is made worse by local admin rights?

To which the answer shoud be: NONE - The access to resources in your network should be restricted on a per user basis, completely unrelated to the fact if this user has local root, admin or masterOfTheUniverse access on his machine. If the user has rights to blow up your network, a local virus does not even need admin access, it can just use the user account to blow up your network. - And if the user-account cannot access something on your network, local admin rights will not change anything about that.

You should trust your developers to handle their own machine responsibly - and with a sensible security configuration in your company local admin rights should be dangerous only for one thing: The local machine. So the only risk you accept by giving out local admin is that a developer breaks his own machine (which he can already do with a cup of coffee).

Addendum: You should grant your developers the possibility to use local-admin rights whenever they need to. This doesn't mean they should be logged in with an unsecured admin-account all the time, but you should trust them to use it sensibly whenever they need it - without asking for permission every time.

Why developers should have local admin-rights

Your developers are people which you entrust the design of core operations of your business. Most companies today are very dependent on their software, so developers are a vital resource to shape a very important part of your company.

First there is the benefit of higher productivity, because the developer can just configure, install and test everything he needs to on his local machine. He may need certain software, helper tools or unusual configurations to experiment with certain aspects of his software (for example run his software on an older version of a OS or with older drivers/SDK).

Second there is the (in my opinion even bigger) benefit of showing your developers how you value them. You show them that you trust them with their own machine - you treat your developers like responsible IT-savy people who can administer their own machine without a babysitter. (In many companies where devs don't get local admin, they will have to ask tech-support or security for every installation/configuration they need. And in many cases these tech-support people know less about the software than your senior lead developer, but they still have to beg for things they simply needs to do their work, which can be very frustrating.)

  • 3
    @Downvoter care to comment how my answer could be improved, or why you think it is completely wrong ?
    – Falco
    Commented Jul 23, 2018 at 10:30
  • 7
    @JamesSnell Visual Studio needs local admin rights, which is (imo) a large reason, as developing without Visual Studio just does not happen. Not disagreeing with the rest of your comment, just the need for local admin rights.
    – Belle
    Commented Jul 24, 2018 at 6:15
  • 7
    @JamesSnell I'm a big advocate of defense in depth, but I just don't see a local restricted account securing anything of value, except the local hardware. Anything of business value can be accessed with user rights xkcd.com/1200
    – Falco
    Commented Jul 24, 2018 at 6:35
  • 2
    Defense in depth for me includes an encrypted hard drive, a strong password on the local account, a secure hardware module... But local user right restriction on a single user laptop is just security theatre
    – Falco
    Commented Jul 24, 2018 at 6:39
  • 4
    Maybe I should edit my answer to set this clear - I think developers should use a secured account normally, but have the option to enable local admin if necessary without the need to fill out a form and ask for permission. And I trust them to use this privilege sensible and sparingly
    – Falco
    Commented Aug 6, 2018 at 20:20

In my career, with rather small companies (less than 100 people), we always had local admin rights. We either have real desktop machines which are maintained by IT, but got the rights, or we were allowed to have virtual machines of all sorts that we completely managed by our own.

If we had not local admin access, we would try all sorts of bad "solutions" which, as in your case, leads to less security. This is one of those cases, that restrictions actually lead to the opposite of their intention.

  • 5
    This does not answer the question. It does not give any explanation if or why this would be "typical".
    – Tom K.
    Commented Jul 16, 2018 at 14:45
  • 13
    @TomK. This answers the question partially. If 10 people out of 10 say "I always had admin rights" then together that is the answer. No single person can canonically answer a global question like this; each single answer is to a degree anecdotal, a "data point" as Joe called it. (Joe also claimed "I know this is common in other origanisations", failing to add "which I know of".) Commented Jul 17, 2018 at 16:13
  • 1
    @PeterA.Schneider: Correct, typically no single person can canonically answer a global question like this just with his/her experiences. But fortunately there are such things called "best practices" that are written down and open to scrutiny. Other possibilities are studies or articles. Just saying "For me, it's like this" is not enough.
    – Tom K.
    Commented Jul 18, 2018 at 7:16
  • @TomK. There's no way to know what is typical short of some kind of survey, so answering that part of the question isn't going to happen.
    – Andy
    Commented Jul 20, 2018 at 0:11
  • 1
    @TomK. Those surveys or studies, if they even exist, would be junk. As you said, itd just be a collection of what might be "typical" and just because something is typical doesn't mean its the right way to go.
    – Andy
    Commented Jul 20, 2018 at 22:12

In a rather small department of a larger organization (~100 in department, ~3500 in full organization) we chose an in the middle solution:

  • sysadmins had 2 accounts, one (non administrator even for the local machine) that was used for non administative tasks (mail, document edition, etc.) and one with AD administrator priviledges that was supposed to be only used for AD administration
  • all other users had only one single non administrator account
  • devs (and some power users) were provided a local account with local machine administrator privileges. It was supposed to be seldom used when local administration was required.

Refusing administrator rights to devs will be a cause of loss of productivity, and that has an immediate cost for any organization. The choice of granting admin privileges on the local machine to the primary account or to a secondary account should depend on the frequency of administrator operation:

  • If more than several times a day, I would advise using the primary account.
  • If less than once a week, I would use a secondary account.

Choose your own if you are in between...

  • 1
    Yep, we did this too. Although our AD admin accounts also had local admin privileges on every machine (that was part of domain/ad).
    – mroman
    Commented Jul 16, 2018 at 13:57
  • 2
    We had a meeting today with our IT team regarding this and I'm leaning towards marking this answer as answered simply because this is the solution they came up for us.
    – TroySteven
    Commented Jul 17, 2018 at 1:53
  • 1
    Considerations: how much internet access for the AD account. At my workplace, my AD has virtually no internet access (Visual Studio updates excepted). I must use my regular account for internet/download/etc. Commented Jul 19, 2018 at 14:51

In my experience working for larger organizations, it is absolutely not common for developers to have full rights to anything other than development specific resources.

It seems like your organization is on the border of small and large, so...

It sounds like it's time for your organization to develop some more mature development practices.

To be fair, this kind of a change isn't something operations groups should surprise development teams with, like it seems was done in your case.

Security and developer productivity need not oppose each other for your company. You can avoid this clash altogether by performing your development activities on a network that doesn't have access to resources on your core business network.

You aren't doing development against your production assets anyway, right?

If you are, you shouldn't be - it introduces a significant risk to your assets, particularly to their availability.

Much better practice is to have an entire development environment setup that replicates key portions of functionality and data sets (without exposing something like private information about real individuals in your company). This replicated environment makes the separation fairly simple. Your developers need full control of machines in this development environment. They do not need full control of assets outside of the development environment.

There are a number of ways to implement a separate development environment:

  • Completely separate hardware (workstations, servers, network devices, etc.), connected to the internet or not
  • Virtualized environments (including virtual networking); hosted on your hardware or with a cloud service provider and with or without internet access
  • A combination of the two approaches above

You can also implement some kind of bridge (if you're not already using a service of some sort already) for any sharing you need to do in and out of the development environment.

Development environments should be protected like most networks. Don't just throw all your code and development assets online without some thought to access control or basic security measures.

I've also seen some places take this one step further and write all of their code in one environment then build/deploy it all to another completely separate environment for integration testing.

  • 3
    Rather than writing my own answer, I want to build upon this one. At my job, we distinguish between: 1)Development servers, 2) Other non-production (QA, TST etc.) servers, and 3) Production. Developers can have admin access to do development work, but they're expected to package their code and other assets and give them to us to deploy in the other non-prod environments, along with all of the documentation about any OS tweaks that need to be done. I don't even want them on those group 2 systems introducing differences from Prod, which defeats the purpose of group 2. Commented Jul 16, 2018 at 17:54
  • 11
    This is the correct answer. Developers should/must have admin access to their development workstations but should NOT have access to production systems, dbs with sensitive data etc from those workstations. Commented Jul 17, 2018 at 5:54
  • 1
    In the GDPR era, keeping developers off production systems is pretty much a legal obligation. The good thing about laws is that they can trump internal company policies.
    – MSalters
    Commented Jul 17, 2018 at 13:00
  • 3
    <h1>You don't need huge and bold text to get your answer read or your point across.</h1>
    – Luc
    Commented Jul 17, 2018 at 15:32

First of all you need to learn that it does not matter what "is common" or "typical" because: typically such situations are handled horribly. You are making the best case for this statement.

If local admin access is needed for a person (be it a contractor or an employee) then it is the obligation of the security team/person - whoever is in charge of that particular area - to find a solution. There are manifold solutions: creating an isolated VLAN, virtual machines and others were named here.

It does not make any sense to inquire upon the setup of other organizations just to hear "we also have admin rights on our machines". You won't find an infrastructure that is exactly the same as yours. The only thing that matters is, that the security team/person plans a secure solution that is then implemented by the IT deparment in this particular organization.

If the solution that has been implemented does not work properly and is therefore still rendering you unable to work, bring it up with the security team/person again. If this does not work, bring it up to your boss or your contractee.

What you are doing right now is burning money and nothing else. If the other participants in this game have not figured this out by now it is bad. But it is good if you do.

  • 7
    In all reality, since you remarked on Marcel's answer: It appears that your reply does not answer the question and actually explicitly refuses to do so. If you want to encourage the OP to ask a different, more relevant question, consider doing that in a comment. Commented Jul 17, 2018 at 16:19
  • 1
    There's a difference between not answering the question and giving a different perspective or trying to show OP the problem in another light.
    – Tom K.
    Commented Jul 18, 2018 at 6:59

This fundamentally depends on context, and in particular on your threat model.

In some organisations, it's common to give developers complete control over their development workstation, to the point of enabling them to install their own OS on it.

In some organisations, all development must be done in an airgapped environment, that no electronic devices can be taken into or out of.

Most organisations fall somewhere between these two extremes. The more locked down the development environment, the less productive your developers will be, and the more likely you are to lose your best talent. Your organisation need to assess the likelihood and impact of a compromised developer workstation, and how much they're willing to reduce developer productivity to mitigate this risk.


The problem you actually have is competent IT are attempting to enforce a boneheaded rule. You really only have one choice, give developers effective admin access.

I keep seeing the same advice being repeated over and over again, that boils down to a second machine that the developer has admin but no internet. If you want to have swiss-cheese security that's the way to go. The lists of software installed on a typical developer's computer are usually longer than a screen. Many of these have only one option for check for updates--internet. You can't patch them via WSU because WSU doesn't know they exist.

Here's what the arguments don't understand: breaching the developer's personal accounts isn't a launching point; it's the jackpot. There is no reason to go for admin from there. The breacher has capacity to modify the codebade to insert backdoors. Gaining admin on the developer's box isn't that much more interesting.

What are you defending against when you want to deny admin? Somebody accessing the codebase? No. Somebody using it as a launching point? If your production LAN isn't protected from your dev boxes you're doing something wrong. The developers installing stuff they shouldn't? No. The dev has a compiler and runs code output by the compiler. This might as well be definition of running unapproved software.

I've heard many many stories of the policy being the devs don't get admin, but the practice of IT looking the other way while the devs overthrew the security policy. I've heard many more of the IT never even finding out. I've heard some of the dev's manager telling the devs to bypass the security checks.

Sooner or later, organizations learn to just give the developers admin. Most of the ones that don't probably end up having done so without actually knowing it.

It's far wiser to just give devs local admin on one box connected to the internet and to the local domain and be prepared to deal with whatever the consequences may be. Protect production instead. There are fewer people who should be accessing production at a high level of privilege, therefore the lockdown is easier, and competent organizations learn to do that.

But suddenly taking away admin like this almost always results in loss of the more important devs. You don't want that.

Since you want to talk about Windows sites, there is one anecdote that outweighs most people's data. Microsoft gives its devs local admin. The maker of Windows has concluded there is insufficient benefit to not giving devs admin to make it worthwhile. Therefore, you should do the same.

  • Can you provide a reference for this? "Microsoft gives its devs local admin. The maker of Windows has concluded there is insufficient benefit to not giving devs admin to make it worthwhile."
    – Soenhay
    Commented Dec 18, 2018 at 19:19
  • @Soenhay: blogs.msdn.microsoft.com/oldnewthing/20110927-00/?p=9543 and about 50 others
    – Joshua
    Commented Dec 18, 2018 at 20:00

I've seen two approaches that work.

  1. Give developers admin access to their machines. This is the easiest and most common approach. It is usually the best choice
  2. Create a team in the organisation whose whole Job is to ensure that developers can work without admin access. This team will usually be 3-4 people. You will find that developer's hardware requirements increase dramatically as you'll be using containers and or VMs, so budget for buying new hardware for all developers. When you roll out, start with a team of early adopters, then gradually move all of your developers to a machine without admin access. This process will take at least six months.

If you do what your company is doing now then your developers will put up with it for a month or so then start looking for new jobs.

  • 2
    @Luc A lot of development tools rely heavily on Local Administrator privileges. MS Visual Studio for instance doesn't need all local admin privileges to run properly, but needs certain admin privileges. DEBUG_SE for debugging, service management for - well - managing services, Create rights for databases and I could go on for ages. Now detecting why a developer isn't capable of running a database script, debugging an application or installing a service can be extremely time-consuming, and it is either the time of the said developer, or the time of dedicated personnel.
    – mg30rg
    Commented Jul 19, 2018 at 9:19
  • 4
    @R you might want to read up on 'devops', you'll find that modern day developers have very reasonable motives for wanting admin access. For me personally, not having control of my machine is huge red flag. If told in advance, I'll decline your job offer, if not, my first two weeks will be my last.
    – Douwe
    Commented Jul 20, 2018 at 8:26
  • 1
    @R.. I regularly start a program, then attach a debugger to that program so that I can read it's internal state, pause it's execution and make it execute arbitrary code. This requires admin access. My productivity will drop if you ban me from doing this.
    – UEFI
    Commented Jul 20, 2018 at 11:13
  • 1
    @Luc It's better to give devs admin access because it's cheaper. It means you won't have to employ 3-4 people full time to keep the developer's machines working and complaint with your security policy.
    – UEFI
    Commented Jul 20, 2018 at 11:16
  • 1
    @R.. So my web-browser running java-script should by able to access the internal state of another program on my system, such as my password manager? I see no security issues with that ....
    – UEFI
    Commented Jul 20, 2018 at 15:08

I worked for some time for a company that really believes in security (or so they think).

Every once in a while they would organize a social event, like playing bowling. Joining was free, but you had to add your name to a list in an Excel file, placed in a shared folder. That folder was dedicated to social events, nothing else.

So, you want to play bowling? You want to add your name to that list? Ohhhhhhhhhh, dear... It's not like they can let everybody edit that file, can they? You have to ask for the appropriate permissions.

This is the procedure:

  • Open the company's site
  • Find the section with some modules ready to be filled in
  • Find and download the document called "Release Sheet"
  • Print it
  • Fill it in with your request and sign it
  • Hand it out to the secretary
  • The secretary will take all these requests to the manager in the morning of the following day
  • Sooner or later the manager will sign it
  • The secretary will bring it back to you
  • At this point you can scan it
  • Open the site used by the IT to handle tickets
  • Create a ticket describing (again) what you need, and attach the scanned Release Sheet. Don't forget to set the urgency, from one hour to two weeks.
  • Eventually the IT will do it (hopefully)

On average, it would take 3-4 days to get it done. In some cases, weeks. Really efficient, eh? Hey, you asked for access to a certain folder but forgot to mention the subfolder? HA! You've won another round! And, guess what? Since they were following some QA process, they were organizing documents in a lot of different folders. When a new colleague came, he could easily spend weeks trying to get all the permissions he needed.


  • Do you think the managers bothered to check what they were signing? Certainly not. They recognized the Release Sheet, and that was it.
  • Do you think the secretaries were checking much more? Maybe they tried, but can they really understand the implications of giving me read/write permission on a certain folder on a certain machine? Certainly not.
  • Do you think the IT gave a damn about the urgency? Certainly not.

So, what did this approach lead to? That if you wanted to steal everything the company ever made, you just had to bring in a USB drive and connect it to your PC. No access to that "Confidential_Documents" folder? Just ask for it, they will sign it. And if it's urgent? "Hi, I need that document but I can't access it, can you give me your password?"

So, this "security model" was incredibly slow, clunky and frustrating, and it didn't protect their properties at all, but at least no one could easily mess with the participants to the bowling event (obligatory xkcd).

Please don't be that company. As others have said: don't ask whether it's common (it is), just ask whether it makes sense. And the answer is: no, it doesn't, unless your company likes burning money.

  • And that's probably why my company decided to block USB drives... I assume their next step will be to physically remove them and give everyone a blutooth mouse & keyboard.
    – Carra
    Commented Aug 7, 2019 at 13:02

Yes and no - our senior devs do have a separate admin account that permits them to elevate when needed and install applications/updates. They are not permitted to login to the computer with the account though. Their admin account also permits them admin access to regular dev computers to provide quicker support than going through the IT team.

This is all combined with an application white/blacklist, strong password policies, removable device prohibition, gateway proxies, DLP policies, stringent AV rules and more. Their machines are routinely audited and the IT team visibility is high.

Personally, I'd prefer for the devs to not have local admin access. We could investigate the app(s) that needs UAC (find out the folders, regkeys etc that it needs) and mitigate the UAC prompt but that takes time and research and not all companies have the resources to do this. So, we meet them half way and expect two-way trust. We also use multiple corporate products to enforce a multitude of rules so there is some relief in that.

  • 1
    This does not answer the question. It does not give any explanation if or why this would be "typical".
    – Tom K.
    Commented Jul 16, 2018 at 14:46

We solved this problem by using a Virtual machine.

Every developer has an normals user account without any admin rights. Inside that user account theres a virtual machine without any internet access. Inside of the virtual machine the developer can run his application with admin rights.

That way we can separate internet access and important data from the use of admin rights while still obtaining a way to run the necessary programs in an enclosed environment.

  • 3
    Let's just assume the OP needs (Local) Admin privileges to run a development environment. The above mentioned Microsoft Visual Studio and SQL Management Studio for instance relies heavily on Admin Privileges. The other thing those software relies heavily (in terms of updates, online help, source control and I could go on for ages) is Internet connection. Having a VM with no Internet connection but providing (Local) Admin rights means switching the rock with a hard place.
    – mg30rg
    Commented Jul 19, 2018 at 8:55

I'm in the same boat as your software developers. Our company recently went from workstations with admin access to virtual machines without. It was severely impacting our workflow so much that I times I found myself doing nothing but reading articles for the IT department to run something as admin for me.

The thing that management came up with was a two virtual machine approach.

One of our virtual machines was a basic business machine with Email, Web Access, and Microsoft Suite. This satisfied the need to communicate.

The other virtual machine had local admin rights, but was disconnected from the Internet entirely. That way, we could not download anything on that machine. (Although we could still download it from the other and copy the download over..) We still got access to internal sites and whitelisted a couple of things visual studio uses (Nuget, Symbols, etc..)

That approach left the IT department satisfied in terms of their security, while also giving us our admin access back.

The only negative thing is that we cannot use our dual monitors for just one machine since we needed each machine to be on their own monitor, but we usually just used one screen for code and the other for web browsing anyway.

  • 1
    This works for a basic Microsoft shop, but falls down when doing cross-platform development (Python, Java, Go, NodeJS - all have their own frameworks / package repositories / set of URLs that need to be whitelisted and can change without notice). It also prevents trying anything new - because you have to jump through hoops to get URLs whitelisted just to test something which you might not ever use if testing does not go well. Want to test out Meteor? Good luck, please submit a ticket to get URLs whitelisted and wait 2 weeks Commented Dec 2, 2018 at 22:52
  • 1
    @ErinDrummond Very true and one of the major pitfalls of this approach.
    – Jimenemex
    Commented Feb 5, 2019 at 15:46

Short answer: Yes, it is common to have local admin access to selected groups, such as developers or IT admins. Basically, people whose day job is a lot easier with admin access while the usual office worker would need it at most once a month and typically much less than that.

Long answer: It depends...

For the general user population, you don't need to run a full risk analysis to understand that admin access has a lot of potential for things going wrong and little advantages to offset that risk.

However, for developers (and a few other groups), a risk analysis is definitely warranted, and a proper decision on the matter based on the facts, circumstances, risk appetite and threat situation of the company is asked for. Pointing to "best practice" and doing a blanked one-size-fits-all move is a cop-out typically caused by the person(s) responsible for information security lacking the time and/or knowledge to run the numbers and come up with a risk treatment decision based on facts.

That doesn't necessarily mean that they are wrong. A full analysis could very well lead to the same conclusion.

At the point you are, from what you write, that is an unknown. You could ask for a proper risk analysis to be done, adding your expert knowledge to the cost of mitigation side of the equation, putting into numbers the lost productivity and other effects of the current measure. This needs to be weighed against the risk that the information security people identify.

There are also other measures that are related. One typical solution that I sometimes recommend (I'm an Information Security Architect by profession, so I get asked these questions on a regular basis) is to seperate the developer network from the ordinary office network to contain the higher-risk area. Harden the developer machines sufficiently and insist on local firewalls and up-to-date virus protection and you are fine against typical attack scenarios. If your company has some outside exposure, you might also add in additional awareness training for developers so they don't fall prey so easily to targeted attacks.

I've personally supervised developer environments of both kinds, and with a little effort both can be made to work well. Just pulling the plug on an established way of work was handling it badly and the backlash you were a part of was to be expected. But what's done is done and it is probably smart to not focus on that and look towards the future.


Segregate Your Networks

You should have relatively isolated environments for development, testing, production, and business. This allows your devs to have privileges where they need them.

Proper segregation prevents unauthorized changes, restricts the spread of malware, and impedes the exfiltration of data.

What Happens Where?


The development network is where coding takes places. Developers should have administrative rights in case they want to test code snippets or run something without packaging it for deployment to test/prod.

Computers run IDEs, source repositories, and prerequisite apps/frameworks for your apps. A dedicated collaboration tool or other dev-specific apps are reasonable.


The testing network is where compiled, ready-to-ship code is tested. Developers may have admin rights, but regular system admins should be deploying applications.

Deployments should reflect what the admins will maintain in production for internal apps. They should be customer-ready packages for external apps (including install wizard and digital signatures, albeit using a separate signature for testing purposes to prevent accident releases).

Developers often need system logs and debug access, and these are the only reasons they should have admin rights. They should not be involved with installation, configuration, and testing unless absolutely necessary.


The production network is where you provide services to clients and partners. Since a formal deployment process should exist, there is no reason for it to connect to your dev/test networks.

To minimize risks of internet-borne malware and accidental changes, accounts from the dev/test/business networks should have no access to production if possible, which translates to limited permissions with occasional arguments in practice.

Ideally, this network would be completely isolated, but in practice this is impossible in a world where production servers must interface with systems for sales, billing, scheduling, netops, and project management. Get as close to the ideal as you can; it's really all we can do.


This is the primary communications network for the enterprise.

Email, web browsing, and partner connectivity all bring a host of risks. Your development, testing, and production networks should be isolated from these risks to the maximum extent possible.

Details, Details, Details

It is possible that your organization went overboard. It is easier to swing the pendulum all the way over than to deal with the myriad details essential to a flexible, secure network architecture.

The developers can have admin access to their machines, at minimal risk to the enterprise, if:

  1. There are separate, unprivileged accounts for internet access
  2. Unique accounts are used in each environment
  3. Restrictive firewall rules/ACLs exist between environments
  4. Standard security measures such as firewall, web proxy, IDS/IPS, etc are in place

Your developers will need four accounts:

  • Unprivileged dev account to access resources on the internet (if they do not want to hop back and forth from the business network, which is onerous)
  • Privileged dev account to configure workstation and test code
  • Privileged test account to debug applications
  • Unprivileged business account for email, web, intranet

If you have developers do some validation or QA work, they may also need unprivileged accounts in the test environment.

Developers should have no access to the production network and no administrative privileges on the business network. If this impossible for the moment, then those roles should be separated or else a rigorous change control process should be put in place.


Despite MS-Windows NT having been a multi-user system system since its inception, its not really easy to operate it in such a manner, and developers (including Micosoft's) still tend to ignore the idea of privilege seperation. This kind of access control is poorly documented, tends not to feature in training, often difficult to access via the UI, hard to audit, lack of patterns/tools for applying the seperation....

In fairness, even on Unix/Linux systems, I see a lot of developers failing to use privilege separation appropriately both for real users and for services. But on any platform, placing barriers in the way of implementors seperating privileges is even more counter-productive for security than giving them full (local) admin privileges.

On the other hand, while I know little about developing on MS-Windows, I do find it surprising that local-admin privilege is required to run Visual Studio. And if the only reason you need admin access is for stopping/starting services or reconfiguring them then I don't have a lot of sympathy for you - possible to provide this facility to designated users without giving them local admin. One of the big changes in IIS7 was the delegated admin capability. And its always been easy to delegate reconfig of Apache, MySQL and PHP.

there was short notice of when the local admin access was removed

It sounds like the issue is the Security team aspiring to a level of competence they are unable to deliver (this, in my experience, is very common). They shouldn't have imposed a policy change without doing a proper impact assessment and considering mitigations for any harm to productivity/security.

We have at least 2 major antivirus programs on all workstations

That's a very naive approach to protecting the integrity of these systems and paints a picture of what you are having to deal with.

there doesn't seem to be much for alternatives out there

Getting into a discussion about that probably isn't going to be very productive at this point.

Overall it sounds as if you are in competition with your local security team. They don't understand what you need to do your job, you don't understand how to meet their objectives. And it seems like neither side is willing to negotiate. No off-the-shelf tool is going to fix that.

  • 4
    One reason Visual Studio these admin rights is to enable debugging of processes, owned by other users IIS traditionally runs under a system account. As soon as the developer debug another process they could disable virus checkers etc the heads removed in 90% slow down that is not uncommon from them. Hence the choices between not letting the developers use the debugger and trust in the developers..... Commented Jul 17, 2018 at 8:46
  • 1
    ....and then I remembered why I avoid doing any programming on Microsoft Windows :)
    – symcbean
    Commented Jul 17, 2018 at 10:37
  • 2
    Factually incorrect. Visual Studio will run without local admin privileges, and in fact that's the default. And if you assign debug privileges to the developer accounts, that means Visual Studio will not need to elevate to admin permissions that often. Is it entirely avoidable? No, driver developers will absolutely need admin access for instance.
    – MSalters
    Commented Jul 17, 2018 at 12:56
  • 2
    Visual Studio will run without admin privileges, but in some cases it won't run properly without admin privileges. Yes, it doesn't need all local admin privileges to run properly, but needs certain admin privileges. DEBUG_SE for debugging, service management for - well - managing services, Create rights for databases and I could go on for ages. Of course one could contact the security team and require the certain rights one needs on a - let's say - daily basis, but do you know how it's called? Productivity-murder.
    – mg30rg
    Commented Jul 19, 2018 at 9:12
  • 1
    @Joshua And what do you think is required to debug a windows service running under System account for instance? This scenario is far from uncommon in Windows development.
    – mg30rg
    Commented Jul 22, 2018 at 15:10

It is only typical to have local admin access denied to devs in companies where either the devs are so useless/malicious they abuse those privileges, or where the "IT and Security" department is run by clueless knee-jerk idiots who view everyone not in their inner circle as an obvious security threat out to make them look bad.

Considering your "IT and Security" department also mandates two anti-virus programs when Windows comes with a perfectly good free one, I'm pretty sure you can determine where the problem is in your organisation, and work from there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .