Privileged Access Reviews: Who Should Review Your Administrators?

Privileged access is different from ordinary user access because the consequences of getting the decision wrong are significantly higher. An employee with unnecessary access to a business application creates risk. An administrator with unnecessary access may be able to create accounts, modify permissions, change security controls, access sensitive information, or alter the systems that record those activities.

If you are a CISO or IAM leader, the question is therefore not simply whether administrator access is reviewed. The question is whether your governance process can continuously establish who has privileged access, why they have it, whether they still need it, how that privilege is being used, and who is accountable for allowing it to continue.

That is the practical purpose of privileged access reviews. They extend the principles of access review and certification to identities and entitlements where an incorrect decision can materially increase organizational risk.

Privileged access is not just an "Admin Account"

The traditional picture of privileged access is a system administrator with a root or administrator account.

Modern enterprises are considerably more complex.

Privileged access can exist through:

• directory administrator roles
• cloud IAM roles
• database administrator accounts
• application administrator roles
• security and IAM administrator privileges
• Kubernetes and infrastructure administration
• SaaS administrative roles
• privileged groups
• emergency or break-glass accounts
• service and automation accounts with elevated permissions

Microsoft identifies privileged roles and permissions as those capable of actions such as modifying credentials, authentication or authorization policies, directory resources, or restricted information. Microsoft Learn

The important distinction is therefore not the account name.

It is the capability that the entitlement provides.

A user called administrator may have tightly restricted permissions. A normal employee account assigned a powerful cloud role may have significantly greater effective privilege.

A strong privileged access review should therefore review effective access and entitlements, not merely search for accounts labeled "admin."

Privileged access requires a different review standard

Consider two access-review decisions.

Standard access

User: Rahul Sharma
Application: Expense Management
Role: Employee
Decision: Approve / Revoke

Privileged access

User: Rahul Sharma
Application: Microsoft Entra
Role: Privileged Role Administrator
Assignment: Permanent
Last privileged use: 74 days ago
Department: Infrastructure
Role changed: 45 days ago
Risk: Critical
Decision: Approve / Revoke

Both are access reviews.

They should not necessarily follow the same certification policy.

NIST's least-privilege guidance specifically calls for privileges assigned to roles or classes of users to be reviewed at an organization-defined frequency and reassigned or removed where necessary. It also separately addresses restricting privileged accounts to defined personnel or roles. NIST Publications

The principle is straightforward:

The greater the potential impact of the access, the stronger the governance around its continuation should be.

Who should review an administrator?

This is one of the most important design questions in a privileged certification campaign.

The administrator's manager may understand whether the employee is still part of the infrastructure team.

But does that manager understand what Global Administrator, Security Administrator, AWS AdministratorAccess, DBA, or a particular production role actually allows?

Conversely, an application or infrastructure owner may understand the privilege but not know whether the employee's current responsibilities still require it.

This creates two separate questions:

Business need: Does this person still require privileged access for their job?

Technical necessity: Does the person require this particular level of privilege?

In many cases, these questions are best answered by different people.

That is why privileged access can be a strong candidate for multi-level certification.

For example:

Manager → Application/Resource Owner → Security/IAM

The manager confirms the business requirement.

The application or resource owner confirms the required privilege.

Security or IAM may provide additional scrutiny for critical roles, exceptions, SoD conflicts, or particularly sensitive access.

Microsoft Entra supports reviews of privileged Microsoft Entra and Azure resource roles through Privileged Identity Management (PIM), with reviewers determining whether users should continue to hold those roles. Microsoft Learn

The objective should not be to add approval layers everywhere. It should be to put the right decision in front of the person capable of making it.

Permanent privilege should receive more scrutiny than eligible privilege

One useful distinction in privileged access governance is between standing and just-in-time privilege.

Consider two administrators.

Administrator A has permanent production administrator access.

Administrator B is eligible for the same role but must activate it when required, potentially subject to MFA, justification, approval, and a limited activation period.

The underlying capability may be identical.

The exposure is not.

Microsoft recommends using Privileged Identity Management for just-in-time privileged access and configuring recurring access reviews to remove permissions that are no longer required. Microsoft Learn

A privileged access review should therefore ask more than:

Does this administrator need this role?

It should also ask:

Does this administrator need this role permanently?

That distinction can substantially change the governance outcome.

Instead of:

Approve / Revoke

the appropriate decision may sometimes be:

Retain permanent access / Convert to eligible access / Reduce privilege / Revoke

This is a more meaningful least-privilege decision.

Privileged access reviews need context

An administrator role name by itself tells the reviewer very little.

A stronger review should provide enough information to answer why the privilege exists and whether the underlying justification still holds.

Useful context can include:

