Access control when other people work on your sites

Give each person the narrowest access that lets them finish the job, on an account that belongs to them alone, with an end date chosen the day you grant it. Every hard problem here comes from breaking one of those three. The cost lands a year later, when you cannot say who still has a way in or which of them touched the thing that broke.

Match the access to the task, not to the person

The instinct is to hand a contractor "access" as if it were one item. It never is. Work out what the task touches, grant that, stop.

Create the access when the work starts rather than keeping a standing account warm between engagements, and record the reason beside it. An account whose purpose you cannot state in one sentence is one you cannot safely keep.

What a shared login actually costs

One login used by four people answers no question worth asking. When a redirect appears that nobody planned, the logs show the account, not the human, so the investigation stops at the door. Revocation fails the same way: changing it locks out three innocent people, so it gets postponed, and postponed removal is access retained.

Shared credentials also travel, into an agency vault, a chat thread, a subcontractor's notes. You cannot revoke a copy you do not know exists. Second factors make it worse, because a shared account has its second factor either switched off for convenience or tied to one person's phone, and that person eventually leaves.

The doors that get forgotten

• A database user made for one import three years ago, still holding full rights on a live database.
• A key added so somebody could work over a weekend, never removed afterwards.
• An API token issued to a script a contractor wrote, still valid, still running.
• A third party service authorised months ago: a backup tool, a form handler, a monitor, a deployment pipeline. It holds its own access, independent of anyone's login.
• Registrar and DNS logins, which sit outside whatever process covers the sites themselves.

Offboarding: the step almost everyone skips

Most offboarding ends at deleting the person's accounts. That takes away their key, not what they knew. Finish the job:

1. Rotate every shared secret they had sight of, starting with database passwords in configuration files and outbound mail credentials.
2. Revoke tokens and third party connections inside the service that issued them, not only on your side.
3. Remove them as an authorised contact on hosting, registrar and payment accounts, so nobody can act on their request later.
4. Check recovery paths: recovery address, phone number, backup codes. A recovery route is access with extra steps.
5. Re-run whatever their scripts did, and confirm the rotation has not broken a nightly job.

A review rule you will keep

Review by door, not by person, once a quarter and again on every departure. The people you have forgotten are the ones you will not think to look up, so start from the openings: hosting logins, file access, database users, keys, tokens, connected services, DNS and registrar. Name the human responsible and the reason each exists. Anything temporary gets an expiry at creation, and 90 days is a sensible default when nobody proposes shorter.

Test the register by picking one site at random and answering "who can reach this database today" without logging into anything. If that takes more than a few minutes, the register is stale. Keep it alongside the rest of your routine in running your estate, and raise changes to the authorised contacts on the account itself through contact.