If your identity governance and administration (IGA) platform is compromised: contain, reconcile access and restore trust

An attacker who controls your identity governance and administration (IGA) platform can create accounts, grant entitlements and approve their own access through a channel every connected system is configured to trust. The platform writes to directories, cloud tenants, databases and business applications through connector service accounts, holds a full map of who can access what, and produces the certification evidence auditors rely on. A compromise therefore has three parts: stolen connector credentials, access granted in target systems, and governance records you can no longer trust. This guide is a vendor-neutral response playbook for that scenario: how it shows up, triage, containment without breaking joiners and leavers, reconciling target systems, rotating connector credentials, restoring workflows and certifications, evidence and notification. It is for identity incident responders, IGA engineers and audit leads, and assumes the controls in Securing the identity governance and administration (IGA) platform itself.

Key takeaways

• Target systems are the source of truth during the incident. The platform's own records, approvals and audit trail may have been altered, so reconcile against what each target system actually holds and its own logs.
• Pause provisioning, not leavers. Stopping connectors halts attacker changes but also halts deprovisioning; set up a manual, out-of-platform leaver process before you freeze.
• Connector credentials are tier 0 secrets. Rotate every connector service account and API client in the target system itself, starting with those that can change privileged groups or reset passwords.
• Look for logic, not just accounts. A modified birthright rule, approval workflow or HR attribute mapping will keep granting access after you delete the attacker's accounts.
• Governance evidence needs re-establishing. Certifications and SoD results from the compromise window cannot be relied on; rerun the high-risk ones and tell your auditors.

What an IGA compromise looks like

The IGA platform performs T1098 Account Manipulation and T1136 Create Account as its normal job, so attacker activity blends into provisioning traffic. The response depth depends on which part was reached.

The provisioning channel is a proven attack path. In the Storm-0501 hybrid cloud attacks, Microsoft reported that the actor extracted plaintext credentials for directory synchronisation accounts from sync servers and used the cloud sync account, which at that time could set or change passwords of any hybrid account. An IGA connector agent holding target credentials is the same class of asset.

Triggers and triage

Invoke this playbook for: an IGA administrator sign-in from an unknown device or network; an admin role granted outside the process; a workflow, rule or connector configuration changed without a change record; a connector service account used from a host other than its agent; a burst of joiners, role grants or privileged group additions; certification campaigns closed or decisions changed unusually; audit logging disabled; or a target system owner reporting accounts or group memberships nobody requested.

1. Preserve evidence: export the platform audit log, request and approval history, provisioning transaction log and connector logs, plus admin sign-in logs from your identity provider, before changing anything.
2. Snapshot the current state: export roles, workflows, rules, connector definitions, admin role membership and API clients as found.
3. Identify the actor's capability: which admin role, connector or API client was used, and which targets and operations it could reach.
4. Set the window: earliest possible access to latest observed activity, extended to the last known-good configuration export.
5. Classify: critical if a connector with rights over privileged groups, password resets or a directory was involved, or if custom logic changed; high if an admin role was used without connector compromise.

Containment without breaking the joiner-mover-leaver process

1. Move responders out of band and confirm a break-glass path into the platform and into the main directory that does not depend on the platform.
2. Stand up a manual leaver process: HR notifies a named team who disable accounts directly in the directory and critical applications while connectors are paused. Leavers are the one flow you cannot stop. See the Joiner-Mover-Leaver Guide.
3. Restrict platform administration to named responders, remove attacker-created admins and API clients, and revoke their sessions.
4. Pause write connectors for targets in scope, starting with directories, cloud tenants and privileged access tools. Aggregation (read) can continue if the read account is separate and uncompromised, because it gives you the current state of targets.
5. Disable connector credentials at the target: for any connector whose credential may be exposed, disable the service account or API client in the target system, not just in the platform. This stops direct use from attacker infrastructure.
6. Isolate agent hosts suspected of compromise and treat every credential they stored as exposed.
7. Freeze the source feed for automated joiners if HR or contractor data may have been tampered with; process urgent joiners manually with verification.

Reconciling target systems

Reconciliation is the core of the response: find every account, group membership and entitlement in target systems that was created or changed in the window and cannot be traced to a legitimate request. Use target-side evidence, because the platform's own request records may be forged.

• Diff snapshots: compare the latest aggregation against the last trusted aggregation before the window. Every added account or entitlement needs a matching legitimate request, approver and business reason, confirmed outside the platform.
• Remove, then investigate: disable unexplained privileged access immediately; for low-risk entitlements, ask the owner and remove if not confirmed within a set time.
• Check removals as well as grants: attackers may also revoke access to slow responders (T1531 Account Access Removal) or delete leaver records so accounts stay active.
• Follow granted access downstream: any account the attacker received through provisioning becomes its own investigation in the target system. See the Identity Incident Response Playbook.

