Privileged Access Management and Identity Governance

Every organization has accounts that, if compromised, give an attacker the ability to read every database record, disable every security control, and erase every audit log. These are privileged accounts — and managing them is the highest-stakes access control problem in enterprise security. Alongside privileged access management sits identity governance: the discipline of ensuring that every person in the organization has exactly the access they need, no more, and that access is reviewed and adjusted as roles change.

This lesson covers the two disciplines — Privileged Access Management (PAM) and Identity Governance and Administration (IGA) — that together form the backbone of access control programs auditors scrutinize most closely.

What is a privileged account?

A privileged account is any identity that can perform actions with a disproportionate blast radius. If a regular user account is compromised, the attacker gets access to that user's email and files. If a privileged account is compromised, the attacker can modify infrastructure, access other users' data, disable security controls, or destroy evidence.

The most common types of privileged accounts you will encounter:

• Root and administrator accounts — The AWS root account, Azure Global Administrator, Linux root, Windows Domain Admin. These have unrestricted access to the environment and can override any other access control.
• Service accounts — Non-human identities used by applications, CI/CD pipelines, and automated processes. They often have broad permissions because developers provisioned them for convenience during initial setup and never scoped them down.
• Break-glass accounts — Emergency access accounts that bypass normal authentication and approval workflows. They exist for scenarios where the primary identity provider is down and someone needs to restore service. They should be rarely used and heavily monitored.
• Shared accounts — Accounts used by multiple people, such as a shared admin login for a SaaS tool that does not support SSO. Shared accounts are a control gap because you cannot attribute actions to an individual.
• Database administrator accounts — Direct access to production databases with the ability to read, modify, or delete data. A compromised DBA account is often the most direct path to a data breach.

Privileged Access Management controls

PAM is the set of controls that protect privileged accounts from misuse and compromise. The core principle is that no human should have persistent access to privileged credentials. Instead, privileged access is checked out when needed, monitored while in use, and revoked when done.

Credential vaulting

A credential vault (also called a password vault or secrets manager) stores privileged credentials in an encrypted, centrally managed repository. Users do not know the actual password — they request access through the vault, and the vault either injects the credential into the session or provides a time-limited credential.

The check-in/check-out model works like a library: you request a credential, the vault records who checked it out and when, you use it for the approved duration, and the vault rotates the credential after you check it back in. This creates an audit trail and ensures no one retains permanent knowledge of the credential.

Session recording

Session recording captures everything a privileged user does during an elevated session — keystrokes, commands, screen activity. If a privileged account is used to make an unauthorized change, the session recording provides forensic evidence of exactly what happened, when, and by whom.

Just-in-time elevation

Rather than granting permanent admin access, JIT elevation activates a privileged role only when a user explicitly requests it, for a defined duration. A developer does not have production admin access by default — they request it, receive approval, operate with elevated privileges for two hours, and the elevation expires automatically.

Approval workflows

Before a user can access a privileged credential or activate an elevated role, the request goes through an approval chain. The approver sees what access is being requested, why, and for how long. This creates a human checkpoint that prevents unauthorized use and generates an audit trail of every approval decision.

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   User        │     │   Approval   │     │  Credential  │
│   requests    │────►│   workflow   │────►│  vault issues │
│   access      │     │  (manager /  │     │  temporary    │
│               │     │   policy)    │     │  credentials  │
└──────────────┘     └──────────────┘     └──────┬───────┘
                                                  │
                                                  ▼
                                         ┌──────────────┐
                                         │   Session     │
                                         │   recorded    │
                                         │   (commands,  │
                                         │   screen)     │
                                         └──────┬───────┘
                                                  │
                                                  ▼
                                         ┌──────────────┐
                                         │  Session ends │
                                         │  Credentials  │
                                         │  rotated      │
                                         │  automatically│
                                         └──────────────┘

The PAM tools landscape

Different tools approach PAM from different angles:

• CyberArk — The dominant enterprise PAM platform. Credential vaulting, session recording, automated rotation, and privileged threat analytics. Complex to deploy but comprehensive.
• Delinea (formerly Thycotic) — Enterprise PAM with Secret Server for credential vaulting and Privilege Manager for endpoint elevation. Often positioned as simpler than CyberArk.
• HashiCorp Vault — Open-source secrets management with dynamic secrets (generates short-lived credentials on demand), encryption as a service, and broad cloud integration. Preferred by engineering teams for programmatic access.
• Azure PIM (Privileged Identity Management) — Microsoft's JIT elevation for Azure AD and Azure roles. Users activate roles for a specified duration with optional approval. Tightly integrated with the Microsoft ecosystem.
• AWS SSM Session Manager — Provides shell access to EC2 instances without opening SSH ports or managing SSH keys. Sessions are logged to CloudWatch and S3. Not a full PAM solution, but eliminates the need for standing SSH access to production servers.

