Privileged access management from the SOC seat
I inherited a privileged access management (PAM) deployment eighteen months into a CyberArk rollout, with the vault live and compliance satisfied. When I asked my detection engineers what rules they'd built against the PAM logs reaching our security information and event management (SIEM) platform, the answer was zero.
The session recordings weren't forwarding at all; they sat in the PAM platform, invisible to the SOC's detection engineering. Organizations buy PAM as an access control, and the SOC inherits it as a detection problem. Owning the control is not owning the visibility, and that gap is where privileged access abuse lives.
In brief:
- Privileged access management (PAM) governs who can use high-impact credentials and how: vaulting, session management, rotation, just-in-time (JIT) access, least privilege, and secrets management. For the security operations center (SOC), it's a detection surface and an attack target before it's a compliance checkbox.
- 97% of identity attacks are password spray or brute force, but the ones that reach privileged accounts cause the highest-impact breaches. PAM telemetry is the early-warning system most SOCs never wire up.
- Attackers operate through standing admins, unmanaged service accounts, break-glass abuse, shadow admin rights, and JIT sprawl, all outside PAM's control plane and inside the SOC's detection responsibility.
- Before approving any PAM purchase or renewal, ask what it sends the SOC and what it actually restricts.
PAM is an access control and a detection surface
Start with what the control does. Privileged access management governs elevated-permission accounts across infrastructure, applications, and cloud through vaulting, rotation, just-in-time (JIT) access, least privilege, and secrets management. NIST SP 800-53 codifies least privilege under AC-6, and CISA's Zero Trust Maturity Model extends it with continuous monitoring.
That is the policy framing. For a SOC, PAM is a set of log streams: vault checkouts, sessions, rotations, JIT elevations, and privileged commands. Each is a detection surface, and the high-fidelity ones, like a privileged session with no preceding checkout, signal a bypass. Most deployments build none.
Privileged access is the prize attackers want
The reason to wire it up is that privileged credentials are what attackers want. 79% of detections were malware-free in 2024, as attackers logged in rather than dropped malware. Stolen credentials reached 16% of initial access in Mandiant's 2024 work, overtaking phishing for the first time, and the ones that matter most are privileged.
MITRE ATT&CK maps the techniques. Valid Accounts spans initial access through evasion; Account Manipulation, cloud account abuse, and Kerberoasting cover the persistence and credential theft that follow. In each, the goal is privileged credentials the defender's tools treat as legitimate, and a vault that isn't wired to the SOC can't tell a real checkout from an attacker holding those credentials.
PAM produces telemetry the SOC rarely wires up
The telemetry to catch this mostly exists; it is rarely connected. PAM produces vault checkout logs (who pulled which credential, when, from where), session logs (duration, target, termination), rotation logs, JIT elevation requests, and privileged command logs. Each stream answers a different detection question.
The integration is where it breaks. CyberArk needs XSL translator files for custom SIEM integration, and BeyondTrust syslog covers only appliance events, with session data behind a separate plugin. Cloud JIT events from Entra ID PIM and GCP land in separate streams from on-prem logs, and what reaches the SIEM arrives uncorrelated with identity and endpoint data. You can't write rules against data you can't query.
A wired-up PAM detection correlates more than one source
Wired correctly, the payoff is concrete. A vault checkout followed by a privileged session is routine on its own. Correlate it with the identity provider sign-in and the endpoint process tree, and a checkout from an unusual source feeding a session that spawns mimikatz becomes a detection no single log produces.
That is the difference between a PAM platform and a PAM detection. The platform records the checkout; the SOC turns the checkout, the session, and the endpoint into a timeline an analyst can work. Building that correlation is detection engineering, and it is the part most deployments skip.
The gaps PAM leaves become the SOC's problem
Even wired correctly, PAM controls the vault, and attackers operate around it. Five gaps land on the SOC's detection backlog, each needing a different data source and correlation:
- Standing admins: authenticate with cached or memorized credentials, bypassing the vault; correlate privileged logons (Event ID 4672) against checkouts, where a logon with no checkout signals a bypass. Service accounts sitting in Domain Admins groups are a recurring finding, a privilege gap CISA's Active Directory guidance ties to full domain compromise.
- Unmanaged service accounts: sit outside PAM because nobody owns them; they authenticate from fixed hosts, so build a known-good fence per account and alert on anything outside it.
- Break-glass credentials: are built to bypass standard policy, including MFA, for emergencies; any use should fire a critical alert with no suppression, correlated to an active incident ticket.
- Shadow admin rights: in cloud identity and access management (IAM) are the fastest-growing gap; in AWS, iam:PassRole plus ec2:RunInstances lets a principal launch compute with an admin role and gain admin without any admin-group membership.
- JIT sprawl: turns temporary access into standing privilege when developers stack concurrent grants that together cover a whole subscription.
Each of these needs log sources and correlations that most PAM integrations don't provide out of the box. The gaps are real, and they are the SOC's to detect.
Before I approve a PAM deployment, I ask what it sends the SOC
That backlog is why I evaluate PAM on what it gives the SOC, not how its compliance screens look. The question I open every vendor call with: when a checked-out credential runs mimikatz in a privileged session, what does the SOC see in the SIEM, and how many clicks from alert to session recording? Then I want specifics:
- session command telemetry forwarded to the SIEM in queryable form, alongside access-boundary events
- a pre-built parser for my SIEM, with a named owner for updates when the vendor changes their log format
- a REST API for event-driven session termination and on-demand credential rotation
- telemetry for privileged activity that happens outside the vault, because a cached credential or Kerberos ticket never touches it
- how service-account sessions appear in the stream
If the vendor can't answer these during the proof of concept, the SOC inherits another log source that produces volume without detection value, a line I won't approve. It has to produce detection value proportional to the engineering hours it costs. A vault that rotates credentials while leaving the telemetry uncorrelated is a compliance control, not a security one.
The control belongs to IAM, the visibility belongs to the SOC
I've learned this through two PAM renewals and one rip-and-replace. The distinction matters when you're defending the line item to a CISO, and it matters more when an attacker uses a standing admin account the vault never managed and the SOC never saw. The control belongs to the IAM team; the visibility belongs to the SOC.
Own the visibility and you own the detection surface. Skip it and you own the incident that lands in your queue at 2 AM, from an account that was supposedly under management. Own the visibility.
Frequently asked questions about privileged access management
What PAM logs should a SOC send to a SIEM?
Send five streams: vault checkout and check-in, session start and stop, rotation success and failure, JIT elevation requests, and privileged command execution. Correlate them with identity provider sign-ins and endpoint process events to build a full privileged-activity timeline, with network flows for the network side.
How do attackers bypass PAM?
By operating outside the vault's control plane: cached credentials over RDP or WMI, PowerShell remoting without a checkout, Kerberoasting service accounts with static passwords, and pass-the-hash using NTLM hashes from LSASS or NTDS.dit. The vault produces no telemetry, because the attacker never touches it.
How do I detect privileged access that bypasses PAM?
Correlate privileged logons (Event ID 4672) against vault checkouts; a logon with no matching checkout in a set window can mean the credential was used outside PAM. For cloud, watch for Entra ID PIM or GCP PAM elevation events with no matching on-prem session record, a sign of privilege obtained off-channel.
What ATT&CK techniques should I map to privileged access abuse?
The core four are Valid Accounts (T1078), Account Manipulation (T1098), OS Credential Dumping, and Kerberos Tickets. Together they cover credential abuse, persistence through credential and role changes, hash extraction from LSASS and NTDS.dit, and Kerberoasting or Golden Ticket attacks. Scope rules to accounts in Tier-0 paths rather than all privileged activity, to avoid false positives.
What should a SOC expect PAM to cover?
Privileged access management governs access to high-impact accounts across infrastructure, applications, and cloud. Core capabilities are credential vaulting, rotation, just-in-time access, least privilege, and secrets management. For a SOC, it is both a detection surface and an attack target adversaries work to bypass.
What should I ask during a PAM vendor evaluation?
Ask whether the tool produces command telemetry or only boundary events, how many steps to reach session context from a SIEM alert, and who owns parser updates when the log format changes. Get the REST API docs up front, and if the vendor can't show queryable session data in the proof of concept, it won't get built.