PAM Process Design: Joiner, Mover, Leaver, JIT and Service Accounts

The PAM Academy · Module 3

Who this module is for

The problems this module solves

What you will learn

1. Access lifecycle processesDesign joiner, mover and leaver flows and access reviews that trigger automatically from an authoritative source and complete within defined service levels.
2. Just-in-time and least privilegeProvide the right access, for the right time, for the right reason, by replacing standing privilege with time-bound, reason-bound grants that expire on their own.
3. Service account managementSecure, monitor and govern non-human identities with named owners, dependency records, restricted logon rights and a defined decommissioning route.
4. Password management and rotationEstablish strong, automated and auditable credential practices based on the actual password state of each account rather than the written policy.
5. Exception and emergency accessPrepare for the unexpected with pre-approved break-glass accounts, clear invocation triggers, full session capture, mandatory rotation and a documented review after every use.

How do you design a joiner, mover, leaver process for privileged access?

The joiner, mover, leaver process, usually shortened to JML, is the lifecycle that governs how access is granted when someone arrives, changed when they move, and removed when they leave. Privileged access needs its own version of it. Standard JML manages the base identity, such as the mailbox and the network login. Privileged JML manages the elevation, which is a separate object with a separate owner, a separate approval and a separate expiry.

Start with the trigger. The process must fire from an authoritative record, normally the HR system for employees and a contract register for third parties, rather than from an email or a ticket. If an HR status change does not automatically create a task for the privileged account, the process is a courtesy, not a control.

Joiner

Grant a role-based baseline and nothing else. Privileged rights are not part of the starter pack; they are requested separately against a named duty. Record the named human owner at the moment of creation, along with the business justification and, where the access is temporary, an expiry date. An account that cannot name its owner on day one will not have one on day five hundred.

Mover

This is the case that most programmes get wrong. Treat a move as a leaver from the old role followed by a joiner to the new one. Revoke first, then grant, with the previous manager confirming what should be withdrawn and the new manager confirming what is genuinely required. Set a service level for withdrawal, such as five working days, and report on breaches.

Leaver

Disable privileged accounts on the last working day, terminate active sessions, reassign vault ownership and rotate every shared or service credential the leaver knew. Deletion can wait for a retention period; disablement cannot. Then measure the process: time from HR event to revocation, accounts owned by leavers, and privileged accounts with no owner at all.

What does an access review process look like when it actually works?

User access reviews, also called access certification or entitlement reviews, are the recurring check that the access people hold still matches the job they currently do. Done properly, a review surfaces over-provisioning, stale group memberships, orphaned accounts with no living owner, dormant accounts and separation of duties conflicts. Done badly, it produces a signature and nothing else.

A workable cycle has eight steps. Define and document the roles and the permissions each one requires. Map users to roles and check that nobody holds a conflicting combination. Review the roles themselves periodically to confirm the permissions are still relevant as the business changes. Audit the user assignments, with validation from the department heads who actually know what the work involves. Evaluate role granularity, because roles that are too broad over-privilege everyone while roles that are too narrow create a jungle of micro-roles nobody can maintain. Assess separation of duties, so that no single role lets one person both request and approve the same transaction. Document every change with its reason and its approver. Then repeat on a schedule set by risk and regulation, which in practice means quarterly, semi-annually or annually.

Three design choices decide whether reviewers engage. Tier the cadence by risk, so domain-wide and production administrator access is reviewed quarterly and low-risk access annually. Give reviewers decision-grade information, including plain-language descriptions, last-used dates and the account owner, rather than raw group names. And set the default for non-response to removal rather than retention, with a grace period and an appeal route.

The consequence of skipping this is documented. In 2018 an employee at SunTrust Banks reportedly accessed and stole personal data belonging to approximately one and a half million customers. No malware, no phishing. The role simply carried wide-ranging privileges and nobody had asked recently whether that was still appropriate. An insider with excessive privilege is not caught by a firewall. They are prevented by a review.

How do you implement just-in-time and least privilege access?

Least privilege means exactly the access a duty requires, nothing more and nothing less. Just-in-time access, often shortened to JIT, is how you make that practical: instead of holding administrative rights permanently, a user requests elevation for a specific task, for a specific window, with a recorded reason, and the rights disappear automatically when the window closes.

Design it from evidence rather than from job titles. Logs and monitoring data show how frequently each privileged account is used, at what times, from where and for what operations. Interviews with privileged users show how the work actually flows through a day, which is what makes JIT grants match real tasks rather than theoretical ones. Access frequency is the key signal: accounts used daily for critical operations may justify standing access with heavy monitoring, while occasional accounts should be on demand.

Structure privileged access into four tiers and aim to shrink the first one over time.

• Standing access for a small, named, closely monitored population where operational reality allows nothing else.
• Scheduled access for predictable work such as patch windows and month-end runs, activated and deactivated on a calendar.
• On-demand access requested against a task, approved by a defined approver, and expiring automatically.
• Emergency access for genuine break-glass situations, covered later in this module.

Every on-demand request should capture the requester, the target system, the task or change reference, the duration, the approver and an automatic expiry. Expiry must be enforced by the platform, not by a reminder in somebody’s calendar. Where risk is high, pair the grant with session recording and step-up authentication.

