Privilege Is an Action, Not a Job Title

Chapter 1

1. What Is Privileged Access Management in 2026?

PAM is the discipline of controlling any account that can change a system: who holds it, when it elevates and what it does. Most programs still scope privilege to human administrators. That scope is shrinking as a share of the whole. Service accounts, workloads, DevOps pipelines and AI agents now hold privileged access at machine scale. Govern the action, and each identity type that can perform it comes into scope.

Privilege is defined by the action, not the role

For years, a privileged account meant a named administrator with elevated rights. That model was easy to picture and easy to list. It is now the smaller part of the problem. A privileged action is any change to a system: a configuration edit, a database write, a credential retrieval, a deployment. The identity performing it can be a person, a service account, a workload or an AI agent. When you scope PAM to the action rather than the job title, coverage widens to match reality. You stop protecting a list of people and start protecting the ability to change things. For the basics, see our page on what is privileged access management.

This shift matters because risk follows the action, not the title. Any identity that can make a change can be misused to make it. A service account with a static password and broad rights carries more exposure than a named admin with monitored access. The job title on the account tells you little about the damage it can do. The action it can perform tells you far more.

The four questions each privileged action raises

A useful way to frame PAM is as four questions asked of a privileged action.

• Who, or what, holds this access, and is that identity known and owned?
• When does it elevate, and does the access expire when the task ends?
• What did it do while elevated, and is that activity recorded?
• Can you prove those answers to an auditor?

A mature program answers the four for each privileged identity, human and non-human. Most programs answer them well for named administrators and poorly for everything else. The chapters that follow work through each question in turn.

What incomplete coverage costs you

When scope is incomplete, the cost is operational, not theoretical. An unknown privileged account cannot be governed, monitored or revoked, because no inventory lists it. An unowned credential has no one accountable for rotating it, so it drifts out of policy and stays valid long past its use. An audit you cannot prove fails examination and stalls the compliance work behind it. The account that needs attention is often the one no one is watching.

Executives often hear PAM framed as breach insurance, a cost you carry against a risk that may not arrive. That view undersells it. The larger cost is the one you pay week after week, whether or not an incident happens. You pay it four ways: manual toil, standing exposure, audit fire drills and lost accountability. Each is a line item in how your team spends its time.

The Toil of Managing Credentials by Hand

The most visible cost is manual credential management. When rotation is not automated and dependency-aware, someone has to do it, and the work is both tedious and risky. Rotate a shared service-account password by hand, miss one dependent service, and an application fails. After one outage like that, teams learn to stop rotating. The credential then stays static, which is the condition an auditor flags first.

The evidence that this drag is real sits in the data. The Verizon 2026 Data Breach Investigations Report measured how long organizations took to fix credential problems in third-party cloud environments. For weak passwords and permission misconfigurations, the time to resolve half of all findings reached almost eight months. That is not a queue that clears. It is a backlog that grows, because the manual work needed to clear it competes with everything else. Automated, dependency-aware rotation removes the toil and the outage risk together, so the backlog stops forming.

Standing Credentials as Continuous Exposure

The second cost is exposure, and it runs around the clock. A standing credential is valid whether or not anyone is using it, including the hours no one is watching. It is a target that does not sleep. The longer it stays valid, the more copies and the more risk accumulate behind it.

Each person who once checked out the credential may still hold a copy, and each copy works until the credential rotates. Chapter 4 shows how just-in-time elevation shrinks that surface, and what the breach data says about credential abuse.

Audit and Certification as a Recurring Fire Drill

The third cost is the audit itself. When you cannot show who holds privileged access and what they did with it, each audit becomes a manual reconstruction. Teams pull logs from separate systems, assemble access lists by hand and hope the picture holds together before the deadline. The work repeats each cycle, and it grows with the estate.

This cost is easy to underestimate because it hides inside normal operations. A certification campaign that should be a scheduled report becomes a project. An auditor question that should have a one-click answer becomes a week of evidence gathering. The underlying problem is not effort. It is that control and proof were not joined. When privileged access and certification sit on one platform, the evidence assembles itself, and the fire drill becomes a report you run on a cycle.

