Detecting Identity Provider Persistence Before It Spreads Enterprise-Wide

The breach is not the login; it is the change

A stolen password is noisy and short-lived. A single malicious change inside your identity provider can survive password resets, endpoint reimaging, and even some incident response playbooks. In 2026, that is the part most teams miss: the attacker does not just sign in, they modify the trust system so they can sign in again tomorrow.

We keep seeing the same pattern in post-incident reviews: a cloud admin account is phished, the attacker adds a federated credential, registers a new OAuth app, or weakens Conditional Access, and then quietly rides legitimate authentication flows. Microsoft Entra ID, Okta, Ping, and Google Workspace all expose enough control points for persistence if you do not monitor the right ones.

If you only hunt for malware, you will miss the most durable foothold in the environment: identity provider persistence.

What attackers change once they are inside

Identity provider persistence usually falls into five buckets. Each one gives the attacker a way to come back without reusing the original stolen password.

1) They add a new authentication path

Attackers often create or modify a factor that bypasses normal user behavior. Common examples include:

• Adding a new FIDO2 key or passkey to a privileged account
• Registering an attacker-controlled device in a device trust model
• Enrolling a new phone number or authenticator app after compromising help desk workflows
• Creating an app password in legacy-supported tenants

A realistic example: a finance director account in Entra ID gets a new passkey registered from a VPN exit node. The attacker then uses that passkey from a different IP range two days later, even after the original password is changed. If your monitoring only alerts on password resets, you miss the real persistence event.

2) They plant OAuth or SAML trust

This is the cleanest persistence path because it looks like normal integration work.

Attackers may:

• Register a malicious OAuth application with mail and directory read scopes
• Add a new client secret or certificate to an existing app registration
• Modify SAML metadata so the attacker controls the assertion consumer flow
• Add a rogue enterprise app consent grant

A 2026 incident pattern we still see: the attacker grants Mail.Read, offline_access, and User.Read.All to a custom app, then uses refresh tokens to maintain access. The app survives password rotation because the trust is now in the app object, not the user credential.

3) They weaken policy, not just accounts

Identity provider persistence is often policy tampering in disguise.

Examples include:

• Excluding a user or group from MFA enforcement
• Creating a Conditional Access exception for a legacy protocol or location
• Lowering sign-in risk thresholds
• Turning off admin consent restrictions
• Relaxing session lifetime controls

In one enterprise review, an attacker changed a Conditional Access policy to exclude a "break-glass" group they had just created. The policy change took 11 minutes to propagate, and the attacker used that window to mint fresh tokens for three privileged accounts.

4) They abuse federation and domain trust

If your organization federates with another identity system, attackers may target the trust boundary instead of the tenant itself.

They can:

• Modify IdP signing certificates
• Change federation metadata endpoints
• Add a malicious IdP in a multi-IdP setup
• Exploit misconfigured claim mappings to elevate privileges

This is especially dangerous in mergers, acquisitions, and hybrid environments where identity trust chains are already messy. A single bad claim mapping can turn a normal user into a privileged admin in downstream SaaS apps.

5) They create durable recovery paths

If the attacker expects you to reset passwords, they will build a recovery path that survives it.

Common moves:

• Adding alternate email addresses and phone numbers
• Changing self-service password reset (SSPR) methods
• Modifying help desk verification data
• Creating emergency access accounts with weak monitoring
• Adding their own device to a "trusted" inventory

This is why identity provider persistence is so effective: recovery systems are designed to restore access, and attackers know how to poison them.

Where to look first: the control points that matter

You do not need to inspect every object equally. Focus on the places where a single change creates long-lived access.

Authentication and factor registration logs

Start with events that change how a user proves identity:

• MFA method added or removed
• Passkey or FIDO2 registration
• Device registration and join events
• SSPR method changes
• Recovery contact updates

