I need to convince my internal IT department to give my new team of developers admin rights to our own PCs. They seem to think this will create some security risk to the network. Can anyone explain why this would be? What are the risks? What do IT departments usually set up for developers who need ability to install software on their PCs.

This question was IT Security Question of the Week.
Read the June 8, 2012 blog entry for more details or submit your own Question of the Week.

  • 9
    Something seems missing from this question: what kind of software are they expected to develop? Web application? Graphics drivers? (Knowing the language/platform may help.)
    – Bruno
    Commented May 15, 2012 at 15:33
  • 59
    The biggest risk is that the developers would actually be able to get some work done.
    – Dunk
    Commented May 15, 2012 at 19:36
  • 21
    Explain them that the biggest security risk to their network is an angry developer ...or just let them learn that the hard way.
    – Sandman4
    Commented May 15, 2012 at 20:11
  • 21
    Put it this way: either give developers admin rights, or developers will get admin rights by their own means.
    – Sonic42
    Commented May 16, 2012 at 12:55
  • 8
    How will you develop an installer, or a Windows Service, or an ActiveX component, or an interprocess communications layer, or use an embedded web server without local admin access? Commented May 17, 2012 at 3:31

8 Answers 8


At every place I have worked (as a contract developer) developers are given local admin rights on their desktops.

The reasons are:

1) Developers toolsets are often updated very regularly. Graphics libraries, code helpers, visual studio updates; they end up having updates coming out almost weekly that need to be installed. Desktop support usually gets very tired of getting 20 tickets every week to go install updated software on all the dev machines so they just give the devs admin rights to do it themselves.

2) Debugging / Testing tools sometimes need admin rights to be able to function. No admin access means developers can’t do their job of debugging code. Managers don't like that.

3) Developer tend to be more security conscious and so are less likely to run/install dangerous malware. Obviously, it still happens but all in all developers can usually be trusted to have higher level access to be able to do their work.

  • 4
    Local admin rights don't/shouldn't affect their network rights either. You've just given them access to their network endpoint, which they have physical access to anyways.
    – pdubs
    Commented May 15, 2012 at 16:13
  • 16
    It should be noted that access to machine hardware is the same as granting admin rights in security terms. A smart malicious agent can easily transform one into the other.
    – Roy Tinker
    Commented May 15, 2012 at 16:27
  • 8
    @DanNeely: If you can attach a debugger to a process you don't own, you can make that process do anything you want. So debugging rights = admin.
    – Jay Bazuzi
    Commented May 16, 2012 at 5:55
  • 5
    I need to learn about how local admin rights can be given without giving network rights, our IT admin people tell me it can't be done. Any pointers to where I can read up on this appreciated. Commented May 16, 2012 at 10:28
  • 5
    @carolineggordon, if they're concerned about network sniffing, maybe there's a wider issue here. Essentially, that would imply that sensitive data may go on the network, where normal workstations are plugged in, and where some employees cannot be trusted. Maybe that's the problem that should be fixed instead: make users use SSL/TLS-protected services for sensitive data instead. There will otherwise always be a (possibly small) risk of someone plugging in their own capturing device.
    – Bruno
    Commented May 16, 2012 at 11:31

This partly depends on the kind of software the dev team is expected to develop. Some types of software are easier to develop without administrative rights than others.

For example, you can do a fair amount of web-based Java development using the likes of Eclipse with Maven artifacts, all installed locally (and typically tested on port 8080), without needing much admin rights (you may need to open certain ports). Developing tools that need closer access to hardware may prove impossible without admin rights. This being said, even for web development, it's good practice to be able to re-build a test machine from scratch (typically a VM), which may need admin rights.

If this is about trust (i.e. some members of your dev team could have malicious intents), you're in trouble anyway. It's unlikely that the sysadmins who would approve/disapprove certain rights will be able to check what the code they've written does in details. That doesn't mean either that you should give your dev team unrestricted access to your production services, nor that they should have admin access on more machines than they need, of course. It's good to have mechanisms in place to mitigate risks, but you'll need some basic level of trust for your organisation to function. Putting the dev team on a separate physical network is a first step to mitigate trust issues and possible mistakes.

