Most teams can tell you the exact moment access was granted. Far fewer can tell you when, or whether, it was revoked.
That gap is where the risk concentrates. Origin Energy confirmed a breach affecting around 900,000 current and former customers, traced to a former call-centre worker in Manila whose credentials reached customer data. It is a failure of the leaver stage, and a useful lens on the Origin Energy breach.
This article covers what credential lifecycle management is, why offboarding keeps failing audits, how to test whether your own offboarding works, and how to get more from the tools you already have.
What is credential lifecycle management and why does it matter?
Credential lifecycle management is the end-to-end governance of authentication credentials, from creation through rotation to permanent revocation. A credential is born, used, changes and must die. It matters because the leaver stage is where unrevoked access concentrates risk, producing orphaned accounts and privilege creep.
In plain English, a credential is anything that proves you are who you say you are: passwords, API keys, SSH keys, tokens and certificates. Each is provisioned when someone joins, used day to day, rotated over time, and revoked when it is no longer appropriate.
The credential-specific slice of identity lifecycle management follows an identity from creation to destruction, under the broader identity and access management (IAM) umbrella. The organising skeleton is the joiner-mover-leaver (JML) procedure: joiners are granted access, movers have it changed, and leavers must lose it.
The leaver stage is where value and risk concentrate: an account stops having an owner but too often keeps having access. That is how you get orphaned and unrevoked credentials: standing access with no active owner, and permissions that keep piling up with nobody reviewing them. A recent study found 63% of businesses may have former employees with access to organisational data.
What is offboarding in a security context, and why is it one of the most common audit findings?
Offboarding is the process of revoking a departing employee's or contractor's access across every system, and the technical act is deprovisioning. It is a common audit finding because revocation is assumed rather than evidenced: manual steps, distributed apps and third-party access leave disabled-but-still-valid accounts and lingering tokens behind.
Offboarding spans a checklist across dozens of systems, many of them SaaS apps provisioned without IT involvement. In one survey, 79% of IT professionals felt confident in their offboarding process, yet 85% spent hours or more deprovisioning a single employee's SaaS accounts, and 70% had already felt the effects of incomplete offboarding.
This is what ISO/IEC 27001:2022 Control 6.5 exists to prevent. It requires security responsibilities that survive an exit, timely revocation, and returned assets. NIST SP 800-53 splits the idea: PS-04 covers termination, demanding prompt revocation, while PS-05 re-checks access on role change.
Automation closes the gap, but only where it reaches. SCIM lets an identity provider (IdP) like Okta or Microsoft Entra ID push a revocation to every connected app the moment HR records a termination, leaving a timestamped trail. Manual offboarding is defensible only for a small, rarely-changing population backed by a checklist and evidence. Genuine revocation requires timestamps and rotated keys; a disabled account whose tokens keep working is not yet revoked.
How do you know whether your offboarding process actually works?
Test whether you can produce a timestamped revocation record for every system from the moment HR records a termination. Strong signals include a documented joiner-mover-leaver procedure, high automation rates, a low orphan-account count and a short mean time to revoke. Contractor access needs its own audit.
Good evidence is an HR termination timestamp mapped to per-system revocation timestamps, plus an orphan-account scan showing no live access for departed identities. One audit found an AWS account and API key still in daily use months after its owner left.
Mean time to revoke (MTTR) measures the gap between termination and full revocation, and it is the figure auditors ask about most. Watch the orphan-account count, the automation rate, and the revocation rate from access reviews.
Contractor access deserves its own audit, since vendors and offshore teams churn faster and are controlled more thinly. When that access is privileged, it ties directly into privileged access management.
What's the best identity governance approach when security headcount is limited?
Make an identity provider, Okta or Microsoft Entra ID, the system of record for identity, then use SCIM-based automation to deprovision connected apps. Handle apps without SCIM with a documented manual step, and run targeted access reviews on high-risk populations. Leverage beats sprawling tooling when headcount is limited.
No team can manually chase deprovisioning across hundreds of SaaS apps. Start with the identity provider, let SCIM handle the apps that support it, and keep a documented manual fallback plus stale credential cleanup for everything else.
Run targeted access reviews on the populations that matter most: admins, finance, contractors and shared accounts. Reviewing everything at once is how reviews stall. Most teams still run access changes through ticketing systems that were never designed for identity lifecycle, leaving fragmented audit trails.
The Origin Energy breach came down to a revocation that never happened. The audit test: can you map an HR termination timestamp to a revocation record on every system? What survives an audit is evidence: a timestamp, a revocation confirmation, a rotated key. The question worth asking is whether you can prove every leaver's access actually died, and that is the credential lifecycle risk worth owning.
Frequently Asked Questions
Is disabling an account the same as revoking access?
No. Disabling an account stops the person logging in through the front door, but it can leave tokens, API keys and active sessions untouched. A disabled-but-still-valid account is one of the most common offboarding findings, because the credential still authenticates against services that never learned the user was disabled. Genuine revocation means killing every credential that identity held, not just switching off the login.
What are orphaned accounts, and how do they get created?
Orphaned accounts are active credentials with no owner, usually left behind when someone changes role or leaves without full deprovisioning. They accumulate through manual handovers, shadow IT sign-ups and contractor access that was never tied to a managed identity. Because nobody owns them, nobody reviews them, and they quietly become standing privilege an attacker can use. An orphan-account scan is the fastest way to find them.
How quickly should a leaver's access be revoked?
Fast enough that there is no working window between the person leaving and their access dying, and for high-risk roles that means within hours, ideally minutes. ISO 27001 Control 6.5 requires revocation to be timely but leaves the exact figure to your risk assessment. The practical test is not the policy number, it is whether you can show a termination timestamp matched to a revocation timestamp.
Do role changes need deprovisioning too, or only departures?
Role changes need their own review, because a mover keeps their identity but should not keep their old access. NIST SP 800-53 PS-05 covers transfers by requiring access to be re-evaluated when someone changes position, while PS-04 covers termination. Moving an engineer into finance without removing their old production rights is how privilege creep builds up, and access reviews are what catch it.
What about API keys, tokens and service accounts when someone leaves?
These are the credentials most often missed, because they are not tied to a person's login. A leaver may have created personal access tokens, SSH keys or API keys that keep working long after their account is disabled. Offboarding must include inventorying and rotating or revoking these non-human credentials. If you cannot list every key that identity ever created, you cannot claim their access died.
Can't we just rely on the HR system to trigger offboarding?
No. The HR system can trigger the process, but it cannot confirm that access was actually removed across every application. Without an identity provider acting as the system of record, and automation to act on that trigger, the HR event is just a signal that someone should do something. Evidence of revocation comes from the target systems, not from HR.
What is SCIM, and do we actually need it?
SCIM is a standard that lets an identity provider automatically create and remove accounts in connected applications. It matters for offboarding because it turns deprovisioning from a manual checklist into an automated action that leaves a timestamped record. You want it wherever an app supports it, and a documented manual fallback plus stale credential cleanup wherever it does not.
What happens if a leaver needs access during a handover period?
Grant only the specific access they need for the defined handover, on a temporary basis, with an expiry date. A blanket extension of their standing access is what turns a handover into an orphaned privilege problem. Time-box the access, log the exception, and confirm it is revoked when the handover ends. Temporary does not mean untracked.
How long should we keep offboarding records for audit purposes?
Keep them long enough to cover your audit and regulatory cycle, which for most mid-market organisations means at least the period your certification or framework requires, often one to three years. The record should link the HR termination date to each system's revocation confirmation. If you cannot produce that trail later, the revocation effectively never happened as far as an auditor is concerned.
Does credential rotation replace the need for offboarding?
No. Rotation limits how long a stolen credential stays useful, but it does not remove an identity's access by itself. A rotated key still belongs to whoever held it. Rotation and offboarding solve different problems: rotation shrinks the blast radius of a compromise, while offboarding ensures a departed identity holds nothing at all. You need both.
What is the difference between offboarding and deprovisioning?
Offboarding is the whole process of ending someone's relationship with the organisation's systems, including asset returns and knowledge handover. Deprovisioning is the technical act of removing their access and credentials across every system. The two are often used interchangeably, but conflating them is risky: you can complete an offboarding checklist while still leaving the deprovisioning half done.
What should a small team do if it can't afford a full identity platform?
Start with one system of record rather than a broad toolset. Even a basic identity provider, or a spreadsheet backed by documented manual steps, beats scattered checklists, as long as you keep it current and produce revocation evidence. Prioritise high-risk populations such as admins, finance and contractors, and let automation expand as budget allows. Leverage beats tooling.