Somehow related to this other question. I am dealing with the following case: a medium-large company (with about 200 on-premises employees) is applying the following procedure for all the newly recruited employees (immediately before their first day at the company):

  • they generate a password for the user (NOT a change-at-first-login one)
  • they login on their laptop (impersonating the final user)
  • they apply some configuration (e.g. they access their Outlook email in order to check that everything works)
  • they change again the password (this time with a change-at-first-login one)
  • the laptop is delivered to the user

It appears that this procedure is quite common also in IT companies.

I cannot say if the initial configuration, "in the name of user", is absolutely necessary or just dictated by convenience reasons (a fully working laptop is delivered to a non-IT user, preventing a lot of requests to the IT for fixing common issues), but there a few things that smell:

  • if I should never tell an admin my password (as it has been answered to the cited question) there is no reason that an admin knows my password even at the very beginning of my work in that company
  • I can accept that an admin knows my password (when he first creates my account or when he resets it) provided that it's a change-at-first-login password (so that I have evidence that it's not been used before). I suspect anyway that most legacy systems (like AD) allow admins to reset passwords with great freedom (for example resetting passwords without notifying the user, or without forcing them to set a change-at-first-login one). Is it an accepted practice? This seems completely different from what happens for example in Google (no one knows my password, if an activity is detected I am notified).

Edit: to answer many comments that state that "the computer is not yours, it's the employer's computer, you should not have personal information on the company computer" I would like to point out that it's not a matter of personal information, but reserved information regarding the company business. So, if it's correct that I should not use my company email to receive my blood analysis results from my doctor, it's perfectly common that some reserved information about the company is exchanged between employee A and employee B.

  • 27
    When the computer is joined to the domain and has MDM software installed, the domain admins can always change the passwords and depending on the setup they can also read and edit all the files stored without logging in as the user. As long as they don't know a password the employee might be using elsewhere, they are not gaining any more access here than they probably already have.
    – J.A.K.
    Commented Nov 21, 2018 at 10:31
  • 8
    No - once data has been associated with the account, they could gain access to it without this being logged as admin access. In the scenario above, logs would show the generation of the change on first use password, and actions prior to this could be attributed to the admin. Actions after the password has been changed could similarly be attributed to the user. If you told the admin the new password, that attribution in log files would no longer apply. Another risk is that it's not actually the admin asking - a genuine admin won't need the password in a sensible system.
    – Matthew
    Commented Nov 21, 2018 at 11:17
  • 12
    @wizzwizz4: As a sysadmin, I can read any data while leaving zero evidence from the production systems. Let this sink in. As sysadmin, I have capacity to alter the OS and erase log entries at will, but I need do none of that but only become the backup agent and read files at will.
    – Joshua
    Commented Nov 21, 2018 at 22:44
  • 7
    For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config.
    – Falco
    Commented Nov 22, 2018 at 10:57
  • 3
    @wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token".
    – Joshua
    Commented Nov 22, 2018 at 15:51

10 Answers 10


If I should never tell an admin my password (as it has been answered to the cited question) there is no reason that an admin knows my password even at the very beginning of my work in that company

One of the main reasons to this rule is that Admins should not access your confidential data such as mails, etc... Since there is no data associated with the account at the very beginning this is not an issue.

they generate a password for the user (NOT a change-at-first-login one)

Using a single sign-on password will ask for a normal password before one can change the configuration. So a password is needed before accessing the config.

I suspect anyway that most legacy systems allow admins to reset passwords with great freedom. Is it an accepted practice?

This is an accepted practice. Not old systems but newer systems like Office 365 also allows the admins to reset the users password without notifying the user. However any such resets gets logged in the system and the admin will be held responsible for any issues.

Also note that not all configurations can be changed at Admin level. Some things can only be performed by the user. Instead of telling each and every user to perform a set of steps, they are doing it ahead of time.

Some other concerns of sharing a password do not apply here such as

  1. Reusing the password is irrelevant as the password is not yours.
  2. None of your personal information is associated with the password.

To answer some comments,

I suspect that "there is no data associated with the account at the very beginning" it's not absolutely true: I could have some emails in my mailbox (someone could have sent my some confidential info to my email address, because the mailbox has been activated before I first log in)

by Diego Pascotto

