In a corporate environment, should developers have admin rights on their computer? Why?

Technological environment:

  • Windows 7
  • Visual Studio 2008 & 2010
  • SQL Server

16 Answers 16


Should they? That's up to the corporation. Personally I think it's fine as long as there are some understood rules.

  1. Being admin on your box is a privilege NOT a right.
    1. Catching viruses on multiple occasions will get the right revoked
    2. Disabling corporate agents will get the right revoked - AV/inventory/software deployment/etc
    3. Basically if you do something that risks the network will get the right revoked
  2. Any tools you install must not be made a dependency of your project without getting them on the officially approved list. Ask nicely don't come crashing in the day of the deploy and demand $random_library be installed on all servers with no testing
  3. For anything outside of normal applications installed everywhere else support will be best effort. Help desk and/or sysadmins will not spend 5 hours trying to debug why you have dll conflicts.
  • 18
    Good list. Would add also that if the product will ultimately be run by users w/o admin rights then you need to test accordingly (real usability testing). Too many developers do the poor man testing where they test on their dev machine on which they have god rights. The product works well and they give it a stamp of approval only to learn that it chokes in a non-priv'd environment. Feb 8 '11 at 0:36
  • 4
    @Shawn, there is a reason you need testers as well as developers. Feb 8 '11 at 9:20
  • 12
    This is a typical network admin reply who doesn't understand why do developers require admin privileges. This should be decided by a manager level person who has managed or been a developer in the past. Otherwise you'll keep the machines free of virus and office free of developers. Feb 8 '11 at 12:12
  • 11
    @Hasan and this is a typical developer reply who has never had to deal with an infested network saturating a DS3 with traffic taking down the entire office. I'm not asking you to do anything all that onerous here.
    – Zypher
    Feb 8 '11 at 13:00
  • 10
    In a development house you're in business because of the software the development team is churning out. I've worked in several businesses where the machines were locked down to a degree that made the job impossible and we had a hard time convincing people we needed admin privileges to run the development tools. Or where internet access was cut so that we couldn't even read the online documentation. Or an antivirus product that scanned every database record insert and so therefore hurt performance so much that it was impossible for us developers to make the software run properly.
    – hookenz
    Feb 8 '11 at 14:45

Typically I would say yes. Things like debuggers require pretty high if not admin rights to work correctly. Developers often need to install random software which can take days or weeks to get installed when going through channels. During that time the developer is usually work stopped costing the company nothing but money, especially if the developer is a consultant.

  • 15
    +1 - developers are (usually) fairly intelligent people and keep their machines clean Feb 7 '11 at 23:26
  • 9
    Don't say that. :)
    – mrdenny
    Feb 7 '11 at 23:28
  • 4
    @Mark, I have yet to see evidence to support that claim. Feb 7 '11 at 23:32
  • 4
    @Mark Henderson, you may be fortunate enough to actually be working with a good group of people. One if the sites I read daily gives me the impression that not all developers are created equal.
    – Zoredache
    Feb 8 '11 at 0:31
  • 8
    I believe there's an old Klingon proverb that goes, "Beware programmers carrying screwdrivers." Feb 8 '11 at 1:59

There is both science and art in development; it isn't as simple as "knowing" what we need. If we already had the answer half our job would be moot; finding the correct approach is often iterative, and may involve multiple tools in unpredictable ways. Requiring an intermediary to install each of these (often with high latency), only to find (about an hour in) that for your scenario the "super-uber tool addon" is needed is silly.

While a VM is ideal for this, there are also a lot of development tools that cannot run (properly, or even at all) in a VM, because they themselves are a VM - and I don't mean things like JVM; I mean full machine emus/vms, such as device toolkits. Compatibility there is improving.

Additionally, most development tools have a very large footprint - much larger than "regular" tools (making VM hosting a bit more painful than you might expect), and often by the nature of being a process debugger require elevated access. Not to mention the fact that they may be GUI intensive; trying to run full-time on a VM GUI is... extremely painful.

Performance is a huge are here; would you think it was OK for users to wait 3 seconds after every keypress in Word for their key to register? I am not kidding - development tools on VMs etc can be this sucky; for most development purposes you need responsiveness. Interrupting the flow of complex logic from brain to keyboard can make it pretty much impossible to get the job done. And I hate to say it, but yes: development time is expensive.


