What credential hygiene actually looks like for a 10-person company

Most security advice for small companies sounds like it was written for a Fortune 500. SOC 2. Zero trust. SIEM. SAML. Hardware tokens for everyone. By the time you have finished reading the article you have decided this is a problem for next year, and you have gone back to pasting your Stripe key into a Slack DM because the developer needs it for an hour.

That gap - between what the advice says and what your day actually looks like - is why most small companies have terrible credential hygiene. It is not because founders do not care. It is because the advice does not meet them where they are.

This post is what credential hygiene actually looks like for a 5-50 person team. It is what I just shipped for a real client, sanitized and generalized, after auditing where their credentials lived on day one. Spoiler: it was not pretty.

Where your credentials probably live right now

Before architecture, an honest audit. Stop reading and tabulate, off the top of your head:

• Where is your Stripe API key right now? (If the answer is "in our .env files" plural, that is already two answers.)

• Who has access to your Shopify Admin login? Have any of those people left the company since last year?

• Where is your AWS root password? Is it in a 1Password vault that three former contractors still have access to?

• When was the last time you rotated the API token your scheduled job uses to read from your customer database?

• If your laptop got stolen tonight, how many credentials would you have to manually rotate to feel safe again? Could you even produce the list?

If those questions made you uncomfortable, you are normal. The honest median answer for a 10-person company is:

Our keys are in a .env file on each developer machine, and a few of them are also in our backend repo because Sam needed them for that one demo, and the AWS root creds are in a shared 1Password vault that I am pretty sure two people who do not work here anymore still have access to, and I do not know when anything was last rotated.

That is the actual baseline. Now let us talk about what good looks like.

Five rules that cover 90% of credential hygiene at this scale

This is not a 47-control framework. It is five operational rules, in priority order. If you only do the first three, you have already moved from the bottom 10% of your peer group to the top 30%.

1. Secrets live in exactly one place

The single most important rule, and the one that breaks most everything else if you skip it.

Pick a secrets vault. Self-hosted (Infisical, HashiCorp Vault), or hosted (Doppler, AWS Secrets Manager, 1Password Developer). For a 10-person team I recommend self-hosted Infisical on a $5-10/month VPS - you keep full data sovereignty, the keys to every system stay on infrastructure you control, and the ergonomics are the cleanest of the open-source options. But the choice matters less than the discipline: once you pick one, every secret moves into it. Period.

The vault is the source of truth. Your .env files become a list of variable names (no values). Your scripts read from environment variables exactly as they do today. Your code does not change. What changes is how the values get into the environment - they get injected at runtime from the vault, into process memory, for the life of the command. They are never written to disk again.

# Before:
python3 scripts/billing/reconcile.py
# (script reads STRIPE_API_KEY from a plaintext .env on the laptop)

# After:
infisical run --env=prod -- python3 scripts/billing/reconcile.py
# (vault injects the value into memory only, evaporates when the script exits)

This is the architectural change that unlocks everything else. Without it, every other rule is duct tape.

2. The repo never holds a secret

Your codebase has a .gitignore. The first line of it is .env. The second line is *.key. The third is *.pem. The fourth is anything that looks like a credential file in the systems your team uses (config/credentials.yml.enc, service-account-*.json, etc.).

A secret-scanning check (gitleaks, trufflehog, GitHub native secret scanner) runs in CI on every pull request. If it finds a key-shaped string, the PR is blocked. Not warned. Blocked.

This rule sounds simple and obvious. It is the single most-violated rule on this list. The number of production AWS keys I have personally found in public GitHub repos written by people whose LinkedIn says DevOps engineer would horrify you.

3. Every credential is company-owned, scoped, and revocable

The pattern most small companies start with is one founder personal accounts becoming the integration credentials. The founder personal Shopify login. The founder personal Klaviyo account. The founder personal Stripe key tied to the founder personal email.

This works until it does not. It does not work the moment the founder takes a vacation, the moment a partner needs access, the moment you hire your first ops person, and especially the moment the founder personal email gets phished.

Every integration moves to a company-owned credential. A company Shopify Custom App with the minimum scopes its actual use requires. A company Klaviyo API key. A company Google Workspace service account, not a personal Gmail. Every one of those credentials lives in the vault, scoped to the project and environment that uses it.

Read-only where you do not need write. The script that pulls daily order data does not need the same key as the script that issues refunds. They are two keys with two different scopes.