Mail Id should not be shared to anyone by the Admins before configuration. The mailbox must have been activated when setting up outlook. Email Ids are shared only after single sign-in password is set. Also as pointed out by James Snell, receiving an email within minutes of account creation is unlikely.

A competent company has images, procedures, via automation that take care of these things without ever logging in as the new user at any time.

by Sokel

Small companies do not always invest in automating. If a company hires around 10 staff per year and each with a different role the effort required to bring automation and maintain it will be greater than the manual effort. Automation is only worth the effort when you are having job that is done repeatedly in large numbers. In other words, the effort required for automation should be less than what your effort required for manual work

If the admin has had unmonitored access to your account at any point in time; they could've set up anything under your name - preventing any returns to them.

by UKMonkey

Any actions taken by the admins during this time can be linked back to them as it is clear that the account is not handed over to the user until the user resets the password using the single sign-on password.

  • 25
    Also mind: Generally company email are property of the employer, not private data from the employee and (depending on other agreements in employment contract, national law, worker council agreements, whatever) the employer (or their representative as admins) always have the right to access it.
    – johannes
    Commented Nov 21, 2018 at 14:28
  • 6
    The answer ignores a very common policy - what happens to your account is your responsibility. Accountability is 99% of the reason for the passwords; the company really don't care if the admin accesses your personal information - that shouldn't be on company PC's in the first place; and the admin can usually access all data on the network for backups etc. If the admin has had unmonitored access to your account at any point in time; they could've set up anything under your name - preventing any returns to them. So no; it's not ok for the sysadmin to have the password at any point in time.
    – UKMonkey
    Commented Nov 21, 2018 at 17:28
  • 15
    @UKMonkey But if the the admin is setting all of this up before the user has even been delivered the system, there is a record that whatever happened was not done by the user. Everything that was done before the change-at-first-login password was done by the admin.
    – David K
    Commented Nov 21, 2018 at 19:56
  • 9
    @Sokel If automation is 100% always worth the effort, I assume you, personally, have already automated your car (if you have one) to be self-driving? Created an AI to respond to all your emails automatically? Automated your entire job? You've built a machine to shampoo your hair for you while you're in the shower? Or perhaps you've decided that some things would be too time consuming (perhaps to the point of impossibility) to automate and make strategic decisions based on the time, complexity, and failure modes of a task about when to automate and when to do things manually? Commented Nov 22, 2018 at 21:06
  • 8
    @Sokel: I work at a company with 7 employees and have only hired 1 person in the last two years. Are you really going to tell me automation is always worth it? Do you assume we have an entire desktop/IT support team and not just a single employee that does that stuff now and then? Not everyone works at a massive corporation. Commented Nov 23, 2018 at 6:16

In a small company, it is likely that the administrator that sets up a new employee's machine is also the administrator of the company emails and document servers. In which case, the admin is already able to read your emails or send an email as you at all time without ever needing access to your machine.

If this is the case, then there is no new security issue here, although it's true that the practice is kinda superfluous. In theory, an admin should never need to login to your account using an active password; they can login as administrator account instead and pretty much do anything they needed to do from there.

In practice, unless your IT team is well practiced enough to be able to set up new machines repeatable, correctly, and reliably every single time, it is often significantly easier to login as the user to test setup and do some configurations that are just easier to do as the actual user rather than trying to simulate the effect while being logged in as the administrator. Many enterprise systems are designed to allow admins to be able to reset another user password or impersonate another user without the user's password, often this is logged to allow auditing, but in smaller companies, the same admin likely also have access to the system where they can tamper the audit log.

The main reason for the adage that "never tell an admin my password" is to prevent users from falling victim to social engineering, because if user are told all the time that a real admin never would actually need or ask your password, it becomes an automatic response that only someone pretending to be an admin would ever need to ask you your password. The secondary reason is that a lot of people reuse their password; in which case they may share much more than they realize. Neither of these applies in this situation.

  • "they can login as administrator account instead and pretty much do anything they needed to do from there." I've been specifically told by IT personnel that something about AutoCAD or some of its plug-ins made this impossible. Unfortunately, I don't know the exact details.
    – jpmc26
    Commented Nov 21, 2018 at 20:26
  • 2
    @jpmc26: I know about it. Basically, to make AutoCAD work you had to install it with admin rights as the user who would be using it. The software wrote all kinds of stuff to HKCU during install.
    – Joshua
    Commented Nov 21, 2018 at 22:49
  • As an admin, my third reason to never ask the user for their password is that I compare it to handing me the keys to their car or home... Then they would have no proof that it was me or them that did something nefarious. Commented Nov 21, 2018 at 23:48
  • It doesn't really make it impossible though, an admin can modify another user's HKCU. Though it's probably just a whole lot easier to just let the software do it than to figure out which keys gets modified.
    – Lie Ryan
    Commented Nov 23, 2018 at 10:42
  • @LieRyan Let's just leave it at "prohibitively expensive," then, as trying to duplicate the logic of the AutoCAD installer (which probably changes by version) is an entirely unreasonable proposition. ;)
    – jpmc26
    Commented Nov 24, 2018 at 22:44