In a Windows environment, and especially when using Microsoft developer products, the dev will require admin rights on their machine. If you deny them those rights their ability to do their jobs will be restricted, if not prevented altogether.

  • 1
    Maybe. But they should be required to test their code in a non-privileged environment if they are making a product for user consumption. Feb 8 '11 at 2:00
  • 2
    @Bart, I fully agree but the devs should be doing their testing on a separate machine anyway because the dev tools create a completely different environment to that of a "normal" computer. Feb 8 '11 at 3:27
  • @BartSilverstrim that doesn't always follow. Just because the user part of the application runs as a normal user doesn't mean all components do (eg. consider a service-client, the server is likely to need higher privilege). And then consider the installer...
    – Richard
    Feb 8 '11 at 8:19
  • 1
    @Richard, that's also true but I believe Bart's point was that the testing needs to be done in an environment that is as close as possible to what the customer will be using. Feb 8 '11 at 21:39
  • 1
    The correct answer to a software issue not related to system tasks should almost never be "run as administrator." Feb 9 '11 at 2:24

In being a developer, I rank us a level of privilege above the basic user, but below the systems administrator(s).

I may, on occasion, need an extra library installed to get the application I am developing to work in the production environment, that being said, I have a strict rule I develop by: "For any application which requires third-party libraries, the libraries should be installed in a sandbox environment prior to production deployment and, in some cases, prior to application development."

The sysadmin I work with and I agree to this, and between the two of us, we will actively enforce that rule and delay any application deployment that has not passed the "dependency checks".

To answer your question though, yes, developers should be given full access to their own machines, but those machines should be isolated from the environment the application will ultimately be deployed on. In which case, even the application deployment should be sandboxed until deemed safe to deploy in the production environment.


Disclaimer: I'm a developer.

To me, this question (and the answers) seem to be attacking the problem from the wrong approach - that is, the debate is focusing on what admins want/need vs. what developers want/need. But you specified we are in a corporate environment, so let's look at it that way.

So let's imagine we are arguing this in front of the director of IT or operations, or whomever controls our budget, and ask these questions.

  1. What is the minimum privilege required to perform department functions? This is our baseline.
  2. What are the risks of granting them more access? (actual risks, not just best/worse case scenarios)
  3. What is the true expected cost of granting them more access? (support costs, fixing inadvertent changes made by inexperienced admin, etc)
  4. What is the true expected cost of not granting them more access? (lost productivity, requiring IT support to perform daily tasks, turnover of experienced people due to morale, etc.)

With these questions answered, you can make an informed decision rather than a passionate one.

For your specific environment, there are some things that require admin rights (see User Rights and Visual Studio) - if they are not doing those things, then you can answer questions 2 - 4.

As a consultant, I have seen both extremes of this policy, and while I always want to have admin access to a machine, in some cases it didn't make sense. And I'm not sure what is cause and what is effect, but without exception, every place that I've seen doing windows development where the devs had admin access also had MUCH higher productivity from every developer than places where they were locked down.

  • +1 because you put it in the right perspective. Take out the personal preferences of devs and admins and focus on what is important to organization as a whole. Nov 27 '14 at 9:44

I think you are asking the wrong question, you should be asking:

Will a good developer work for an employer that does not give him/her admin rights on their PC?

What someone “needs” and what they expect are often not the same thing, after all you don’t need to allow a developer to drink coffee in works hours, but if you don’t…

(Make sure you make your policy clear at interview stage, otherwise you may get people taking the job that then despise your company due to the lack of admin rights – don’t expect programmers to think in a logical way about this sort of thing!)

  • I'll admit that I both work in higher education and am a "systems administrator/programmer", as is everyone in my group, so I guess my experience isn't totally relevant. But I can't imagine working as a developer at a shop that wouldn't give me full control over my workstation (OS choice and installation, software choice, etc.) let alone root privs on it. Feb 8 '11 at 14:55

It depends actually more on who you ask then about who actually needs it. If you ask corporate IT and risk management groups they will be all over you with horror stories (and if they are to give it to you they demand a goat sacrificed in a holy bond of promise that they will not be held responsible), the developers on the other hand demands admin rights mostly because the job is stressful and demanding enough without having to seek permission from help desk to go take a leak. The sad state of affairs is that now its more about power struggle and exerting power then it is about business and productivity needs (e.g. it boils down to who will make the other jump through hoops)

