Access control and offboarding

Somebody leaves on a Friday. IT disables their account, collects the laptop, and closes the ticket. On Monday an integration stops working, because it had been authenticated as that person since 2022 and nobody knew. Six weeks later a VPN certificate issued to their personal machine still authenticates, because revocation was never part of the process. A year later their name is still on a shared vendor portal login that three people use.

None of this is unusual and none of it reflects carelessness. It reflects the fact that access accumulates through dozens of small, individually reasonable grants over several years, and offboarding is a single event that inherits none of that history. The account is the part everyone can see. Everything else is invisible unless somebody wrote it down at the time.

The business consequence is a slowly growing population of credentials that work, belong to nobody, and appear in no review. That is the population an attacker is looking for, and it is also the first thing an auditor asks about.

Joiner, mover, leaver — and the one everyone skips

Access management is conventionally described as three events. In practice businesses handle the first well, the third adequately, and the second not at all — and the second is where most of the accumulated risk originates.

The middle row is where entitlement creep comes from, and it is entirely mechanical. Someone moves from support to operations, then to a team lead role, then to a different department. At each step new access is required immediately and old access is removed never, because nobody is certain it is safe to remove and nobody is accountable for the accumulation.

After a few years the longest-serving people hold the broadest access in the business, which is precisely the inversion of what a least-privilege model intends. They are also the accounts most valuable to compromise.

Copying permissions is how creep spreads

The single most common onboarding shortcut is to grant a new starter the same access as an existing colleague. It is fast, it works, and it copies every accumulated entitlement that colleague acquired across three role changes. Within two hires the original justification for half those grants is untraceable.

The alternative is a role profile: a documented set of access that a role requires, granted from that definition rather than from a person. It takes an afternoon to write for the five or six roles that cover most of a business, and it stops creep propagating by inheritance.

What actually survives an offboarding

Disabling the directory account is necessary and it addresses one category. The categories below survive it, and each one has been found live in businesses that considered their offboarding complete.

• Client certificates issued to the person's device, which authenticate independently of the account unless revoked and unless the gateway checks revocation.
• Integrations and scheduled jobs authenticated as that person, which fail on their last day and are then fixed by re-authenticating as somebody else rather than by moving to a service account.
• API keys and tokens they generated, which are attached to the system rather than to the directory and continue working.
• Shared credentials they knew, in vendor portals, hosting panels, domain registrars and telephony systems, where access is knowledge rather than identity.
• Local accounts on individual servers, network devices and appliances that were never joined to central identity.
• Access granted as an exception during a project and never withdrawn, which is invisible precisely because it sat outside the normal process.
• Data on personal devices, and in personal cloud storage, that no revocation reaches at all.

The fourth item is the hardest and the one businesses most often accept. A password that several people know cannot be revoked by disabling an account — it is revoked by changing it, which means knowing every consumer of it. That is the same inventory problem described in the secrets management article, and offboarding is where its absence becomes visible.

The controls behind this are standardised

This is useful when the work has to be justified to somebody holding a budget, because the requirement is not a matter of opinion.

NIST SP 800-53 addresses it in the Access Control family. AC-2, Account Management, requires that organisations create, enable, modify, disable and remove accounts in accordance with defined policy and criteria, and that account managers are notified when accounts are no longer required. Its enhancements are more specific still: AC-2(3), Disable Accounts, calls for disabling accounts within a defined period when they have expired, are no longer associated with an individual, violate policy, or have been inactive beyond a defined period. AC-2(2) addresses temporary and emergency accounts, requiring that they be automatically removed or disabled after a defined period rather than persisting.

Two things are worth extracting from that. The standard expects a defined time period rather than best effort, which converts offboarding from a task into a measurable control. And it treats inactive accounts as a category in their own right — accounts belonging to nobody in particular, which is exactly what accumulates when leaver processes are incomplete.

Access review: the control that finds what the process missed

Every offboarding process leaks. The question is whether anything catches the leakage, and the mechanism that does is a periodic reconciliation between who has access and who should.

1. 1

   Take the access list

   Every account with access to each significant system, including local accounts on devices and accounts in vendor portals that are not joined to central identity. This list is usually harder to produce than expected, and its difficulty is itself a finding.

2. 2

   Take the people list

   Current staff, current contractors with live engagements, and current service accounts with a named owner. Anything on the access list that is not on this list is the output of the review.

3. 3

   Reconcile, and route the differences

   Accounts with no matching person are disabled. Accounts whose access exceeds their role profile are reduced. Service accounts with no owner are assigned one or removed.