4. Offboarding is a five-minute operation, not a forensic project

This is where most small companies leak access, and where most small-company "security incidents" turn out to have started.

When someone leaves - employee, contractor, agency partner - the offboarding sequence is:

1. Vault access revoked centrally. Every credential they could reach is dead to them in a single click. There is no "what keys did Sam have access to?" question because Sam never held a raw key.

2. Removed from GitHub Org. Repo access ends immediately.

3. Sensitive secrets they touched are rotated as a defensive measure, even though they never held the value.

4. Logged in an access register. What was revoked, when, by whom.

Total time on a well-architected system: five minutes. Total time on a personal-keys-and-shared-vaults system: a frantic week of "wait, did Sam have AWS access? What about Klaviyo? Did they ever know our Stripe webhook secret?" - usually concluding with "we had better just rotate everything to be safe," at which point you discover that you do not actually know what everything is, and three things break in production over the next week.

The cost of bad offboarding is paid in the panic of every offboarding. Architecture pays it down once.

5. The audit trail is a byproduct of the workflow, not a separate burden

Branch protection on main. All changes through pull requests. PR review is enforced. CI runs on every PR (lint, secret scan, tests, any compliance checks specific to your industry).

This sounds heavy until you have worked in a system where it is true. Then it sounds like the only sane way to operate. Because:

• Every change to your operating layer has a name on it, a reason in the PR description, and a reviewer who agreed.

• "Who changed this and why" is git log, not a Slack archaeology project.

• Decisions stop getting re-litigated in the next meeting because the repository is the record.

• A version-controlled audit trail is exactly what an acquirer technical due diligence wants to see.

The trail is a byproduct. You do not sit down on Friday afternoons and write the audit trail. The workflow produces it.

What this costs you

Real numbers, for a 10-person team setting this up from scratch:

• Self-hosted Infisical on a VPS: $0 software, ~3-5 hours engineer time, then $5-10/mo VPS ongoing

• GitHub Organization: free for the first 5 seats, $4/user/month after that

• Secret scanning in CI: free (GitHub native, or open-source gitleaks)

• Migrating existing credentials into the vault: ~1 day of focused work for ~20 integrations, then quarterly rotation review (~2 hrs / quarter)

• Onboarding runbook: ~2 hours to write once. Same runbook, every new hire forever.

• Total: ~1 week of focused work, then ~$15-50/month plus 2 hours/quarter ongoing

That is the cost. Compare it to the cost of one stolen laptop, one ex-contractor with leftover access, one .env file accidentally committed to a public repo, or one phishing-compromised personal email account that was the root credential for your Stripe.

What this does not cover

This post is about credential hygiene, not the full security stack a 10-person company should eventually build. It does not cover:

• Network security (VPN, firewalls, segmentation) - mostly not your problem at this scale, mostly your cloud provider problem

• Endpoint security (MFA enforcement, device management, FileVault / BitLocker on every laptop) - critical and adjacent, but a separate rabbit hole

• Application security (input validation, authn/authz patterns in your own code) - separate craft

• Compliance certifications (SOC 2, HIPAA, PCI) - relevant when a customer or auditor asks; the foundation here makes them dramatically cheaper to achieve when they do

• Incident response - what to do when something goes wrong; should be a separate written runbook

Credential hygiene is the foundation. Get it right and most of the others get easier. Get it wrong and most of the others are theater.

A reasonable next step

Walk through the five rules above against your actual current state. Be honest. The exercise itself is most of the value: you will discover credentials you forgot existed, contractors who still have access they should not, and integrations whose owner is "Sam, who left in March."

If the gap is bigger than you want to close internally, I run a 2-week productized engagement that takes a 5-50 person team from "credentials in Slack" to the architecture above. Audit week one, build week two, runbook + training at the end. You can read about it at jasonpellerin.com/security-sprint.

If the gap is smaller, fix the top one. The single most leveraged thing you can do this week is move your three most-sensitive credentials (whatever they are - probably Stripe, AWS root, and your customer database) into a vault and stop pasting them into Slack. Everything else compounds from there.

Jason Pellerin is a systems architect for AI-native operations. He helps lean teams ship like they are 10x bigger by building the governance, automation, and security layer that makes AI actually compound. Based in Denver. Book a free 30-minute Bottleneck Audit.