I've led the post-incident review after every serious incident my teams have handled in the last decade, and the board question is always some version of how it got this bad. The answer is rarely the initial phish or the exposed service; it's the next step, when the attacker gains the authority to reset MFA, create identities, change roles, or export data. In many serious cases, the impact expanded only after the attacker reached that privilege.
Identity weaknesses played a material role in nearly 90% of Unit 42's 2026 incident-response investigations. That is not a universal breach rate, but it matches what the investigation seat sees. So treat every high-impact role activation, service-principal permission change, OAuth grant, and MFA reset as a security event, and export the identity and cloud logs to reconstruct it before an incident.
In brief:
- Credential abuse fell as an initial-access vector in the 2026 DBIR but stays important later in the chain, for lateral movement and privilege abuse, so the initial-access measure understates the privilege problem.
- The handoff from initial access to a secondary threat group now takes a median of 22 seconds, so the privileged action, not the entry event, defines the detection window.
- Investigations stall on logs that expired or were never generated: Entra ID sign-ins default to 7 or 30 days by license, Okta logs to 90, and CloudTrail data events are off unless someone turned them on.
- PAM often starts with the human admin accounts someone onboarded to the vault, but the breach path can run through service accounts, OAuth tokens, and shadow admins that were never in it.
What every investigation teaches about privileged access
Two things show up in every reconstruction I've led: the escalation moment matters more than the entry point, and the numbers most teams budget against measure the wrong one.
It's where the incident stopped being small
The textbook defines privileged access as administrative roles, service-account permissions, API keys, or OAuth tokens with administrative scopes. That describes a property of accounts, but from the investigation seat privileged access is the point where an attacker can make high-impact changes. Before it, the attacker holds one box or one mailbox. After it, they're resetting MFA and exporting the directory, and the report grows a disclosure section.
In the 2026 DBIR, credential abuse declined as initial access and now trails vulnerability exploitation, which reads like progress in isolation. But initial-access numbers describe how attackers first entered, not whether they gained the permissions for persistence or control-plane changes, and those are separate stages with separate telemetry. The second stage is the one that matches the timelines I've reconstructed.
How privileged access actually gets abused in 2026
Four patterns appeared repeatedly in the cases I worked this year: standing admin, over-privileged service accounts, token theft, and identity-first paths that skip malware entirely.
Standing admin and service accounts carry privilege with less scrutiny
Attackers favor standing admin accounts because their roles stay permanently active. Scattered Spider operations repeatedly show help-desk social engineering: voice phishing, accurate verification answers, and impersonation to reset Entra ID, SSO, and VDI accounts. When the reset account holds a permanently active Global Administrator role, that reset workflow becomes the decisive step, and help-desk social engineering opens a path downstream.
Service accounts and tokens carry the same privilege with less scrutiny. Microsoft said Midnight Blizzard abused credentials for a legacy test OAuth app with broad Microsoft Graph permissions. The actor then created a user and assigned it highly privileged directory roles, including Global Administrator.
UNC6395 abused compromised OAuth tokens from Salesloft Drift to reach Salesforce across more than 700 organizations. Because those tokens were already authorized, the API access needed no fresh MFA challenge.
Identity-first attacks can bypass endpoint-only visibility
CrowdStrike reported that 79% of 2024 detections were malware-free. In the first half of 2024, valid-account abuse was the primary initial access method in 35% of cloud incidents. In M-Trends 2026, voice phishing was the second initial infection vector at 11%, with stolen credentials at 9% and dwell time up to a 14-day median. In Cisco Talos's Q2 2026 IR data, authentication abuse featured heavily via adversary-in-the-middle proxies, session-token theft, and MFA fatigue.
Attack speed changes the operating model. The same M-Trends data puts the median handoff to a secondary group at 22 seconds, and prior compromise is now the top ransomware initial vector at 30%. A triage process built around multi-hour windows is mismatched to that tempo, and the decisive evidence may never appear in endpoint telemetry. Privilege-focused detection should fire on the privileged action, because by then the entry event is history.
What the investigation seat wishes had been logged
Every stalled investigation I've sat through stalled for the same reason: the privileged action happened, and the record of it either expired or was never generated.
The privileged actions you can't reconstruct after the fact
Storm-0558 is the mailbox-audit case I make people read: MailItemsAccessed events were pivotal to determining email access, and teams without that audit coverage faced material investigation limits. The necessary data did not exist. The defaults have not gotten more forgiving. Entra ID keeps sign-in logs for 7 or 30 days by license, Okta's System Log holds 90 days, and CloudTrail does not log data events like S3 reads unless configured.
Where native retention is short, stream the events that show privileged actions to a security information and event management (SIEM) system. On the identity side, that means Entra sign-in and audit logs, including non-interactive sign-ins, service-principal activity, role assignments, and consent grants. Add the Okta System Log with its admin-role and MFA changes.
On the cloud side, keep multi-region CloudTrail management events, selective data events for sensitive S3 buckets, and IAM and KMS activity. Retain the Microsoft 365 mailbox-audit events your licensing allows, including MailItemsAccessed. Then alert on the few that signal abuse: a privileged role granted outside your workflow, new service-principal credentials, an MFA-method change, an access-key creation, or abnormal mailbox access.
Okta's post-incident analysis shows why exact event types and identifiers matter: the key evidence was tied to file-view activity in its support system, found only after the initial review. Log export and long-term retention usually cost far less than reconstructing missing evidence mid-incident. Default retention periods are often shorter than investigation timelines, so export and retention need explicit decisions.
What this changes about how you grant and watch privilege
Make human administrative privilege just-in-time where feasible, and monitor every privileged action. Workload identities and emergency accounts that need standing access should instead be tightly scoped, rotated, and reviewed.
Make privilege temporary, then watch every activation
Microsoft recommends zero permanently active assignments for roles other than emergency-access accounts, with two cloud-only emergency Global Administrator accounts. The value is as much detective as preventive: when nobody holds standing admin, each activation becomes a rare, high-signal event. Some just-in-time deployments preserve standing privilege anyway, because the activation only toggles an account that already holds static sensitive permissions.
I've watched approvers rubber-stamp requests they couldn't evaluate, and break-glass accounts quietly recreate standing privilege. Most programs also fail to monitor the privilege they already trust: alert on role assignments added outside PIM, and detect token replay across impossible geography. In renewal demos, I ask the same thing: show me the alert that fires when someone gets a privileged role outside your workflow, or when the actor is a service account.
Where this connects to PAM and posture
PAM is important, but it is not the same as complete privileged-access coverage, and the investigation seat is where the difference shows up.
PAM covers the accounts someone onboarded, not the breach path
Traditional PAM programs often begin with the human admin accounts someone onboarded, though many platforms can also govern service accounts and secrets. The breach paths I've walked route around that scope: shadow admins that gain equivalent control without an obvious privileged role, and service accounts nobody could safely rotate.
Identity security posture management (ISPM) finds privilege that should not exist, and identity threat detection and response (ITDR) watches for abuse. I run both with PAM.
This week, run the exercise I use to open every program review. Pick your last real incident, or your last purple team run, and try to produce the privileged-access timeline from logs you actually retained. If a link in that chain is missing, from the identity event to the role change to the data access, you've found a specific coverage gap, cheaper to close now than mid-incident.
Frequently asked questions about privileged access
What is privileged access?
Privileged access includes administrative roles and service-account permissions, along with API keys or OAuth tokens that carry administrative scopes. In practice it also covers indirect paths, like shadow admin accounts and help desk staff who can reset MFA on privileged users, which hold effective privilege without appearing in any admin group.
How is privileged access abused in a breach?
Common 2026 patterns are help desk social engineering against standing admin accounts and abuse of over-privileged service accounts or OAuth tokens that bypass MFA. Session-token theft through adversary-in-the-middle phishing is also common. Attackers increasingly log in rather than exploit: malware-free detections reached 79% in 2024, and credential abuse stays important later in the attack chain.
What should you log for privileged access?
Export identity-provider logs beyond their short retention defaults: Entra ID sign-ins, including non-interactive and service principal activity; Entra audit logs for role and credential changes; Okta System Log streamed to a SIEM; and CloudTrail management plus data events. Add Microsoft 365 mailbox events like MailItemsAccessed so investigators can reconstruct mailbox access.
How is privileged access different from PAM?
Privileged access is the risk; PAM is one control over part of it. PAM tools vault and record the human admin accounts that were onboarded and time-limit access to them, while the breach path can run through unvaulted service accounts, OAuth grants, shadow admins, or the identity provider itself. PAM coverage should be measured alongside service-principal, OAuth, delegated-admin, and shadow-admin coverage.