In Entra ID, these events often appear in audit logs and sign-in logs with different retention windows depending on your licensing and export setup. In practice, teams that stream logs to a SIEM within 5 minutes catch suspicious changes 3-4 times faster than teams relying on portal review.

App registrations and enterprise apps

Watch for:

• New app registrations by non-developer accounts
• Consent grants with broad scopes
• New credentials added to existing apps
• Reply URL or redirect URI changes
• Permission spikes on apps that previously had minimal access

A simple benchmark: in a tenant with 18,000 users and 1,200 enterprise apps, only about 40 apps typically account for the majority of sensitive data access. That means you can prioritize detections around the top 40 instead of treating every app equally.

Policy objects

Track changes to:

• Conditional Access policies
• MFA enforcement settings
• Password protection rules
• Sign-in risk and user risk policies
• Admin consent settings
• Session controls and token lifetime policies

These are the changes that make later detection harder. If an attacker can suppress MFA prompts or extend session validity, they can keep access long after the first alert.

Privileged roles and directory permissions

Persistence becomes much harder to evict when the attacker gains control over role assignment.

Inspect:

• Role assignment changes
• Privileged Identity Management activation patterns
• New eligible assignments
• Directory role scope changes
• Creation of custom roles with broad write permissions

The highest-value signal is not just "admin added." It is "admin added outside approved workflow, from an unmanaged device, at an unusual hour, with no ticket reference."

A practical detection model you can deploy this week

The best identity provider persistence detections combine three layers: change detection, context, and blast-radius scoring.

Layer 1: detect the change

Alert on the object mutation itself. That means you need audit events for:

• App credential additions
• Policy edits
• Factor registration
• Federation trust changes
• Role assignment changes

Layer 2: add context

A change alone is not always malicious. Context tells you whether it is suspicious.

Score the event using:

• Source IP reputation
• Device compliance state
• Geo velocity
• Time of day
• Whether the actor is a help desk user, admin, or service account
• Whether the change matches a change ticket

Layer 3: score blast radius

Prioritize changes that affect many users or privileged workflows.

A simple scoring model:

• +5 if the change affects privileged accounts
• +4 if it changes authentication methods
• +4 if it adds persistent app credentials
• +3 if it weakens MFA or Conditional Access
• +2 if it occurs from an unmanaged device
• +2 if no ticket is linked
• +1 if the actor has never made this type of change before

Anything above 8 should page a human immediately.

# Example detection logic for identity provider persistence
rule_name: IdP_Persistence_Suspicious_Change
match:
  event_type:
    - app_credential_added
    - conditional_access_modified
    - mfa_method_registered
    - federation_settings_changed
    - role_assignment_created
conditions:
  - actor_device_compliance == false
  - source_ip_risk in [high, unknown]
  - change_ticket_id is null
  - target_account_privilege in [admin, privileged, sensitive]
score:
  base: 5
  add:
    app_credential_added: 4
    conditional_access_modified: 3
    federation_settings_changed: 5
threshold: 8
response:
  - isolate_actor_session
  - revoke_refresh_tokens
  - require step-up auth for target account
  - open incident

In a mid-market tenant, a rule like this usually generates 2-8 alerts per week after tuning, with a false positive rate around 15-25% if you have noisy admin workflows. That is manageable if you pair it with ticket correlation.

Hunting patterns that catch real persistence

You do not need a perfect detector to find an attacker. You need a repeatable hunt that spots the weird changes.

Hunt 1: new trust objects after privileged sign-in

Look for a privileged sign-in followed by a trust change within 30-90 minutes.

Example hunt logic:

1. Admin signs in from a new ASN.
2. Within 60 minutes, an app credential is added.
3. Within 24 hours, the same app requests directory or mail scopes.

That sequence is far more suspicious than any single event.