Context	Why it matters
Privileged role	What capability does the administrator possess?
Assignment type	Is access permanent, temporary, or eligible?
Business role	Does the current job require the privilege?
Resource	What system or environment can be administered?
Last privileged use	Is the access actually being exercised?
Last review	When was the privilege last challenged?
Granted date	How long has the access existed?
Granted by	Who originally authorized it?
Risk level	How damaging could misuse be?
SoD conflicts	Does the privilege create a toxic combination?
Alternative role	Could a lower privilege satisfy the requirement?

Microsoft's governance guidance similarly combines privileged role management with controls such as activation duration, MFA, Conditional Access, justification, ticket information, approval, and assignment duration. Microsoft Learn

The certification decision should therefore evaluate the context of the privilege, not simply its existence.

Dormant privileged access deserves special attention

Suppose an administrator has production-level access but has not exercised that privilege for six months.

There may be a legitimate reason.

But the inactivity itself is a useful governance signal.

The question becomes:

If this privilege has not been required for six months, why does it need to remain permanently assigned?

This is where identity risk management can strengthen certification.

Dormancy should not necessarily cause automatic revocation. But combining dormancy with other factors can substantially increase the need for review.

For example:

Privileged + Permanent + Dormant + Role changed = High review priority

Similarly:

Privileged + Temporary + Recently used + Valid owner + Current project = Lower review priority

The goal is not merely to identify administrators.

It is to identify privileged access whose justification is weakening.

Privileged access should be reviewed when risk changes, not just when the quarter ends

A quarterly privileged-access campaign remains useful.

But some changes are too important to wait for the next scheduled review.

Consider an administrator who transfers from Infrastructure to Sales Operations one week after completing a quarterly certification.

The privileged role may technically remain certified for another three months.

From a governance perspective, however, the business justification has changed immediately.

A stronger model combines periodic campaigns with event-driven reviews.

Useful triggers can include:

• department or role change
• manager change
• assignment of a new privileged role
• privilege escalation
• long periods of inactivity
• new SoD conflict
• privileged access granted outside the normal process
• contractor engagement approaching expiry
• unusual change in identity risk
• application ownership change
• conversion from temporary to permanent privilege

This aligns privileged certification with the broader identity lifecycle.

The governance question then becomes:

What changed that might invalidate the previous approval?

Not every privileged role needs the same review frequency

A common certification model puts every administrator into the same quarterly campaign.

That is simple operationally, but not necessarily risk-based.

Consider:

Privileged condition	Possible governance approach
Low-impact delegated admin	Periodic certification
Production administrator	More frequent certification
Security/IAM administrator	Higher scrutiny
Permanent critical privilege	Frequent or multi-level review
Eligible/JIT privilege	Periodic eligibility review
Dormant privileged access	Targeted review
Privilege after role change	Event-driven review
New SoD conflict	Immediate review
Break-glass access	Post-use review

The frequency and depth of certification should therefore reflect the potential impact of the privilege.

Microsoft's access-review guidance similarly recommends regular reviews of privileged Microsoft Entra roles and Azure resource roles to reduce stale role assignments. Microsoft Learn

A mature governance model does not ask:

When is our privileged-access campaign?

It asks:

Which privileged access currently deserves our attention?

Privileged access review and PAM solve different parts of the problem

This distinction is important.

Privileged Access Management (PAM) and Identity Governance and Administration (IGA) overlap, but they do not solve exactly the same problem.

PAM primarily focuses on controlling and securing the use of privileged access.

IGA focuses on governing whether the identity should have that access in the first place and whether it should continue.

A simplified model is:

IGA: Who should have privileged access, and why?

PAM/PIM: How and when can that privilege be exercised?

Runtime security: What happened when the privilege was used?

These controls should reinforce one another rather than operate as disconnected programs.

A certification decision, for example, may determine that an administrator still requires production access but no longer needs it permanently.

The outcome might therefore be:

Permanent privilege → Eligible/JIT privilege

rather than complete removal.

That is a stronger governance outcome than a binary approve-or-revoke model.

SoD becomes more important when privileged access is involved

Privileged certification should not evaluate each entitlement in isolation.

Suppose a Finance administrator can:

Create vendors + Modify payment details + Approve payments

Each permission may have a legitimate business explanation individually.

Together, they create a materially different risk.

That is why Segregation of Duties governance should inform privileged access reviews.

The reviewer should be able to see not only:

Rahul has Finance Administrator.

but also:

Rahul's Finance Administrator privilege creates a conflict with Payment Approver.

That changes the certification decision.

The appropriate response could be:

• revoke one entitlement
• reduce the administrator role
• introduce an additional approval
• implement a compensating control
• approve a documented exception
• increase monitoring

The objective is to review effective risk, not individual role names.

