Orchestrate Identity Incident Containment & Hardening

Outcome

When a compromised identity is confirmed, Oleria enables complete containment — across every application where the identity holds entitlements, including local accounts and group-inherited access that IDP deprovisioning does not reach — with confirmation in the Access Graph and a full audit trail for regulatory reporting. After containment, the posture conditions that contributed to the incident are surfaced as structured Posture Campaign findings that feed directly into the post-incident hardening program.

Most organizations contain incidents at the IDP layer — suspending the account in Okta or Entra ID and assuming that downstream access is revoked. It is not. Local SaaS accounts, group-inherited access, and OAuth grants survive IDP suspension. Oleria finds them, surfaces them, and tracks their revocation to confirmed closure.

The containment gap that persists after IDP suspension: A compromised identity suspended in Okta still holds: their local Salesforce account (authenticated with Salesforce credentials, not Okta SSO), their Snowflake ACCOUNTADMIN role (granted through a local Snowflake account created for a project two years ago), and an OAuth grant to a third-party analytics tool that has read access to their Google Drive. None of these is revoked by IDP suspension. Oleria surfaces all three and tracks their revocation.

‍

Why this is hard without Oleria

Containment and hardening after an identity incident face five structural gaps:

· IDP suspension does not reach applications with local accounts. Accounts that authenticate to SaaS applications with local credentials — not through IDP SSO — remain active when the IDP account is suspended. These accounts are often the ones created for break-glass access, legacy integrations, or convenience — and they are precisely the accounts that are hardest to find under incident pressure.

· Group-inherited access persists after direct permissions are removed. Revoking a direct role assignment does not remove access the identity holds through group membership. A user removed from the Salesforce System Administrator profile may retain equivalent access through a permission set group they belong to. Without a complete entitlement view, containment misses these inherited paths.

· OAuth grants survive account deactivation. OAuth grants made by the compromised identity — including grants using local credentials rather than IDP-federated accounts — may retain valid tokens after the IDP account is deactivated. The third-party application continues to hold access to the identity's data through the grant until it is explicitly revoked.

· Containment completion is never confirmed. Even when revocation actions are taken across multiple systems, there is no native mechanism to confirm that all access has been removed and none was missed. Without confirmation, containment is assumed complete but is rarely verified.

· Post-incident hardening has no structured starting point. After an incident is contained, the list of posture conditions that contributed — the dormant account, the local credential, the MFA gap, the over-privileged role — is assembled manually from post-mortem notes. It is rarely turned into tracked, time-bound remediation actions. The same conditions recur in the next incident.

What Oleria delivers

Complete Containment

· Full revocation scope across all connected systems. Oleria surfaces every application where the compromised identity holds entitlements — directly and through inherited group memberships and local accounts. Containment actions can be targeted at the complete scope, not the IDP-visible subset. Local accounts, group-inherited access, and OAuth grants are all in the revocation scope.

· Containment confirmation in the Access Graph. After revocation actions are taken, Oleria re-evaluates the Access Graph to confirm that the identity's entitlements have been removed across all systems. Any access that persists after the intended containment action — a local account not reached, a group membership not removed — is surfaced as an open containment gap and tracked to resolution.

· OAuth grant revocation as part of containment. Active OAuth grants held by the compromised identity are surfaced in the containment scope view — including grants made with local SaaS credentials that survive IDP suspension. Revocation can be initiated from Oleria through Microsoft Graph and Google token revocation APIs.

· Audit trail for regulatory reporting. Every containment action — which access was revoked, in which system, when, by which analyst — is recorded in the Oleria audit trail. The complete containment record is exportable as structured evidence for regulatory notification requirements and post-incident reviews.

Post-Incident Hardening

· Posture findings as structured hardening input. After containment, Oleria generates a structured view of the posture conditions that contributed to the incident: dormant account not detected, no MFA on a privileged role, local credential bypassing IDP enforcement, OAuth grant on a departing employee's account, over-privileged role with no active use. These are surfaced as typed Posture Campaign findings — not a post-mortem action list — with assigned owners, severity tiers, and due dates.

· Systemic pattern detection across the environment. The conditions that existed on the compromised identity may exist on other identities. Oleria queries the Access Graph for other accounts that share the same risk conditions — the same local credential pattern, the same dormancy profile, the same missing MFA — turning a single incident into a broad posture improvement program.

· Continuous monitoring prevents recurrence. After the hardening campaign is complete, Oleria monitors for recurrence of the same conditions. If a privileged account is provisioned without MFA, if a local credential is created bypassing IDP, or if an OAuth grant with broad scopes is issued by a departing employee — a posture finding is generated within hours, before the condition becomes the entry point for the next incident.

