How should security teams strengthen identity protection when identity providers and their customers are both being targeted?

Security teams should treat identity protection as a layered control problem, not a single vendor problem. A practical programme combines identity security posture management and identity threat detection and response to find misconfigurations, weak admin access, and unusual login behaviour early. The goal is to reduce blind spots, tighten remediation, and detect identity-centric attacks before stolen credentials become a full breach.

Identity providers and their customers need different, but connected, protections

When identity providers are being targeted, security teams have to protect the control plane and the downstream tenants at the same time. The provider needs hardening around admin access, support workflows, token handling, and monitoring, while customers need stronger detection of abnormal sign-in, consent, federation, and privilege changes. The Ultimate Guide to NHIs is useful here because the same identity hygiene problems often show up across both environments, especially around secrets, lifecycle, and excessive privilege.

That is why layered identity protection is more effective than relying on a single vendor boundary. A team should assume that compromise can begin in the provider, move through trusted integrations, and still end at the customer tenant if monitoring, rotation, and access governance are weak. The lesson from incidents such as the Okta Breach and the Cloudflare Breach is that trust relationships must be treated as attack paths, not comfort blankets.

One useful metric from NHIMG’s research is that only 5.7% of organisations have full visibility into their service accounts. That matters because visibility gaps are exactly where provider-side compromise, stale credentials, and tenant-spanning abuse can hide long enough to matter. If the team cannot inventory identities, tokens, and privileged relationships on both sides, it cannot reliably distinguish routine auth noise from a staged identity attack.

Where the control failures usually happen

Identity provider attacks and customer-side account abuse often share the same failure modes: overprivileged admin roles, weak recovery processes, unrotated tokens, and poor separation between human support actions and machine-enforced controls. When those controls are loose, attackers can pivot from a single account or credential into broad access, especially where federation and delegated administration are in play. The problem is not just theft of a password, it is abuse of trust that was never bounded tightly enough.

Teams should pay special attention to what they can still observe after an authentication event succeeds. Unusual consent grants, changes to MFA state, helpdesk-driven resets, new application registrations, and token reuse are all signs that the attack has moved beyond login and into authority escalation. The best defensive posture is to make each step visible, time-limited, and independently reviewable rather than assuming the identity provider will absorb all of the risk.

Separate provider admin privileges from customer tenant administration wherever possible.
Require strong review for support actions that can reset, bypass, or rebind authentication.
Track token issuance, refresh, consent, and federation changes as first-class security events.
Rotate exposed secrets and revoke stale sessions quickly enough that abuse windows stay small.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OC-01 — Organisational Context	Identity-provider compromise changes organisational trust boundaries and blast radius.
	PR.AA-01 — Identities and Credentials Managed	The answer centres on protecting identities, tokens, admin access, and sessions on both sides.
	DE.CM-08 — Monitoring for Unauthorized Activity	The answer stresses early detection of unusual login and trust-changing behaviour.
Recommendation — Map provider and tenant trust dependencies before setting detection and response priorities. Inventory provider and customer identities, credentials, and privileged relationships continuously. Monitor sign-in, consent, federation, and admin changes for anomalous identity activity.
CIS Controls v8	6.1 — Establish and Maintain an Inventory of Accounts	Dual-sided identity protection depends on knowing which accounts and support roles exist.
	6.3 — Disable Dormant Accounts	Stale identities and inactive support paths enlarge exposure in provider and customer environments.
	8.2 — Collect Audit Logs	The answer depends on observing token, consent, reset, and federation changes.
Recommendation — Maintain current inventories of provider and customer accounts with privileged access. Disable inactive privileged accounts and revoke standing access that is no longer needed. Collect identity events that show resets, token issuance, and privilege changes.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Identity-provider and customer attacks often hinge on tokens, API keys, and exposed secrets.
	NHI-03 — Access Governance and Least Privilege	The answer emphasises reducing admin blast radius and limiting delegated authority.
	NHI-08 — Identity Threat Detection and Response	The answer explicitly calls for early detection of identity-centric attacks and unusual login behaviour.
Recommendation — Protect and rotate credentials that can authenticate to provider or tenant systems. Apply least privilege to provider admins, support roles, and federated access paths. Detect anomalous sign-in, consent, and session behaviour before compromise spreads.

Practitioner Guidance

What to prioritise: Start with the identities that can change other identities, that is, provider administrators, delegated support roles, federation operators, and customer super-admins. Those are the accounts that convert a local compromise into a multi-tenant problem.

What to verify: Confirm that both provider-side and customer-side logs can answer the same questions, who approved the change, what was altered, what token or session was issued, and whether the action was expected. If the answer depends on vendor tickets alone, the control is too weak for an active identity threat environment.

Decision rule: If an identity event can grant new trust, reset assurance, or extend access across tenants, treat it as a high-risk change and require independent validation before it is accepted. If it only affects a single user session, normal step-up checks may be sufficient.

What practitioners underestimate: Provider compromise is not only about the provider being breached, it is about the customer inheriting the blast radius through federated trust. The right model is to assume that a trusted upstream system can become an attack source without warning.

Practitioner takeaway: Strong identity defence here means shrinking the amount of authority any one account, token, or support path can exercise, while making every trust-changing action detectable and reversible.

Risk and Threat Considerations

Identity providers are high-value targets because compromise can scale into many customer environments at once. On the customer side, the risk is not limited to direct account takeover, it also includes privilege escalation, session abuse, and silent abuse of federation or consent pathways that look legitimate until the damage is already spread.

Failure mechanism: Attackers exploit trusted support, federation, token, or admin workflows to move from one compromised identity into broader access, often without needing to break primary authentication again.

Impact: A single control failure can expose multiple tenants, expand blast radius across environments, and delay detection because the activity appears to come from a trusted identity system.