The access no one remembers granting

The goal was never to make access harder to get. It’s to make sure access doesn’t outlive its purpose.

It starts, almost always, with a deadline.

A cloud migration has three weeks left on the clock. A vendor needs access to troubleshoot something before the weekend. A new employee starts Monday, and IT needs to get them productive quickly.

Someone grants elevated access so the work can move forward. It is a reasonable decision, made under pressure, by someone trying to solve a real problem.

Nobody puts a date on the calendar to take it back.

That is the quiet mechanism behind one of the most common—and most avoidable—sources of identity risk: access that was supposed to be temporary becoming permanent because nothing was designed to remove it.

The migration is the easy part 

Picture a midsize company moving part of its infrastructure to the cloud. The project team needs privileged access to provision resources, configure networking, assign roles and troubleshoot problems as they arise. That access is necessary. This is exactly the kind of work privileged access management should support.

The access is granted, and the team gets to work. Several weeks later, the migration is complete. The project closes, the team moves on and attention shifts to the next priority.

The access does not move on with them.

The accounts remain active. The roles stay assigned. Access keys, tokens or service identities created during the migration may continue working in the background. Permissions that once had a clear owner and purpose become part of the permanent environment.

This rarely appears as a failure in a project retrospective because there is no obvious moment when the access becomes dangerous. The migration succeeded. Nothing broke. The permission simply remained in place until everyone became accustomed to seeing it there—or stopped seeing it at all.

This is why I consider expiration part of the access decision, not an administrative task to handle later. If temporary access is granted without a defined duration, an accountable owner or automatic revocation, it is technically standing access from the moment it is created.

Why “it’s probably fine” is doing a lot of work 

Standing access is difficult to recognize because each permission has a history that makes it look reasonable.

The administrator role supported a migration. The vendor account helped resolve an outage. The service account still runs an integration no one wants to interrupt. The contractor may return for another phase of the project. There is always a reason to leave the access alone for one more week.

Over time, those exceptions accumulate.

Employee identities usually have lifecycle events that can trigger a change. Someone joins, changes roles or leaves the company. Project access, vendor access and non-human identities are different. A cloud role does not know that the migration ended. A service account does not tell HR that its application was replaced. A vendor account will continue working until a person or an automated control disables it.

What I would want to know is straightforward: Who owns this access today? What business process still depends on it? When was it last used? What could the identity reach if its credentials were compromised? If no one can answer those questions, “it’s probably fine” is not a risk decision. It is an assumption.

That is the difference between identity management done intentionally and identity management done by default. Granting access is the easy part. Building a process that changes or removes it when the business need changes is where the real discipline comes in.

What “good” actually looks like 

The answer is not more friction. It is not slower approvals, another form or a process that forces engineers to wait several days for access they need to perform a ten-minute task.

If the secure process is harder than leaving permanent access in place, teams will continue choosing permanent access.

A strong program brings several disciplines together:

• Identity governance: knowing who has access to what and why, at any given moment, not just at the point access was granted. 
• Least-privilege access: giving people and systems exactly the access their role requires and no more.
• Continuous monitoring: watching how access is actually used, not just approving it once and moving on.
• Automated lifecycle management: provisioning and revoking access automatically as roles, projects and people change. 

Taken together, these practices move access from a one-time approval to something that is continuously governed.

They also support just-in-time access and zero standing privilege. With just-in-time access, elevated permissions are granted for a specific task and duration, then removed automatically. With zero standing privilege, the powerful entitlement is not left permanently attached to the identity while it waits to be used.

There is an important operational point here: temporary access still needs to be fast and predictable. If an administrator has to navigate an hour-long approval process during an outage, the control will become an obstacle rather than a safeguard. Good privileged access management applies the right level of approval based on the risk, records the activity and closes the access automatically when the work is complete.

For workloads and automation, the same principle applies differently. Where the platform supports it, use workload identity, narrowly scoped roles and short-lived credentials instead of storing a long-lived secret that someone has to remember to rotate.

Modern cloud-native privileged access platforms have changed what is practical. Work that once depended on spreadsheets, manual access reviews and calendar reminders can now be automated: access is requested, evaluated, granted, recorded and revoked without relying on someone to remember the final step.

The real question isn’t “how do we protect access?” 

It’s “why does this access still exist?”

That reframing matters. Most security conversations focus on protecting the access already in place: stronger authentication, better credential storage, session monitoring and tighter policy enforcement. Those controls are necessary, but they solve a different problem.

Strong authentication helps protect an account from compromise. It does not make an unnecessary permission necessary. Monitoring helps identify suspicious activity. It does not reduce the access available to an attacker who takes control of the identity.

If a permission no longer supports a legitimate business purpose, the safest version of that access is not a better-protected permission. It is a permission that has been removed.

That is the idea behind the ConRes and Britive approach to privileged access: give people and systems the access they need, when they need it, while reducing the standing privilege available the rest of the time. Britive provides the cloud-native controls for just-in-time access and zero standing privilege. ConRes helps organizations assess the environment, design the access model and integrate those controls into the way teams actually work.

The goal is not to make access difficult. It is to make access precise, temporary when appropriate and accountable from beginning to end.