I'm going to approach this question from a different direction.

Your question is based on the assumption that the account is the responsibility and/or property of the new user at the moment it is created, but that's not really true.

When the account is created, it belongs to the IT department, not to the user.

The initial setup you describe is happening before the new user takes possession of the account.

The fact that the account has the new user's name on it doesn't change this. The admin could create an account for Donald Duck, and then later change the name to that of the new user.

The user only takes possession of the account and becomes responsible for it when they log in and assign their own password. That's the hand-off of the account.

Suppose you order a pizza for delivery. The shop writes your name down and starts cooking the pizza. They could put the wrong toppings on it, or burn it, or drop it. Is this a security concern, because they have access to your pizza? No, because it's not your pizza yet. It hasn't been handed over to you. If the shop makes a mistake, they are responsible for correcting it.

Once you have paid for it and taken delivery, it becomes your responsibility. If you drop it, or throw it at your neighbor, the pizza shop is not responsible.

Regarding email concerns, if email is present in the account before the user's first login, it doesn't matter, because it's not his email yet. Email isn't secure anyway, it's easily viewed by any number of people. Also, in most jurisdictions, corporate email is the property of the company, not the individual.

  • However; if your company hands you a laptop which you can use for private usage, most countries have privacy laws in place to protect the user from being spied on by the company, even though they might technically own the laptop. You have privacy at work and you have privacy when you're not working. Following your theory, that means the company can just install RAT software because they own the laptop, then give it to the user and no harm done?
    – Kevin
    Commented Nov 22, 2018 at 0:33
  • @KevinVoorn: I was getting ready to answer in a similar vein with a simple scenario-the employee-to-be decides the job isn’t worth it, and never starts work.Now,there’s activity under a username that would have been used by him had he actually started work.What is the never-employed on the hook for?Nothing, because he never had access and didn’t do anything, and it can’t reasonably be alleged that he did.Same thing for things that happened before he started work. As for the email and privacy, turn it to the physical: he barged into my cube without a by your leave and rifled my filing cabinet.
    – jmoreno
    Commented Nov 22, 2018 at 0:52
  • 3
    @KevinVoorn the whole question of whether or not an IT admin could do illegal or nefarious things is irrelevant, because the question is about any inherent risks in the procedure described, NOT about any inherent risks in trusting IT staff. If your IT admins want to install nefarious software on your computer, they don't need YOUR login to do it.
    – barbecue
    Commented Nov 22, 2018 at 1:18
  • 3
    @jmoreno Here's a real-world example from my own experience. A user was hired for a position, an account was created, computer previsioned, etc. Shortly before he was to start, a positive drug test came back, making him ineligible for the job. At that point, the runner-up for the position was contacted,. She accepted the job immediately. The existing account that had been created for the first employee was simply renamed for the new employee. Neither employee owned the account yet. The account was still under the control of the IT department.
    – barbecue
    Commented Nov 22, 2018 at 1:26
  • 2
    @KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed.
    – barbecue
    Commented Nov 22, 2018 at 1:36

is the configuration made by admin AS THE USER an acceptable practice?

Yes it is.

As with all practices it depends on the context. But generally speaking this is a common and acceptable practice, given that you have a basic level of trust in your admins and not a super high level of security need, like when you guard state secrets.

It is okay, despite the general rule, because initially your account does not contain sensitive data. While there is a short time-window where mails could come in, before you changed the password, this is typically so unlikely to a) be the case and b) contain really sensitive data that it is usually not considered an issue.

