Your PAM Is Live. Your Admins Still Have Standing Privilege
TL;DR
Most PAM programs produce a deployed tool and unchanged privilege. JIT is configured but optional, so admins skip it under pressure. Standing access persists because nobody forced the workflow to change. Automation is excluded from governance entirely because “it can’t wait for approval.” PAM works when it enforces inconvenience by design, not when it offers JIT as a feature admins can choose to use.
The call happens nine months into the deployment. Not during an incident. In a project review.
The tool is configured. JIT workflows exist. Session recording is on. The CISO’s slide deck shows “PAM: deployed” in green. The project is closing out.
While the team is talking, I pull up the Entra ID admin center. Every person with a Global Administrator role still has it as a permanent assignment. Not eligible. Standing. Always active. The JIT workflow is live, but nobody made it mandatory. Admins use it when they feel like it. When they’re in a hurry, they go straight to the standing role. Nobody has ever been blocked for skipping the process.
The tool is live. The privilege posture is identical to what it was before the project started.
This is not unusual. It is the most common outcome of enterprise PAM deployments.
The Deployment Is Not the Change
PAM tools are necessary. They are not sufficient. Treating deployment as the outcome is how organizations spend six figures on a product and get no meaningful reduction in privileged access risk.
The work of a PAM program is not configuring JIT workflows. It is changing who can do what, under what conditions, and what happens when someone tries to skip the process. That is a governance change. The tool enforces it. Without the governance decision behind it, the tool is a feature that admins opt into when convenient.
Optional JIT is not Zero Trust. It is a documentation tool for compliant admins. It does nothing about the standing assignments sitting alongside it in the same directory.
The moment you make JIT mandatory, you find out how many workflows assumed standing privilege. Scripts running under domain admin accounts. Scheduled tasks with Contributor at subscription scope. Vendor monitoring tools that need persistent access because they were never designed for time-bounded models. Every one of these is a dependency that mandatory JIT will surface. That is the point. Breaking those dependencies, or explicitly documenting them as exceptions with owners and expiry dates, is the actual work of privilege governance.
Most organizations see the problem, decide it is too big to fix right now, and quietly keep JIT optional so nothing breaks. That is not a PAM program. That is a PAM tool with nobody governing it.
Three Ways JIT Gets Bypassed Before Anyone Notices
The break-glass path becomes the daily path. Every PAM implementation includes an emergency bypass. Within months, it is the standard path. Nobody wants to wait twenty minutes for an approval when they are troubleshooting a production issue at 11 PM. If the emergency path does not require authorization and does not expire automatically, it is not break-glass. It is standing privilege with a different name. Admins learn the path of least resistance. It is not malicious. It is rational behavior in a system that makes the secure path harder than the insecure one.
The scope excludes automation. Human admins get JIT. Service accounts, pipelines, and managed identities keep standing rights because automation cannot wait for an approval workflow. This is accurate, and it creates a class of identities with effective Tier 0 access and zero governance. The human surface area is controlled. The automation surface area is wide open. Most post-incident analyses of cloud environment compromises find the initial lateral movement path was a service principal, not a human admin. The PAM program addressed the visible part of the problem and left the dangerous part untouched. This is worth reading more about if workload identity governance in your environment is unreviewed.
The program covers production. Dev and staging are out of scope. The logic sounds reasonable: dev does not have real data; it does not need the same controls. But dev and staging share identity infrastructure with production. A pipeline compromised in a dev environment can authenticate to production using the same service principal credentials. The PAM boundary drawn at “production only” leaves a clean path around every control you spent months building.
Tier 0 Is a Constraint, Not a Label
The Tier 0 concept is well understood in principle. Identity systems, key management infrastructure, core logging platforms, directory services. These are Tier 0 because compromise here means compromise everywhere. The label marks the target. It rarely changes how administrators reach it.
Tier 0 should mean: standing privilege does not exist here. Not “JIT is preferred” or “standing access is discouraged.” Every operation against Tier 0 systems goes through a controlled path. Admin accounts that touch Tier 0 do not also touch email and Slack. And the devices those accounts operate from should meet a higher bar than standard user endpoints — MDM compliance is a baseline, not a security guarantee for privileged sessions.
Session recording is not optional. Changes require a ticket that can be correlated to the session log. Credential rotation is scheduled and automated, not deferred to when someone gets around to it.That is an operating model. The tool enforces it. The governance model defines what gets enforced and for whom.
The model has to extend to non-human identities. A pipeline with Contributor access at subscription scope is a Tier 0 principal whether or not anyone labeled it that way. A service account with read access to every key vault in a tenant has more effective privilege than most human administrators. The principle that identity is your real perimeter applies to workloads as much as users. A PAM program that governs humans but leaves automation unrestricted has defined Tier 0 by where it looked, not by what actually matters.
The Governance Model That Makes PAM Stick
Four components. Without all four, the program drifts back toward standing privilege within a year.
Who approves. Not the manager. A named role with decision authority for the system being accessed. Domain admin requests go to the identity authority. Production infrastructure changes go to the security architecture owner. Tier 0 access requires a second approval from outside the requesting team’s management chain. The approver is accountable for what happens in the session, not just whether the request looked reasonable when it came in.
What approval produces. A time-bounded session, not a standing role assignment. The approval opens a window. The window closes automatically. If the work is not done, they request another. The request log is the audit trail. If you cannot correlate a session recording to a specific request and a named approver, the approval process is not a governance artifact. It is just friction on the path to the same standing access.
How exceptions are handled. Some workloads genuinely cannot operate without standing access today. Document it. Named business owner, compensating controls, expiry date tied to a real milestone. Not “until we fix it” but “until the legacy app migration completes in Q3, reviewed at that date.” The exception register is reviewed monthly. Exceptions that miss their expiry are escalated, not auto-renewed. This is the same discipline that prevents exception sprawl across governance programs generally: the exception log is honest documentation of where policy and operational reality have diverged.
Cadence. Monthly review of the top twenty principals by privilege level and scope. Not a compliance checkbox. A real question: is this still needed, does the current scope match the current use case, and who is accountable if it gets abused? The review has a default outcome: justify or suspend. Reviews without consequences are documentation exercises.
Starting When Standing Privilege Is Everywhere
Do not try to eliminate standing privilege everywhere at once. You will break production and lose the organizational support you need to keep going.
Week 1: Inventory. Pull every account with domain admin, Global Administrator, or subscription-level Contributor rights. Name a human owner for each one. Count them. This number surprises most organizations. Double digits is common. Triple digits is not unusual in environments that have grown through acquisitions. Many of these accounts have no known owner and have not been used in months.
Week 2: Stop creating new standing privilege. From this point forward, no new standing privilege grants are approved outside the JIT process. Do not touch existing accounts yet. Stop the accumulation. This is achievable immediately and does not disrupt anything currently running.
Week 3: Identify the five highest-blast-radius principals. These are the accounts where compromise produces the worst outcome: tenant-wide admin, subscription Contributor with access to key management, directory sync accounts. Mandatory JIT for these five, or fully documented exceptions with business owners, compensating controls, and expiry dates. Start where the exposure is most severe.
Week 4: First cadence meeting. Review the exception list. Confirm the five target principals have named owners and compensating controls. Establish the monthly review rhythm. Pull the first metric: how many privilege escalations went through JIT this week, how many bypassed it. That ratio tells you whether the governance model is functioning or decorative.
The goal is not a solved problem in 30 days. The goal is a functioning governance loop. Exceptions expire. New access flows through JIT. The standing privilege surface area shrinks over time, not overnight.
The Slide Says Deployed. The Admin Behavior Says Otherwise.
PAM governance is one of the few places where the gap between “we have a tool” and “the problem is addressed” is wide enough that organizations can complete an entire deployment cycle and end up materially no safer.
The tool does not make JIT mandatory. The governance model does. The tool does not force admins to use separate accounts or keep automation out of standing privilege. The operating model does. The tool does not expire exceptions or review privilege on a cadence. The people running the program do.
The test is not whether your PAM tool is configured. It is whether an admin who wants to skip the JIT process can do so without being blocked. If they can, the deployment is complete and the governance is not. Those are different projects. Only one of them reduces risk.
