Nobody asks if you still need that access

Privilege creep rarely starts with a security incident. It starts with something routine. A sales operations analyst moves to finance, and by the end of her first day she has the ERP access, reporting tools, and shared drives her new job requires. Six months later, she still has admin rights in the CRM. Nobody removed them, because nobody asked.

Most joiner, mover, leaver (JML) programs aren't built to catch this. They're measured on how fast leavers lose access, and that matters. But leaver metrics say nothing about the access that builds up while people are still employed, so most organizations never measure it.

What is privilege creep, and why don't leaver metrics catch it?

Privilege creep is the gradual accumulation of access rights beyond what a person's current role requires. It affects active employees, not people who've left. Leaver metrics track a different problem: orphaned and dormant accounts that belong to former employees.

Both are real risks, but they fail at different points. A leaver process that only disables accounts when someone leaves the company doesn't account for someone who changes projects or teams while still employed. That person is still supposed to be there, so none of the leaver metrics ever count them.

Why do JML programs focus on leavers?

Leavers are easy to measure. An account is either disabled or it isn't. The HR termination date gives you a clear trigger, and auditors know exactly what evidence to ask for. Time to deprovision fits neatly on a dashboard.

What happens mid-tenure has none of those qualities. A role change often shows up as an attribute update in the HR system rather than a formal event. The new manager requests what the person needs next, and nobody owns what they no longer need. In the sales conversations about identity governance and administration (IGA) that I listen to, access left behind by leavers comes up much more often than access kept by movers.

Some organizations design for this from the start. When La Mayenne, a French departmental government serving more than 308,000 residents, chose an IGA solution, managing the full lifecycle from onboarding through role changes to departure was a core requirement, along with granting access strictly on a need-to-know basis.

If you're not sure who your movers are or how their access should change, start by defining your identity personas. Movers are the clearest example of a broader pattern: governance checks access when it's added, then rarely looks at it again.

Where does excess access build up?

Role changes are the most structural source. Each move adds access for the new job, and the old access stays because removing it isn't anyone's task. After two or three moves, a person can hold the combined access of every role they've had.

Role changes aren't the only source, though. In seven years at one company, my job title changed once, but most of my excess access didn't come from that move. It came from the many times I asked other teams and IT for elevated access to get something done. The answer was always yes, and nobody revisited any of it. Looking back, some of that access shouldn't have been granted at all. The people approving it had no way to know what my role required.

The same pattern shows up elsewhere. Access for a project or an incident gets granted as temporary with no end date, so it never ends. Birthright packages are often designed broadly to avoid day-one tickets, so new hires start with more than they need. In SaaS and cloud apps, admins can grant access directly, outside any request process, so the governance system never knows it exists. Non-human identities follow the same path: service accounts and bots pick up permissions for one project and keep them long after it's over.

Why is privilege creep a security risk, not just an audit finding?

Excess access turns a compromised account into a bigger incident. MITRE ATT&CK tracks the abuse of valid accounts as technique T1078, which attackers use to get in, stay in, and expand their reach. An attacker who phishes an over-privileged employee doesn't need to escalate privileges or exploit a vulnerability, because the access is already there. Insider risk works the same way.

Compliance frameworks expect more than fast offboarding too. ISO/IEC 27001:2022 control 5.18 requires access rights to be provisioned, reviewed, modified, and removed in line with policy. NIS2 Article 21 lists access control policies as part of cybersecurity risk management. A strong leaver process alone satisfies neither.

How do you stop privilege creep without adding manual work?

• Treat every role change as a joiner event and a partial leaver event. Grant what the new role needs, and remove what the old role no longer justifies.
• Give approvers context at request time. Show what the role normally has and whether the request creates a segregation of duties conflict, so approvers can stop wrong grants before they happen.
• Put an end date on anything that isn't birthright access. If the access is still needed, the owner can extend it. If not, it expires on its own.
• Reconcile continuously. Compare what people have in each system with what was approved, and flag the difference.
• Review what's new. Ask reviewers to confirm access gained since the last campaign instead of handing them a full list to approve.
• Keep privileged access out of everyday accounts. Manage admin rights in a privileged access management (PAM) tool, where they're granted for a specific task and removed when it's done.

How Netwrix Identity Manager governs access between joining and leaving

Netwrix Identity Manager governs the whole identity lifecycle, not just the start and end. When someone changes roles, it recalculates the access their new role and policies call for, and removes access the old role no longer justifies. Access requests go through approval workflows that record who approved what and why, with segregation of duties checks before access is granted. Temporary access gets start and end dates and is removed automatically when it expires. After every sync, reconciliation compares what exists in connected systems with what was approved, so access granted outside the process gets flagged instead of forgotten. Targeted certification campaigns let business owners review access with context, and remediation happens automatically. The same controls apply to non-human identities.

Netwrix Identity Manager also manages administrator accounts separately from regular user accounts and integrates with PAM tools, including Netwrix Privilege Secure, to keep elevated rights under dedicated control.

ADIS Assurances, a subsidiary of AXA France, started looking for an IGA solution after an audit found unstandardized access, accounts that were hard to reconcile, and too few formal access reviews. After moving from ad hoc permissions to a business role catalog in Identity Manager, preparing a recertification campaign went from about four weeks of spreadsheet work to five minutes.

The bottom line

Fast offboarding is table stakes, and it tells you little about the risk in your active accounts. A better test of your JML program is to pick someone who has been with you for five years, changed roles once or twice, and made a dozen access requests along the way. Look at what they can reach today, and ask how much of it their current job needs. If nobody can answer that quickly, privilege creep is already there.