imate permissions in ways that produce effective access that no reviewer would have explicitly approved.
Why This Matters Now
Identity security programs focus heavily on preventing unauthorized access: strong authentication, least privilege, PAM controls, access reviews. These controls address escalation that requires crossing authorization boundaries. They are less effective against escalation that occurs through the creative combination of permissions that individually appear appropriate.
An analyst with read access to a financial database, write access to an export directory, and the ability to create scheduled tasks has the effective ability to exfiltrate financial data on a schedule. No individual permission is inappropriate. The combination produces a capability that no reviewer intended to grant.
The escalation risk is not in individual permissions. It is in the combination. Access reviews that assess permissions individually miss the capability that combinations create.
The Governance Problem Beneath the Surface
Separation of duties exists to address exactly this problem: defining incompatible permissions that should not be held by the same individual. The challenge is that the number of potentially harmful permission combinations in a complex enterprise environment vastly exceeds the separation of duties rules that governance programs have defined. SoD frameworks address the most obvious and well-known incompatible combinations. The long tail of harmful combinations that fall outside defined SoD rules is not covered.
Additionally, escalation can occur through chains of access: user A has permission to access resource B, resource B has credentials for system C, system C has administrative access to data D. The user never directly touches data D. They access it through a chain of legitimate steps.
What This Actually Means in Enterprise Practice
Cloud Permission Combinations
Cloud environments create complex permission combination scenarios that traditional SoD frameworks were not designed to govern. An AWS IAM user with iam:PassRole permission can assign IAM roles to services, potentially escalating to permissions the role provides. An Azure user with Microsoft.Authorization/roleAssignments/write can grant themselves additional roles. These cloud-specific escalation paths require cloud-native governance.
Service Account Chain Access
Service accounts that have access to credential stores, secrets management systems, or other service accounts create chain access paths. A compromise of one service account with access to a secrets store that contains credentials for a highly privileged account creates an escalation path that traverses multiple access control boundaries through individually legitimate access rights.
Chain access paths are difficult to detect because each individual link appears legitimate in an access review. The review confirms that the service account has appropriate access to the secrets store. It does not trace what credentials in the secrets store provide access to what other systems.
Developer Access Combinations
Developers in DevOps environments frequently hold combinations of access that enable them to modify their own access controls. The ability to modify IAM policies, combined with the ability to deploy code that executes with elevated permissions, combined with the ability to create service accounts, provides a path to self-escalation that does not require any individual permission that a developer access review would flag.
Data Pipeline Escalation Paths
Data pipelines that move data between systems create access paths that are determined by the pipeline's authorization, not the requesting user's authorization. A user with access to trigger a pipeline that moves data from a sensitive source to a permissive destination can effectively access sensitive data through the pipeline even if they do not have direct access to the source.
How Different Teams See This: Where They All Miss
Privilege escalation within approved access is the identity governance problem that falls between all the standard governance activities. Individual permissions look fine. Combinations are the problem. No current governance activity is specifically designed to analyze combinations.
Framework Control Reference
The specific control obligations most relevant to this topic. Use in governance discussions, vendor assessments, and audit responses.
These controls share a common requirement: the obligation is active, not declarative. Documenting alignment is not the same as demonstrating it.
The Enterprise Reality Gap
The enterprise privilege escalation reality gap is the effective access that exists in the environment through permission combinations, service account chains, and multi-hop paths, that would not be approved if any reviewer were asked to explicitly grant it. This effective access is not visible through standard access review processes because access reviews assess individual permissions, not the capability that combinations create.
The access that creates the most significant escalation risk is the access that no reviewer noticed because no reviewer was looking at combinations. Individual permission reviews confirm that each permission looks reasonable. The governance gap is the capability that reasonable-looking permissions produce in combination.
Enterprise Scenario
All permissions confirmed. All reviews completed. Capability to exfiltrate sensitive financial data to external recipients exists through the combination. The access review process was not designed to find it.
Industry Signal
Cloud security incident analysis has consistently identified cloud-native privilege escalation as one of the most common techniques used in cloud breaches following initial access. Researchers have documented dozens of escalation paths within AWS, Azure, and GCP that use legitimate permissions in combinations to achieve administrative access. The persistence of these paths in enterprise environments despite known documentation is evidence that standard access governance processes are not closing them.
Privilege escalation within approved access is not a theoretical concern. It is documented in breach analysis, in cloud security research, and in penetration test findings across enterprise environments. The question is whether governance programs are specifically looking for it.
Enabling Capabilities
- Cloud permission graph analysis: Tools that map cloud IAM permission combinations and surface escalation paths that individual permission review would not detect.
- SoD analytics beyond defined rulesets: Identity analytics platforms that identify potentially harmful permission combinations beyond the defined SoD ruleset.
- Service account chain analysis: Mapping of service account access chains to identify multi-hop escalation paths through legitimate credential access.
- Pipeline authorization governance: Review of who can trigger pipelines and what effective access those pipeline triggers provide.
A Practical Starting Point
For your cloud environments, run an IAM privilege escalation analysis using one of the documented cloud-native escalation path detection tools. The analysis will surface the escalation paths that exist in your current permission configuration. This test typically takes hours and produces a concrete list of escalation paths that standard access governance has not addressed.
Cloud privilege escalation analysis is the fastest way to find the combination problem. Most organizations conducting this analysis for the first time find escalation paths they did not expect.
Questions Leaders Should Be Asking
- Have we analyzed our cloud IAM permissions for known escalation paths, specifically including the cloud-native escalation vectors documented by security researchers?
- Does our SoD ruleset address combination-based escalation in our cloud environments, or was it designed for on-premises separation of duties scenarios?
- How do we analyze the effective access that service account chains provide, and do we trace access chains through multiple hops?
- How do we assess who can trigger data pipelines and what sensitive data those pipelines can access?
What to Require From Vendors
Ask directly:
"What privilege escalation path analysis does your platform provide, specifically including combination-based escalation through multiple legitimate permissions and cloud-native escalation vectors beyond standard SoD rule violations?"
Expect as evidence:
- Escalation path detection capabilities beyond SoD ruleset enforcement
- Cloud-native escalation vector analysis
- Service account chain and multi-hop access path analysis
A vendor whose privilege controls address SoD violations without analyzing combination-based escalation paths has governed the documented risks. Ask specifically about the undocumented ones.
Demonstrating Diligence
- Documentation: Privilege escalation path analysis results; combination risk assessment; cloud-native escalation vector inventory.
- Process: Regular escalation path analysis as part of access governance; pipeline authorization review; service account chain analysis.
- Technical evidence: Escalation path analysis outputs; combination risk remediation records; cloud IAM review results.
Privilege escalation governance requires analyzing combinations, not just individual permissions.
Closing Perspective
The individual permissions in most enterprise environments have been reviewed, confirmed, and documented. The combinations those permissions create have largely not been analyzed. The gap between reviewed individual permissions and unanalyzed combination capabilities is the privilege escalation surface that standard governance processes do not address.
Closing this gap requires a different governance activity: combination analysis, escalation path mapping, and chain access tracing that goes beyond standard access review methodology.
Escalation happens where governance stops looking. Start looking at combinations.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.