Just-in-Time Privileged Elevation with PAM

Integration of Privileged Access Manager (PAM) (opens in a new tab) with broader identity and security posture means PAM provides short-lived elevation while surrounding controls decide whether that elevation can be used. In this model, Cloud IAM defines persistent least-privilege baselines, PAM grants temporary, time-bound elevation (opens in a new tab) on top of that baseline, and Identity-Aware Proxy (IAP) controls access to protected web applications and tunneled sessions through its own IAM policy. A request succeeds only when all layers allow it, so compromise of one credential or approval does not by itself create standing privileged access.

1.1Layered Defense with PAM, Cloud IAM, and IAP

Layered defense with PAM, Cloud IAM, and IAP separates permanent permission, temporary elevation, and application entry into three enforced checkpoints. Cloud IAM allow policies grant only the minimum permanent roles a principal needs at the smallest scope, with IAM Conditions used for expiring bindings and deny policies used for hard guardrails that time-based conditions cannot override. PAM then manages just-in-time elevation for select principals, recording justification, approver, active period, and accessible resources, and automatically expiring the grant so no standing privilege remains. IAP protects web applications and remote access paths by requiring its own IAM decision, where administrators grant the IAP-Secured Web App User role on the IAP-protected resource, often to provisioned groups such as a payroll-application group.

Traffic flows from the user identity to IAP first for application access, then to Google Cloud APIs where Cloud IAM and PAM-derived bindings are evaluated. The PAM grant depends on the underlying Cloud IAM resource hierarchy, while IAP depends on federation and group provisioning when external identities from Microsoft Entra ID or another provider are used. Choose permanent Cloud IAM roles for everyday least-privilege work, choose PAM entitlements for emergency access, production troubleshooting, customer-data access, database maintenance, contractor access, and remediation of excessive permissions flagged by IAM recommender, and choose IAP policy when the goal is to control who can see and open a specific web application.

PAM composes with the other layers because a user can hold an active PAM grant yet still be denied by IAP or by a deny policy, which preserves least privilege even during approved elevation.

1.2Enforcing Context-Aware Access on Privileged Elevation

Context-Aware Access enforcement on privileged elevation adds device, network, and identity conditions that are checked on every API request in addition to the PAM grant. Access Context Manager defines access levels that specify attributes such as being on the corporate network, and Chrome Enterprise Premium binds those levels to API traffic so requests that present valid but compromised credentials are rejected when they do not meet the defined conditions. Supported conditions include IP-based access and certificate-based access for mutual TLS, which ties use of elevated privilege to a trusted network location or a verified device certificate. Because this check runs per request, elevation that is valid in time and approval still fails from an untrusted location or device.

This creates a user-centric and resource-centric boundary pair. Chrome Enterprise Premium is user-centric and applies only to user identities within the organization, while VPC Service Controls (VPC-SC) is resource-centric and applies to all user identities and service account identities by defining perimeters within which resources can communicate. When PAM elevation is combined with both, stolen OAuth tokens on an attacker-controlled machine outside the environment lose effectiveness because the identity check, the time-bound grant, and the perimeter check must all pass. Strengthen the same posture by requiring 2-Step Verification, also called multi-factor authentication, for all privileged users, by configuring OS Login with 2-Step Verification for SSH to Compute Engine, and by restricting persistent service account keys with the constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints.

1.3Monitoring and Investigating Privileged Access in Cloud Logging

PAM audit logging in Cloud Logging provides the record of who requested elevation, what was granted, when it was active, and how it was approved. Cloud Audit Logs capture privileged access requests and access patterns, including when granted roles were active, which resources were accessible during that window, the business justification supplied, and who approved the grant. Administrators review these logs to reconstruct privileged sessions, compare granted scope against actual API activity, and detect anomalies such as off-hours elevation, repeated emergency grants, or use beyond the approved task. Enterprises should export these logs to persist them for the retention period required for audit purposes.