How it works

Stage -1 -Entitlement Blueprint Assembly: Oleria's read-only connectors maintain the Access Graph continuously. The complete entitlement footprint — including local accounts and OAuth grants — is already assembled when the incident is declared. No additional data collection is needed to generate the containment scope.

Stage- 2- Multi-System Revocation Query :The analyst queries the implicated identity's full access footprint, confirms the blast radius, and requests the revocation scope — all connected systems, all entitlements, including local accounts and OAuth grants. Oleria surfaces the complete containment action list with the specific revocation step for each system and account type.

Stage - 3- Graph Boundary Verification: The containment scope view shows each entitlement with: the application, the account type (SSO or local), the specific role or permission, the recommended revocation action (IDP suspension, direct application deprovisioning, OAuth token revocation), and the current status (pending, actioned, confirmed). After actions are taken, the Access Graph re-evaluates and confirms closure or surfaces remaining gaps.

Stage -4- Hardening Pattern Deployment: Post-containment: Oleria generates the post-incident posture finding set — the conditions that contributed to the incident, as structured Posture Campaign findings with assigned owners and due dates. The hardening program starts immediately from a tracked, evidence-based finding list. Systemic pattern queries identify other identities with the same risk conditions, expanding the program scope beyond the single compromised account.

What good looks like

▸ Containment completeness: IDP suspension only — local accounts missed, group-inherited access persists, OAuth grants survive — → confirmed complete across all connected systems, with Access Graph verification and audit trail entry per revocation action.

▸ Time to confirmed containment: Unknown (no confirmation mechanism exists) → confirmed in the Access Graph within the same response cycle, with open containment gaps surfaced and tracked to resolution.

▸ Post-incident hardening start: Manual post-mortem action list assembled days later, infrequently followed through → structured Posture Campaign findings generated immediately after containment, with owners, SLAs, and tracking in Oleria.

▸ Recurrence prevention: Same conditions recur in the next incident because hardening was incomplete → continuous monitoring detects recurrence of contributing conditions within hours of reoccurrence, before they become the next breach entry point.

Frequently Asked Questions

Why doesn't suspending an account in Okta or Entra ID fully contain the incident?

IDP suspension deactivates the account in the IDP and revokes access to applications that authenticate exclusively through that IDP via SSO. It does not revoke local SaaS accounts created outside the IDP provisioning workflow, access inherited through group memberships that are not directly linked to the IDP account status, or OAuth grants made using local credentials. In environments with significant local account populations — which is most enterprise environments — IDP suspension is partial containment, not complete containment.

How does Oleria confirm that containment is complete?

After revocation actions are taken, Oleria re-evaluates the Access Graph for the compromised identity. The graph reflects the current state of access across all connected systems — if any entitlement persists after the intended revocation, it appears in the graph as an open containment gap. Analysts receive a confirmation view: revocations confirmed in the graph are marked closed; persistent access is flagged for immediate follow-up. This confirmation does not exist without a continuously maintained, cross-system access model.

How does Oleria handle OAuth grant revocation as part of containment?

Oleria surfaces all active OAuth grants associated with the compromised identity — including grants made with local SaaS credentials that survive IDP suspension. For Entra ID grants, revocation is initiated through the Microsoft Graph API consent revocation endpoint. For Google Workspace grants, through the Google token revocation API. Each revocation is confirmed in the Access Graph and logged in the audit trail. Grants made with local credentials that are not tied to the IDP account require direct application-level revocation, which Oleria surfaces with the specific action needed.

What does the post-incident hardening program look like when driven from Oleria?

After containment, Oleria generates a Posture Campaign containing the specific conditions that contributed to the incident — dormancy, missing MFA, local credential bypassing IDP, over-privileged role, stale OAuth grant. Each finding has an assigned owner, severity tier, and due date. The campaign also includes a systemic query result: other identities in the environment that share the same conditions. Hardening is not a post-mortem action list — it is a tracked, time-bound remediation program that starts immediately after containment.

How does Oleria prevent the same conditions from recurring after hardening?

Continuous posture monitoring re-evaluates the conditions identified in the hardening campaign on an ongoing basis. If a new privileged account is provisioned without MFA, a local credential is created bypassing the IDP, or an OAuth grant with broad scopes is issued by a departing employee, a posture finding is generated within hours. Recurrence of the specific contributing conditions is detected before it becomes the entry point for the next incident — closing the loop between incident response and continuous identity security posture.

Contain the breach faster and close the gap permanently so the same identity weakness never triggers another incident