Rotating connector and platform credentials

Use the rotation to fix the scoping problem that made the compromise worse: one account per connector and environment, least privilege per operation, and federated or certificate authentication where the target supports it. See the Service Account Security Guide.

Restoring governance integrity

1. Diff and revert logic: compare every workflow, rule, script, role definition, birthright policy and SoD policy against version control or the last trusted export. Revert unexplained changes, and have a second engineer review the reverted state.
2. Rebuild or restore: if the application host or database was reached with code execution, rebuild the platform on clean infrastructure and import configuration from the verified export, not from a backup taken in the window (CSF 2.0 RC.RP-03 asks that restoration assets are verified before use).
3. Re-verify identity data: check joiners, terminations and attribute changes in the window against the HR system directly. See the Identity Data Quality and Authoritative Sources Guide.
4. Rerun certifications: run targeted certifications for privileged access and for every target in scope, with reviewers confirming outside the platform for the most sensitive grants. See the Access Reviews Guide.
5. Re-evaluate SoD: reopen SoD exceptions approved in the window and rerun detection. See the Segregation of Duties Guide.
6. Re-enable connectors in stages: read first, then low-risk targets, then directories and privileged targets, watching each for unexpected changes.

Evidence and notification

• Preserve: platform audit and transaction logs, configuration as found, connector logs, agent host images, target-side logs for every connector identity, and identity provider sign-in logs for administrators.
• Personal data: IGA platforms hold HR attributes for every worker; bulk export or API extraction is a likely personal data breach for legal to assess. See the Cyber Incident Reporting Requirements Map.
• Auditors: tell internal and external audit which access reviews, approvals and SoD results fall inside the window, because they may have been relied on as control evidence.
• Target owners: notify application owners in scope with the list of changes to verify.

Scaling the response to your estate

In both cases, the decision to rebuild should be driven by what the attacker could execute, not by convenience. An attacker who could run custom scripts inside workflows effectively had code execution in the platform, even without touching the operating system, because those scripts usually run with the connector credentials. Treat a modified script or rule as equivalent to host compromise for the targets that logic could reach.

Detection and measurement

Keep these at high priority for 90 days after recovery: admin role changes in the platform, workflow and rule changes outside change windows, connector identities used from hosts other than their agents, privileged group additions by connectors without a matching approved request, volume spikes in joiners or grants, and certification decisions changed after closure.

• Target accounts and entitlements reconciled as a percentage of those changed in the window.
• Connector credentials rotated and verified at the target, by priority group.
• Leavers processed within policy time during the freeze.
• Connectors with rights reduced to the scoped minimum before re-enablement.
• Privileged grants with a request matched in an independent record, which should reach 100%.

Common failure patterns

• Trusting the platform's own history: request and approval records are what the attacker could edit; use target-side logs.
• Freezing everything: leavers keep their access for days, creating a second incident.
• Rotating in the platform only: the old connector password still works in the directory, from anywhere.
• Missing the rule change: attacker accounts are deleted but a modified birthright rule recreates the access at the next joiner.
• Over-privileged connectors kept "to be safe": re-enabling a domain-admin connector restores the blast radius. The sync account abuse in Storm-0501 shows what one such identity can do.

Framework mapping

Practitioner checklist

• Document a manual leaver process that works with the IGA platform switched off.
• Export platform configuration to version control on every change.
• NHI Mgmt Group recommends keeping aggregation snapshots for at least 12 months so you can diff target state.
• Send platform audit, connector logs and target-side logs for connector identities to a SIEM the IGA team cannot change.
• Keep a register of connectors with their target rights, credential type and rotation method.
• Alert on connector identities used from anywhere other than their agent hosts.
• Agree with audit in advance how certification evidence is re-established after an incident.
• Exercise this playbook with a tabletop that includes a modified approval workflow.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• IETF: RFC 7644, System for Cross-domain Identity Management: Protocol
• NCSC: Secure system administration, risk manage administration using tiers
• MITRE ATT&CK: Account Manipulation
• Microsoft Threat Intelligence: Storm-0501 ransomware attacks expanding to hybrid cloud environments

Related NHI Mgmt Group resources: Securing the identity governance and administration (IGA) platform itself · IAM and IGA Basics · Identity Provider Tenant Compromise Playbook · SCIM Provisioning Guide · If your secrets manager is compromised