What are the recommended ways to store and give access to passwords?
How can a new hire be given access to all required passwords day 1?
And when such new hire gets promoted, how can we give access to the additional passwords they will need?
And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?
Any best practices? Any 80/20 suggestions? Low hanging fruits? Any warnings about what not to do?
Remember, as you give people access to passwords, that those passwords will need to be rotated when those people change to incompatible roles or depart the company. If passwords aren't a total pain in the ass for you, you're probably doing something wrong.
Yes, but they should be unique to your account. I.e. via SSO.
> What are the recommended ways to store and give access to passwords?
Whenever possible, don't. Otherwise, it depends on the scale and security you need. A password manager is one possible solution. Another solution is something like Hashicorp's Vault or OpenBao.
> How can a new hire be given access to all required passwords day 1?
They should access it through their SSO account, and not need a billion passwords across systems.
> And when such new hire gets promoted, how can we give access to the additional passwords they will need?
Again, whenever possible, tie access to their SSO account.
> And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?
Well if you did all of the above this wouldn't be an issue, you just close the 1 account.
> Any best practices? Any 80/20 suggestions? Low hanging fruits? Any warnings about what not to do?
Another thing you can do is give people 2 accounts, a normal account and an Admin level account, this is useful for things where the employee needs a regular day to day account as well. i.e. for the employee self portal for instance.
Also automate as much as is reasonable, e.g. github access to push code to a dev branch, then enqueue merging of it. But a CI/CD pipeline does the actual deploy, the employee doesn't need to access any of the production systems. A very small number still will, but that's a much better situation.
Give the employee 1Password to manage their own passwords.
- only share passwords for personal accounts; those accounts you terminate when the employee separates. For shared resources, use SSO and SCIM group management via the SSO provider to add and remove accounts from groups with different roles.
Rippling seems like a neat offering because they bundle SSO with HR people management, and their HR product is the best I’ve used as an employee - hopefully the administrative side is just as good or better.
If those SaaS tools aren’t in your budget, try looking for open-source or gratis alternatives with the same shape, or repurposing whatever IT infra you have to implement a similar model.
1. SSO everywhere. Okta if budget is no concern and Keycloak if it is.
2. Password manager for the entire company. Even if it's possible to go SSO everywhere, there are still secrets employees will need to manage. Give them a solution or they'll solve it on their own and not in a good way. I like 1Password.
3. All services use a secret solution that can broker short lived secrets and a policy that limits secret TTL to a day or less. I like HashiCorp Vault.
1-20 people - password manager (bitwarden, 1pass, etc.) 20-30+ people - SSO
50+ people - start assigning real roles to your SSO schema
1-5 services - secrets in CircleCI and password manager is good enough.
5+ instances - use a secrets manager like Vault.
10+ instances - start using a secrets manager locally as well for dev. Start to consider using well scoped IAM policies for each of your services and team members.
15+ instances - start to think about adding additional zero trust boundaries.
Of course, this is very rough. Depending on your regulatory/compliance requirements and how much revenue you’re bringing in and from who, you might have to do this stuff sooner. In general, it should go:
1. Centralize secrets even if you can’t easily revoke people (password manager).
2. Make things easily revocable and centralized (sso).
3. Make roles and access finer grain (RBAC).
4. ^ with automation between all of these steps where it makes sense.
Something I would warn anyone of is building your own auth/secrets core tooling. This stuff is incredibly complex because of the edge cases and it’s just not worth the risk you take on by saving money unless you have a really good core business reason to roll your own. It’s also dangerous to prematurely optimize and pay the SSO tax too early. You will find that a lot of engineers appeal to emotion when it comes to risk. Something extremely helpful is going through and actually assigning a security risk score for all your systems. This might be tedious, but it brings a lot of clarity to the conversation of “what do we want to build when? What risk can we take on at any given stage?”
Password manager like 1Password, for the few passwords that do need to be managed
SSO as much as possible. Fewer places to manage access = easier onboarding and off boarding
In general you want to use role based access control. I'm not familiar with off the shelf solutions, but the concept is that you grant people access to systems according to what they need for their job (role). A role in this case may be a team, or a specific job on that team (e.g. engineers on xxx product team). Then e.g. when that team has to add another engineer to their oncall rotation, they give them access associated to that role. When person moves off the team access gets removed. when the team realizes they need another permission to troubleshoot their systems, everyone in that role on the team gets it. Etc.
- A secrets manager (e.g. AWS Secrets manager) with an API key for each team, and the team can access their secrets on a team level there
- An encrypted file encrypted with e.g. KeePass, and one password for that
- Bitwarden or Lastpass on a team or department level (yes, shared passwords, for example where there is one password for one proxy)
- Yopass https://yopass.se/
Your company can apply various aspects of threat modelling and more often than not several companies I've worked with find that Bitwarden self-hosted can meet a lot of requirements, this is the best solution in terms of privacy and security and controlling your trust boundaries. Failing that, Bitwarden Enterprise (they host) is also just as good. In either case there's granular controls for controlling what your new hires can be given access to.
There won't be a perfect solution such as notifying everyone about rotation, it's not needed though - simply rotate it and the next time they need it they get the new version.
Of course the general advice is something I agree with - use SSO where possible, but I fully recognise that it isn't always possible with some third party services that haven't implemented it yet.
There is a cruder solution I've often seen too, it's a bit painful but KeePass2/KeePassXC on a company hosted SAN is the ultimate offline, fully controlled solution but comes with extra hurdles to access, whereas Bitwarden is browser based and simpler to use.
I have heard that LastPass is about as good, but have no experience using it.
The latest version of 1Password isn't so good, but it works fine.
Some places let you configure SSO+2FA, which helps; but in most cases clicking a social login button gets you full access.
And speaking of a single point of failure, cloud password managers look even worse[1].
[1]: https://thehackernews.com/2023/02/lastpass-reveals-second-at...
What I describe is more or less what has been the standard at the companies I worked for, no secret sauce here, and I added some extra processes to address the questions you asked.
Get a password manager service (none of the keepass file thrown onto Google Drive), we used 1password, it's good enough I assume. Keep related items in one collection, don't mix unrelated items. Always save passwords in the pw manager, and make sure everyone does that, too. When someone joins, give them access to what makes sense. If someone gets promoted, add them to a new collection. Document who is allowed access to each collection if necessary. When someone leaves, kick them out of the password manager service first, then in a timely fashion, change the passwords (I don't know if you can do it automatically, but if churn isn't too bad, you can also do it manually). Save the new passwords in your passwords manager. As everyone uses the password manager, they will automatically get the new passwords without them even realizing it changed.
Some extra that's also important: if possible, use SSO and everyone uses their own account, eg Okta. Create and share passwords only if needed. When one off accounts are needed, make sure they are created with company email addresses, ideally named after a team rather an individual.
My experience is that most companies can't be bothered to change passwords every time someone leaves. Most people are not assholes, or want to go to court and possibly jail for messing around in accounts from their old companies (even if they could technically save the passwords for their own use for later).
Most environments I have worked with struggle with sharing passwords like OP and it’s a massive pain. One time, dev team was sharing active directory credentials to access service. At some point service account gets locked because someone was using an older password of the account.
Usually a quick problem to solve with 2-3 people in same region (or prevented entirely), but teams across time zones and countries (US vs Vietnam or India). It becomes painful. Doesn’t matter if they are “senior” or green/“junior” engineers.
If I ever have my own company, I want my own internal IdP (identity provider) and all internal and external services integrated with it. Employees issued (multiple) physical hardware keys. This is required to authenticate with work computer and subsequent access to VPN/tail scale.
Individual services and products must support oauth.
Access to public cloud resources? AuthN through company IdP. Admin creates roles for you to access resources necessary for work
Access to database? No shared passwords. get admin to add authorization, then authN via IdP and get access token
Version control? Same as above.
E-mail? Same as above.
Company document repository? AuthN through IdP which requires physical security key.
Access to company laptop/desktop? Plug-in security key. Permissions/roles managed remotely (give bob sys access for dev work but jenny from HR is given very basic system access).
Then once you are done, then remove security key and all established sessions are removed and logged out of computer (or just locked).
Employee leaves? Just disable the account. Maybe leave a small window of access to certain services (ie, email) so they could say their goodbyes, turn in company equipment. Then revoke access completely.
Hostile or state actor obtained security key of active employee? From IdP, mass revoke all access. Can also track what actor accessed as well.
With this, problem OP has proposed has disappeared completely.
Some suggest using KeePass or equivalent, but I advise against it - too easy to copy and leave with the vault and very difficult to audit.
Find a solution that audits who had access to such password. And do your audits!
Consider rotating your shared passwords frequently, especially any high privileged ones.
If your risks warrant it, check for a PAM (privileged access manager) that acts as a middlemen and fully hides the password.
I realize I am not really answering your questions, so I'll stop here. But... SSO and proper directory management!
2. Use a password manager that enables sharing. There are 1s with company accounts and different ways to share. A new hire can pick up a certain role/group and get all the passwords.
On the other end, I'll chip in on https://onetimesecret.com/ for quickly sharing a secret. It will only allow the consumer to view the secret once, after that, the secret is no longer available. You can also set up One Time Secret with your company domain (self-hosted, I presume)
Some tips from what we learned: 1. don't use shared spreadsheets or docs, way too easy to mess up 2. need granular access controls + audit logs 3. automate onboarding/offboarding as much as possible 4. rotate creds regularly, especially for sensitive stuff 5. use SSO where you can to minimize password sprawl
There are some decent enterprise password managers out there, but they get pricey fast as you scale. We ended up using a combo of 1password for team passwords + a custom system built on top of vault by hashicorp for machine creds/api keys etc.
One thing that worked well was having "password owners" for each system who were responsible for rotations, access reviews etc. helps distribute the work.
If you want something more turnkey, you might want to check out hoop.dev - does a lot of this stuff out of the box, including automated access reviews, just-in-time access etc.
Whatever you do, just please don't use a shared google doc :)
All employees also have a 1password account for which we can store individual passwords for the services that are not connected through SSO.
For some services we only have a single token/service account which we need to share within the team. Often they were stored in a `.env` file, but that tend to be a burden for onboarding and quite a bit of maintenance for each individual.
Within my current team we share them using direnv and https://github.com/tmatilai/direnv-1password. Secrets are loaded as environment variables whenever the dev enters the projects directory. They are loaded from 1password which is unlocked using fingerprint scanner. This way the secrets are not actually stored on disk.
People leaving the team does still require manual password rotation, but at least not everyone in the team needs to update their `.env` file this way.
As opposed to "login with Facebook etc." logins that are individually administered by each end user for each app.
This is low fruit for many things but often companies require you to be on an expensive SaaS pricing tier to use SSO on their product.
Next problem to solve is Software Engineer's cloud secrets. Use key vaults in your cloud for this. Use SSO to authenticate your team to that cloud.
Enable 2fa as much as possible. TOTP not SMS.
Finally you will need people to save passwords for some stuff. Lastpass or Bitwarden etc.
Avoid shared passwords. Sometimes unavoidable in which case rotate them often and when people leave too.
But when your employees start to join and out, the first thing is SSO, IAM & IGA. With strong password requirements, schedule rotation, and MFA. All employees can be onboarded on day one and lost permission on the last day. Then how does an employee on day one know the init credential, you can share the init password with the employee in the onboarding email or face-to-face. The RBAC or ABAC control relies on IAM. The employee lifecycle management and approval can rely on IGA. After this, the milestone for supporting the employee's identity lifecycle is done.
Currently, You have an empty app dashboard. When you start onboarding applications, most mature 2B applications will easily integrate. Eventually, you need to onboard some applications that only support credentials login. This time you need password injection, eg. the password-based SSO on Microsoft Entra ID. Or root or breaking class accounts in the application cannot be integrated with the SSO system, You need to find a new tool, which is PAM. eg. CyberArk, or Hashicorp Boundry. Which can protect those privileged accounts.
In the end, Just do remember, never directly share credentials with your employees, except the init password for your SSO, human error always exists in the real world, people always forget to change the password after an employee or manager leaves or switches positions, and they will assume that person is a good guy, no worry for no rotation.
If you make an effort to define granular groups for every team, and role you have in your company it makes the management of access to resources (and not only secrets) a lot easier.
In the example you describe, the newly promoted hire would automatically be added to new groups which will have the right to access the needed Secrets. Similarly, whenever a person leaves your company, simply remove them from the groups they are in and they (almost) immediately loose all access.
It's not a small feat to built, maintain and reconfigure all your tools to use it, but if you do it really pays dividends
Any help/advice would be greatly appreciated, and thank you in advance.
It seems like perfect simplicity built on time-tested cryptography: store pgp-encrypted files in a git repository. We already had an internal git server and used PGP internally, it was the perfect marriage. The tool provides the common functions like selecting which colleagues to encrypt for, finding an entry and copying it to clipboard... but think of the moment your organization changes. Everyone has access to everything offline, which is great if you need it in a rainforest or when the server is down, but also you'd need to rotate all exposed-to-them entries whenever someone leaves. Re-encrypting everything to remove an old key is pointless because the git history will provide an attacker with whatever version they need.
Offline access is useful for selected credentials (like the disk unlock password for some central servers) but, to avoid unnecessary rotations, should not be the default unless you're a sysadmin mentioned on disaster recovery team
Skimming the recommendations, so far there are no tools mentioned that don't require maintaining another service or that can't read your data. At least pass had that going for it
As many here have recommended, where possible employ authentication/authorization mechanisms which are not reliant upon account+password for everything. OIDC, OAuth2, Kerberos[0], and Active Directory[1] are all technologies worth considering.
Where possible, employ a per-developer sandbox development environment such that each can have a representative system able to support feature/integration tests without having to rely on the CI/CD workflow or a fully replicated production environment.
All of the above share a common theme - limit shared access while maximizing productivity.
As for access to support tools, like source code repositories, ticketing systems, wikis, HR systems, and the like, automate where possible to create the requisite accounts and recommend use of a password manager for same.
EDIT: bonus points for using a private organizational GitHub repo configured to execute GitHub actions that create the above support accounts when a new-hire PR is approved by authorized personnel.
*limitations apply.
What has also worked really well in the past for me and my teams, especially if they are more technical and these credentials really never need to go beyond this more technical team is setting up a single 'vault' encrypted with GPG. Each team member then gets the vault re-encrypted for them, adding them to the recipient list. While this takes a little bit of effort to get a workflow going, it keeps it out of a cloud service, if you're concerned about that, and you get to pass it around just like any other file. When someone leaves, or no longer needs access, their recipient is removed and then the file recommitted and redistributed. In the past I've had the ASCII-armored file committed in git and people just pull down a tools repo every so often.
If you are wanting to store credentials for, say, public cloud services, don't. Use roles as much as possible, don't pass around passwords, don't bother setting up individual users beyond those required to bind a role to it, grant only by roles as much as possible.
There are some modern Privileged Access Management platforms like Strongdm, teleport, us (https://adaptive.live) and few more in the market that works well with cloud and modern application architectures.
There is debate in the industry whether access should be given or not. There is pros and cons for either of them. This purely depends on the culture of the org in my opinion. But in scenario, you really have to give access, it should have the least privilege as well it should be time bound. Also, all the operations should be audited and recorded.
I believe you should have zero standing access in the org, but there are always use cases like data repair and administration where you have to give access to users. In that scenario, the access should be limit, time bound and audited. Also, you have to make sure you run access review campaigns and checks for over privileged or unused users.
Be absolutely strict on password sharing via non approved means.
Bitwarden enterprise for whatever is left, with collections per team/department.
It’s pretty extendable and can integrate with other engineering use cases, shame about hashicorp license change though. Openbao looks great though as a replacement. These are open source so look no further if that’s what you’re looking for if you want password management, ssh auth, cert issuance, authentication and secret retrieval with k8s for example.
BTW, not related to the passwords is to put everything non-public serving behind a firewall and access it only via individual VPN keys.
Rippling's Rpass is a good example of effective implementation.
You can deploy passwords on day 1 based on roles, dept etc.
You can also set passwords to be hidden , not shared etc.
SSO is best practice but this is by far the most effective way for vendor account management.
Oh if you are doing this make sure you have set up group-based SSO.
For developers, everything is done in their individual accounts, no system accounts. There is a dev system account that does leak out some times but this is frowned upon. Production data that is synced to dev environments have to be scrambled so devs dont get to see all the real prod data.
On the other hand, external SaaS is still hard to integrate into your own IdP, so I guess we are stuck with some forms of passwords for some time to come.
They've made it simple for admins and users alike.
If you don't have much of a budget, then it can be self-hosted using VaultWarden which supports the various BitWarden clients
Lastly, of course like everyone said: SSO is your friend!
Groups and ACLs would help to give "scoped" access to passwords.
Not a full fledge solution but useful for quick one time sharing. Curious if people here find it helpful.
You could do a mid-roll-your-own with Bitwarden commercial, etc., though consider the operational management overhead.
As a last resource, at a Former Employer™, people put a public key in their profile, and we used GPG to encrypt secrets and paste the encrypted value on Slack/Teams. This was only among developers, and there was a tutorial for setting up the GPG GUI and encrypting values with it, so it worked fine. But we did also actively worked towards not needing that as much as possible.
Would still recommend.
Every employee has a collection. When employee needs access to something, we add that password to their collection.
When they leave the company, we revoke access to Bitwarden and then change all passwords in their collection.
For small companies of maybe up to 100 employees, this is a super cheap and practical solution.
Everyone else seems to be going on about SSO. That's good for end users signing into websites & laptops, but I'm getting the sense that you're more worried about admin-level permissions management.
First, some terminology to help you Google for things:
> new hire be given access to all required passwords day 1
> when such new hire gets promoted, how can we give access to the additional passwords
> if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access
The more technical/sales-y way to say this is "I want a PAM solution with JML workflow integration for my secrets management" (JML: Joiner, Mover, Leaver, PAM: Privileged Access Management), and it'd be part of your overall identity management (IdM) strategy.
Some big-name companies in the IdM space: Sailpoint, Quest One Identity, CyberArk. Those'll give extended management of your canonical source(s) of identity & authorization info (typically Active Directory/Entra ID, but with the big-name products you can also integrate with modern solutions like Workday, FOSS e.g. LDAP servers, or old-fashioned stuff like CSV drops on an FTP share, and set up push or pull workflows to set user attributes & permissions based on your needs).
So you want IdM, plus (at least) 1 of 2 things:
1. Secrets management (for static secrets). I've personally seen folks using Thycotic Secret Server and LastPass Enterprise (although there's lots more companies in that space). That gets you the basic "get admin X a password that was created by admin Y". This is more of a requirement for servers you can't integrate IdM with (so it'd be licensed to admins only), because for day-to-day admin work (stuff like "add this user to that group"), what you'd ideally want is:
2. Full PAM. Essentially, you'd set up a workflow to temporarily "check out" a secret (i.e. password) for a set period of time (which the user could request some capped number of extensions to), that's then automatically-changed by the IdM once their time's up. (You can also do things like "give anyone who asks & gets manager signoff group permissions to XYZ that expires in 90 days".) Sailpoint and CyberArk can both do this.
Now, all that's for server admin. If you're talking about handing out admin permissions for endpoints (this is your classic "Tech support needs to privesc to fix something, but I don't want to leave the Windows admin passwords lying around in random techs' clipboards, and I don't want to let just anyone use ADUC (which, IIRC, is required to effectively use LAPS)"), you want something slightly different (in addition to an IdM solution):
3. EPM (Endpoint Privilege Management). BeyondTrust is the big name here. This lets you grant some permissions to end users (e.g. "install pre-approved software", "change (only some) networking settings"), while locking everything else behind an admin account (which you can gate access to using your PAM; that gets you auto-rotation of Windows admin PWs right after they're touched, plus JML workflows for your tech support personnel).
Now, go forth and Google (and when you start asking for demos, try not to let the salespeople drown you in buzzwords like I just did)!
There's no good solution imo for what I think you're asking for (and that isn't: how can I share passwords for services that allow SSOv?)
"This reminds me of a problem that I wanted to solve in the future, but I don’t have the expertise. The problem is when an organization has a single account on an external service which needs to be used by several people, and the organization wants to safely manage the access to the shared account on the external service, adding accountability: who was using the account at X time? Users of the shared external account should not know the credentials of the account, so rotation of passwords when employees leave/change roles is not as necessary. I thought of something like a proxy which could use a Selenium (or something else) script for each of the external website, which would handle the login/authentication flow for the external service.If this was a business, those scripts could be offered as a per-website/month package. An administrator would create the automatic flow for a specific service, and save the username and password somewhere in the script. Normal users of the external service’s singular account would then use the proxy using their individual credentials, to add accountability to accessing the external service. Maybe someone in this realm could come up with something and market it."
Use Okta for SSO.
and of course, save their own, which arent shared
* Great authenticator support. We have some accounts that our team members have to share, and we want MFA on those accounts. I can add an MFA field to 1Password entry and the people who have access to that entry can use it. Doesn't help when those entries require phone/e-mail based MFA; I'm working on a little Twilio / outlook group setup to take care of that. * Easy to navigate group membership. Passwords are stored in vaults and individuals or groups can be given access to those vaults. The model for it fits in my head and I like that. * Easy share ability. There are a few credentials that I occasionally need to share outside of a vault. I can create a link and grant access to specific individuals for a given amount of time. * The browser extension and integration have been really smooth in my opinion. * I find tagging and taxonomies of tags to be helpful, and 1Password supports those well. * We've gotten some great mileage out of 1Password connect. Some of our infrastructure secrets now reside directly in 1Password, and 1PW connect pushes them into our k8s environment as secrets where our apps can refer to them. Makes secret management across environments that much easier. * SCIM support (which I haven't yet implemented) and SSO support to bring more convenience for end-users. * Easy ability to recover if an employee forgets their master PW (have done this a handful of times). * A nice perk: our 1PW business comes with a free 1PW personal subscription for people, completely separate. If the employee leaves they have can convert their personal vault to a paid subscription or export it.
To answer your questions specifically based on my current context:
> What are the recommended ways to store and give access to passwords?
1Password vaults. One vault per style of responsibility. 1+ groups have access to a vault. People get put into 1+ groups.
> How can a new hire be given access to all required passwords day 1?
In our case, day 1 they accept the 1PW invite in their inbox, and then we assign them to groups. Done.
> And when such new hire gets promoted, how can we give access to the additional passwords they will need?
Keep those "tiers" of passwords in separate vaults. Update the groups when someone's role changes.
> And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?
See what groups that person is in and what vaults they had access to. Review "high priority" items which you've tagged in such a way as to surface them. Send an e-mail to the members of the vault telling them you're rotating passwords. Rotate the passwords. Anyone who's a vault member can see the password history too, I believe, so if something goes wrong the old password will still be available.
And then, yeah, find a password manager tied into that SSO platform to fill the gaps/enforce policies for users using tools that don't have SSO available.
HR-and-manager-enforceable policies and penalties for users who go off the reservations.
I know the third party SSO services are recommended but .. I still have a hankering after the old, run it yourself approaches.
Am I missing something?
You have the ability to share a password to anyone even without an account (similar to OTS). Team vaults. Recovery. Etc..
Been using it the last few companies and it’s worth the money.
You always want to take into account who will manage this when it breaks and how often? Roll your own BW instance you’ll be in charge of it 24/7. Outsource the infrastructure to 1Pass and you really only have to manage policies and access.
The problem is actually a bit more general than just passwords alone, it's any kind of secret credential like keys, tokens, and certificates that enables authority. Thus the problem is actually about authority management.
Even when SSO is involved, there's always going to be credentials that enable access to various external systems. Especially when autonomous services or apps need to perform actions. Also SSO is very much human-operator centric, and is only suited for tightly-managed centralized systems. Such kinds of centralization is ripe for service downtime if the SSO gateway/portal ever goes down, especially if somehow you hacked the SSO flow into autonomous systems. It becomes a single point of failure.
> What are the recommended ways to store and give access to passwords?
If it's just passwords alone, using a cloud password manager is probably fine.
> How can a new hire be given access to all required passwords day 1?
Although you can just select a bunch of passwords in your favorite cloud password manager and share them with the new employee account, the challenge is actually scoping their authority, tracking them, and managing change, entropy and sprawl - that's not well managed by password managers yet, because password managers are primarily just the key-value DB CRUD of passwords, they have no awareness of the Source, User and Target of authority. So this is what we are focusing on in Polykey.
> And when such new hire gets promoted, how can we give access to the additional passwords they will need?
See previous answer. This requires understanding authority scope, which is best done with some sort of visualisation system.
> And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?
See previous answer. This requires automation that integrates with the source of authority and other users of authority. It's a also a deployment problem tying into devops and so on. The key thing to understand is that once you share a secret with them, there's no takebacks. Capability-based security theory does mention ways of dealing with this, such as delegating a proxy derivative authority rather than the true underlying authority.
We're still in development and we're currently working on the enterprise portal as a control plane for addressing the more difficult questions you have. We've got internal documents explaining the theory behind the general problem of authority management, however they haven't been released to the public yet. I will likely publish them on our https://polykey.com/docs soon.