A solo fractional operator holds credentials for every client they have ever worked with, including the ones they offboarded months ago and forgot to rotate. The blast radius of a compromised inbox is every client's production environment. Here is the credential hygiene system I run across seven concurrent and prior engagements.
The blast radius problem
When a full-time employee's credentials are compromised, the blast radius is their employer's environments. One company. One set of systems. Bounded.
When a fractional operator's credentials are compromised, the blast radius is every client whose production systems accepted those credentials. If the operator reuses passwords or has 2FA fallback to their personal email, a single compromise can cascade across the entire client base. The insurance math, the reputational math, and the legal math all point the same direction. Credential hygiene in a fractional practice is infrastructure, not a side project.
Most operators I talk to underweight this. They have a password manager. They have 2FA on most things. They feel reasonably secure. Reasonable is the wrong standard. The standard is: if your personal email is phished tomorrow, what is the worst case? If the answer is "a few clients might need to rotate a few credentials," you're fine. If the answer is "I cannot enumerate the systems that would be affected," the hygiene needs to be tighter.
The four-layer hygiene stack
The system I run has four layers. Each layer reduces blast radius at a specific surface.
Layer 1: separate password vaults per client
Every client gets their own vault in 1Password. Not a shared vault. Not a shared tag or folder inside one vault. A separate vault, labeled with the client name, with its own unlock state. The client's credentials live in that vault. Mine live in my personal vault. The two never mix.
The reason for separate vaults is blast radius containment. If one client's vault is compromised (which can happen if a client admin accidentally shares the wrong thing), the blast is bounded to that client. The other clients are unaffected. If I kept everything in one vault with tags, a single leak would expose the full practice.
Separate vaults also make offboarding clean. When an engagement ends, I archive or delete the entire vault for that client as part of the exit protocol. The credentials are not lingering in a tag inside my personal vault. They are either gone or explicitly preserved for a documented reason.
Layer 2: hardware keys everywhere that accepts them
Every primary account across every client gets a hardware key as the second factor. Not SMS. Not an authenticator app. A physical key. I carry two (a YubiKey and a Nitrokey) and both are registered on every account that supports them.
The logic is that SMS 2FA is phishable and porting attacks exist. Authenticator apps are better but can be compromised if the device is compromised. Hardware keys require physical possession. A remote attacker cannot pass a hardware key prompt even with the password.
The accounts that do not support hardware keys get the strongest second factor they do support, usually TOTP through an authenticator. The ranking is: hardware key, then TOTP, then email-based, then SMS. SMS 2FA is disabled wherever possible because SIM-swap attacks against fractional operators are real; the target value is high and the operator is usually not a hard target.
Layer 3: scoped service accounts, not my personal logins
Wherever a client's platform supports scoped service accounts, I create one with a client-scoped email address and invite that account, not my personal email. For Shopify staff accounts, GitHub collaborators, Google Workspace guest access, Vercel team invites, and similar, the access is tied to an account that exists only for client work.
The reason is clean revocation. When an engagement ends, the service account is deleted by the client during offboarding. The client's system removes the access as part of their own cleanup. My personal email remains uninvolved and therefore uncompromised even if the client's cleanup is imperfect.
The downside is operational: more accounts to manage, more 2FA devices to set up, more notifications. I use a dedicated Gmail account per client where the platform requires it. Plus-addressing (me+clientname@) works for some platforms; others require actually separate addresses. The friction is real but the security posture is much cleaner.
Layer 4: quarterly audit, not annual
Every quarter, I sit down with the four vaults and go through every entry. For each credential, I ask three questions. Do I still need this? Has it been rotated in the last 6 months? Does the client know I still have it?
Most credentials I still hold are legitimately needed. A few are stale and get deleted. Occasionally one is surprising, an account I configured for a pilot that never went into production and still has valid credentials six months later. Those are the highest-risk credentials because nobody is watching them. Delete, notify the client.
A quarterly audit catches drift that an annual audit would miss. A credential that was fine in Q1 can become stale by Q3 as the engagement evolves. Quarterly is the cadence that keeps the hygiene tight without becoming daily overhead.
The offboarding rotation protocol
The moment an engagement ends, a specific protocol runs. Every credential that passed through my hands during the engagement gets treated as potentially compromised, regardless of whether any actual compromise occurred. This is defensive posture, not paranoia.
The offboarding rotation covers: any API key I had access to (rotate), any webhook secret I configured (rotate), any shared password I knew (rotate), any SSH key I authorized (rotate), and any personal access token I created on any client platform (revoke). The client does the rotation; I prompt it with a written list.
After rotation, I delete the vault. The credentials are gone from my side. The client has new credentials that never touched my devices or my password manager. The engagement's blast radius is closed.
This protocol is part of the clean exit playbook but it has its own hygiene dimension worth calling out separately. An engagement that ended cleanly without a rotation pass is an engagement where the operator still has standing access three months later. That access is an unmanaged risk.
The email layer
Email is the weakest link in most fractional operators' security postures. It is the recovery channel for almost every other credential, which means a compromised email is functionally a compromise of everything else.
The specific hardening I run on my primary email account:
- Hardware key as primary 2FA, with a backup hardware key
- App passwords revoked for anything that doesn't strictly need them
- Forwarding rules audited monthly for unauthorized rules
- Security log reviewed weekly for unfamiliar logins
- Account recovery phone number is a dedicated line, not my main cell
The account recovery phone is an underdiscussed vector. SIM-swap attacks target high-value accounts, and a fractional operator with access to multiple DTC brands or healthcare platforms is high-value even if they don't feel like it. A dedicated recovery phone number that is not tied to my primary mobile contract reduces exposure.
“A compromised email is functionally a compromise of every credential that recovers through email.
”
The client-ownership framing
A specific conversation I have with every new client early in the engagement. Who owns what credentials, who is responsible for rotating them, and what the policy is when the engagement ends.
The framing is that all credentials are the client's. I hold them because the engagement requires it. I do not own them. When the engagement ends, every credential either gets rotated or deleted. The client has final say on which.
Having this conversation up front creates the precedent for the rotation protocol at exit. Without it, offboarding becomes an awkward "oh by the way, can we rotate everything?" conversation that nobody enjoys. With it, the rotation is just execution on an agreed policy.
The conversation also exposes clients who have weak internal credential hygiene. If the client doesn't know who owns their Shopify admin, who has Stripe API keys, or who configured their Klaviyo webhook, that's information about the engagement you're about to enter. You will inherit that chaos. Better to see it on day one than to discover it during an incident.
What most operators miss
Three specific items I see fractional operators consistently miss.
First: they forget credentials on platforms they used once for a single task. A one-off Zapier zap six months ago. A test project on a data platform during a vendor evaluation. Those credentials often have broad permissions and stay active for years. Quarterly audit catches them.
Second: they reuse browser profiles across clients. Chrome profile for Client A saves Client A's cookies, auth tokens, and form data. Chrome profile for Client B does the same. If the operator switches clients by switching profiles, they're still in one browser and the profile separation is thin. Better to use genuinely separate browsers (Chrome for Client A, Arc for Client B, Firefox for Client C) so there is no shared session state.
Third: they store client credentials in their personal notes or Notion workspace "just for quick access." The convenience is real; the exposure is also real. Client credentials belong in the vault, not in general notes. If the note-taking workspace is breached, the credentials should not be part of the compromise.
The tooling stack
The concrete tools I use for this system:
- 1Password (separate vaults per client)
- YubiKey 5 Series and Nitrokey Pro (redundant hardware keys)
- Authy for TOTP fallback on platforms that don't accept hardware keys
- Separate Gmail addresses for client-scoped accounts where plus-addressing isn't supported
- 1Password Watchtower for breach monitoring across all vaults
- Cloudflare Zero Trust for any VPN-like access patterns
The stack costs roughly $25 to $40 per month for a solo operator. The cost is trivial relative to the blast radius it contains.
How this shapes engagements
Credential hygiene influences which engagements I can take. A client who resists scoped service accounts and insists I use my personal Gmail for their Shopify staff invite is a friction point. Most negotiate through it once I explain the logic. A few don't, and those clients are usually poor fits for other reasons as well. The credential hygiene conversation is an early tell about how the engagement will go.
The full hygiene system is part of the methodology inside the Operator's Stack course and connects to the rest of the productized ladder.
The hygiene layer also interacts with the subcontractor playbook. When subcontractors touch a client's systems, their credentials go through the same hygiene model: scoped accounts, rotated on exit, audited quarterly. The subcontractor's access is tighter than mine because their engagement is typically shorter.
Frequently asked questions
Is this overkill for a two-client practice?
Less essential, but the hygiene cost is low enough that starting right is easier than retrofitting. A two-client practice that onboards a third client without credential separation has to redo the entire architecture at that point. Building it in at engagement two is cheaper than rebuilding at engagement three.
What about clients who won't let me use scoped service accounts?
Explain the logic. Most clients accept once they understand the blast-radius math. Some don't, and those clients have to be weighed against the risk. You can choose to use your personal credentials for those engagements, or you can choose not to take them. Both are valid answers. The hidden answer ("use personal credentials anyway without thinking about it") is not.
How do I handle a client that shares credentials via Slack or email?
Move the credential out of the channel immediately. Store it in the client's vault. Then reply: "Got it, stored in our shared vault. For future, let's use the vault directly." Over 2-3 instances, the client learns. If they don't, escalate the conversation to the engagement terms.
Do I need liability insurance specifically for this?
Yes, if the credentials you hold are meaningful. A general professional liability policy plus a cyber liability rider is standard. The premiums are modest relative to the blast-radius exposure. Get a broker who works with fractional operators or solo consultants rather than a generic agent.
How do I audit quarterly without it becoming a tax?
Block two hours on the calendar, four times a year. The audit covers all vaults in that window. First time takes longer because you're catching backlog. Subsequent audits take about 90 minutes for 7-8 active vaults. The cadence matters more than the depth of any single audit.
Sources and specifics
- The four-layer stack is the system I actively run across seven active and prior client vaults.
- 1Password with separate vaults has been my tool of choice since 2022. Bitwarden works similarly; the architecture generalizes.
- Hardware keys (YubiKey 5 Series, Nitrokey Pro) are registered redundantly on every primary account. The backup key lives in a separate physical location.
- The quarterly audit cadence has caught at least three stale credentials per audit on average, which would not have surfaced in an annual review.
- This article is part of the fractional practice cluster. The credential layer is one component of the broader practice operating system.