Viewing PAM audit entries requires the logging.logEntries.list permission, while managing entitlements and grants requires PAM permissions such as privilegedaccessmanager.entitlements.* and privilegedaccessmanager.grants.* at the matching organization, folder, or project scope. For investigations that extend beyond PAM itself, enable Data Access audit logs on the target service to see resource-level reads and writes performed while the grant was active:

• ADMIN_READ records administrative read operations on the service API.
• DATA_READ records reads of user-provided data.
• DATA_WRITE records writes of user-provided data.

For example, enabling all three log types for compute.googleapis.com lets an investigator correlate a PAM grant for Compute Admin with the specific Compute Engine reads and writes that followed, then confirm whether activity stopped after grant expiry or withdrawal.

1.4Keeping PAM Functional Inside Deny Policies and Perimeters

PAM functionality inside deny policies and perimeters depends on explicitly allowing the PAM service agent to perform escalations. Privileged Access Manager Service Agent is a single organization-level service account named service-org-ORGANIZATION_NUMBER@gcp-sa-pam.iam.gserviceaccount.com, and PAM does not create or use folder-level or project-level service agents. The setup flow grants the Privileged Access Manager Service Agent role to that organization-level identity, and the role is inherited by child folders and projects through the resource hierarchy when granted at the organization or folder.

Enablement follows an ordered dependency:

1. Select scope: Select the organization, folder, or project where PAM will manage entitlements.
2. Grant service-agent role: Grant the Privileged Access Manager Service Agent role to the organization-level service agent so it can add and remove time-bound bindings.
3. Exempt from deny: Add the service agent to the exceptionPrincipals field of relevant deny policies so a deny rule does not block the escalation itself.
4. Allow through perimeter: Add the service agent to the appropriate VPC Service Controls access levels or add an ingress rule to the perimeter to allow the service agent.
5. Complete setup and notifications: Complete setup and add pam-noreply@google.com to email allow lists so entitlement and grant notifications are not blocked.

If the service agent is missing from exceptionPrincipals or from the perimeter access level, legitimate grant activation fails even when the requester, justification, and approvals are correct. This ordering matters because Cloud IAM evaluates deny policies above allow policies, and VPC Service Controls evaluates resource communication independently of identity elevation.

Evaluation of use cases for Privileged Access Manager (PAM) (opens in a new tab) means distinguishing standing access from temporary elevation that requires governance. An administrator defines an entitlement that states who can request which privileged role on which resource, and a requester activates that role only for a time-bound grant with justification and approval. After the grant expires, audit logs show who had access to what and when, including the justification and approver.

2.1Standard IAM Roles Versus PAM-Controlled Elevation

Standard Identity and Access Management (IAM) roles versus PAM-controlled elevation differ in persistence and governance. Standard IAM allow-policy bindings grant persistent, always-on access that remains effective until manually removed, which fits stable day-to-day duties assigned under least privilege. PAM entitlements grant temporary, on-demand access that activates only after a request, optional approval, and a defined time window, then expires automatically.

Choose standard IAM for the permanent least-privilege baseline every identity needs continuously. Choose PAM when elevated privilege is infrequent, sensitive, or risky enough to require a request, a business reason, an approver, and an auditable active window.

2.2Emergency, Sensitive-Data, and Extended-Workforce Access

High-risk human access scenarios are the core fit for Privileged Access Manager (PAM) because speed and control must coexist. PAM lets select emergency responders activate critical roles without waiting for approval while still requiring a justification for later review. The same entitlement model tightly controls sensitive operations that need approvals, justifications, and a record of which resources were accessible during the grant.

Common scenarios that necessitate PAM include:

• Emergency break-glass access: responders self-activate predefined roles to resolve an incident, with justification captured for audit.
• Production troubleshooting and deployments: developers receive temporary access to production environments only for the incident or release window.
• Sensitive customer-data operations: support engineers receive scoped access to customer data for a specific ticket or task.
• Privileged maintenance: database administrators elevate for configuration or maintenance, then the grant expires or is withdrawn.
• Contractor and extended-workforce access: external users receive time-bound access with approvals and justifications instead of standing roles.

