Episode 86 — IAM Lifecycle: Provisioning, Deprovisioning, Permissions, and Identity Proofing (4.5)
In this episode, we look at the Identity and Access Management (I A M) lifecycle, which is the full journey of an identity from the moment access is requested to the moment that access is removed. This topic matters because security is not only about stopping outsiders at the edge of a network. A lot of risk comes from accounts that have too much access, accounts that stay active after someone leaves, or accounts that were created without enough confidence in who the person really is. I A M is about making sure the right person, device, or service gets the right access, at the right time, for the right reason. When that lifecycle is handled carefully, the organization reduces mistakes, limits damage, and makes everyday access easier to manage.
Before we continue, a quick note. This audio course is part of our companion study series. The first book is a detailed study guide that explains the exam and helps you prepare for it with confidence. The second is a Kindle-only eBook with one thousand flashcards you can use on your mobile device or Kindle for quick review. You can find both at Cyber Author dot me in the Bare Metal Study Guides series.
Provisioning is the process of creating an identity and giving it the access needed to do a job. When a new employee, contractor, vendor, application, or service needs to use organizational resources, something has to create the account, assign permissions, and connect that identity to the right systems. Provisioning should not be treated as a casual setup task, because the permissions granted at the beginning often shape what that identity can do for a long time. A well-managed provisioning process usually depends on a request, an approval, a role or job need, and a record of what was granted. The goal is not to give every new identity broad access just in case it becomes useful later. The goal is to provide enough access to work safely without opening unnecessary doors.
Identity proofing comes before or during provisioning, and it answers a basic but critical question: how does the organization know this identity is tied to the right person or entity? For a person, identity proofing may involve checking official records, employment status, contractor agreements, manager approval, or other trusted evidence. For a service or application, it may involve confirming ownership, purpose, system relationship, and business need. The strength of identity proofing should match the risk of the access being granted. A person requesting access to a public training portal does not require the same level of proof as someone requesting administrative access to sensitive systems. Weak identity proofing creates risk because an organization may give access to someone who should not have it in the first place.
Permissions define what an identity can do after it has been provisioned. A permission may allow someone to read a file, change a record, approve a transaction, manage a system, view sensitive data, or create other accounts. Permissions are powerful because they translate trust into action. If permissions are too broad, a simple mistake or compromised account can cause far more damage than necessary. If permissions are too narrow, people cannot do their work and may look for workarounds. Good permission management tries to balance security and usability. The common security principle here is least privilege, which means giving an identity only the access it needs to perform approved tasks. Least privilege is not about making work difficult. It is about limiting unnecessary risk.
Access requests provide a controlled way to ask for permissions. Instead of someone informally asking a coworker to add access, a formal request process captures who is asking, what they need, why they need it, who approved it, and how long it should last. This record matters later if someone asks why an account had access to a system or why a sensitive action was allowed. Access requests also help separate responsibility. The person requesting access should not always be the only person deciding whether that access is appropriate. A manager, system owner, data owner, or security reviewer may need to approve the request depending on the sensitivity involved. This keeps access from becoming a collection of undocumented favors and old assumptions.
Role changes are one of the most common points where I A M lifecycle problems appear. People move between teams, take on new duties, support short-term projects, or receive temporary responsibilities. When their work changes, their access often needs to change too. The mistake many organizations make is adding new permissions without removing old ones. Over time, this creates access creep, where an account slowly collects more permissions than the person actually needs. Access creep can be dangerous because an attacker who compromises that account receives all of those accumulated permissions. It can also create internal risk when someone can perform actions that no longer match their role. A good lifecycle process updates access when responsibilities change, not only when someone first joins.
Deprovisioning is the process of removing access when it is no longer needed. This may happen when an employee leaves, a contractor finishes work, a vendor relationship ends, a service is retired, or a temporary project closes. Deprovisioning needs to be timely because every unnecessary active account is a possible entry point. A former worker may no longer have a business reason to access systems. A forgotten vendor account may still connect to sensitive data. A retired service account may still have permissions that nobody remembers. Strong deprovisioning disables or removes accounts, revokes sessions, removes group memberships, recovers devices where appropriate, and documents the change. The faster and cleaner the process is, the less chance there is for old access to become a new problem.
Stale accounts are accounts that still exist even though they are no longer clearly needed or actively used. They are dangerous because they often receive less attention than accounts used every day. A stale account might belong to someone who left months ago, a contractor whose work ended, a test identity created during a project, or a service account tied to an old application. Attackers like stale accounts because unusual use may not be noticed quickly, especially if nobody owns the account anymore. Stale accounts may also have outdated passwords, weak controls, or permissions that were never reviewed. Cleaning them up is one of the practical ways an organization reduces attack surface. If an account has no clear owner, no current purpose, and no recent legitimate use, it deserves review.
Privileged access needs special attention throughout the lifecycle because privileged accounts can change systems, access sensitive data, or control other accounts. Provisioning privileged access should require stronger approval and clearer justification than ordinary access. Identity proofing should be stronger because the impact of a mistake is higher. Permissions should be tightly limited to the role and task. Deprovisioning should happen quickly when privileged access is no longer needed. Privileged access should also be reviewed regularly because these accounts can do more damage if misused or compromised. A normal user account might let an attacker read some data or send messages. A privileged account might let an attacker disable controls, create new accounts, change logs, or reach many systems. That difference is why lifecycle management becomes even more important for high-impact access.
Service accounts are another important lifecycle concern because they are used by applications, scripts, systems, or automated processes rather than by a person sitting at a keyboard. A service account might allow an application to connect to a database, a backup system to read files, or a monitoring tool to collect data. These accounts can be forgotten because no individual logs in with them during normal work. They still need ownership, documented purpose, appropriate permissions, secure credentials, and deprovisioning when no longer needed. A service account with broad permissions can become a serious risk if its credentials are exposed. The organization should know why the account exists, what it can access, who owns it, and what would break if it were disabled. That knowledge makes safe management possible.
Reviews and recertification help keep the lifecycle accurate over time. An access review asks whether current permissions still make sense. A manager may review access for direct reports. A system owner may review who can use an application. A data owner may review who can see sensitive information. The point is to catch access that was once valid but is no longer appropriate. Recertification means formally confirming that access should continue. This is especially useful for privileged access, sensitive data, third-party access, and systems that support important business functions. Reviews should not be treated as a rushed checkbox activity. They are one of the few chances to compare actual access against current job needs. When done carefully, they reduce access creep and strengthen accountability.
I A M lifecycle management also depends on coordination between teams. Human Resources (H R) may know when someone is hired, transferred, or terminated. Managers know what job duties a person has. System owners understand what access their systems require. Security teams understand risk, policy, and monitoring needs. Information technology teams often carry out the account changes. If these groups do not share accurate information, access can be late, excessive, or left behind. For example, if H R records a departure but the access team is not notified, an account may remain active. If a manager approves broad access without understanding the system, permissions may exceed the job need. Good lifecycle management is not just a technical control. It is a business process that depends on clear ownership and timely communication.
Monitoring supports the I A M lifecycle by showing whether access is being used in expected ways. Logs can show successful sign-ins, failed attempts, permission changes, new account creation, group membership changes, password resets, and unusual access patterns. Monitoring can help identify stale accounts by showing accounts with no recent activity. It can also identify suspicious activity, such as a dormant account suddenly signing in, a user accessing resources outside normal duties, or a privileged account being used at an unusual time. Multi-Factor Authentication (M F A) events may help show whether additional verification succeeded or failed. Monitoring does not replace good provisioning and deprovisioning, but it gives the organization feedback. It helps confirm whether identity controls are working and whether access behavior matches expectations.
At the Security Plus level, you should connect the lifecycle pieces into one continuous flow. Identity proofing helps confirm who or what the identity represents. Provisioning creates the account and assigns initial access. Permissions define what actions are allowed. Access requests and approvals create a record of why access was granted. Role changes require updates so old access does not quietly remain. Reviews and recertification help confirm that current access still makes sense. Deprovisioning removes access when the business need ends. Monitoring helps the organization notice suspicious use, stale accounts, and unexpected changes. The lifecycle matters because identity is one of the main ways modern environments make security decisions. If the organization gets identity wrong, many other controls become weaker.
The main takeaway is that I A M lifecycle management is about controlling access from beginning to end, not just creating accounts when someone joins. A secure process starts by proving identity, granting only needed permissions, documenting access decisions, and updating access as responsibilities change. It continues by reviewing permissions, watching for unusual activity, and removing accounts or access when they are no longer needed. Stale accounts are dangerous because they leave old doors open. Excessive permissions are dangerous because they turn one mistake or compromise into a larger event. Strong lifecycle management makes access more intentional, more traceable, and easier to defend. When you hear provisioning, deprovisioning, permissions, and identity proofing, think about the full story of trust: how it begins, how it changes, how it is checked, and how it ends.