The failure mode is well illustrated by the breach at the US Office of Personnel Management, which exposed personal information for around twenty-two million individuals. It traced back to a contractor’s credentials that carried more privileges than the work required. When the contractor was compromised, the attackers inherited the excess. Standing privilege is inherited privilege.

What are the best practices for service account management?

Service accounts are the identities applications, scripts and appliances use to talk to other systems. They are frequently the most privileged accounts in the estate and the least governed, because they sit outside the human joiner, mover and leaver process. Discovery routinely finds them hiding inside user lists, on appliances that no inventory covers, and in vendor-installed software nobody has looked at since go-live.

A governance process for non-human identities has seven parts.

1. Discover continuously. Scan directories, appliances, scheduled tasks, application configuration and code repositories on a schedule, so new accounts are captured on arrival.
2. Assign a named owner. Every service account needs a responsible human and a backup team, recorded in the inventory. Ownership is a control, not an administrative detail.
3. Record dependencies. Capture what the account is used by and what it connects to, so you know what breaks if you change it. This single field is what makes rotation safe.
4. Classify by risk. Score each account by what it can reach, how privileged it is and what state it is in, then apply controls in proportion.
5. Constrain the account. Remove interactive logon rights, restrict which hosts it may authenticate from, scope its permissions to the specific operations the application performs, and forbid humans from using it directly.
6. Manage the credential. Move it into a vault, remove it from scripts and configuration files, and prefer platform-managed identities, group managed service accounts, certificates or key-based authentication where the application supports them.
7. Decommission deliberately. When an application is retired, its accounts are retired with it, with a disable-then-delete period to catch hidden dependencies.

Two lessons make the case. In the Uber breach affecting fifty-seven million users, attackers found login credentials for cloud storage embedded in code on GitHub, held by developers whose work did not require that level of access. Closer to home, discovery at one organisation surfaced two service accounts living on an appliance nobody inventoried, found not by a scanner but in a twenty-minute conversation with the engineer who built them.

How often should privileged passwords be rotated, and how do you do it safely?

Start by recording the password reality rather than the password policy. For every privileged account, capture the actual state: age, rotation history, complexity as enforced, the authentication method in use, and whether the credential is vaulted or sitting in a script. The written standard tells you what should happen. Only the per-account state tells you what does.

Rotation frequency should follow risk and account type rather than a single organisation-wide number.

• Interactive privileged accounts managed through a vault are best rotated automatically on check-in, so each credential is used once and the user never sees or stores it.
• Service and application accounts rotate on a schedule set by risk, coordinated with the dependency record so every consumer of the credential is updated in the same operation.
• Shared and emergency accounts rotate immediately after every use, without exception.
• Event-driven rotation applies whenever a privileged user leaves, a vendor engagement ends, a suspected compromise occurs or a credential is exposed.

Rotation programmes usually stall because an unmapped dependency caused an outage, so sequence the work. Vault first and record dependencies, rotate in a test or low-risk tier, verify the application, then automate. Where an application genuinely cannot tolerate rotation, register it as an exception with a named risk owner, compensating monitoring and a review date.

Passwords are not the only credential in scope. SSH keys, API keys, certificates and tokens all need issuance, storage, rotation and revocation processes. Pair rotation with strong authentication on the human side, since multi-factor authentication on privileged accounts is what turns a stolen password into a failed login. The South Carolina Department of Revenue breach in 2012, which exposed three point six million Social Security numbers and three hundred and eighty-seven thousand credit card records, began with one phished employee and spread through elevated accounts that had no multi-factor authentication and no comprehensive privileged user list behind them.

Useful measures include the percentage of privileged credentials under vault management, the percentage rotated within policy, and the age of the oldest unrotated privileged password.

How do you build a break-glass emergency access procedure?

Break-glass access is the pre-approved route to elevated access when the normal process cannot be used, typically during a major incident, an outage of the identity platform itself, or the absence of a key approver. The aim is not to prevent emergency access. It is to make sure it is rare, visible, time-limited and fully reconstructable afterwards.

A sound procedure has the following elements:

• A small number of named accounts with defined scope, held for emergencies only and never used for routine work.
• Documented triggers stating exactly what justifies invocation, so the decision is not improvised under pressure.
• Independence from the systems it may need to fix. If the vault, the directory or single sign-on is unavailable, the emergency route must still work, which usually means a sealed offline copy of credentials held under dual control.
• Immediate alerting to the security operations team and the account owner at the moment of use, not the next morning.
• Full session capture, mandatory rotation of the credential once the session closes, and a post-use review within a defined window confirming the trigger was valid and the actions appropriate.
• Regular testing, at least quarterly, because an emergency procedure that has never been rehearsed will fail at the moment it is needed.

Exceptions need the same discipline. Temporary project access, vendor logins and emergency grants are all supposed to expire, and supposed to is a finding. Maintain an exception register in which every entry has a business justification, a named risk owner, compensating controls and a hard expiry date, and enforce expiry in the platform so the access ends on its own. Review the register at the same cadence as your access reviews.

Measure how often break-glass is invoked and by whom, how quickly each use was reviewed, and how many exceptions are past their expiry date. A rising invocation count usually means the normal process is too slow, which is a design problem rather than a behaviour to punish.

Common mistakes to avoid