BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 20, 2026

Quick answer: Every employee who joins your organization needs access provisioned. Every employee who changes roles needs their access updated to reflect their new responsibilities and their previous access revoked. Every employee who leaves needs all access revoked promptly and completely. The joiner-mover-leaver (JML) process sounds simple; in practice it is one of the most consistently underperformed identity management functions in organizations of every size. Manual provisioning creates delays and inconsistency. Role changes that add access but do not remove old access create privilege accumulation. Departures that trigger only the most obvious access revocations leave behind service accounts, shared mailboxes, cloud platform access, and third-party application accounts that remain active for months or years. Each of these gaps is a potential unauthorized access point that neither the security team nor the former employee’s manager has visibility into.

Key Takeaways

• Orphaned accounts are accounts that no longer have a current, active owner but remain enabled with whatever access they were last assigned. They include accounts of former employees that were not fully deprovisioned, service accounts whose owning application has been decommissioned, accounts created for contractors or projects that were never closed, and shared accounts that no individual currently claims. Orphaned accounts are attractive targets for insider threats and external attackers because they have access and no one monitors them.
• Access creep is the gradual accumulation of permissions beyond what a user currently needs, resulting from access being added when roles change or projects begin and never being removed when those roles or projects end. An employee who has worked in three departments over five years may have accumulated the access of all three roles rather than only the access needed for the current role. This accumulated access represents standing privilege that the employee may not need and that creates unnecessary exposure if that account is compromised.
• The access review process is the governance mechanism that catches and corrects both orphaned accounts and access creep on an ongoing basis. A quarterly access review requires managers and application owners to certify that each person under their responsibility has only the access appropriate for their current role. Reviews that happen annually or not at all allow orphaned accounts and access creep to accumulate for the full period between reviews.
• Automation is the practical solution to consistent JML execution. Manual provisioning processes are slow, error-prone, and dependent on the person performing them knowing which systems each role requires access to. Automated provisioning workflows tied to HR system events provision access based on defined role templates when someone joins, update access when a role change is recorded in HR, and trigger deprovisioning workflows when a termination is processed. Automation does not eliminate the need for governance; it ensures that the baseline JML actions happen consistently and promptly while governance catches what automation does not cover.
• Contractor and vendor access is the most undercontrolled JML scenario. Employee access is managed through HR processes that at least trigger some deprovisioning action on termination. Contractor access is often provisioned for a project, has no formal end date, and is never explicitly revoked because no HR termination event triggers the deprovisioning workflow. Time-bound access that expires automatically at the end of the contractor engagement, requiring positive renewal if the engagement extends, is the control that prevents contractor access from persisting indefinitely beyond its authorized scope.

How Orphaned Accounts Accumulate

Incomplete offboarding

Employee offboarding in most organizations focuses on the obvious access: the Active Directory account is disabled, the email account is removed or delegated, and the corporate laptop is returned. The less obvious access frequently survives: accounts in SaaS applications that were provisioned separately from Active Directory, cloud platform access that was granted directly to the individual’s personal cloud account rather than through the corporate identity provider, shared administrative accounts where the person’s knowledge of the credentials cannot be technically revoked without changing the password, and service accounts the person created that are tied to their individual email address but run system functions. These accounts remain active because no offboarding checklist captured them, no system flagged them, and no one with authority to deprovision them knew they existed.

The risk from incompletely offboarded accounts ranges from the disgruntled former employee who retains access and uses it maliciously to the benign situation where the account simply sits unused until an attacker who has compromised the former employee’s personal email address uses it for password reset to gain access to the corporate system. Neither scenario requires the former employee to do anything with the account; the risk is the existence of the account with no current owner monitoring it. This is exactly the kind of standing exposure that belongs on a security risk register as a tracked, owned risk rather than an invisible gap discovered only during an incident or an audit.

Role changes without access updates

When an employee moves from one role to another, the new access required for the new role is typically provisioned. The access from the previous role is typically not revoked. The reasons are operational: IT does not know exactly which access the old role used and is reluctant to remove access that might still be needed, the manager approving the new access does not have visibility into the old access and does not think to request its removal, and the provisioning process does not have a defined access set for the previous role to remove. The result is that each role change adds to the employee’s access profile without ever reducing it.

Over a career with several role changes, the accumulated access profile of a long-tenured employee may include access to systems, applications, and data repositories that are completely unrelated to their current function. This access creates unnecessary exposure: if the account is compromised, the attacker has access to everything the employee has accumulated, not just what the current role requires. It also creates compliance risk: auditors who review the access profile of a single user and find permissions inconsistent with the stated role will identify the gap as a failure of the least-privilege principle regardless of how the access accumulated. Enforcing least privilege consistently is one of the core objectives of a zero trust identity architecture, and access creep is precisely the drift that undermines it over time.

What Access Governance Requires

Quarterly access reviews

A quarterly access review is a structured process in which managers and application owners certify that each member of their team or user base has only the access appropriate for their current role. The review presents each reviewer with a list of their reports or application users, the access currently assigned to each, and a certification interface where they confirm, modify, or remove each access entitlement. Exceptions to the standard access set require documented justification and approver sign-off. Access that the reviewer cannot justify is revoked as part of the review cycle.

Quarterly frequency is the standard recommended by most compliance frameworks and security benchmarks. Annual reviews are too infrequent to catch access that should have been revoked when a role change occurred six months ago. The quarterly cycle ensures that no access accumulation persists for more than three months before being reviewed. For privileged access, more frequent reviews, monthly or even continuous monitoring through privileged access management, are appropriate given the higher risk of privileged account compromise.