Common PAM findings in audits

When auditors evaluate privileged access, these are the findings that appear most frequently:

• Shared credentials without individual attribution — Multiple people using the same root or admin password. There is no way to determine who performed a specific action.
• Permanent administrative access — Users who have admin rights 24/7 when they only need them occasionally. This violates least privilege and expands the blast radius of credential compromise.
• No session recording — Privileged sessions are not captured, so there is no forensic evidence if something goes wrong.
• No credential rotation — Privileged passwords that have not been changed in months or years. If a credential was leaked or shared, it remains valid indefinitely.

Identity Governance and Administration

If PAM focuses on the most dangerous accounts, IGA focuses on everyone. Identity Governance and Administration is the discipline of managing the full lifecycle of every identity in the organization — from the day a person joins to the day they leave — and ensuring their access remains appropriate throughout.

The identity lifecycle: Joiner-Mover-Leaver

Every identity follows a lifecycle, and each stage has specific access control requirements:

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│     JOINER       │     │     MOVER        │     │     LEAVER       │
│                   │     │                   │     │                   │
│  New hire         │────►│  Role change      │────►│  Offboarding     │
│  provisioned      │     │  access adjusted  │     │  accounts        │
│  with role-based  │     │  old access       │     │  disabled within │
│  access           │     │  revoked, new     │     │  SLA (e.g., 24h) │
│                   │     │  access granted   │     │                   │
│  Day 1: accounts  │     │  Transfer:        │     │  Immediate:      │
│  created in IdP,  │     │  engineering ──►  │     │  SSO disabled    │
│  email, apps      │     │  product mgmt     │     │  sessions killed │
│  assigned per     │     │  Remove: GitHub   │     │  credentials     │
│  role template    │     │  Add: Jira admin   │     │  rotated for     │
│                   │     │                   │     │  shared accounts  │
└─────────────────┘     └─────────────────┘     └─────────────────┘

Joiner: When a new employee starts, they are provisioned with a standard set of accounts based on their role. A software engineer gets GitHub, AWS (read-only), Slack, and Jira. A salesperson gets Salesforce, Slack, and email. Role-based provisioning ensures consistency and prevents ad hoc access grants.

Mover: When an employee changes roles — transferring from engineering to product management, getting promoted, or shifting teams — their access must be adjusted. The critical action is removing the old access, not just adding the new access. Without active revocation of previous access, employees accumulate permissions over time (privilege creep), eventually holding access to systems they no longer need.

Leaver: When an employee leaves the organization, every account must be disabled within a defined SLA. Most organizations target 24 hours; high-security environments target same-day or real-time. SSO should be disabled immediately, active sessions should be killed, and credentials for any shared accounts the person had access to should be rotated.

Access certifications

Access certifications (also called access reviews or entitlement reviews) are periodic reviews where managers and system owners verify that the access assigned to each person is still appropriate. A typical cadence is quarterly for privileged access and semi-annual for general access.

The process: the IGA system generates a list of all access for each user, grouped by manager. The manager reviews each entitlement and certifies (approves) or revokes it. Uncertified access is automatically revoked after the review deadline. The completion rate and decisions are logged for audit evidence.

Role mining and RBAC

Role mining is the process of analyzing existing access patterns to define standard roles. Instead of granting individual permissions to each person, you define roles (Engineer, Sales, Finance) and assign a standard set of permissions to each role. This is Role-Based Access Control (RBAC), and it makes provisioning, reviews, and audits dramatically simpler.

Segregation of duties

Segregation of duties (SoD) prevents a single person from holding a combination of access that creates a conflict of interest or a fraud risk. The classic example: the same person should not be able to create a vendor in the payment system AND approve payments to that vendor. SoD rules define toxic combinations, and the IGA system flags violations during provisioning and access reviews.

IGA tools

• SailPoint — The leading enterprise IGA platform. Identity lifecycle management, access certifications, role mining, SoD enforcement.
• Saviynt — Cloud-native IGA with strong cloud infrastructure governance (AWS, Azure, GCP entitlements).
• ConductorOne — Modern, developer-friendly IGA with Slack-based access requests and automated reviews.
• Okta Identity Governance — IGA capabilities integrated into Okta's identity platform. Access requests, certifications, and lifecycle management within the Okta ecosystem.

What to carry forward

PAM and IGA are two sides of the same problem. PAM asks: "How do we protect the most dangerous accounts?" IGA asks: "How do we ensure every identity has appropriate access throughout its lifecycle?" Both generate the audit evidence that demonstrates an organization's access controls are not just documented in policy but enforced in practice.

In the next lesson, you will learn about Just-in-Time access and Zero Trust — the architectural principles that are replacing the traditional model of permanent access grants and network-perimeter trust.