Shared Accounts and the Accountability Gap

The fourth cost is lost accountability. Many teams still rely on shared administrator accounts, where several people use one credential and no action ties back to a person. That saves a little setup time and costs a great deal of traceability. When something breaks or an investigation opens, you can see that the shared account acted. You cannot see who was behind it.

The fix is not to ban shared accounts. It is to put each privileged login through individual authentication, and to record the session. Each action then ties to a named person without slowing the work. That turns a shared credential from an accountability gap into a controlled, attributable path. It also removes a standing secret, because the shared password stops traveling in people’s notes. Our case against shared privileged accounts covers accountability in more depth.

The table below maps each state of incomplete coverage to the cost it carries and the control that removes it.

Non-human identities (NHIs) change the privileged inventory

NHIs have become the larger share of privileged access in many enterprises. Service accounts run scheduled work. Workloads and pipelines authenticate to deploy code and move data. AI agents now request access and act on it at machine speed. These identities hold secrets, and those secrets are privilege. A program that inventories human administrators alone measures a shrinking fraction of its own exposure. The first job of a 2026 PAM program is to see the privileged population, then decide what to do about it.

The growth here is not gradual. Each new automation, integration and model deployment creates more NHIs that authenticate and act. Each one needs a credential, and each credential is a standing path unless something governs it. A program that counts people alone is measuring the past. Chapter 5 returns to non-human identity in depth, because that is where the coverage gap is growing.

Chapter 2

2. How PAM Relates to IAM and IGA

PAM controls the privileged action itself: the elevation, the session and the credential. It works alongside the rest of identity security rather than repeating it. Identity governance and administration, or IGA, governs who should hold access and proves it. Identity and access management, or IAM, decides who exists and what they reach. You will often see the terms used interchangeably. What matters behind each of them is coverage.

PAM vs. IAM vs. IGA: three disciplines, three questions

PAM, IGA and IAM answer different questions, and the difference shows up in what breaks when one is missing. PAM controls what a privileged identity can do in the moment it acts. IGA runs the joiner, mover, leaver lifecycle, certifies access, and proves who should hold it. IAM establishes identity, authenticates it and decides what it should reach. You need the three working together. The table below sets them side by side.

Each discipline fails in a different way, and each failure has a different cost. Weak PAM means privileged credentials sit unrotated and sessions go unrecorded, so a compromised account acts freely and invisibly. Weak IGA means joiners, movers and leavers go unmanaged and access accumulates without review, so no one can prove who should hold what. Weak IAM means unknown or duplicate identities and weak sign-in, so access decisions rest on an identity you cannot trust. A program can be strong in one discipline and exposed in another.

Where the disciplines intersect

PAM does not stand alone. It hands off to IGA for certification: controlling access in the moment is one job, and proving who should still hold it is another. PAM also depends on IAM for identity truth, because a privileged session means little if the underlying identity is wrong. These disciplines coexist. A purpose-built PAM program runs alongside your identity platform rather than replacing it.

This is also why coverage has to be measured across disciplines, not inside one. An identity platform that handles sign-in and federation well can still leave shared admin credentials unrotated. A governance tool that runs joiner, mover, leaver lifecycle and certifies access quarterly can still miss the service account no one owns. PAM closes the specific gap the others leave: control over the privileged action, in the moment, with a record. Bringing that control onto the same platform as identity and governance makes the handoffs clean rather than manual.

Certification is the proof point

Certification proves, on a cycle, who should still hold privilege, rather than just controlling who does. That is governance, and it is where PAM and identity governance meet. Control keeps the estate safe day to day. Certification is what lets you demonstrate it to an auditor. Without it, you can show what happened but not that it should have.

Bringing privileged access and certification onto one platform, the Bravura Security Fabric, makes that proof practical rather than aspirational. Convergence is something you grow into, not a package you buy, and you reach it from a PAM program.

PIM vs. PAM: where built-in identity tools stop

Many identity platforms include privileged features, such as role activation, conditional access and approval workflows for admin roles. These are useful. They often cover the cloud roles the platform itself governs, and they cover them well. The gap sits outside that boundary. Shared administrator accounts on servers, local admin credentials and service accounts with static passwords rarely live inside the identity platform’s reach. Network gear, legacy applications and mainframe accounts sit outside it too.