Role-based access control as the foundation

Role-based access control (RBAC) defines standard access sets for each job function in the organization. A member of the finance team has the finance role, which grants access to the financial systems and data that all finance team members need. A new finance team member is provisioned with the finance role rather than having access individually configured; a finance team member who moves to operations has the finance role removed and the operations role added. RBAC reduces provisioning time, makes access consistent across people in the same role, and makes access reviews more efficient because reviewers are certifying role assignments rather than evaluating individual access entitlements one by one.

Building a functional RBAC framework requires documenting the access required for each role in the organization, mapping existing access profiles to those roles, identifying and resolving cases where individuals have access beyond what their role requires, and maintaining the role definitions as organizational structure and application portfolios change. This is a significant one-time effort that pays dividends in operational efficiency and governance effectiveness over time. Armour Cybersecurity designs the RBAC framework and access governance process as part of its identity and privileged access management engagement, producing the role definitions, certification workflows, and exception handling procedures that make the quarterly review sustainable.

Automated JML workflows

Automated JML workflows connect the HR system, which is the authoritative source of employment status and role information, to the identity provisioning system, which executes access changes. When HR records a new hire, an automated workflow provisions the new employee’s account with the access defined for their role and their manager. When HR records a role change, an automated workflow removes the access of the previous role and provisions the access of the new role. When HR records a termination, an automated workflow disables all accounts associated with the terminated employee across connected systems within a defined timeframe.

Automation does not eliminate the need for human oversight. Role templates may not cover every access entitlement the employee needs; exceptions must be manually provisioned and tracked. The HR system may not capture every system the employee has access to; application access that was provisioned outside the standard process requires a separate review and offboarding step. Automation handles the roughly 80 percent of JML actions that follow standard patterns quickly and consistently; governance catches the remaining share that requires human judgment.

Frequently Asked Questions

How do we find all the orphaned accounts in our environment?

An identity posture assessment inventories accounts across connected systems and compares them against active HR records, identifying accounts with no current owner: accounts for individuals who are no longer employed, accounts assigned to email addresses that no longer exist in the directory, and accounts that have had no login activity for an extended period suggesting they are no longer in active use. The assessment covers the on-premises Active Directory, the cloud identity provider, and optionally individual SaaS applications where direct application account discovery is feasible. Service accounts are inventoried separately and classified by the application or process they support, with accounts that cannot be associated with a current operational purpose flagged for review and decommissioning. The output is a prioritized list of orphaned accounts with recommended disposition for each.

What should the SLA be for revoking access when someone leaves?

The access revocation SLA on termination should be measured in hours, not days. For voluntary terminations with planned end dates, access can be scheduled for revocation at the end of the final working day. For involuntary terminations, account suspension should occur simultaneously with or immediately following the HR action that terminates the employment relationship. Privileged accounts for terminated employees should be revoked within one to four hours of the termination decision regardless of the circumstances, because a terminated employee who retains privileged access to systems is an insider threat risk in the period immediately following termination. Standard user access should be revoked within four to eight hours of the formal termination. Access that requires the employee’s cooperation to identify and transfer, such as documented credentials for systems the employee managed alone, should be addressed through the offboarding process prior to the final day wherever possible.

What are the risks of not revoking contractor access promptly?

Contractor access that persists beyond the contractor’s engagement represents unauthorized access to organizational systems by an external party who is no longer bound by the organization’s agreements, no longer supervised by anyone in the organization, and may not even be aware that their access remains active. The risk ranges from accidental data access (the former contractor logs in out of habit or curiosity) to deliberate unauthorized access (the former contractor accesses systems for competitive intelligence or retaliatory purposes) to breach facilitation (the former contractor’s credentials are compromised and used by an attacker who now has access to the organizational systems the contractor could reach). The simple control that prevents all of these scenarios is time-bound access with automatic expiration: contractor access is provisioned with an end date matching the expected end of the engagement and requires a formal extension request to continue beyond that date.

How do we handle access when an employee takes a leave of absence?

A leave of absence presents the same risk as a termination from an access management perspective during the leave period: the employee is not working and should not have active system access, but the employment relationship continues and access will need to be restored when the leave ends. The appropriate control is account suspension, not deletion: the account is disabled so that authentication is rejected if the credentials are used, but the account record and its access assignments are preserved so that reinstatement at the end of the leave requires only re-enabling the account rather than reprovisioning all access from scratch. For extended leaves, a quarterly access review during the leave period should evaluate whether the access the account held when it was suspended still reflects what the employee will need upon return, given that the role or systems may have changed during the absence.

The Bottom Line

The joiner-mover-leaver process sounds like paperwork, but every gap in it is a live account with real access and no one watching it. Joiners get provisioned inconsistently, movers accumulate the access of every role they have ever held, and leavers keep the SaaS logins, cloud access, and service accounts that no offboarding checklist ever captured. The fix is not heroics from IT; it is structure: role-based access control so provisioning and review work off defined role sets instead of guesswork, automated JML workflows tied to HR events so joins, moves, and departures trigger the right access changes on time, quarterly access reviews so nothing accumulates for more than a quarter, and time-bound expiry so contractor access cannot outlive the engagement. Automation handles the standard cases and governance catches the exceptions. Armour Cybersecurity’s identity and privileged access management engagement builds that lifecycle control set end to end, from the orphaned-account inventory through the RBAC framework and the sustainable quarterly review.