Certified: The ISC(2) ISSAP Audio Course

In this episode, we’re going to look at a lifecycle problem that shows up in almost every organization and causes a huge number of real security incidents: people and accounts change, but permissions often do not change correctly. Joiners, movers, and leavers describes three moments in a person’s relationship with an organization: when they first join and need the right access, when they change roles and need different access, and when they leave and should lose access promptly. The risk is that accounts can be left behind, privileges can accumulate over time, and old access can remain active long after it should be gone, creating what is called orphan access. Orphan access is dangerous because it gives attackers and insiders a quiet path into systems, and it also makes auditing and incident response much harder because you cannot trust that every active account has a legitimate owner. For beginners, this topic is a great example of how security architecture is about processes and design decisions, not only about technology. The goal here is to teach you how to think about provisioning and deprovisioning as a controlled workflow that prevents access from lingering, ensures accountability, and stays resilient even when HR data is messy and systems are complex.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

A good first step is to define provisioning and deprovisioning in plain terms. Provisioning is the process of creating an identity record, creating accounts where needed, and granting access so a person can do their job. Deprovisioning is the process of removing that access, disabling accounts, and ensuring that no hidden or indirect access remains. The tricky part is that modern access is not just one login; it includes application accounts, cloud services, group memberships, shared resources, devices, tokens, and sometimes physical access too. A person can “have access” in many ways, and not all of them are obvious from a single directory. That is why orphan access happens: the organization disables one account but forgets about another, or removes a user from a group but forgets a service token that still works. Architects focus on designing the lifecycle so access is granted and removed based on well-defined events and authoritative sources of truth, rather than based on informal emails and memory. For beginners, the key idea is that access must follow the person’s lifecycle, not the other way around. If the system cannot reliably tie access to current status, it will drift toward over-permission.

Joiners are the easiest to picture, but they hide important traps. When someone joins, there is pressure to get them working quickly, which can lead to granting broad access “temporarily” that later becomes permanent. A safe design starts by defining a baseline access set that every new person receives, such as basic collaboration access, and then adds role-based access as needed. The baseline should be minimal and should not include privileges that are difficult to remove later. A joiner workflow also needs identity proofing decisions already made, because you want to be sure you are creating an account for the correct person. It must also define who approves access and what data drives the decision, such as job role, department, or location. A common beginner misunderstanding is thinking provisioning is a one-time task, but good designs treat it as a controlled process with checks, such as verifying that a manager exists, verifying that the start date is correct, and ensuring the person is in the right organizational unit. These checks reduce mistakes that can accidentally create accounts for the wrong person or grant access in the wrong scope. The joiner stage is where you set expectations for least privilege, and if you start sloppy, you will spend years trying to clean up accumulated mess.

Movers are where many organizations struggle, because role changes happen constantly and are not always captured cleanly in a single system. A mover could be someone changing teams, getting promoted, moving locations, taking on temporary duties, or switching from contractor to employee. Each change can affect what access is appropriate, and the danger is “privilege creep,” where people keep old permissions and add new ones, becoming more privileged over time than any single role should allow. A secure design treats a role change as a trigger to reassess access, not as a minor update to a profile field. One approach is to define access packages by role and then re-evaluate group memberships when the role changes, removing what no longer applies. Another approach is to implement time-bounded access for temporary duties, so elevated access expires unless renewed. The architectural point is not to pick a single method but to ensure there is a mechanism that reliably removes prior access when it should end. For beginners, the important idea is that movers are a predictable pattern, so you design for it up front rather than treating it as a special exception each time.

Leavers are often the highest risk moment because the person is leaving the organization’s control, and motivations can be complicated. Sometimes departures are friendly, and sometimes they are not, but security design should not depend on guessing intent. The core requirement is timely removal of access, ideally aligned with the moment employment or engagement ends. That includes disabling interactive accounts, revoking sessions, and removing remote access methods that could be used later. Leaver workflows also need to handle edge cases like extended notice periods, where a person continues working for weeks, and sudden terminations, where access should be cut immediately. Another complication is that people may have access through personal devices, external accounts, or third-party services, and those pathways must be addressed too. A good design defines which system is authoritative for termination events, such as the HR system or contract management, and ensures that downstream systems receive the update quickly and reliably. It also includes procedures for recovering assets, like keys and badges, and for transferring ownership of data, like shared folders or application responsibilities. The beginner takeaway is that deprovisioning is not just turning off a single login; it is closing all doors, including the hidden ones.

Orphan access can take many forms, and understanding those forms helps you design against them. One form is orphan accounts, where an account remains active after the person has left or after the account owner is unknown. Another form is orphan entitlements, where access rights remain assigned to an identity even if the account is disabled in one system but still valid in another. A third form is orphan tokens and keys, such as application tokens, A P I tokens, or long-lived sessions that continue to grant access even after the underlying user account is disabled. There is also shared or generic access, where multiple people know a password or share a credential, making it hard to tie activity to a real person and hard to remove access when someone leaves. Architects aim to minimize shared credentials because they make orphan access almost inevitable. They also aim to design systems where access is mediated through central identity where possible, so disabling the identity effectively disables access across many systems. The key idea is that orphan access exists because access is distributed, so prevention requires visibility into where access lives and a plan to remove it consistently.