So the useful question is not which tool to choose. It is which privileged identities each one governs. Map your privileged population against both. Where the identity platform covers a role well, let it. Where a credential sits outside it, PAM takes the credential, rotates it, brokers the session and records it. Handled this way, the two coexist without overlap, and the gaps between them close. You add control where it is missing rather than replacing what already works.

What identity should sign in to the PAM platform

The identity that enters the console is itself a privileged action, so tier it by risk. An identity platform authenticates the person. Bravura Privilege governs what that person does next. Low-risk credential retrieval can use an everyday account with multifactor authentication. Administrative work needs a separate, dedicated privileged identity, kept apart from daily email and browsing.

This closes a gap the four questions leave open. They govern the target credential. They do not say which identity should reach it. The answer follows the logic of the rest of the guide. Privilege is the action, not the account. So the login that starts privileged work deserves privileged control.

Tier the entry by what it can do. Reading a low-risk secret is not the same as opening an administrative session on a domain controller. Match the identity and the checks to the risk of the action behind them.

For administrative access, Bravura Privilege brokers the session without disclosing the credential, authenticates each user, records activity and grants access just in time. The dedicated identity signs in, the session is attributed and recorded, and the elevated access expires with the task.

Keep a break-glass path for the times the identity platform or the PAM platform is unavailable. Store those emergency credentials under the same controls, and review their use after each event. A controlled exception is still a controlled account, not a standing back door.

Chapter 3

3. Coverage, and Getting There in Weeks

In this guide, coverage means how much of your privileged estate is under management. It has two dimensions. Breadth is which identities are under management: human and non-human, across your estate. Depth is how much control each credential is under: stored, rotated, session-controlled, dependency-aware. A vault gives you storage, not control. An unrotated vaulted credential stays an open path for anyone who once held it. Most programs fall short on both dimensions and cannot prove either.

How to measure PAM coverage: breadth and depth

Coverage is often reported as a single number, and that number hides the gap. Breadth asks which identity types you manage. A program that vaults human administrators but ignores service accounts has narrow breadth, whatever its dashboard says. Depth asks how much control each credential is under. A credential that sits in a vault but does not rotate has shallow depth. You need both. Measure them separately, and the real state of the program comes into view. Three counts make it concrete: privileged accounts estimated, discovered and managed.

The distance between those three counts is the story. The gap between estimated and discovered is what you cannot see. The gap between discovered and managed is what you cannot control. Both are exposure, and they are different problems. Discovery closes the first. Management closes the second. A program that reports one number tends to be reporting the smallest one, and hiding the two gaps behind it.

Password vault vs. privileged access management

A vault stores a credential. Credential management under PAM discovers the account, rotates the credential, controls the session it opens and understands what depends on it. The distinction matters because a stored credential can still be a standing path. Someone who once checked it out may hold a copy. If it does not rotate, that copy still works. The table below shows the difference between a vaulted credential and a managed one.

Many programs reach the vaulting stage and stop, because vaulting feels like completion. Credentials are in one place, behind strong authentication, and the dashboard turns green. A vault, paired with a connection manager, can even launch a session with a stored credential. The problem is that a vault answers just the storage question. It does not rotate the credential, so a leaked copy stays valid. It does not record and replay the session, so you cannot review what happened after checkout. It does not track dependencies, so rotation risks breaking an application. Vaulting is real progress. It is a start, not the finish.

Service account password rotation without outages

Rotation sounds simple until a password is in use somewhere you did not map. Consider a Windows service account. Rotate its password, and each dependent service that uses it needs the new value: Service Control Manager entries, IIS application pools, scheduled tasks. Dependency-aware management notifies those dependents automatically, with retry and rollback if one fails. Rotation without that awareness breaks applications. That is why teams stop rotating. Passwords then stay static for months, and the breach surface grows with them.

A team rotates a shared service-account password, a dependent service misses the new value, and an application fails at the worst time. After one outage, the team leaves that account alone. Dependency-aware rotation removes the fear by handling propagation, retry and rollback as one orchestrated step. The credential rotates on schedule and the applications keep running.

