I am the volunteer IT administrator for a local non-profit organization. The organization has a few systems - specifically security cameras, network hardware, and telephones - that have local administrator accounts to manage them. Right now, I am the only person working for the organization with any amount of technical knowledge about these things. As part of our disaster recovery plans, I am writing a complete manual for administration of everything in the building.

The problem is what to do about passwords. No one else in the organization wants to be responsible for having the administrator passwords to everything (and honestly I don't trust them anyway), but reducing the bus factor necessitates that a password be available somewhere for some other person to manage these devices in the future.

My first thought was to use something like LastPass's "Emergency Access" feature that allows another user to request access to an account, except that I have no idea who that future user might be to give them permission and I have no confidence in this feature working properly anyway (since my wife and I tested it with our accounts and it didn't work).

My current thought (loosely inspired by the opening scene of WarGames) is to generate secure passwords for the accounts and make scratch-off cards with the passwords on them. These cards would be kept in a sealed envelope in the manual binder. Access to the passwords then requires opening the envelope and scratching the cards.

I am not worried about someone going through the effort to steam open the envelope, scratch the cards, copy the passwords, then re-cover the cards in scratch-off material, and perfectly re-seal the (signed edge) envelope. Physical access control will prevent outsiders from doing that, and we are confident that all of our insiders don't want the passwords and wouldn't know what to do with these passwords even if they had them.

I know that this plan is still vulnerable to anyone with physical access gaining admin rights, but I can't think of any better options.

Is this a good plan? Are there better alternatives? Or am I overthinking it?

  • 15
    How many passwords are we talking? Why not just print them and put them in a physical sealed envelope which you put on top of the admin's physical files. Then tell a couple co-workers (witnesses) about it.
    – Joooeey
    Commented Oct 22, 2020 at 8:46
  • 6
    @kelalaka I have never seen a network switch or a SIP desk phone that allows two-factor authentication for administering it.
    – Moshe Katz
    Commented Oct 22, 2020 at 14:41
  • 25
    If this organization is large enough to have this IT setup, it probably has an attorney, and handling this sort of thing is one of their routine responsibilities. Commented Oct 22, 2020 at 19:00
  • 5
    You're over thinking this. You're not trying to defend against Law Enforcement or Government Agents. A thumb drive and maybe a CD in a safe deposit box or even a lock box should be sufficient to the needs. Commented Oct 22, 2020 at 23:59
  • 5
    A regularly updated password manager (like KeePass) on a thumbdrive stored somewhere securely is plenty. Anything more elaborate than that is not only overkill, but will actively discourage you from keeping it up to date, and be detrimental to usability.
    – Xander
    Commented Oct 23, 2020 at 2:39

14 Answers 14


Offline password manager

I would use an offline password manager (for example, KeepassXC as an open source option) for the whole list of credentials that may need to be accessed by someone else.

The encrypted file containing the passwords can be given to any relevant persons and management beforehand, or it may be stored in some network location that's accessible also to some of your colleagues. But the passphrase (and possibly 2FA token) to access that file can be physically put in an envelope in a safe to be given to the appropriate person if/when needed.

This also means that you can continuously keep that credential list up to date without touching that 'envelope in a safe'.

  • 5
    It seems obvious to me that the last sentence is the only motivation and advantage of using a password manager as opposed to simply archiving a hardcopy of the passwords. Commented Oct 23, 2020 at 15:47
  • 9
    @Peter-ReinstateMonica it's a pretty big advantage!
    – Kat
    Commented Oct 23, 2020 at 18:47
  • 4
    What an understatement. There are 2 things to do: 1) being able to provide access to the passwords to an unknown future person and 2) keeping the passwords up to date. So your "only motivation and advantage" is 50% of the goals. Pretty significant to me.
    – Bakuriu
    Commented Oct 23, 2020 at 19:04
  • 3
    @Peter-ReinstateMonica I would argue that there is a significant benefit for a password manager by itself in comparison to a paper hardcopy as soon as you have more than a few credentials - if a new admin has to manually change all the credentials which are long, secure passwords, entering random combinations of non-alphanumeric characters from paper is inconvenient, and it's quite likely that you would also want to store non-password credentials such as SSH keys or signing certificates which also can be printed out as a backup but it is a bit of a pain to re-enter a SSH keyfile from paper.
    – Peteris
    Commented Oct 23, 2020 at 19:40
  • 1
    @Peter-ReinstateMonica Providing access to the correct passwords to an unknown future person. You can't split providing access from ensuring they work. I just had to do recovery with passwords on paper. It stinks. Some worked. Some were out of date. Some were transcribed wrong. Some needed answers to security questions. Some needed 2FA. Its fortunate I had access to their email account and phone.
    – Schwern
    Commented Oct 24, 2020 at 19:36

