What is Toxic Combination in Identity Security?
A toxic combination is a set of permissions, roles, or attributes that — while individually safe — combine to create unacceptable risk. Learn what they are, common examples, and how to detect them.
What is Toxic Combination in Identity Security?
Definition
A toxic combination in identity security is a set of permissions, roles, group memberships, attributes, or trust relationships that are individually unremarkable but, when held by the same identity, create an unacceptable risk — fraud, privilege escalation, data exposure, or evasion of controls.
The core idea:
Two safe permissions can combine into one dangerous capability.
Toxic combinations are sometimes called toxic combinations of access (TCoA), risky entitlement combinations, or Separation of Duties (SoD) violations, depending on context.
Why Toxic Combinations Matter
Most access reviews evaluate one entitlement at a time: "Should this user still have read on this folder?" Yes/no. But the combination of entitlements often matters more than any single one.
Examples that pass an entitlement-by-entitlement review but create catastrophic risk:
- "Create user" + "Approve user access" → invisible backdoor accounts.
- "Submit invoice" + "Approve invoice" → fraud.
- "Reset password" + "Membership in admin OU" → privilege escalation.
- "Read database" + "Read encryption key" → data exfiltration.
- "Create OAuth app" + "Grant tenant admin consent" → tenant-wide compromise.
Toxic combinations are central to financial controls (SOX), data protection (GDPR/HIPAA), and cyber resilience.
Toxic Combinations vs Separation of Duties
Separation of Duties (SoD) is the control that prevents toxic combinations. SoD policies define which combinations of duties or permissions must never be held by the same identity.
- Toxic combination = the dangerous state.
- SoD = the policy and control that forbids it.
NIST SP 800-53 (AC-5) and most regulations require SoD for sensitive workflows.
Common Categories of Toxic Combinations
1. Financial Fraud
- Create vendor + approve payment.
- Submit expense + approve expense.
- Initiate transfer + approve transfer.
2. Privilege Escalation
- Reset password on privileged OU + ability to log in as that user.
- Modify GPO + GPO applies to Tier 0 systems.
iam:PassRoleto admin role + ability to launch EC2.- Service account impersonation + admin scopes.
3. Data Exfiltration
- Read sensitive data + permission to export or share externally.
- Read encrypted data + access to keys/HSM.
- Create OAuth app + admin consent for tenant-wide scopes.
4. Audit Evasion
- Perform sensitive action + delete or modify audit logs.
- Disable logging + perform action.
5. Backup / DR Abuse
- Read backups + decrypt backups.
- Manage DR replication + initiate restore.
6. Identity Backdoors
- Create user account + assign privileged group.
- Modify federation trust + create tokens.
- Add OAuth app + grant tenant-wide consent.
Real-World Examples
Example 1: Help Desk + Privileged OU
A help desk user has the Reset Password right delegated on an OU. The OU was originally for standard users — but a Domain Admin's account was later moved into it. The help desk now holds a toxic combination: standard delegation + accidental Tier 0 reach.
Example 2: Cloud Engineer with PassRole
A cloud engineer has iam:PassRole on arn:aws:iam::*:role/AdminRole and ec2:RunInstances. Each permission is fine on its own; together they enable launching an EC2 instance with administrative role privileges.
Example 3: Procurement Fraud
An accountant can both create a new vendor and approve invoices under $5,000. Over time, they create a fake vendor and submit small invoices for years.
Example 4: M365 OAuth App Abuse
A user has the Application Administrator role and can also grant admin consent. They register an app with Mail.ReadWrite.All, grant consent, and read every mailbox.
Example 5: Backup Engineer + KMS Access
A backup engineer can read encrypted backups and has access to the KMS keys that decrypt them. Either alone is fine; together they can decrypt customer data.
Example 6: Audit Log Bypass
A privileged user can disable audit logging on a system and perform sensitive actions. Together, they enable invisible activity.
Why Toxic Combinations Are Hard to Find
- Per-entitlement reviews don't see them.
- Effective access often passes through nested groups, ownership, ACLs, and inheritance — invisible to spreadsheets.
- Cloud and SaaS create new permission combinations weekly.
- Many SoD libraries are tied to ERPs (SAP, Oracle) and don't cover cloud, AD, or SaaS.
- Mover events accumulate combinations silently (privilege creep).
Detecting Toxic Combinations
1. Define the Policies
Start from business and security risk:
- What workflows require SoD (procurement, payroll, code deployment, identity changes)?
- What technical combinations enable escalation (PassRole + RunInstances; reset password + reach Tier 0)?
- What data-protection combinations exist (read data + read key; read PII + export)?
Document these as SoD policies.
2. Compute Effective Access
For each identity, compute effective access across:
- Direct grants
- Group memberships (including nested)
- Role assignments
- ACL inheritance
- Cross-system relationships
3. Match Against Policies
For each policy, find identities that hold all parts of the toxic combination.
4. Prioritize
- Privileged identities first.
- High-impact workflows (financial, identity, cloud admin).
- Identities with weak authentication or recent risk signals.
5. Remediate
- Remove one half of the combination.
- Add compensating controls (4-eyes approval, monitoring).
- Move sensitive accounts out of conflicting scopes.
6. Continuously Monitor
Combinations re-emerge after every mover event, new permission grant, or system change. Detection must be continuous.
Best Practices
- Define SoD policies for both business and technical workflows.
- Compute effective access, not just direct grants.
- Cover NHIs and AI agents, not only human users.
- Detect toxic combinations continuously, not just at audit time.
- Tie SoD to mover events so role changes trigger re-checks.
- Use 4-eyes approval and monitoring as compensating controls when separation isn't feasible.
- Review toxic combinations during access certification.
- Map toxic combinations to attack paths — many escalation paths are technically toxic combinations.
- Treat federation, OAuth admin, and AD CS configurations as high-risk combinations.
- Educate business owners on what makes combinations toxic.
Toxic Combination Examples Cheat Sheet
| Domain | Toxic Combination |
|---|---|
| Procurement | Create vendor + approve invoice |
| Payroll | Modify employee + approve payroll |
| Code | Develop + deploy to prod (without review) |
| AD | Reset password + reach Tier 0 OU |
| AD | Modify GPO + GPO applies to DCs |
| AD CS | Enroll right + risky template (ESC1) |
| AWS | iam:PassRole admin + ec2:RunInstances |
| AWS | Read S3 bucket + decrypt KMS key |
| Azure | App Admin + grant tenant-wide consent |
| GCP | Service account impersonation + admin role |
| M365 | OAuth Mail.ReadWrite.All + tenant-wide consent |
| Backup | Read backups + decrypt keys |
| Audit | Perform action + disable/modify logs |
Toxic Combination Checklist
- Are SoD policies defined for sensitive workflows?
- Are technical toxic combinations documented (escalation, data, backup, audit)?
- Is effective access computed for every identity, including via nested groups?
- Are NHIs and AI agents included?
- Are detections continuous, not only at audit time?
- Are remediation paths defined (remove half, or compensate)?
- Are mover events triggering re-evaluation?
- Are findings prioritized by impact?
How Forestall Helps
Forestall computes effective identity access across AD, Entra ID, AWS, GCP, and SaaS, then matches it against toxic-combination policies and known escalation patterns:
- Surfaces identities holding dangerous combinations of permissions and roles.
- Maps technical combinations that translate into attack paths to Tier 0.
- Flags new toxic combinations introduced by mover events or configuration changes.
- Prioritizes remediation by exploitability and impact.
- Tracks SoD posture trends over time.
This turns toxic combinations from a quarterly spreadsheet exercise into a continuously enforced control.
Frequently Asked Questions
Is "toxic combination" the same as "SoD violation"?
In practice, yes — they describe the same risk. SoD is the framework; toxic combinations are the violations.
Why isn't this caught by regular access reviews?
Reviews typically look at one entitlement at a time. Toxic combinations require evaluating multiple entitlements together, often across systems.
Do toxic combinations apply to NHIs?
Absolutely. Service accounts and AI agents often hold combinations of permissions that no human should ever hold.
How are toxic combinations related to attack paths?
Many attack paths are technical toxic combinations (e.g., PassRole + RunInstances). Path analysis surfaces them automatically.
Can SoD be enforced automatically?
Some preventive controls (request-time SoD checks in IGA, IaC policy gates) prevent new toxic combinations. Detective controls catch existing ones.
Conclusion
Toxic combinations are where individually-reasonable access decisions collide to create unreasonable risk. They are also where most fraud, privilege escalation, and data exfiltration ultimately live. Detecting them requires more than per-entitlement reviews — it requires effective access analysis across systems, defined SoD policies for both business and technical workflows, and continuous monitoring across human and non-human identities.
Treat toxic combinations as first-class identity risks, not as audit-time afterthoughts. Every one you remove is a class of incident your environment can no longer experience.
Find toxic combinations before attackers chain them.
Forestall surfaces dangerous combinations of permissions, roles, and paths across human and non-human identities.