In each case, traffic flows from the requester to the entitlement, then to a time-bound grant on the target project, folder, or organization, and the grant flows back to automatic expiry. Because the elevated role is not persistently bound, the attack surface exists only during the approved window.

2.3Least-Privilege Enforcement, Automation, and Insider-Threat Reduction

Least-privilege enforcement with Privileged Access Manager (PAM) keeps permanent roles narrow and moves infrequent privilege to on-demand entitlements. Administrators assign only the minimum standing roles, then create entitlements with tag-based conditions and require requesters to ask for a customized scope and withdraw the grant when the task completes. When IAM recommender (opens in a new tab) flags excessive permissions, the permanent binding can be transitioned to a PAM entitlement, which removes the standing grant and preserves on-demand access for infrequent but critical tasks.

PAM also reduces single-actor and non-human risk in advanced environments. Multi-party and multi-level approvals can require a second approver and up to two sequential approval levels, so one compromised administrator account cannot approve its own malicious elevation. Service accounts and agent identities can self-elevate only when an automated task needs the role instead of holding it permanently, and service accounts or agent identities can act as programmatic approvers in DevOps pipelines by validating Information Technology Service Management (ITSM) tickets before approving.

2.4Compliance and Audit Requirements Driving Adoption

Compliance drivers for Privileged Access Manager (PAM) are privileged-activity logging and separation of duties with enforceable expiry. PAM records when each granted role was active for a user, which resources were accessible during that time, the justification submitted, and who approved the request. Administrators can analyze these Cloud Audit Logs for access patterns and anomalies, and enterprises are expected to export the logs for retention needed for audit purposes.

PAM supports separation of duties by separating the requester, the approver, and the entitlement administrator, reinforced by multi-party approvals and least-privilege baselines. Privileged access must either expire automatically or be reviewed periodically, and access can be further constrained with 2-Step Verification for all privileged users and attribute-based controls from Access Context Manager, such as requiring use from the corporate network during the grant window.

Configuration of Privileged Access Manager (PAM) (opens in a new tab) policies and access workflows centers on entitlements that pre-authorize elevation and grants that consume it. Access is defined in an entitlement that pre-authorizes who can elevate, to what, and under what controls, and it is consumed through a grant that temporarily activates those privileges and then removes them automatically. This model replaces permanent high-privilege bindings with on-demand access that supports justification, approval, and auditing of who had access to what and when.

3.1Entitlements: Targets, Principals, and Justifications

A PAM entitlement is a policy object bound to an organization, folder, or project that specifies the privileged roles, the target resources, the eligible principals, and the rules for requesting them. Eligible principals can include human users, Google groups, contractors and extended workforce, and non-human identities such as service accounts and agent identities. A requester can only request a grant against an entitlement they have been added to, which keeps eligibility explicit and auditable.

Each entitlement enforces least privilege through its core fields:

• Privileged roles and target resources: the roles that will be temporarily granted and the organization, folder, project, or filtered set of resources where they apply.
• Eligible requesters: the users, groups, service accounts, or agent identities allowed to request grants.
• Justification requirement: a mandatory business reason or incident context that is recorded for audit.
• Maximum duration: the longest grant lifetime allowed, so every grant expires automatically.
• Approval workflow: whether grants activate immediately, require one or more approvers, or allow emergency access without approval.
• Scope controls: tag-based conditions, customizable role and resource scope, and the ability for requesters to withdraw grants when work finishes early.

When Security Command Center Premium or Enterprise tier is active, requesters can customize grant scope to a subset of the entitlement by turning on Customize scope, adding up to five resource filters, and selecting only the required roles. This preview capability lets a developer troubleshoot one project, a support engineer access specific customer data, or a database administrator elevate only for a maintenance task without activating the full entitlement.

3.2Enabling PAM and the Service Agent Trust Boundary

