For solo or small-scale operators who manage several servers, sites, and domains. The more you've postponed taking stock because "it works," the more this applies. No attack steps here — only risks you can list and delete yourself.
Count and reduce what you have before adding controls
Untracked state is itself a risk. Take stock and you usually find:
1. Protect the PCs that hold keys and credentials
No matter how hard you harden the server, if the PC holding your SSH private key is compromised, every server that key can access is exposed. Once you switch to key auth, the real boundary of your fleet moves to "the PC that holds the key." So the priority isn't "server → PC" but "PC → server."
The highest-value check: whether .ssh sits OUTSIDE a cloud-sync folder (OneDrive/Drive/Dropbox). If a private key accidentally lives under sync, your key leaks the moment the cloud account is taken over — even without touching the PC. The least-privilege mindset for keys is in SSH keys and least privilege.
2. Set up 2FA in priority order: email, then domain, then billing
"Add 2FA to everything" never ends if you start vaguely. Rank accounts by which ones can recover the others (root of trust) and the priority becomes clear.
| Tier | Target | Why it's top priority |
|---|---|---|
| Tier 0 | Email account | Almost every service recovers via "reset link to email" — take the email and the lower 2FAs are bypassed |
| Tier 1 | Domain control (registrar/DNS/hosting/code platform) | The site itself can be hijacked or swapped |
| Tier 2 | Billing APIs (payments / AI APIs / mail sending) | Leads to direct financial loss |
In practice: keep backup codes on paper (putting them in the cloud halves the point of 2FA), and confirm your recovery email still works and is under your control. Steps are in the multi-factor authentication guide and the security baseline checklist.
3. List which SSH key opens which server
"It's key auth, so it's safe" is not management. What you actually need is one table of "which key on which PC opens which server." Match each server's authorized_keys by fingerprint and the invisible appears — duplicate keys (the same key under two names), unused keys (used nowhere), and orphan registrations (left over for a purpose that's gone). authorized_keys is easy to add to and easy to forget to prune. A table lets you ask, row by row, "what is this for?"
4. Cut off end-of-support devices with the fewest steps
A key on a device whose OS reached end of life (EOL) is common. Going big — "rotate every key and reconfigure every server" — is so heavy you never do it.
Check for any sign of leakage
The least-effort cut = delete the key from the device
Put the support deadline on a calendar
The trick: pick the cut you can actually finish today over a perfect procedure you leave undone.
5. Remove plaintext passwords from the cloud
Before the password-manager debate, there's a bigger real harm: a plaintext password list sitting in a cloud document. Leak it and every account is exposed at once.
Plaintext list (a cloud document)
- One account being taken over leaks everything
- You'll paste into a fake site by hand
- No breach detection, no autofill
On-device-encrypted storage
- Contents are encrypted on your device (provider can't read them)
- Won't autofill on a fake domain = phishing-resistant
- After migrating, delete the plaintext for good
"Which manager is best" matters far less than "did you remove the plaintext from the cloud" (→ how to choose a password manager / storing passwords safely).
6. Remediate one change at a time, reversibly
When the inventory surfaces problems, you'll want to fix them all at once. In production, changing several things on momentum is the most dangerous move. Hard-to-undo operations — key rotation, config changes, production deploys — should be done one at a time, after preparing a full backup and a restore procedure (i.e. make it reversible). Don't create a new problem with the remediation itself (→ backup and recovery).
7. Design the ledger to hold no secrets
The ledger of your results becomes a target list for attackers if it leaks. So draw the line up front.
Fine to write (not catastrophic if leaked)
- Public keys, fingerprints
- The structure of your setup, whether 2FA is on
- Pass/fail results
Never write (one leaked line can be abused)
- Private key contents
- Passwords, API keys
- Real reset codes
Fingerprints and public keys only identify "which key" and can't be abused alone. Express your state using only information that isn't catastrophic if leaked — then the ledger stays safe in the cloud or shared with a team.
This site's view: take inventory before adding tools
On this site we never keep secrets (keys, passwords, connection details) in plaintext — not in shared docs, not in code — we split keys per purpose (so one leak doesn't spread to anything else), and we remediate reversibly, one at a time. Before adding a new tool, first turn "untracked state" into "a listed state." It's unglamorous, yet it deletes more risk than anything else.
Read next
- Keys: SSH keys and least privilege
- Baseline: Security baseline checklist · Multi-factor authentication guide
- Storage: How to choose a password manager
- Where things sit: public buckets (the inventory is not only your servers)
- What you forgot to delete: subdomain takeover and dangling DNS (retired is still an asset until deleted)
- The bigger picture: common mistakes are failures of assumption (why inventory works)
- Why the inventory matters: 2026 breaches came through valid credentials (without the list you cannot even tell whether you are in scope)