IMHO, the best work environment I've seen to this day is where the two groups are being kept separated. Developers have their own domain in the forest (whereby IT controls what this domain and its users can do in the rest of the company) and they are all local admins with experienced guys with MCSE acting as local domain admins, they have their own test environment and can do pretty much what they want and need on their local LAN with a single IT policy (no pirated software). Corporate IT is not responsible and does not render support to devs and only enforces some high level corporate rules (no facebook, porn or similar through firewall, devs not allow to mess with corporate LAN) and they all have RSA based VPNs to work from home which puts them directly inside their LAN. Neat, isn't it?


The answer is likely to be subjective and specific to each individual scenario, but in most cases I would say yes.


I would say that administrative rights are important for the development process. Given the relative ease of using a VM to sandbox though, there's no reason why you can't put them in a VM and keep security.

Anything goes wrong and you can wipe and rebuild in a matter of minutes.

  • 2
    There's one very good reason not to lock them into a VM - performance. A dev working on a major application could easily use every bit of a high spec machine with massive amounts of RAM, fast HDD, etc. Putting them on a VM is about the same as giving them back their machines from a few years ago. Great for security but not so good for productivity. Feb 8 '11 at 1:51
  • 1
    But great for forcing developers to write to the low end of officially supported machines in the project. Moreover, with virtual servers we're able to do fault tolerance (and in some cases main load) support for live products. All a matter of what machine/cluster your VM is run in.
    – DivinusVox
    Feb 8 '11 at 5:24
  • 4
    It isn't about writing for the low end of requirements, its about using tools that require higher performance than VMs allow. Using Visual Studio 2010 inside a VM is noticeably less responsive than on bare metal. The product you're writing may run just fine in a VM, but that doesn't mean developer's tools always do. Feb 8 '11 at 6:24

Definitely! Usually a lot of the development that goes on may or may not be in a virtual environment. Admin rights help to overcome a lot of the overrides of service handling, registry entries, and IIS locally. On the other hand, it depends on how much trust you have in your developers.

As a developer, it's frustrating when something doesn't work because we don't have access.


Depends. As a developer, one should always operate on the principle of least privileges. If you are working as a government contractor, you might be contractually obligated not to have admin access, for example.

As a Java developer, I've hardly had a need to have admin rights on my machine on an ongoing basis. However, there are legitimate cases when you need on-demand admin access (.ie. you need to move your laptop across physically separate domains, and you need to change your NIC accordingly.) That was the only time were I've really needed permanent, ongoing admin access to my machine.

Sometimes you need admin access because IT is understaffed (or incompetent or mired in red tape.) But if you work with a competent IT department, they can install the stuff for you even remotely (or by providing custom installers that will "run-as" admin and install the stuff for you by just clicking in them.)

So the answer (again) is - it depends. Do you have a responsive IT staff that can install things on demand (or within a reasonable time)? Do developers actually need it for the tasks they are paid for?

If the developers truly and legitimately need it (as in "I will literally WON'T be able to do anything without it") as opposed to a convenience (as in "I want to install whatever I want"), and if IT support is not sufficiently responsive (for whatever reasons), then yeah, they should have admin access to their machines.

Otherwise, no. Remember the principle of least privilege, people.


There are developers and there are Developers. If a "developer" is some $40/hour JBoss java guy writing rules for a rules engine then of course not. If a "developer" is a $350/hour C/Assembly guy getting your video editing software to run as fast as possible on a GPU, then yes, of course.


For corporations that are worried about security, they will have security persons dictate and attempt to enforce a policy that works with their model of development and systems. In a Windows Environment most people will tell you that you must have Administrative rights on the host they are developing on in order to perform their tasks.

This is not necessarily true...

You can create a custom policy and have all programs and functions work with development users on a system. You will just have to get down and dirty and into the nitty gritty with custom permissions on program/system directories with groups or custom groups depending on the desired design.