A typical risk by having someone with admin access is to be able to capture packets on the network. This is a risk that you may have to accept depending on the nature of what's developed. Tools like Wireshark can be useful for development sometimes. Even within your organisation, IT or non-IT people should use services with SSL/TLS enabled if possible, this should help against eavesdropping and MITM attacks.

I can think of a few downsides when not giving devs admin access (unless they really don't need it):

  • It may create a "them v.s. us" culture between devs and sysadmins in your organisation. This already exists in many places, but it's generally not a good thing. Each team is likely to consider the other one as a pain. Security is not a purely technical problem, but a human interaction one too. I think good human communication should help the overall goals of your organisation in general, not just from a security point of view in fact. (I've always found to be able to find better solutions after talking in person to the sysadmins with whom I needed to solve problems rather than replying to a faceless ticket.)

  • Human nature is such that people get creative when limited, but not necessarily in the right way. You may find that the devs end up putting a fair amount of effort (and often succeeding) in circumventing the limitations imposed upon them within the organisation. They should use their creativity on what they're meant to do instead.

  • IT systems are complex and debugging is a dark art. If you need to debug your product against library XYZ version a.b.c_13 and a.b.c_24, the developers may need to be able to install and uninstall each version, which may in turn require admin access. Chasing bugs that depend on version numbers is already annoying as it is. If you have to raise a ticket and wait (perhaps hours or days) for someone else to install/uninstall the right version will make it a nightmare: it will increase the "them v.s. us" cultural problem and, more importantly, it will cost more to the organisation. You can think of this from a risk/cost assessment perspective.

  • 4
    The most important reason NOT to give a programmer admin rights is the fact they will make the same mistake people have made for years, not test their code as a limited user, because in the current version of windows there are protected folders.
    – Ramhound
    Commented May 16, 2012 at 11:19
  • 9
    @Ramhound, that's not so much a security issue but a bad dev practice. Having admin rights doesn't mean that you have to run everything with full privileges at all times, even as a developer.
    – Bruno
    Commented May 16, 2012 at 11:43
  • 2
    @Ramhound - That's why you have separate QA team with a written test plan. It's not an excuse for hogtying your devs for the sake of IT empire building. Commented May 17, 2012 at 3:26

Risk is an increasing function of access

There is a simple rule of risk computation which explains the fear of your colleagues of the IT team. The more access you have on any operating system the higher are the impacts of any error or attack.
For example, if one of your colleague, lets say Bob, is attacked through a standard phishing attack, then Bob account is available to cyber-criminal and sold on the Internet within minutes. If Bob account has admin priviledges then this account will be used to send SPAM at a large scale on the Internet, then to steal other accounts with phishing attacks at a large scale, and very quickly (within minutes) will open a back door to your network (this is possible because the Bob account is an admin one) permitting a total remote control of Bob's PC (through tools as ssh, VNC, VPN...). This attack initiated from an internal PC, from a privileged account is able to break any firewall, stop any anti-virus, anti-spam protection.

The evil is inside.

Even your best network admins, system admins or security admins may leave this corrupted PC undected for months (cf. Stuxnet).

False risk reduction

If your developper colleagues are good at managing the OS on which they works, and have a physical access to the computer, then this difference in risk is null.

Any engineer on any OS
can grant himself admin access
if he has a physical access to the computer.

Blocking the admin access on any OS is a valid risk reduction approach for users who are unable to make a difference between admin privileges and normal user privileges. Here is the key question I would ask to your developper team colleagues and act upon their awareness of risk:

"What will you take care of if you are granted
admin privilege on your OS?"

If they are good enough to be risk aware, then they are good enough to get the access they want. Then there is no risk reduction in refusing them this admin access. Beware: there is a collateral risk for your company as a whole if you refuse them an access they can easily get: they will do it the dirty way, they will behave as outlaw, they won't be able to ask any help, they'll have to cover any mishap.


