Okta identity provider change

An Okta inbound identity provider was created, activated, deactivated or deleted (system.idp.lifecycle.*).

Adding an IdP is a federation backdoor: authentication is delegated to a directory the attacker controls, so they can sign in as any user whose account maps to it without ever knowing a password or satisfying the tenant's MFA. It is the cloud-native equivalent of adding a trusted domain, it looks like ordinary SSO administration, and it persists through every credential reset.

Deactivation and deletion are included because removing a legitimate IdP is how an attacker forces users onto an authentication path they do control, and because destroying the record is a way to cover the addition.

• T1556Modify Authentication Process· Persistence
• T1484.002Domain or Tenant Policy Modification: Trust Modification· Privilege Escalation

Tenants configuring SSO, migrating between directories, or piloting social login do this legitimately, and the work usually arrives as a burst of create/activate events from an identity administrator inside a project. The signal is a single IdP appearing with no project behind it, one pointing at a domain the organisation does not own, or a change made by an account that does not normally administer federation. Read the IdP's issuer and its username-mapping template before judging.

Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/okta_identity_provider_change.yaml, licensed under the Apache License 2.0.

id: cloud.okta.identity_provider_change
version: 1.0.0
status: stable
severity: high
confidence: 0.7
platforms: [application]
mitre_techniques: [T1556, T1484.002]
description: |
  An Okta inbound identity provider was created, activated, deactivated or deleted
  (`system.idp.lifecycle.*`).

  Adding an IdP is a federation backdoor: authentication is delegated to a directory
  the attacker controls, so they can sign in as any user whose account maps to it
  without ever knowing a password or satisfying the tenant's MFA. It is the
  cloud-native equivalent of adding a trusted domain, it looks like ordinary SSO
  administration, and it persists through every credential reset.

  Deactivation and deletion are included because removing a legitimate IdP is how an
  attacker forces users onto an authentication path they do control, and because
  destroying the record is a way to cover the addition.
match:
  provider: Okta
  event_action_contains_any:
    - system.idp.lifecycle
correlation_keys: [user_name]
false_positive_guidance: |
  Tenants configuring SSO, migrating between directories, or piloting social login do
  this legitimately, and the work usually arrives as a burst of create/activate events
  from an identity administrator inside a project. The signal is a single IdP appearing
  with no project behind it, one pointing at a domain the organisation does not own,
  or a change made by an account that does not normally administer federation. Read
  the IdP's issuer and its username-mapping template before judging.

• Entra sign-in frequency weakenedSeverity critical
• Microsoft 365 domain federation changeSeverity critical
• CA Policy Removed by Non Approved ActorSeverity medium
• CA Policy Updated by Non Approved ActorSeverity medium
• User Added To Group With CA Policy Modification AccessSeverity medium
• User Removed From Group With CA Policy Modification AccessSeverity medium