4. 4

   Have the system owner confirm, not IT

   IT can produce the list but cannot judge whether a finance user should still reach a particular system. The person accountable for that system signs off, and their sign-off is recorded.

5. 5

   Record the result

   What was reviewed, when, by whom, and what changed. A review that was performed and not documented cannot be relied on later, by an auditor or by the next engineer.

The first time this runs in a business that has never done it, the result is uncomfortable and that is the point. Finding fourteen live accounts belonging to people who left is a good outcome, not a bad one — the accounts existed either way, and now they do not.

Privileged access deserves separate handling

Administrative access to servers, network devices, hypervisors, identity systems and financial platforms is a different category from ordinary user access, and treating both through one process under-protects the first.

Three practices carry most of the value and none requires a dedicated platform. Administrators should hold a separate privileged identity rather than elevating their daily account, so that a compromised email session does not carry administrative rights. Privileged access should be reachable only through a defined path — a bastion or jump host with multi-factor authentication and session recording — rather than directly from a user workstation. And privileged sessions should be logged in a way that survives the administrator, because the audit question is what was done, not who was logged in.

Where a business can go further, time-bound elevation is the strongest improvement available: administrative rights granted for a defined window on request rather than held permanently. It removes standing privilege entirely, which means an offboarding that misses something misses something with no rights attached.

Contractors, third parties and the accounts nobody owns

Third-party access fails differently from employee access, because there is no HR event to trigger the leaver process. An engagement simply ends, quietly, and nothing in any system notices.

The mechanism that fixes this is an expiry date set when the account is created, matched to the contract. An account that expires by default fails safe; an account that must be remembered fails open, and the person who would have remembered has moved to the next project. This is the same reasoning applied to temporary firewall rules and to temporary access exceptions, and it is the single highest-value habit in this whole subject.

Service accounts have the same problem in a different shape. They belong to a system rather than a person, so no leaver process touches them, and they frequently hold broad permissions because they were created to make something work. Every service account needs a named human owner who can answer whether it is still required — not because they use it, but because somebody has to be accountable for its continued existence.

Common mistakes

A representative scenario

A composite of situations we see repeatedly; no client detail is included.

A business with around ninety staff runs its first access review after an insurance questionnaire asks how often one is performed. The expectation is that it will be a formality.

The reconciliation found live accounts for eleven people who had left, the oldest more than two years earlier. Four integrations were authenticated as individuals rather than service accounts, two of them as someone no longer employed — they had continued working because disabling the directory account did not invalidate the stored token. Several administrators used their daily account for privileged work. Two vendor portal logins were shared by name among a team, so no departure had ever changed them. A contractor engagement that ended the previous year still had VPN access with a valid certificate.

The remediation was ordered by what a compromise would reach. Dormant accounts were disabled and their certificates revoked the same week. Integrations moved to service accounts with named owners. Administrators were issued separate privileged identities and routed through a bastion. Shared vendor logins were replaced with individual access where the vendor supported it, and where it did not, the credential was rotated and its consumers recorded. Contractor accounts were given expiry dates matched to their contracts.

The review itself became quarterly, with system owners signing off rather than IT. The second review found two items rather than twenty, which is what the control looks like when it is working.

Implementation checklist

• Role profiles exist for the common roles, and new access is granted from them rather than copied from a colleague.
• A role change is handled as a leaver followed by a joiner, so old access is removed rather than accumulated.
• The leaver process covers certificates, tokens, API keys, shared credentials, local device accounts and project exceptions — not only the directory account.
• No integration or scheduled job authenticates as a named employee; all use service accounts.
• Every service account has a named human owner accountable for whether it is still required.
• Contractor and temporary accounts carry an expiry date set at creation, matched to the engagement.
• Administrators hold a separate privileged identity and reach management interfaces through a defined path with MFA.
• Privileged sessions are logged in a way that survives the administrator.
• An access review runs on a fixed interval — quarterly for general access, more often for privileged.
• The system owner signs off the review, not IT, and the result is recorded with scope, date and changes.
• Anything found by a review that the leaver process should have caught is fed back into that process.

Frequently asked questions

Conclusion

Offboarding is judged by what it misses, and what it misses is determined years earlier by whether access was recorded when it was granted. A business that grants access from role profiles, assigns an owner to every service account, and sets an expiry on anything temporary will have a leaver process that mostly works. One that grants access by copying colleagues and remembers exceptions informally will not, however good its checklist.

The access review is what makes the difference visible. It is uncomfortable the first time and routine by the third, and the trajectory of what it finds is the only honest measure of whether the rest of the process is improving.