You give them Local admin rights to their workstation and anything else they want. The development environment is always isolated from the main network. It is IT's job to make sure you provide them with what ever setup they need while making sure nothing in the dev environment can harm the main network. Plan ahead and work with management to buy the equipment/software you need to accomplish this.


A few things that have not been mentioned in previous answers and comments that would be an argument for developers working under least privilege:

  1. Depending on the industry in which you are working, there may be legal or regulatory reasons that restrict employees from having elevated privileges on their workstations. Allowing administrative access to developers could put the organization at risk of being out of compliance.

  2. When components are developed with elevated privileges, there could be a risk of failure during deployment to other environments that do not have those privileges. Developers may have inadvertently upgraded or added libraries to their local machines that do not exist in other environments, and the components may have dependencies on specific versions of those libraries. Also user accounts under which the components will run in other environments may not have the required database or other access that was assumed by the developer working with elevated privileges. I have seen this happen many times in the past. Sometimes its obvious why the deployment failed, sometimes its not, and you have to roll everything back until you can figure it out.

  3. If developers install open source tools or libraries and use those for development, there could be unintentional license restrictions on how the software they produce is eventually distributed, particularly where "copyleft" terms are part of the license. There is nothing wrong with using open source tools or libraries, it just should be intentional. You don't want to find out upon delivery that you now need to release all of your source code back into the community because your developers used some open source component that had strict copyleft terms in the license that they didn't really read before they installed it.

Something I have seen done is to have the developers work under least privilege, but allow them request elevated privileges for a specified period of time. Then, this "fire call" request for elevated privileges it recorded and monitored, and is reset automatically at the end of the requested time.

  • Point 1 is tricky. I've seen organisations trying to restrict the usage to approved software, but it's of course virtually impossible to audit software during its development. Point 2 is just good dev/testing practice, it doesn't have much to do with the security of the devs workstation itself. Point 3 is just normal dev practice too, this has nothing to do with open/close source: any soft or lib used will have a licence that should be respected, devs always have to check, whether-or-not they have admin rights. (Note that very few OSS tools imply that what they're used for must be OSS.)
    – Bruno
    Commented May 16, 2012 at 11:39
  • 1
    2. Should be handled by a continuous integration server Commented Jun 27, 2012 at 17:28

The security risks associated with providing developers the ability to install their computers are numerous. Here's why I would object (speaking as a sys admin)

1) Potential violation of best security practices - One of the 8 rules of security is the rule of least privilege - only give employees access to what they need to complete their task. If someone told me that their dev's needed admin access to install software to do their work then I would reply with "Why can't one of my staff install it for them?". Having a centralized point for installing software ensures that an IT department knows exactly what software is on what machine.

2) Legal Reasons - Perhaps one of your dev's has less than admirable ethics and decides to install pirated software. Not only is that software probably riddled with malware, but you then open up can of worms for litigation should you be caught with pirated software on your computer. An IT department is considered responsible for those computers and, as such they are responsible for auditing them and ensuring that the licensing is in compliance with the TOS of each piece of software. While it's convenient for the dev's in that they can install their own software and not bother the IT department, you create a lot more work for the IT department.

3) Unintentional installation of Malware - mentioned before, but this could be innocent enough. Elevating user privileges so that they can install malware leaves them susceptible to malware by opening an infected PDF they got via an e-mail, or a drive by download. Limiting user access so they can't install software will help mitigate the threat of malware.

4) Malicious activity - Similar to point 2, but what's to say that one of your dev's isn't going to install a back door or purposely open up another security threat on your network. You'd be surprised how many IT professionals do this to exact revenge should they be terminated or their boss pisses them off.