Note that many companies retain the right to access your mails and/or files on your work machine anyway. Though ethical companies will guard that access with either a requirement that you are present or that at least two admins are present when they log in to your account, to make sure they only act in line with their administrative task, e.g. remove a virus, look for a totally necessary file while you're on holidays etc. The same safeguards could be in place for this short time where they have direct access to your new account.

Note that you have to trust your admin department in general - they could simply install a corrupted system anyway. The risk of impersonation within the short time frame is minimal however, as it is clear from your contract and the timestamp of your initial password change, from when on you had control over your account.

Whether the practice is acceptable without further safeguards, e.g. 4 eyes principle, depends on the security needs of your company/job. The more crucial security is the more strict the safeguards need to be - and the more one would aim at automating these processes to minimize the window of opportunity for anyone to corrupt your machine/account or gain temporary access to your data. Note that the latter could also be achieved by simply having you activate your mail address once you reset the password.


Generally it recommended to use a personal account for everything you do. Logs will show who did what. That's why admins don't just all log in with "root" or "Administrator", but have their own accounts: you can tell who did what, and you can easily revoke the administrator's credentials without changing the password for all administrators.

Users have trouble choosing secure passwords. If they memorized a few strong passwords and use those for everything, you can probably consider it an above-average user already. If administrators know the user's password, they might be able to log into the user's private accounts (such as personal email, music streaming service, whatever). The administrator can always impersonate a user: they can reset the password, and often it's also possible to just log in as that user without knowing the password. On unix-like systems, you can run the command su john to log in as john: if you are a normal user, it will ask for john's password; if you are root, it will just log you in as john without needing their password. This is not recommended for the reason mentioned in the first paragraph, but it's totally possible on many systems.

The final piece of relevant information is that things are easier to configure from the user that needs it. If John needs Outlook, you can write a script and schedule it to be executed on first login. In smallish organisations, however, it might be more efficient to just log in as John once and setup Outlook manually. Windows in particular does not lend itself well for scripting: most of it is possible, but it's not well-established and some things are still accessible only through the graphical user interface (GUI).

In conclusion, assuming that this is the established procedure, I see no risk in it. The administrators can log in as any user anyway, so they are not gaining more privileges through it. They are also not learning the user's personal password. The only issue is that logs will briefly show activity under the wrong name, but I see no benefit for a malicious administrator: there are a thousand other (easier) ways to do malicious things.

  • 1
    From your answer i see that it is an accepted practice that an admin sets a password for the user and logs into a system as the user (I'm limiting only to Windows system). If a malicious admin then reads the user's emails this must be considered an acceptable risk (he is not gaining more privileges with that action). What about sending an email as the user? Commented Nov 21, 2018 at 11:23
  • 5
    @DiegoPascotto - there's no reason to limit it to windows. It's perfectly reasonable for IT to check that the user environment works correctly before the account/machine is handed over to them. It's not usually necessary, but in a small/medium business like that it's hardly unusual. Commented Nov 21, 2018 at 11:33
  • 4
    @DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user.
    – Luc
    Commented Nov 21, 2018 at 13:22
  • 5
    @DiegoPascotto "If a malicious admin then reads the user's emails" Wait what? Earlier you were saying it's a one-time thing when creating an account. Now you say there is email in the user's account, implying that the admin should not read it. If you change the question, you should not expect my answer to still match. Reading/sending email is different from finishing an account setup.
    – Luc
    Commented Nov 21, 2018 at 13:24
  • 1
    I'm not changing the question, it is actually a one-time thing. I guess it is not a frequent situation but it may happen that during this operation (the Outlook configuration) the inbox has already some incoming messages. In this case the reading (voluntary or not) of an email would be almost unavoidable (imagine the preview panel which is set by default). My question is still "is the configuration made by admin AS THE USER an acceptable practice"? Commented Nov 21, 2018 at 14:27

Acceptable But Not Ideal

In order for this to be acceptable, it should be part of a documented procedure. This serves to explain the reason for the behavior as well as to preclude any accusations of impropriety.

Documents are generally approved when signed off or otherwise finalized, so this would also establish official approval of the practice.

Better Idea...

If there are actions which must be performed with the user's credentials, it is preferable to automate the process. The automation can take the form of a script, a setup wizard, or a self-service portal---whatever the organization prefers.

This provides multiple benefits:

First, the user interaction is minimized to prevent misconfiguration. Second, administrator "touch time" is reduced. Third, the configuration will not suffer from human errors or inconsistency between deployments. And, finally, your concerns about account use will be eliminated.


There are additional skills required for automation (compared to manual installation), and your organization may not have those skills. Some platforms are difficult to automate, although this is less of a problem than it used to be. Or, the company simply may not understand the benefits of automation.


There seems to be a mistaken assumption here, that a portable PC owned by an employer and an e-mail account provided and paid for by an employer in some sense belong to the employee. They don't! The situation is that you are employed and paid to operate their equipment and to process their data. (Ditto, the sysadmins).

So the only way to be certain of privacy, is to handle private matters on hardware that you own personally. Your mobile phone connected to the mobile network is probably that device, while you are at work. If you employer allows personal use of its connection to the internet at large, secure (https) communication with a personal account on an external e-mail service such as Gmail is almost as safe -- just as long as you trust your employer not to do anything blatantly immoral such as installing a keystroke-logger on your employer-owned PC to intercept your private password and a screen recorder to allow the employer to watch your screen later. In the EU this would be blatantly illegal unless the employers policies (which you have been made aware of and which are part of your contract of employment) warn of such. It's likely to be illegal even if they do, unless you are working in a particularly sensitive environment (in which case all personal use of the employer's hardware is likely to be forbidden for sensible security reasons).