Most corporations will say it is very dangerous for developers to have systems on open networks because hackers could gain control and start compiling their own tools so going through the task is much worth the risk in my professional opinion.

  • While what you say is technically correct it is also a nightmare to implement and maintain and creates fragile environments. Feb 8 '11 at 0:05
  • I would rather then full access on the dev network, and then only connect to the corporate network over the internet with a VPN if this is a real issue. I also a lot of corporate it departments I have seen provided me with less then what a good ISP does!! There is no need as a developer to be on the same unfiltered network as the account department etc. Feb 8 '11 at 9:17

Developers should (ideally) have two domain logins.

One that has local admin rights (for development work) and one that has the same rights as everyone else in the company. Then, they can test their work on a representative set of permissions.

This should then reduce the likelihood of ItWorksOnMyMachine-itis that appears occasionally.....


I have to (apparantly) provide the dissenting voice and say not only no but "heck no". I have no problem giving devs admin rights on a sandboxed VM that has no network access. Zypher had it almost right (correction bolded):

"1.Being admin on my box is a privilege NOT a right." These systems are corporate assets that I am ultimately responsible for. When Joe Developer installs his pirated copy of Microsoft Bob ("because I needed it") it's not going to be him that has to explain how it wasn't found before the audit. Developers routinely think that somehow the corporate rules just don't apply to them. By giving them a sandboxed VM they can follow all of the rules everyone else has to follow (since now only IT can copy files to and from the system). Magically the request system gets used by developers again, the sky is no longer falling when Joe Developer mangles his development box - he just asks for a new one (or a restore if he's asked for backups)

Mr. Denny mentioned developers costing money when they have to wait for apps to be installed, A. hello ... my time is usually just as valuable as Joe Developer (usually more so since I keep the exisiting crapware running- and do I really have to mention all the time spent helping Joe developer debug his last masterpiece), and B. when dev goes overbudget because they were waiting for an application and try to blame IT for it I'd say:

Your lack of planning for what you need to write software is not my responsibility, we have a standard set of tools and if that toolbox is missing what you need you should have had your requests to get more tools expedited rather than attempt to make me jump thru hoops to get it for you because your deadline is tomorrow.

Having said all this, locking down the desktops of developers stinks, if you could weed out the crappy developers that think thye are entitled to watch their baywatch collection and are outraged to learn they can't install babewatch player to view them ("but it's open source") you might be able to loosen up. But for every great developer out their that "gets" it, there's 10 more that your company is going to hire for that 200 million dollar vertical application instead, and that's who you need to watch out for.

EDIT: It's certianly quite possible that the developers I've been exposed to are unusually dull (polling the current crop only 1 has heard of stackoverflow, to give some level of benchmark). The starting point of view that I begin with is "what do you need to do what the company is paying for you to do". If you need admin rights you get them, but you shouldn't stqart with them and if I can give you a box that frankly I don't care what you do to it and that works then we are both good to go.

  • 14
    Wow, the BOFH lives amongst us! You have failed on the basic principle that our job is primarily one of enabling everyone else to do their jobs as best we can within the limits imposed on us by policies, legal requirements, etc. It is NOT one of arbitrarily dictating to others how they are to work simply because it suits us to do so. Feb 8 '11 at 4:48
  • +1 for the last paragraph. You can eliminate all the other paragraphs if you just hire decent developers. Feb 8 '11 at 5:57
  • 6
    Wow - love the us and them mentality. Did you consider that "his" deadline is actually "your" deadline too since you're all in it together (presumably) for the benefit of the company. I don't know you from a bar of soap, but you remind me of the nasty, arrogant, try-to-find-a-way-to-say-no-rather-than-yes typical sys admin. For everyone 1 good sys admin out there there are another 10 that your company hires that perpetuate the stereotype you just laid out and make every else in the company's lives that much harder. You should be concerned with service delivery, not constraint. Feb 8 '11 at 6:20
  • I have specifically addressed most of these points in an answer: serverfault.com/questions/232416/… Feb 8 '11 at 8:54
  • 1
    Maybe YOU are the reason that the “the developers you been exposed to are unusually dull”…. A company has to decide if it wants freethinking or dull developers and can’t act in a way that freethinking developers hate and then expect to keep anyone apart from dull developers. However dull developers can be best of a lot of corporate work. Nov 19 '13 at 9:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.