I would do something like this:

  1. Create an encrypted text file with the passwords that has enough copies to survive the level of disaster you're protecting it from.
  2. Make a plain text printout of the private key used.
  3. Store this printout in a secure place (the bank's lockers, at an attorney, in a fire resistant safe) but make sure its location physically differs from the encrypted text.
  4. Make a fool proof guide on how to use the key to decrypt the text file. Make sure to add enough details so the software used can be identified years later.
  5. ???
  6. Profit.

If you use such a key to co-encrypt your up-to-date password file it would mean that with some steps a person in the know can gain access to the accounts.

If you prefer a more service based solution you could convince your fellows to use a password manager for it. Most of those can be setup so that you need 2/3 keys (or however many you need) to unlock the database.

In a pinch even a service like Last Pass could be used, but those require payments for their upkeep and would just shift the problem without actually solving it in my opinion.

  • 2
    This is very similar to the advice I gave my brother (single dad) who wanted a way to secure his passwords but have a backup plan incase he died. Use something like Keypass or Bitwarden ... have other non-technical people in your organization generate rsa priv/pub key pairs ... tell them to stash the priv in a safe place and give you the pub ... then encrypt the master password of your password vault w/ each of the public keys and leave directions for your replacement on who to contact and how to decrypt. Thus you can change passwords in the safe w/ out having to do it all over again. Commented Oct 22, 2020 at 6:58
  • 14
    What benefit does this have over just printing the passwords and putting them where you would put the key other than adding an extra step that a non technical person might struggle with?
    – ydaetskcoR
    Commented Oct 22, 2020 at 15:12
  • 2
    It would also separate the secret from the printout. Just having the decryption key therefor does not meant you have the password. Having the encrypted password file does not give you the passwords. In short its a mechanism to protect against having a single point of failure. (You need atleast 2 things)
    – LvB
    Commented Oct 22, 2020 at 15:35
  • 2
    @ydaetskcoR The password file can be kept current without having to update the password stored in the bank (assuming the OP is able to access the password file without the paper in the bank). Commented Oct 22, 2020 at 18:06
  • 1
    As OP is concerned about the technology literacy of someone, he might explicitely not want to make it too fool proof, requiring the padawan to show they have some basic proficiency before reaching higher knowledge. I completely agree about software versions, though. Although they ideally wouldn't matter, you don't want unable to decrypt the contents just because they have a newer openssl version. Knowing the exact versions used for testing the procedure would allow the next administrator to replicate with those if usual ones failed.
    – Ángel
    Commented Oct 23, 2020 at 0:03

There's a lot of good ideas here to pick from. However, all of them should come after a key step: develop a threat model.

What sort of adversary are you protecting against? This will dictate how well you need to protect your copies of the password. What sort of interruptions are acceptable for your organization, and how bad can a lack of these passwords upset the organization.

For many organizations, a file where you write the passwords down is a sufficient match to the threat model. For others, you may need a offline password manager. If you're in the bitcoin vault business, with billions of dollars at stake, you probably want something stronger. There is no one solution for everything.

When I was in college, one of the students who ran our Kerberos server left without handing it off. We had a hacking party to try to break into it, but no avail. We ended up re-imaging the computer.

What was the cost? It turned out not to be very high. We did not have anyone who was using Kerberos in an "essential" way. It was really just convenient for us to have it. Nobody really tried to keep our data safe. So when the server went down, we found ways of accessing our data without Kerberos.


If physical security is not a concern for you, given all of your constraints then a time-delay combination lock might be a better option than scratch-off cards. Install one in a fixed visible location and set it so many people become aware before it opens.

  • 3
    Just be aware that these types of devices are more often than not extremely trivial to bypass. Do your research before purchasing one. May also be good to go for a fully mechanical solution, so you don't need to worry about dead batteries. Commented Oct 22, 2020 at 13:31
  • With my locksmithing teacher, we went to a bank where such a lock with a mechanical clock had supposedly malfunctioned, and spent an hour trying to effect an NDE. In the end, we decided to come back the next day and drill, but the next morning the lock opened. The manager had set the clock wrong by several hours.
    – Conrado
    Commented Oct 24, 2020 at 18:07

I'd just print them out on a medium that is going to survive the device itself (so laser printer instead of inkjet), and ask the organization's administrator to put them in the organization's safe, inside an envelope that lists the devices' type and asset tags (so a future administrator can determine when it is safe to throw away).

Realistically, none of these devices will be in operation twenty years from now, and even ten is probably going to stretch it, while the organization most likely has record-keeping duties for ten years, so it would be a matter of adding an envelope to that pile. Give it a different color.


Your intention here is to make your replacement grateful to you for your foresight/planning, and not curse your name for years to come.

Upshot - if you contract Red Bus Syndrome, whatever process has to be accessible and simple for non-technical people to find a technical person/team to replace you.

Do consider the risk case - its a non-profit. Doubtless there will be personal information of users but there's not going to be any credit cards or state secrets to protect from malicious action.

20 years ago I worked in a high school as network administrator. There were plenty of disparate credentials, from wireless APs to printers to Active Directory stuff, and bios passwords through to web-based software services and site serial numbers.

All of this was in an encrypted text file which was stored on a 32 MB USB1 pen drive with write protect switch, that hung on the wall behind my 17" CRT. Any password change was edited into that file when it happened. Every school holidays, which was about ~4 months, I'd print the file onto archive paper, fold/envelope/seal it, and the finance lady would store it inside her fireproof safe. Then I'd dispose of the obsolete copy in the coal-fired boiler's firebox.

Each printout had a "date printed" field on it to help avoid mix-ups.

  • After I left that role, there was a major earthquake which wrote-off the school. I later learned that several of the hosts I had running had run non-stop since 2006 through to 2011, without reboot or update. The password system had lapsed, but since few things had changed, the last version was still 95% useful.
    – Criggie
    Commented Oct 24, 2020 at 21:39

You could generate n of m key shares that need to be combined in order to recover the original secret using Shamir's Secret Sharing algorithm. Then you distribute the parts amongst different people. You can decide whether you keep the remaining part or even create more parts than necessary in order to reassemble the original secret.

E.g. using the following implementations: Windows: https://github.com/aseidlitz/ssss-win32 Linux: https://linux.die.net/man/1/ssss


The following example shows how a password can be split without revealing it. It should be split immediately after creation e.g. printed. The complete list then needs to be discarded. One could also pipe it into a small script that reveals only one line and then clears the display.

$ sudo apt-get update && sudo apt-get install -y ssss
$ head -c 16 /dev/urandom | base64 | ssss-split -t 3 -n 6
Generating shares using a (3,6) scheme with dynamic security level.
Enter the secret, at most 128 ASCII characters: Using a 192 bit security level.
  • The problem with this is one has to share the secret, so the dealer knows it. The other, once the k people decide to construct the key, then they know the result, too. There are some works to solve these issues,
    – kelalaka
    Commented Oct 22, 2020 at 12:54
  • 2
    Nice idea, but I'm worried that the people holding onto the pieces will lose them or accidentally throw them away in a year or two not realizing that they are still useful. That's why I want something I can keep in a central secure location.
    – Moshe Katz
    Commented Oct 22, 2020 at 14:49
  • @kelalaka: The key can be created in a pipeline. I've updated the answer with an example. Commented Jan 14, 2021 at 19:26

The scratch-off card idea is interesting, but those can be tricky to make. Plus there's always people like me that scratch too hard and tear the paper. Not to mention water damage...

Instead, you can save the passwords on a slim flash drive (or even a few scraps of paper) and put them inside a good old-fashioned piggy bank (grab one at a thrift store for a few bucks). You have the same "break glass in case of new administrator" effect but easier to implement. And it looks better out on a shelf.

Updating passwords is difficult once they're sealed away, though. If you want something easier to update, try this. Record all your passwords in a normal text file, then encrypt the file. Store the encrypted version of the file in several easy-to find places (you can even keep a printed copy of the hex dump of the file in your desk drawer). Provide a copy of the decryption key and instructions to someone like your organization's lawyer or store it in your deposit box at the bank (if you have one). That will let you update your password file whenever you need to, and the static copy of the key is still valid. For the best chance at disaster recovery, encrypt using a one-time pad. These are much easier to decrypt by hand, in the event that your successor doesn't have the software that you used. Your file isn't going to be very long, so you don't have to worry about a gigantic pad.


I think what I'm going to put its the combination of different elements from the answers, There is a service called Hashicorp Vault. This is a secret manager where the vault can be closed using the Shamir algorithm so you can create secrets and the access to them through devices, sso or username/password in the platform, but once you lock the vault this can only be unlocked with a set of passwords you can share with the main involved ones in the business. Vault


If you have a little bit of software writing capabilities (and your colleagues don't) then you could encrypt the list of passwords with a password that you give to your backup folks. But then to access the encrypted data they have to start a process that sends your admin account a message/email as a notification, and then after some amount of time (i.e., 24h) gives them access to the encrypted password file.

If you were still with the organization and this access was undesirable, you could kill the upcoming access to the file.

Certainly this could be circumvented with some technological knowledge but:

  1. It would require technological knowledge, which the people you are trusting with the backup passwords don't have.
  2. It requires the password either way, so you don't have to worry about an attack from someone on the outside.

The main failure to the system is if one of your trusted people ends up letting the password get out into the wild, and then an untrusted person gets the password, has technical knowledge to stop your warning system and has enough access to the computer that is running the warning system (such as to unplug it's internet, though there are ways your software could require that).

You could also combine this with a distributed shared key as mentioned elsewhere which would mitigate the risk further - though I'd have more than one distributed shared key if you do that, otherwise everything is lost if one key is lost.

So it's not foolproof or perfectly secure, but what you want is something that allows for a compromise of security to begin with.


In my opinion you're not overthinking it. Rightful access during an emergency is as much part of the information security puzzle as other considerations. I'm in a similar situation and part of our solution involves the use of KeepassXC with a second factor, which is already mentioned by others, but for which I will expand on in this answer. KPXC can be used on numerous platforms. I also draw to your attention two additional utilities that make this a good choice:

  • KeepassDX, which gives you access to your kdbx file on an Android device ^1,
  • and keepassxc-cli, which grants automated exports from the command-line.

Exporting the contents of a kdbx from the cmdline

Firstly, you don't actually need to automate the export. You can periodically produce a plain-text export from the secrets database using the Database > Export > CSV menu option, and place this file somewhere secure. You could theoretically place this into an encrypted container, eg LUKS or Veracrypt. Of course, unlocking, mounting, writing to, and un-mounting such a container could also be automated using a similar auto-type technique, described subsequently.

To export the kdbx entries in semi-structured form (xml) from the command line, using keepassxc-cli:

keepassxc.cli export --key-file ~/Desktop/.N.key ~/N.kdbx

Now, in our case, the export is piped to openssl, which in turn encrypts using a complex password that likely can't be remembered, but can be transcribed relatively easily ^3 on a phone's soft-keyboard.

_KFILE="Nkdbx.$(date +%Y%m%j%H)" && 
_KPXRT=$(keepassxc.cli export --key-file ~/Desktop/.N.key ~/N.kdbx) && 
echo -n "$_KPXRT" | 
openssl enc -aes-256-cbc -pbkdf2 -iter 3000000 -out "$_KFILE" && 
unset _KPXRT && chmod 0400 "$_KFILE"

To decrypt the export backup in the future, but limit the output on the cli using grep (ie. once you decrypt and print to the cli, you must then change those account passwords to ensure the credentials can't be found in some scroll-back buffer or log):

openssl enc -d -aes-256-cbc -pbkdf2 -iter 3000000 -in Nkdbx.2020xxx | grep -9 'ACCOUNT_CLUE'

... where ACCOUNT_CLUE is some search string for the account details you're looking for

Configuring a new KPXC entry to auto-type an encrypted export

In KPXC, you can create entries that are configured to auto-type into a terminal window, which unlocks a particular KDBX file, and dumps the content into a plain-text file using keepassxc-cli ^2.

The use of these auto-type entries is done by bringing up a terminal window, then switching back to your KPXC window, then selecting the appropriate entry, right-clicking, and selecting Perform Auto-Type. KPXC will now switch back to the terminal window and execute the command on your behalf.

Screenshot of the auto-type function, with command terminal shown in the background

You configure auto-type through the Auto-Type settings in password Edit entry, and you manage the commands in the Edit entry > Advanced > Additional attributes section.

First, we'll add an attribute called CLI_PWD and tick PROTECT. Now, click Reveal and then click in the edit box. Finally, type the password for this kdbx into this, then Apply.

Screenshot of CLI_PWD protected attribute data entry

We'll add an attribute called CLI_EXPORT with the value described previously, but now on a single line:

_KFILE="Nkdbx.$(date +%Y%m%j%H)" && _KPXRT=$(keepassxc.cli export --key-file ~/Desktop/.N.key ~/N.kdbx) && echo -n "$_KPXRT" | openssl enc -aes-256-cbc -pbkdf2 -iter 3000000 -out "$_KFILE" && unset _KPXRT && chmod 0400 "$_KFILE"

Next switch to the Auto-Type section for the entry and choose use custom auto-type sequence:


This bit can be tricky, and will depend on your machine as well as the parameters you chose for your kdbx security ^1. On my machine, {DELAY 400} is enough time for keepassxc-cli to load and parse the kdbx file, and {DELAY 4000} is enough time for the kdbx file to be unlocked. What will happen if these auto-types occur too early is that the secrets will show up in the command line - everything else works as expected, however, because it is still read as stdin.

Doco is here: https://keepassxc.org/docs/KeePassXC_UserGuide.html#_configure_auto_type_sequences

I should note that this is a manually triggered process that results in a separate exported file that doesn't rely on KeepassXC, rather, only openssl. We still bak the kdbx file through a separate automated process.

The choice of openssl to secure the export is debatable, because it doesn't provide for integrity of the encrypted file at this time. I vaguely remember reading somewhere that it wasn't possible to modify openssl to use AEAD on the command line, because the output format couldn't be modified to include the authentication tag, and still maintain backwards compatibility. If this is important to you (ie. if your encrypted export is readily accessible by potential adversaries), then another tool such as age, see https://github.com/FiloSottile/age could be a better choice.


^1 Some sensible, long-term settings for your database security would be:

  • use a password and a keyfile
  • use KDBX version 4, KDF Argon2 - Argon2 is a password-based key derivation function (PBKDF) that has tunable 'hardness factors', designed to slow down the dictionary-based attacks to determine the password that generates your master encryption key
  • if you intend using this on Android devices with ARM:
  • if you'll only ever access using a desktop/ server, with AES cooked into the cpu core:
    • AES or ChaCha20
    • RAM 1024MB
    • parallelism 8
    • rounds 15
  • set yourself a task to review these numbers each year - you can change them after the fact, as processors get more powerful

^2 This works in KPXC, but to be sure I would un-select 'automatically save after every change' in the settings, so the kdbx file doesn't get modified when you perform 'auto-type' - this may not suit your needs, the downside being that your changes aren't automatically saved: you now need to manually save the database, or wait 'til it locks. I've looked through the source code a while ago and couldn't see anything that may lead to corruption, however, to be sure you should also un-select automatically reload the database when modified externally and select safely save database files.

^3 A starting choice would be 14 lower-case alpha and numeric characters, chosen at random and each possibility being equally likely, which you then extend by distributing five additional punctuation characters throughout the password, chosen from the range that can be typed on a soft-keyboard on a phone without the use of the SHIFT-modifier. I calculate the strength for this to be over 80 bits of CS-entropy, ie. log-base2 (36^14 x 5^5).

You must, of course, write this down somewhere once the password manager picks it. To decrypt on any Android phone, you can instal Termux and then add the openssl utility pkg search openssl and pkg install openssl-tool


Argon2 inputs and outputs - https://tools.ietf.org/id/draft-irtf-cfrg-argon2-05.html#rfc.section.3

Message string P, which is a password for password hashing applications. MUST have length from 0 to 2^(32) - 1 bytes.

Nonce S, which is a salt for password hashing applications. MUST have length not greater than 2^(32)-1 bytes. 16 bytes is RECOMMENDED for password hashing. Salt SHOULD be unique for each password.

Degree of parallelism p determines how many independent (but synchronizing) computational chains (lanes) can be run. It MUST be an integer value from 1 to 2^(24)-1.

Tag length T MUST be an integer number of bytes from 4 to 2^(32)-1.

Memory size m MUST be an integer number of kibibytes from 8*p to 2^(32)-1. The actual number of blocks is m', which is m rounded down to the nearest multiple of 4*p.

Number of iterations t (used to tune the running time independently of the memory size) MUST be an integer number from 1 to 2^(32)-1.


In an ideal world:

  • Your fellow organization members, in particular the board members and officers, would have user accounts with strong passwords (NIST Special Publication 800-63B Revision 4).
  • Your systems would all have a centralized method of updating passwords for all devices.
  • Board members would hold permission to grant or suspend 'Administrative' privileges upon a vote (or an otherwise agreed upon process described in the bylaws) designating the relevant organization member.

The way you describe your organization, it sounds as if your peers may not have unique credentials to access the relevant systems. Because I've found security cameras tend to be antiquated and lack integration with other authentication systems, I'd not be surprised if a centralized method of credential verification and revocation is not possible.

If this is the case, I'd say that it's back to pen and paper. The board members should have a responsible means of storing privileged credentials, whether it be a physical vault, a password manager on their phone, etc.. and these credentials should be communicated to the relevant organization members. The process of regular updating of passwords may be a manual one, but should be done regularly. If your organizational hierarchy has a director rather than a board, then it is the director's responsibility to hold these credentials, plan for the transfer of these credentials to their successor, and share them with the relevant organizational members. Ultimately you as the system administrator should not be the sole holder of system credentials. If you are, then your organization's leaders are making a mistake. You ought to try and outline and express this issue, but ultimately I would say the decision of how to manage privileged credentials should not be a system administrator's in the first place.

  • 3
    That's a nice ideal world you've got there, but I have to deal with a real world in which these things do not exist. More specifically, it's not a question of access credentials, it's a question of administrator credentials. Most of the people here cannot be trusted with regular access to administrator credentials as they are guaranteed to accidentally do something that they shouldn't be doing, And the whole problem is how to give them these credentials in a way that is for future use of somebody else.
    – Moshe Katz
    Commented Oct 23, 2020 at 14:36
  • 1
    Yes, but delegation of "administrative" credentials is a permission of its own. I outlined manual credential management. I did not indicate that "most people" should have the privileges you indicate. I specifically outlined that, unless you are the organization's leadership, you should not be responsible for managing credentials. I take it, you have an issue with the idea that anyone but you hold credentials, but my point still stands. Ultimately it is your volunteer organization's leadership who is responsible for the systems you manage. Commented Oct 24, 2020 at 19:12

You put your passwords in a vault. Congratulations! The real work has just begun. As with any backup, how do you know it works, and how do you know its complete? Were they transcribed correctly? What about answers to security questions? 2FA codes? Private keys (SSH, GPG, SSL, Digital IDs)?

And how do you keep them up to date?

The best answer I've found is to store what you use. And if your office is already using a shared password manager this becomes much easier. I use 1Password shared vaults for this purpose, but it can be any password manager which provides this functionality.

While you're thinking about using this for Big Disasters, it will likely be used in mundane situations, like when you're on vacation. Shared vaults let you ensure at least two people have access to each shared vault to increase your bus number in more mundane circumstances. No safe required.

You can also store an Emergency Kit (test that it works) in a secure location (for example, a safe only accessible by the organization's officers) for access. You'd also make an offline copy of the vault in case the network or 1Password service is unavailable. This snapshot can be kept up to date by grabbing a fresh offline copy as part of your normal backup procedure. Because it's encrypted, the offline backup can be accessible to more people to do the backup. Only the Emergency Kit needs to be truly kept secure.

This can also include answers to security questions, 2FA codes, private keys (SSH, GPG, SSL), and any secure information a future administrator needs.

Then you'd use the same password manager for your organization solving multiple office security problems. This makes it easy to keep the emergency password vault up to date, and you know they're correct and complete because this is the same password vault everyone is using.


The organization has a few systems - specifically security cameras, network hardware, and telephones - that have local administrator accounts to manage them.

I apologize if my question is naive: What would you do if one of these had a major software or hardware failure necessitating a reinstallation of the operating system?

My hope was that in an ideal world, you are also documenting how the software setup works, i.e. steps for a "fresh install". This would of course include setting the new passwords. And again ideally, the process would hopefully be clear and well-documented enough that the new administrator could just follow it for each device -- this also gives them a chance to get familiar with the devices anyway.

In this case, you don't need to leave behind passwords; the new administrator will reinstall things and set new passwords.

P.S. Maybe this isn't possible because the devices run some proprietary software that you can't reinstall (and hopefully never crashes nor needs replacement parts?). Also, this solution doesn't take care of the scenario that you suddenly leave and the organization needs short-term access until a new person starts. It wasn't clear if that's part of your requirements.

  • This doesn't address the issue or the question at all. You're bringing up a completely tangential issue that is unrelated. You're saying that if someone, anyone, who would need to interact with the system and needed admin-level access, that they would need to reinstall the entire OS or reset to factory defaults and reconfigure? You're imagining that the current admin is gone. What about when the admin is unavailable, on holiday, or a legitimate party simply needs to interact with the system?
    – schroeder
    Commented Oct 24, 2020 at 7:44
  • And since the OP's comments include the phone system, I'm not sure the org is going to be ok with the entire phone system going down just so someone can add a new number ...
    – schroeder
    Commented Oct 24, 2020 at 7:53
  • @schroeder Thanks for your comments. I read the question as asking how to transfer over to a new administrator, something that might happen once in a couple of years (not every time you need to add a new number).
    – usul
    Commented Oct 24, 2020 at 15:29
  • 1
    So, when you hire a new admin, the admin needs to rebuild every system preemptively? That's crazy.
    – schroeder
    Commented Oct 24, 2020 at 15:34
  • As I said in the first paragraph: As part of our disaster recovery plans, I am writing a complete manual for administration of everything in the building.
    – Moshe Katz
    Commented Oct 25, 2020 at 0:03

You must log in to answer this question.

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