PAM enablement depends on the Privileged Access Manager Service Agent, which performs privilege escalations on behalf of the service. PAM uses only the organization-level service agent (service-org-ORGANIZATION_NUMBER@gcp-sa-pam.iam.gserviceaccount.com), even when PAM is set up for a folder or project, and it does not create folder-level or project-level service agents. Granting the Privileged Access Manager Service Agent role to that organization-level agent on an organization or folder causes the role to be inherited by all child folders and projects in the resource hierarchy.

The service agent must be able to act through surrounding guardrails or grants will fail closed. Administrators add the service agent to the exceptionPrincipals field of relevant deny policies so a deny rule does not block the elevation, and they add the service agent to appropriate VPC Service Controls access levels or add an ingress rule to the perimeter to allow it. Notification recipients should allow pam-noreply@google.com so approval and grant emails from PAM are not blocked.

3.3Approval Workflows with Conditional and Automated Approvers

A PAM approval workflow controls whether a grant request activates immediately or waits for review, who can approve, and how many checks must pass. Entitlements can require business justification plus approval for sensitive resources, allow emergency break-glass access without waiting for approval while still recording justification, or require multi-party approval so a second approver must concur. With multi-level approvals in preview, administrators can mandate up to two sequential approval levels per entitlement to separate team review from security or owner review.

Approvers can be human users or non-human approvers used for automation and conditional logic. Service accounts or agent identities can serve as approvers inside DevOps pipelines and programmatically approve by validating tickets directly from ITSM systems, which removes slow manual checks while keeping an auditable decision. The same identity model also secures automation itself: instead of permanently granting roles to service accounts, administrators let those accounts self-elevate and assume roles only when an automated task needs them, and contractors receive only temporary, time-bound access with approvals and justifications.

3.4Grant Durations, Scheduling, and Request Limits

A PAM grant is a time-bound activation of an entitlement with a requester-chosen duration up to the entitlement maximum. The transition flow from IAM recommender (opens in a new tab) defaults to 8 hours, and any grant can be scheduled up to seven days in advance (opens in a new tab) or left to activate immediately after creation or approval. Successful grants are implemented with time-based IAM Conditions and are subject to standard access-change propagation, so activation and removal take time to take effect across the system.

Grant requests follow strict concurrency and approval-deadline rules that enforce least privilege in practice:

1. Request: The eligible principal selects the entitlement, optional customized scope, duration, justification, and optional additional notification emails.
2. Approval wait: If approval is required, the request enters Approval awaited and must be approved or denied before it expires.
3. Activation: An approved immediate grant becomes Active, while an approved scheduled grant becomes Scheduled until its activation time.
4. Expiry and removal: PAM automatically removes the roles when the grant ends, and requesters can withdraw early after completing the task.

One user can have a maximum of 10 open grants per entitlement in Active, Scheduled, or Approval awaited state. A principal cannot request a grant with the same scope as an existing open grant on that entitlement, cannot create two scheduled grants whose scopes and activation times both overlap, and cannot schedule a grant to start before an active grant with the same scope ends. Approval deadlines depend on activation type:

Key Facts

• Privileged Access Manager grants temporary, time-bound elevation with justification and approval on top of the persistent least-privilege baseline defined by Cloud IAM, while Identity-Aware Proxy enforces a separate IAM decision before a protected application is reached.
• PAM uses only the organization-level service agent named service-org-ORGANIZATION_NUMBER@gcp-sa-pam.iam.gserviceaccount.com, which must be added to exceptionPrincipals in deny policies and allowed through VPC Service Controls perimeters.
• One user can have a maximum of 10 open grants per entitlement in Active, Scheduled, or Approval awaited state, with immediate grants approved within 24 hours and scheduled grants scheduled up to 7 days ahead.
• PAM audit logs record when granted roles were active, which resources were accessible, the justification supplied, and who approved the grant, and Data Access logs with ADMIN_READ, DATA_READ, and DATA_WRITE show resource activity during the grant window.