A strong joiners-movers-leavers design depends on having authoritative sources of identity status and attributes. This typically means there is a “system of record” for employment or engagement status and a system that manages identities and entitlements. The details can vary, but the architectural principle is that you want a single trusted signal for join, change, and leave events, and you want downstream systems to consume that signal rather than relying on manual notifications. Manual steps can exist, but they should be exceptions, not the primary method. This also requires reliable identity linking, so a person’s identity in HR is clearly tied to their identity in access systems, preventing duplicate accounts and confusion. If linking is weak, you can end up disabling one identity while another remains active, which is a perfect recipe for orphan access. The design should include reconciliation processes that periodically compare identity records across systems to detect mismatches. Reconciliation is important because real data is messy, and even the best automation can drift over time. For beginners, it helps to see this as the difference between a one-time action and a continuous control: lifecycle management must keep checking itself.

Approvals and governance are part of the design, but they must be applied thoughtfully to avoid slowing work unnecessarily. If every small access change requires a long approval chain, people will seek shortcuts, which can lead to shared accounts or unmanaged access. On the other hand, if access is granted without accountability, privileges will expand and orphan access will grow. A balanced design defines which access is low risk and can be automated based on role, and which access is high risk and requires explicit approval and periodic review. This is where the idea of separation of duties becomes practical, because you do not want the same person requesting and approving privileged access without oversight. Governance also includes periodic access reviews, especially for privileged roles, where managers confirm that access still matches job responsibilities. These reviews are not perfect, but they are a safety net that catches drift and exceptions that automation missed. For beginners, the key is to understand that governance is not a bureaucratic add-on; it is the part of the system that keeps lifecycle processes aligned with real organizational changes. When governance is integrated into the workflow, it can be a steady, predictable process rather than an emergency cleanup.

Timing and propagation are common failure points, especially in complex environments where changes take time to reach every system. A termination in HR might happen instantly, but some applications may sync only once per day, leaving a dangerous window. A role change might update in the directory but not in a downstream Saa S system for hours, causing either over-access or under-access. Architects design with these realities by defining acceptable delays for different access types and implementing compensating measures where delays are unavoidable. For example, privileged access might require near-real-time deprovisioning, while low-risk access could tolerate slower updates. Session management is also critical because disabling an account may not immediately kill existing sessions, so leaver workflows often include revoking sessions and invalidating tokens. The design should also include confirmation steps, such as verifying that deprovisioning actions succeeded in key systems, not just assuming they did. This is not about being paranoid; it is about preventing the quiet failure mode where everyone thinks access was removed but it actually wasn’t. The beginner takeaway is that lifecycle controls must consider the time dimension, not just the state change.

Exceptions and edge cases deserve explicit design attention because they are where orphan access often hides. Contractors may start and stop frequently, interns may rotate, and people may have multiple roles simultaneously. Some roles require break-glass access for emergencies, which must be tightly controlled and audited. Some users may need temporary elevated access for projects, which should expire automatically rather than relying on someone to remember to remove it. Service accounts tied to a person are another dangerous edge case, because when the person leaves, the service account may remain and no one realizes it is still active. A mature design includes policies that prevent tying non-human identities to human users in untrackable ways, and it includes ownership assignment for every account and entitlement. Ownership means someone is responsible for reviewing and maintaining the access, even for non-human identities. When ownership is missing, orphan access grows. For beginners, the key idea is that exceptions should be visible and time-bounded whenever possible, because invisible, permanent exceptions are the seeds of future incidents.

Logging and monitoring complete the picture because they allow you to detect orphan access that prevention controls missed. If an account belonging to a departed user is still active, you want to detect its use quickly. If a deprovisioning action fails, you want that failure to generate an alert rather than being buried in a report. Monitoring can also detect unusual access patterns during move periods, such as a user suddenly accessing systems that do not match their new role. These signals support investigations and help drive process improvement. But monitoring works best when identifiers are consistent and when events are recorded in a way that supports attribution, which connects back to identifier design. Architects therefore ensure lifecycle events, access changes, and authentication events are logged and correlated. They also ensure that logs are protected from tampering, because attackers who exploit orphan access may try to erase evidence. For beginners, the takeaway is that lifecycle design is not only about granting and removing; it is also about being able to prove what happened and detect when reality diverges from policy.

Designing joiners-movers-leavers provisioning and deprovisioning is about keeping access aligned with real-world status changes so that no one retains privileges they should not have. Joiner workflows must provide necessary access quickly without granting broad permissions that become permanent by accident. Mover workflows must prevent privilege creep by removing old entitlements when roles change and by using time-bounded access for temporary needs. Leaver workflows must remove access promptly, revoke sessions and tokens, and ensure all pathways, including indirect and third-party access, are closed. Preventing orphan access requires authoritative lifecycle signals, consistent identity linking across systems, and reconciliation to catch drift. It also requires balanced governance that applies strong review to high-risk access without creating so much friction that people bypass the system. When you can explain how lifecycle events drive access changes, how timing and propagation affect risk windows, and how monitoring catches failures and exceptions, you are thinking like an ISSAP architect. The most important lesson is that access is never a one-time grant; it is a living relationship that must be maintained and ended cleanly, or attackers will eventually find the forgotten doors.

123456