All in all, I would have to advise against it. While people may argue it would save time in preventing them from always bugging IT to install software, I would counter that with "it takes less time to do that than it does to patch up security holes created by allowing users to install their own software". If it's deemed that this IS necessary, they should really be put on a network that doesn't have direct access to the outside world.

  • 13
    Pretty much all of these can be done without admin privs. A lot of software does not require admin privs to install. The only way to prevent most of these is having a software whitelist, but that's obviously impossible for devs. Commented May 15, 2012 at 13:21
  • 11
    1, 2 and 3 are all true, however attaching a debugger to a process running as another user requires local admin. Visual Studio 2005 recommends always running it as an admin. Installing windows services requires admin. These are all things that I as a developer have to do, some more often than others, which means that local admin is a permission that I require to do my job. For point 4 I'd say that the dev has physical access to the workstation, so if they were malicious they could get admin rights, unless the PC is locked shut.
    – pipTheGeek
    Commented May 15, 2012 at 16:41
  • 18
    I would downvote this answer if I could. I do not see how these problems cannot be solved with good communication with the developers. If you do not trust one deveper to fullfil the requirements you mentioned, then it would be better not to hire him/her on the first place. I think that restricting admin priviledges to (untrusted?) advanced users that have complete access to their hardware is naive, to say the least.
    – yms
    Commented May 15, 2012 at 17:21
  • 7
    As a professional developer, I'd say that I need your approval to install software, you'd better not write any scripts without mine. Commented May 15, 2012 at 21:03
  • 7
    Besides the points that PipTheGeek made, almost all developers have their private set of helper tools that they use in order to be more productive on the job (hotkeys, luanchers, snippet-orgenizers, code generators, grep, Notepad++, etc...) Besides they use sysinternals-tools like process explorer to kill hanging processes. They also need access to eventlogs and other MMC-snap-ins, and use tools like regsvr32.exe to register their COM stuff... the list goes on and on... I cannot imagine doing my job without being at least local admin. Rather kick me off domain, only providing internet access. Commented May 26, 2012 at 23:22

You have a few questions to answer.

  1. What applications do these developers need to use daily require admin privilages and is there any way to setup these applications so thats no the case?
  2. What reasons do these developers need admin privilages in order to do trivial daily tasks and is there a way to avoid this?
  3. Are these developer machines connected to the internet?

The question should not be what are the risks, the question should be (which you can only answer) what are the reasons the developers even need to have an admin account. You can them up with a "power user" account and give them the ability to do exactly what they need but also limit their ability to do harm to your network.

If these machines are connected to the internet....then you will introduce a large amount of risk because of their ability to run anything and install anything on these machines. These developers are well developers, they are not security experts, it's only a question of WHEN they will make a mistake that exposes the network to malware.

Take a look at Google for instance. A Google employee click on a link contained in a MSN Messenger window, downloaded malware that took advantage of an exploit that had already been fixed by Microsoft, and infected the entire network.

I should add the Google employee clicking on the link had nothing to do with this question, it was to point out, people WILL make a mistake so limit your exposer.

  • Wouldn't Google's network getting infected be IT's fault for not installing the existing fix from MS?
    – Andy
    Commented Sep 3, 2016 at 1:36
  • @Andy - That is my point. A employee still exposed them to the threat.
    – Ramhound
    Commented Sep 3, 2016 at 2:52
  • But nothing would have happened if IT applied the patch in a timely manner. Expecting humans to never make mistakes seems like a pretty silly way to go about security.
    – Andy
    Commented Sep 6, 2016 at 0:17
  • I would like to point out that not every Google employee is a developer, it might have been the lady who orders the office supplies. Commented Jun 22, 2018 at 7:45
  • The question was specifically about giving developers Administrator rights. The Google employee in this case can presumably be a developer. It also was just an example.
    – Ramhound
    Commented Jun 22, 2018 at 11:02

A workaround is to install a virtual machine, not connected to the domain. It will be quite a hassle but it's better than being totally crippled by policies.

  • 3
    For future readers: this will not work for developers of mobile apps that require using a device emulator. Device emulators are also virtual machines, and you cannot run a VM within a VM. Also note that if you use a modern IDE (Visual Studio, Intellij IDEA, Eclipse) the poor performance of such tools in a VM will make your life miserable.
    – yms
    Commented Nov 15, 2016 at 19:06

You must log in to answer this question.

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