Freelancing in DevOps means holding other people’s keys. One week you have a deploy role in a startup’s cloud account, the next you are inside a retailer’s CI system, and a few months on you may hold access to six companies you will never visit in person. Nobody tells you how to carry that responsibility without becoming the weak link in each client’s security. IdentityOps gives you the vocabulary. This is a step-by-step routine, laid out as I would talk a fellow contractor through it, for taking on client access cleanly and handing it back without leaving a trail of open doors.

A quick note on where the ideas come from. The Ops Atlas from xOps School describes IdentityOps as the upkeep of who and what exists in a company’s systems and how each one proves itself. The Atlas says plainly that the term is still emerging, so I am using it as a practical lens rather than a rulebook.

Step 1: Agree how you will exist in their systems

Before you type a single command, ask the client how your identity will be created. The cleanest answer is a named account for you, tied to your own email address, appearing in their directory with a clear end date. The answer you should resist is a shared login that every contractor uses. The Atlas lists humans sharing service accounts as an anti-pattern because actions can no longer be attributed to anyone, which will also protect you the day something breaks and someone asks who did it.

Write the arrangement into your engagement notes: account name, start date, expected end date, the person at the client who owns your access. If you are already negotiating terms, the points in this guide to working out contract terms with clients are a good place to add a line about access removal on completion.

Step 2: Set up your own sign-in properly

You are the front door to every client you serve, so tighten yours first. Three moves matter.

• A hardware security key for anything important. The Atlas says only FIDO2 or WebAuthn keys and smart-card certificates count as truly phishing resistant, while codes by text and tap-to-approve prompts do not. Buy two keys and register both, keeping one in a drawer.
• A long passphrase in a password manager. The guidance it cites favours fifteen characters or more when a password stands alone, drops forced symbol rules and scheduled changes, and checks choices against a blocklist.
• A recovery plan you have actually tested. If your phone is stolen on a Friday night, can you get back in without phoning a help line?

On that last point, the Atlas calls ringing someone back an unreliable check, since SIM swapping defeats it. For a solo operator, the equivalent is a second enrolled method kept offline, such as the spare key.

Step 3: Keep a register of every client door you hold

A simple spreadsheet does the job. For each client, list the systems you can reach, the type of credential (personal login, API key, deploy token), who granted it, and when it should end. The Atlas describes a lifecycle for machine credentials that starts with exactly this: take stock, record an owner, purpose and expiry, then rotate and retire. When a client gives you a token for a pipeline, you are creating a machine identity that probably belongs to them, so record whose it is.

Once a month, open the register and ask three questions. Which entries have passed their end date? Which credentials have I not used in ninety days? Which ones live somewhere they should not, such as a note, a chat message or a repository? The Atlas suggests a ninety to one hundred eighty day window for dormant sweeps, and ninety days is a sensible choice for a freelancer who juggles many clients.

Step 4: Never keep long-lived secrets on your laptop

This is where most contractor stories go wrong. A token pasted into a local config file in March is still sitting there in November, long after the project closed. Prefer short-lived credentials issued through the client’s identity provider, and when you must hold a key, set a calendar reminder for its removal. The public record is a useful reminder. The Atlas recounts a 2023 incident in which a service-account credential was discovered in an employee’s personal cloud drive, and its summary of the 2024 Snowflake customer breaches notes credentials that had gone unrotated for up to four years. In neither case did cryptography fail; careless handling did.

Step 5: Make sure the client can remove you for real

Offboarding is a two-way job. At the end of an engagement, ask the client to confirm in writing that your account is disabled. Then understand what disabled means. The Atlas points out that a live session or token can survive the account that created it, so you should also close your own browser sessions and sign out of their tools. On some platforms the account may stay active until the last downstream application receives the update, and the Atlas notes that revoking a session can take a few minutes to take hold.

A good habit: send a short message on your last day listing what you held and asking for confirmation of removal. If a client has a tidy process, they will reply with timestamps. If not, you have just given them their first leaver drill, and you have documented that you did your part. It also builds the sort of confidence described in this practical piece on earning trust from clients who have never worked with you.

Step 6: Offer a light identity review as a paid add-on

Here is where this turns into income. Many small clients have never counted their accounts. You can offer a short roster audit: export the users from their directory and their main tools, compare the two lists, and flag anything unowned. The Atlas notes that reconciling against application exports is more reliable than reading provisioning logs, because logs show intent, not outcome. A one-page report with five findings is easy to sell and easy to deliver.

Keep the scope modest. The Atlas is clear that a tiny organisation does not need a heavyweight governance product, and that buying one before the HR data is clean is a mistake. Your value as a freelancer is making the first small improvements with a spreadsheet and a calm explanation.

Step 7: Measure like a professional

If you do repeat work for a client, bring one number. The Atlas example is worth borrowing as a template: measure leaver compliance across every application, not only the central directory, because the second figure flatters. Over time, a number that rises is the strongest testimonial you can have, and it gives you something concrete to point to when renewing a retainer.

What good looks like after a year

Picture the freelancer who follows this routine for twelve months. Every client has a named sponsor for your access. Every engagement closed with a written confirmation. Your register shows no credential past its end date, and your own sign-in relies on two registered security keys. When a prospect asks for references on security practice, you hand over a one-page summary of how you work, and it becomes a quiet differentiator against contractors who answer with a shrug. That is the long game, and it costs very little.

A weekly rhythm for one person

Freelancers do not need quarterly committees, but a rhythm helps. On Monday, review the register for expiring access. On Friday, check that no new secrets slipped into notes. Monthly, run the ninety-day dormant check and test your recovery route. Each time an engagement ends, finish the handover message in Step 5. That is perhaps an hour a week for a handful of clients, and it makes you the contractor who leaves nothing behind.

Where to read more

If you want the full framework behind this routine, including the maturity ladder and the cadence of checks, start with the Ops Atlas page that explains the IdentityOps discipline. The first few sections are enough to get you talking confidently with a prospective client, and the rest is a reference you can dip into as engagements demand. And if a prospect asks how many ex-contractors still have access to their cloud account, you will now be the person who knows how to find out.