It really depends on how mature your org and stacks are. This is generally how I would do it. 1-20 people - password manager (bitwarden, 1pass, etc.) 20-30+ pe

It really depends on how mature your org and stacks are. This is generally how I would do it. 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?”