There is a second approach, and it solves the same problem from the other end. Rather than push a new password to each dependent, the application retrieves the current secret from the vault through an API each time it needs it. Because it reads the vault each time, a rotation cannot leave it stranded. That makes API-based retrieval an alternative to dependency-aware password changes, and different enough to plan for on its own. It suits automation and service-to-service calls well.

Rotation is technically possible with a vault alone, but fragile there. If the real password changes on the target outside the vault, the application retrieves a stale value and fails. The approach holds up when the vault manages the credential and stays the source of truth. Mature programs use both approaches, matched to each workload.

PAM implementation timeline: coverage at scale

Privileged accounts do not come under management at the same moment. A rollout protects some accounts first, then more, until the estate is covered. Time to coverage at scale is how long it takes to bring your privileged estate under management. It is not how fast the first few accounts are protected. An example makes the difference clear. A vendor can vault your first 50 admin accounts in a week. Covering the last few hundred service accounts, with their tangled dependencies, is the work that sets the real timeline. A phased rollout puts the first accounts under management in weeks, then works outward until coverage is complete.

The last 20% stalls because it holds the hardest identities. Shared service accounts carry tangled dependencies. Legacy systems, mainframe and network gear sit beyond the reach of a proxy-based tool. Time to first account rewards the easy start. Time to coverage at scale rewards the architecture that reaches the legacy and non-human parts of the estate. When you compare programs, ask how long full coverage took, not how fast the first vault filled.

Privileged account discovery: turn coverage into a number

Coverage is easier to act on when it is a number, and you can get one with a simple method. Estimate your privileged population, compare it against what is discovered and managed and name the segment that is vaulted but not managed. That segment is a depth gap in your coverage. Chapter 1 named what that gap costs, and Chapter 4 shows how to close the standing-access part of it.

Count by evidence, not intent. A program that plans to rotate credentials has not closed the gap until rotation runs and produces logs. Measuring what you can prove tells you two things at once: where you are today, and what the single next control is.

Count each segment separately: human administrators, shared accounts, service accounts and other NHIs. Human administrators on core servers may be managed and rotated while service accounts sit at discovered. A single program-level number averages those together and hides the weakest segment. The least-covered, highest-risk segment is usually the most useful next project, and it lets you report real progress while naming where the next investment goes.

Chapter 4

4. Make Standing Privilege the Exception with Just-in-Time Access

Standing privilege is access that persists whether or not it is in use. A standing account is an around-the-clock attack surface, including the hours no one is watching it. Standing privilege is a different axis from how well a credential is managed. A credential can be fully managed, rotated and session-controlled, and still be standing if it is always on. Just-in-time elevation and ephemeral accounts shrink standing access, because access is created for the task and then removed. The goal is to make standing privilege the exception, not to claim each entitlement can disappear. Vaulting and rotation do not get you there on their own. Discovery and randomization are the foundation, just-in-time elevation and ephemeral accounts do the shrinking, and session control and detection govern what remains.

Why standing privilege is a problem

Standing privilege is a problem because idle access is still live access. A credential that is always valid is always reachable, by the person who holds it and by anyone who takes it. Managing the credential well raises the cost of misuse. It does not close the standing window, because the access is still there when no one is using it.

This is why non-standing access became a goal in its own right. If access exists only while a task runs, there is almost nothing standing to misuse or inherit. The next sections show how to get there, and what to do about the access that must remain.

The path to zero standing privilege

Some steps on this path are shared with most PAM programs. Discovery and automatic randomization are foundation work that a credible PAM program needs. They matter here, but they are table stakes. Two mechanisms do the specific job of shrinking standing access. Just-in-time elevation grants access for a task and expires it when the task ends. Ephemeral accounts exist only for the session and are removed after it. Session control and recording belong to a mature program too, but they govern and record the access that happens. They do not, on their own, reduce standing privilege. NIST SP 800-207, Zero Trust Architecture, calls for granting access to individual resources on a per-session basis. Just-in-time elevation applies that principle to privilege.