The sysadmins are paid by the employer to maintain its assets in accordance with its policies. These policies ought to comply with the law. So in the EU there is an expectation of privacy with respect to e-mails, hedged around with actions necessary for the employer to perform. So a sysadmin may have to look at "private" e-mails in order to administer a mail server system, but should not ever reveal or act on what he sees unless it reveals some serious misconduct or crime. He certainly should never deliberately look at e-mails outside the policies set by the employer and known to the employee.

But a bad or corrupt sysadmin is privileged, so there is nothing you can do to protect yourself from him. If you don't fully trust your employer, at a minimum don't use it's hardware for private purposes that would hurt you were they to be made public. At a maximum, you should be looking for a new job!

In passing, I'm a small-company sysadmin, and set up PCs pretty much as described. At a previous employer, it was s.o.p. to send a single e-mail from the newly configured PC to the the sysadmin's company e-mail account, reply to that, and delete the reply, to make sure everything was working well. It was also s.o.p. to send a longer e-mail from the sysadmin to the newly created employee's account, generally welcoming him to the organisation and providing standard information about getting started. It would be waiting for them after they logged in for the first time, resetting their password.


What the other answers miss IMO is:

Why isn't this process automated?

Provisioning of user accounts (no matter of the operating system) is nothing what an admin should do by hand over and over again. The initial configuration of a user account and provisioning of software can be done via automation. The setting of the user account's respective password would be done automatically as well. This should be "change after first use". This automation process has to be reviewed regularly and has to be implemented with a four eyes principle.

Everything an admin does on a machine should be logged. If an admin just roams freely on a system before provisioning, 'bad admin'-scenarios are bound to happen.


As this answer has stirred up some conversation, let me add the following:

Here are the some tools to provision Windows images to company hardware, for Windows 8 the Microsoft Deployment Toolkit and the System Center Configuration Manager for Windows 10. These tools are official Microsoft tools, they are free (as far as I can tell) and from frist glance pretty well documented. There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily. All admin accesses to a machine should be done via tools like these and should be logged with a logging server. Then there are less possibilities for a single admin to manipulate a single machine.

If an admin handles every machine by hand, 1) manipulation is possible and 2) errors are bound to happen. An automated process can be reviewed and audited, a manual process is impossible to control.