Break-glass accounts require a different review model

Emergency or break-glass access creates another special case.

These accounts may rarely be used.

That inactivity is expected.

Therefore, a generic rule such as "privileged account unused for 90 days → revoke" would be inappropriate.

Instead, governance should ask:

• Is the break-glass account still required?
• Is its ownership clearly defined?
• Is access tightly controlled?
• Are credentials appropriately protected?
• Has it been tested?
• Was every actual use justified?
• Was access returned to its expected state after use?

Most importantly, use of emergency privilege should itself trigger review.

This is an example of why access governance cannot depend exclusively on fixed campaign schedules.

Different types of privileged identities require different certification logic.

A revoke decision is not the end of privileged certification

Suppose a reviewer decides:

Revoke Global Administrator.

The security risk does not disappear when the reviewer clicks Revoke.

The role must actually be removed.

Microsoft's PIM documentation illustrates this distinction: a reviewer can approve or deny continued access, but assignment status does not necessarily change until review results are applied. Microsoft Learn

A defensible privileged-access workflow therefore needs to preserve:

Privilege discovered → Reviewer assigned → Context presented → Decision recorded → Remediation initiated → Privilege removed → Result verified → Evidence retained

This is especially important for privileged accounts because failed remediation leaves high-impact access in place.

Organizations should therefore measure not only:

How many privileged reviews were completed?

but also:

How many revoke decisions were actually remediated, and how quickly?

Audit evidence needs to explain why privilege existed

Privileged access frequently receives additional attention from auditors because it can alter systems, permissions, security configurations, and sensitive information.

NIST's assessment guidance for privileged accounts includes examining artifacts such as access-control policies, lists of privileged accounts, system administration personnel, audit records, configuration settings, and related documentation. NIST Publications

A defensible certification record should therefore demonstrate:

• privileged identity
• privileged entitlement
• target system or resource
• business justification
• assignment type
• accountable owner
• certifier
• certification decision
• reviewer comments
• reassignment where applicable
• SoD or risk context
• remediation action
• completion status
• timestamps and evidence

This is the practical meaning of audit-ready identity governance.

An auditor should be able to ask:

Why did this administrator have this privilege on this date?

and receive an answer based on evidence rather than institutional memory.

What good privileged access governance should change operationally

The goal is not to produce another administrator spreadsheet.

It is to reduce unnecessary standing privilege and make every remaining privileged assignment attributable, justified, reviewable, and removable.

Organizations should expect to:

• maintain an authoritative inventory of privileged identities and entitlements
• distinguish permanent, temporary, and eligible privilege
• identify dormant privileged assignments
• correlate privileged access with current business roles
• select reviewers who understand both business need and technical privilege
• use multi-level certification for critical access where appropriate
• bring SoD and identity risk into the certification decision
• trigger reviews when material context changes
• convert standing privilege to JIT or eligible access where possible
• verify remediation after a revoke decision
• preserve evidence from assignment through removal

The measure of maturity is therefore not simply how many administrators were reviewed.

It is how much unnecessary privileged access remains after the review process has done its job.

FAQ

What is a privileged access review?

A privileged access review is a certification process that determines whether users or other identities should continue to hold administrative, elevated, or otherwise high-impact permissions.

How often should privileged access be reviewed?

There is no single frequency appropriate for every privileged entitlement. Review frequency should reflect risk, sensitivity, assignment type, business context, and regulatory requirements. Critical permanent access may justify more frequent scrutiny than lower-impact or tightly controlled eligible access.

Who should certify privileged access?

It depends on the privilege. Managers can validate business need, while application, resource, or entitlement owners may better understand the technical capability. High-risk privileges may justify multiple certification levels involving security or IAM.

Should administrators certify their own privileged access?

Self-review can be useful in some scenarios, but it should not be the sole governance control for critical privileged access. Independent review provides stronger accountability where the potential impact is high.

Is privileged access review the same as PAM?

No. PAM primarily controls how privileged access is obtained and exercised. Access certification determines whether the identity should retain the privilege. The strongest governance model connects IGA, PAM/PIM, and runtime evidence.

Should unused administrator access be automatically revoked?

Not always. Inactivity is an important risk signal, but context matters. A dormant permanent administrator role may warrant revocation, while a deliberately dormant break-glass account requires a different governance policy.

What happens after a privileged-access reviewer selects Revoke?

The entitlement must actually be removed, automatically or through an actioner/remediation process. The organization should verify completion and preserve evidence showing that the governance decision was implemented.

Privileged access reviews should ultimately answer more than "Does this administrator still need access?"

They should establish:

Does this identity still require this exact level of privilege, to this resource, under the current business context, and does that privilege need to remain permanently available?

That is the standard modern privileged access certification should meet.