It helps to see these as one sequence. Discovery finds the privileged accounts. Randomization neutralizes their static passwords. Just-in-time elevation then grants access only when it is needed, and ephemeral accounts leave nothing behind. Skip the first two, and just-in-time has nothing solid to stand on. Bravura Privilege supports just-in-time access through several methods: time-bound elevation of an existing account, on-demand creation and removal of a temporary account, and just-in-time group membership. You pick the least-privilege option that suits each situation. Independent analyst research supports this flexibility as a strength.

Two controls, not one: shrink and detect

Just-in-time access reduces the chance of abuse. It does not remove it, because some access must persist, and any valid credential can be misused while it is live. A complete program pairs two controls. The first shrinks the standing window, through just-in-time elevation and ephemeral accounts. The second watches what remains, through monitoring for anomalies in activity carried out under a valid credential. Detection is a partner control in our approach, so you can pair just-in-time access with the analytics tool you already trust. The principle holds whatever the tool: shrink the window, then watch what is left.

A realistic word on the ideal state. Some standing privilege is hard to remove, because many enterprise applications still rely on persistent entitlements to function. The aim is not a number that reads zero on a slide. It is to make standing access the exception, to grant it just in time where you can, and to record and review whatever must remain. A program that treats total elimination as the sole pass mark will struggle to move off the starting line.

What just-in-time changes for the admin’s day

Zero standing privilege holds up when people use it day to day. The daily pattern becomes request, approve, elevate, expire. An administrator asks for access to a system. The request is approved against policy, access activates for a bounded window, and it ends on its own. Done well, just-in-time access adds little friction and removes a standing target. Done poorly, people route around it, and the standing accounts creep back. Experience determines adoption, and adoption determines whether the control is real.

This is why PAM programs should prioritize solving the operational constraints to adoption. A just-in-time system that is slow or confusing trains people to keep a standing account “just in case,” which defeats the point. A system that approves routine requests in seconds and gets out of the way earns the trust that keeps standing access rare. The goal is not to make elevation hard. It is to make time-bounded, recorded elevation easier than keeping a standing credential around.

From a coverage number to a remediation story

Chapter 3 turned coverage into a number and named the segment that is vaulted but not managed. Part of that segment is also standing: access that stays on whether or not it is used. Chapter 1 put a cost against the gap. This is where you close the standing part of it. Start with the always-on access your coverage count found. Randomize those credentials so no old copy stays valid. Move routine elevation to just in time, so access expires with the task. Record and review whatever must stay standing. Then count again. The first result is your before, and the smaller standing segment is your after.

The breach data shows why this matters. The Verizon 2026 Data Breach Investigations Report counts credential abuse at any point in the breach progression. On that measure it still sits on top, at 39% of the breaches studied. As a first entry point it fell to 13%, behind vulnerability exploitation. The report still calls credential abuse “a legitimate mitigation target chokepoint.” Removing standing credentials removes part of that surface.

Chapter 5

5. Securing Non-Human Identities (NHIs) and AI Agents

Machine identities hold a large share of the privilege in a modern estate. Service accounts, DevOps pipelines, APIs and AI agents authenticate, hold secrets, and act at machine speed and scale. Most programs govern the human share. Governing non-human privilege uses the same discipline as human privilege: discover the identity, control the credential, scope the elevation and record the action. The fundamentals come first, and service accounts are where that work is proven today.

AI agent security starts with the fundamentals

Much of what makes AI feel dangerous is unmanaged privilege that was already dangerous. Take an unrotated service account, a shared admin credential or an entitlement no one certifies. These are the same exposure whether a person or an agent reaches for them. An AI agent does not invent a new attack surface so much as reach an existing one faster and at greater volume. Master the fundamentals and you remove most of that exposure. You also build the discipline the harder, AI-specific problems will demand.

The fundamentals are not yet universal, and that is the deeper issue. Discovery, zero standing privilege, just-in-time access, role-based access, certification and continuous authorization are familiar words and uncommon practice. Many organizations are still doing basic vaulting while shopping in a hurry for something to secure AI. Our own work on non-human and agent identity is the next step, not a substitute for the basics we already serve well. Your program is better served treating it the same way.

