Four categories, one job, and the gap between finding over-permission and fixing it

Ask five vendors how to control privileged access and you will get five category names: privileged access management, just-in-time access, cloud infrastructure entitlement management, identity governance, and the cloud providers’ own elevation features. Each category grew up around a different problem, and each is genuinely good at that problem. The trouble for a security leader is that the job — making sure the right person has the right access for the right length of time, and can prove it — cuts across all of them.

This post maps the market as it stands in late 2026: what each category does well, where it typically stops, and how they fit together. Vendors are named from their public descriptions, as examples rather than a complete list. Products change quickly; check current capabilities with each vendor before relying on any line here.

One job, many categories

Strip away the category names and the access problem has six parts. Something has to find the access that exists and judge whether it is excessive. Something has to decide whether a new request should be granted, by whom and for how long. Something has to grant it, which means holding a credential powerful enough to change permissions. Something has to watch what is done with it, remove it on time, and finally prove all of the above to an auditor. No single category was designed around all six.

Where each category is typically strongest. Many products now reach beyond their home ground.

Privileged access management suites

PAM is the oldest of the categories and the most mature. It began with a simple, vital idea: put powerful shared credentials — domain administrator passwords, root keys, database owner accounts — in a vault, rotate them, and broker sessions to servers so that nobody needs to know the password at all. Modern suites add session recording, privilege elevation on endpoints, remote access for vendors, and increasingly their own zero-standing-privilege features for cloud.

What they are good at: credential vaulting and rotation, session isolation and recording, mature compliance reporting, coverage of on-premises estates, and long experience in regulated industries. Where they often stop: a vault protects a powerful credential but the credential stays powerful. Checking out a domain administrator account for an hour is better than sharing it, but the person still has full administrator rights for that hour. Cloud permission models, where the right answer is often a fresh, narrow policy per task, fit the vault model less naturally, and suites have been extending to cover them.

Just-in-time access platforms

A newer group of products starts from the request rather than the credential. Engineers ask for access, often in Slack, an approval workflow routes it, and the platform grants membership of a group, a role, or a permission set for a fixed time and removes it afterwards. Several also run access reviews and connect to identity providers and ticketing systems.

What they are good at: a fast, friendly request path; approval routing; time-bound grants; integrations with many applications; and often access reviews. Where they often stop: many grant pre-built roles or groups, so a JIT grant of an over-broad role is still an over-broad grant, just for less time. Approval policy is frequently a fixed rule per resource rather than a judgement on the specific request. And the platform usually holds, or is handed, credentials that can change your permissions — a design choice worth examining in any security review.

Cloud infrastructure entitlement management

Cloud infrastructure entitlement management (CIEM) tools analyse identity and permissions across cloud accounts. They compute effective permissions from every policy, find administrators and privilege-escalation paths, flag unused permissions, and in cloud-native application protection platforms (CNAPPs) connect those findings to exposed workloads and sensitive data.

What they are good at: breadth of visibility, effective-permission calculation, attack-path context, and prioritisation by blast radius. Where they often stop: finding is not fixing. A report that 300 roles are over-privileged is valuable; it does not tell the platform team how to remove the access without breaking the engineers who rely on it. That fix needs an alternative people can use — fast, narrow, temporary access — or the findings come back next quarter.

The cloud providers’ own tools

Each major cloud now offers native temporary elevation. They are close to the platform, inexpensive or included, and deep within their own provider.

Native feature	What it provides	Good fit when
AWS TEAM (Temporary Elevated Access Management)	An open-source AWS solution for time-bound IAM Identity Center permission-set assignments, with approval workflow and audit	You are mostly on AWS, use Identity Center, and can operate the solution yourself
Microsoft Entra Privileged Identity Management (PIM)	Time-bound activation of Entra ID and Azure roles, with approval, MFA on activation, justification and access reviews; requires the appropriate Entra licence	Your privileged estate is mostly Microsoft and Azure
Google Cloud Privileged Access Manager (PAM)	Just-in-time, time-bound IAM role grants with approvals and audit logs	Your privileged estate is mostly Google Cloud

What they are good at: native depth, no extra infrastructure, and alignment with how each provider’s own identity system works. Where they often stop: at the edge of their own cloud. Most organisations hold privilege in more than one place — a cloud, a production database, a Kubernetes cluster — and three native tools mean three policies, three approval paths and three sets of evidence. They also grant the roles you define, so least privilege still depends on how well those roles were designed.

The gap between finding and fixing

Put the categories side by side and a pattern appears. Analysis tools are good at telling you what is wrong. Vaults are good at protecting the powerful credentials you keep. Request platforms are good at making access easier to ask for. The part that tends to fall between them is the actual reduction of privilege: replacing a standing administrator with access that is narrow enough to be safe and fast enough that nobody misses the old way.

InsightKeys is built around that conversion. Discovery reads AWS accounts, permission sets, assignments and IAM authorisation details, PostgreSQL roles and privileges, and Kubernetes bindings. A standing-access cleanup agent, which by default only drafts proposals for a person to act on, suggests turning each standing admin, escalation path, unused role or database superuser into on-request access, and the removal itself goes through the broker.

How the categories combine

Few organisations will choose one category and drop the rest. A practical architecture assigns each tool a clear role and answers three questions explicitly.

Question	Why it matters	A reasonable answer
Which tool holds the credential that can change permissions?	That tool is the most attractive target in your access stack	As few as possible, ideally running inside your own network, with a local policy that limits what it will do
Which tool is the record of access decisions?	Auditors want one consistent story of request, approval, grant and removal	One system of record per class of access, exporting evidence to your compliance tooling
Which tool owns the shared credentials you must keep?	Some secrets cannot be eliminated: root keys, vendor accounts, legacy systems	A vault, with checkout and rotation
Which tool tells you what is excessive?	You cannot reduce what you have not measured	Your CIEM or CNAPP, or the discovery built into your JIT platform

A common pattern is PAM for vaulted credentials and server sessions, a CNAPP for posture and entitlement analysis, and a JIT platform for day-to-day human access to cloud, databases and clusters, with native tools used where an estate sits almost entirely in one provider. The overlap is real, and it is worth deciding deliberately which tool owns which decision rather than letting each one grow into the others.

Questions to ask any vendor

Whatever category you are evaluating, the same questions separate a tool that reduces privilege from one that only reorganises it:

• What exactly is granted? A pre-built role, or a permission narrowed to the task?
• Who holds the granting credential, and where? In the vendor’s cloud, or in your network?
• What happens to live grants if the vendor is unreachable? Do they still expire?
• How is approval decided? A fixed rule, or a judgement on this request that a reviewer can read?
• What does the auditor get? A complete record of request, decision, grant and removal, or a log to reconstruct it from?
• What is supported today, and what is planned? Ask for the integration list as it stands, not the roadmap.

Keep reading