The commitment to tools like these is a step towards a more secure provisioning of operating systems and user accounts in a company environment.

  • How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
    – Kolappan N
    Commented Nov 22, 2018 at 3:58
  • 2
    To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
    – Nelson
    Commented Nov 22, 2018 at 4:55
  • 1
    @TomK. Have worked in large and small orgs for many years. You cannot automate everything. It can be a lot more efficient for the admin to do this by hand before the user comes in rather than walking the new user through the whole process on their first day. For a "new user experience" to hit them with a complex and error-prone process is a poor first impression. And they are admins, they have access to everything anyway.
    – schroeder
    Commented Nov 22, 2018 at 13:07
  • 1
    @TomK. except that the admin who does this would be known. "Tom was configuring new devices". And I'm not sure why there needs to be further attribution when there is no access granted or exercised.
    – schroeder
    Commented Nov 22, 2018 at 13:55
  • 1
    I'm asking because from experience, it's usually only the people who never had to figure out why MSSQL failed to install correctly automatically although it works perfectly fine if you try the same command line parameters in the interactive CLI session, who think this is trivial and done in an afternoon. Doable? Absolutely. But a pretty big investment that requires constant involvement (you need new images very regularly and the setup procedures change all the time). For a small company the ROI just doesn't exist in my experience.
    – Voo
    Commented Nov 24, 2018 at 21:35

I feel like this question just points out the dichotomy between "how we wish IT worked" vs. "how it really works".

At some time in history, I bet the IT guys setup a laptop for an exec. When they passed the laptop off, the exec was peeved when it didn't work or needed additional setup. So, they get yelled at, and that's probably when some policy started of "log in and make sure it's fully setup and working before hand-off".

Is this ideal? No. But, nobody in IT is ever surprised at the amount of accomodation IT makes to get things running smoothly in a company, especially when it impacts higher-ups.

It's sort of like how a contractor that gets hired, but keeps giving the hirer bad news will be out of business.. well, an IT dept that keeps running things by-the-book and upsetting the folks that hire them will eventually get replaced.

IT is often walking on eggshells, and has to pick-n-choose its battles.

Setting up a laptop and logging into it to do any post-setups for odd programs and double-check to make it all work (QA) before hand-off... that's something IT just made a concession for to make everyone's life easier. As long as IT admins were the only ones doing it, it was a "safe bet" to make.

But, when execs ask someone to log in for them and do work (to which, the admin could get suckered into cooking the books for someone without realizing it).. or an exec / manager asking IT to relax on a policy intended to protect users from themselves, or protect the servers from viruses (eg: "just let my people keep their passwords on post-its next to the computer"... um, no.)

You have to pick-n-choose your battles. You can nitpick policy all day long, and in fact if you keep digging into policy you'll be getting frustrated at seeing all the little consolations the IT dept is making to keep things running smoothly.

The other issue with this is that as the IT dept makes consolations, they can be seen as a group willing to bend rules.. so some folks may not take rules as seriously, or expect them to bend them to the point of breaking.

So, IT, much like Bruce Lee's Jeet Kun Do philosophy is "be like water". You want to fill the needs and desires of the company you're working for to make things go smoothly while also satisfying your primary purpose. But, you also want to be a force to be reckoned with if someone pushes you in a direction that is clearly bad for themselves or the company.

This is why there's a delicate balancing act at companies. You want to hire trustworty people in IT. I would rather have mediocre IT employees that I trust then rockstars I'm worried are finding ways to embezzle money on the side or pimping out the servers to work on contract work at night.

On the other hand, I also don't want exec staff to think they can walk all over IT. Dealing with IT should be like dealing with the police. They need to be trustworthy that they have enough power to push back against people being arrogant, but also trustworthy enough that they're not abusing their power.

So, tl;dr... I think you're getting stuck on a policy that doesn't look ideal from an academic / ideal perspective, but was probably born out of a past faux pas, and now acts as the IT dept caring enough to QA things before handing them off blindly.


You buy a new car. At least once a year you take it to mechanic for maintenance (oil check etc.). Most of us will give mechanic a key and went to do something (shopping, coffee, etc.). They have a complete access to your car. They can do anything. Do you consider it as a big problem alto you could leave/forget your private/office laptop inside or some personal documents or....??

Just as maintenance of your car, preparing your account is something that need to be done. You can sit by, watching and pretending that you know what they are doing or let them do it by themselves trusting them they are professionals and know what they are doing.

In case of moving to a new job, I would be more concerned about my full mailbox left on old job that empty one on a new job.

Being paranoid is quite OK, as long as you are sure you know why you are paranoid.

This remind me of a GDPR joke:
In the doctors office nurse comes out saying: "Due to GDPR I'm not allowed to say your names in public, but the one with syphilis can go to see doctor...."

  • This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
    – schroeder
    Commented Nov 22, 2018 at 13:02
  • Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys! Commented Nov 22, 2018 at 13:50

You must log in to answer this question.

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