Why non-human identity, and why now

Your teams are already asking how to secure AI agents and machine identities. Start with the NHIs you can govern today. Service accounts are often the largest segment, and discovery and dependency-aware rotation bring them under control now. Apply the same controls as you add agents and workloads.

The timing matters for your program. Each automation and model you deploy adds NHIs that hold secrets and act. If your PAM program governs people alone, that gap widens with each deployment. Starting with service accounts is not a partial answer. It is the part of the non-human estate that is both large today and ready to govern. That is where effort pays back most reliably right now.

Service account management: the proven core

Service accounts are NHIs that already sit inside strong governance. We discover them across the estate, including the ones no inventory lists. We rotate their credentials with awareness of what depends on them, notifying dependent services and rolling back on failure. That dependency orchestration is the hard, documented work that makes non-human rotation safe rather than disruptive. A service account that holds broad access around the clock is standing privilege, and leaving it unrotated compounds the risk. Bringing service accounts under management closes a real part of the gap Chapter 3 described.

The reason service accounts are the right starting point is that they combine high risk with high readiness. They are numerous, they often hold broad standing access, and they are frequently shared and rarely rotated. They are also well understood, so discovery and dependency-aware rotation apply to them directly. You do not need a new, specialized technology to govern a Windows service account and its dependencies. You apply the same controls you use for human privilege, run at machine scale, with the specifics tuned to each case.

Secrets management extends to the code that uses them. Bots, scripts and pipelines retrieve secrets through a governed API instead of embedding plaintext credentials in code or config. Where code cannot change, a command-line utility injects the current password into config files or command-line arguments at runtime, so legacy applications you cannot rewrite still rotate on schedule.

One identity model for people, NHIs and agents

Bravura Identity and Bravura Privilege share one identity model across people, NHIs and agents. You design a control once and it spans governance and execution. Each non-human account pairs with a dedicated profile that names a responsible human owner. When that owner changes roles or leaves, the NHIs they own reassign automatically, so no account is orphaned.

Bravura Identity governs the lifecycle: onboarding through request forms, ownership, certification and retirement. Bravura Privilege controls the credentials those identities hold. Because both run on the same model, there is no stitching between the tool that knows who owns an NHI and the tool that rotates its secret.

What agentic access changes

Agents break the oldest assumption in identity security: that a valid credential plus an authorized action equals a safe outcome. An agent can hold valid credentials and take authorized actions at machine speed, across systems, in ways no person would.

AI agents add speed, volume and delegation. An agent authenticates, holds secrets and can act on behalf of a chain of other identities. That raises the same questions PAM has asked from the start, now at a new scale. You still need to know which identity is acting, what it can do and whether you can prove what it did.

Delegation is the part that is genuinely new. When an agent acts for a chain of identities, the question of who is responsible gets harder. The audit trail has to capture the chain, not just the last actor. The market does not have a settled answer yet. Start now with the service-account work that is ready.

Provable control holds this together. Identity history, including profiles, attributes, roles and group memberships, is retained indefinitely by default, and stable identifiers track an identity even as its accounts are renamed. Privileged sessions are recorded, with detailed audit trails, risk scoring, and integration with your SIEM and SOAR platforms. When an auditor asks what an identity did, human or machine, you can show them.

Machine identity management beyond the cloud

Coverage is the benchmark, so it matters where your coverage runs deepest. Our non-human strength is the estate that sits outside the service mesh: Windows service accounts and their dependencies, legacy applications, mainframe and network gear. Discovery and dependency-aware rotation are established capabilities there, and that estate is what a workload-identity rollout most often leaves behind.

That estate is large, it is high-risk, and tools built only for cloud-native workloads tend to underserve it. Governing it well is the practical place to start, because most of the standing non-human risk lives there today. Run it alongside your cloud-native tooling, and the long-lived accounts that tooling does not reach stay governed.

The next section shows how the Bravura Security Fabric does this work across the identity types you run. It covers discovery and dependency-aware rotation for service accounts today, least privilege through policy and just-in-time control where it applies, and the audit trail that proves it.