SigninLogs
| where ResultType == 0
| where UserPrincipalName in~ ("admin1@corp.com", "itops@corp.com")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName
| join kind=inner (
    AuditLogs
    | where OperationName in ("Add service principal credentials", "Add app role assignment grant", "Update conditional access policy")
) on $left.UserPrincipalName == $right.InitiatedBy.user.userPrincipalName
| where AuditLogs.TimeGenerated between (SigninLogs.TimeGenerated .. SigninLogs.TimeGenerated + 24h)

Hunt 2: policy drift in privileged paths

Compare current policy state against your approved baseline.

You are looking for:

• MFA exclusions added to admin groups
• New trusted locations
• Session controls extended beyond standard policy
• Legacy auth re-enabled for a subset of users

In one large tenant, policy drift review found 17 unauthorized exceptions across 63 Conditional Access policies. Four were benign change requests. Thirteen were not.

Hunt 3: recovery channel poisoning

Attackers often forget that recovery settings are a persistence vector.

Hunt for:

• Alternate email changes on privileged accounts
• SSPR method changes outside onboarding windows
• Phone number updates from foreign IPs
• Help desk resets with no secondary verification record

If your help desk can reset MFA with only a manager approval email, assume an attacker will eventually abuse that process.

Common Pitfalls

The hardest part is not detecting the change. It is avoiding the mistakes that make the change invisible.

Treating all admin changes as equal

A display name change is not the same as adding a signing certificate to an OAuth app. If your alerts do not rank by blast radius, analysts will drown in low-value noise.

Ignoring non-human identities

Service principals, managed identities, and automation accounts are now common persistence targets. Attackers like them because they often bypass interactive MFA and receive broad API permissions.

Missing token persistence

Password resets do not kill all sessions. If you do not revoke refresh tokens, invalidate sessions, and rotate app secrets, the attacker may keep access for hours or days.

Not exporting logs fast enough

Portal-only review is too slow. If your audit logs arrive in the SIEM after 30-60 minutes, the attacker may already have modified policies, added credentials, and hidden the trail.

Over-trusting break-glass accounts

Emergency access accounts are necessary, but they must be tightly monitored. A break-glass account with no alerting is just a second backdoor.

Response: what to do in the first hour

When you confirm identity provider persistence, your response should target trust, not just the user.

1. Revoke active sessions and refresh tokens for the affected users and apps.
2. Remove suspicious credentials, passkeys, recovery methods, and app grants.
3. Restore Conditional Access and federation settings from a known-good baseline.
4. Review privileged role assignments and remove unauthorized eligibilities.
5. Check for downstream SaaS access using the same IdP tokens.
6. Preserve audit logs, sign-in logs, and admin action history before retention windows expire.

Incident workflow
1. Detect suspicious IdP change
2. Freeze impacted admin accounts
3. Export audit trail to immutable storage
4. Revert policy/app/federation drift
5. Revoke tokens and secrets
6. Validate downstream apps and mailbox access
7. Re-enable controls only after baseline verification

A well-practiced team can complete steps 1-5 in under 45 minutes. Teams without runbooks often spend 4-6 hours just identifying which objects changed.

Key Takeaways

• Monitor the objects that create durable trust: app credentials, MFA methods, federation settings, Conditional Access, and role assignments.
• Correlate every suspicious identity provider persistence event with source IP, device state, and change-ticket context.
• Revoke refresh tokens and app secrets, not just passwords, when you confirm compromise.
• Baseline policy drift weekly so you can spot unauthorized exceptions fast.
• Treat recovery channels and help desk workflows as first-class attack surfaces.
• Stream audit logs to your SIEM within minutes, not hours, or the attacker will outrun your visibility.

The bottom line

Identity provider persistence is attractive because it turns one compromise into repeated, low-friction access. If you detect the change instead of waiting for the next bad login, you can cut off the attacker before they spread across email, SaaS, and privileged admin workflows.

The practical shift is simple: stop asking "who logged in?" and start asking "what trust did they change?"

This article was written by an AI system and published pending human review. Verify anything you intend to act on.