Third-Party and Federated Identity Risk

Every SaaS integration, every OAuth consent screen, every vendor service account, and every federated SSO trust relationship is a door into your environment that someone else holds the key to. This article maps the real architecture of third-party and federated identity risk — the protocols, trust boundaries, and failure modes — and gives engineers, SOC analysts, and SREs a concrete blueprint for treating identity as the primary control plane rather than an afterthought bolted onto the network perimeter.

The shape of the problem: identity as the new perimeter

Ten years ago, the security perimeter was a firewall and a VPN concentrator. Today the perimeter is a graph of trust relationships: federation metadata between your identity provider (IdP) and dozens of service providers (SPs), OAuth 2.0 client registrations granting delegated access to your Microsoft 365 or Google Workspace tenant, SCIM provisioning pipelines pushing identity data to SaaS vendors, and non-human identities — service accounts, API keys, workload identities, CI/CD tokens — that outnumber human identities by a wide margin in any modern cloud estate. The attack surface is no longer a set of IP addresses; it is a set of trust assertions, each with its own expiration, scope, and revocation semantics that are frequently misunderstood by the teams operating them.

Third-party identity risk specifically concerns the identities and trust relationships you do not fully control: a managed service provider (MSP) with standing administrative access to your tenant, a SaaS vendor holding an OAuth refresh token that never expires, a contractor's federated account provisioned through a partner IdP, or a supply-chain dependency whose CI pipeline holds a deployment credential to your production environment. Federated identity risk is the specific subset that concerns the trust fabric itself — SAML assertions, OIDC tokens, WS-Federation trusts — where a compromise of the identity provider or a misconfigured trust relationship can cascade into every downstream relying party simultaneously.

The reason this deserves top billing over network-centric controls is simple: in a cloud-first, SaaS-heavy, API-integrated enterprise, the vast majority of initial access and lateral movement techniques observed in real incidents involve credential theft, token replay, consent phishing, or abuse of legitimate federation trust — not exploitation of unpatched services sitting behind a firewall. MITRE ATT&CK's Valid Accounts (T1078), particularly the Cloud Accounts sub-technique, and Steal or Forge Kerberos Tickets (T1558), Steal Application Access Token (T1528), and Use Alternate Authentication Material (T1550) collectively describe an attack surface that has almost nothing to do with network segmentation and everything to do with how identity is issued, federated, and governed.

This is why identity threat detection and response (ITDR), privileged access management (PAM), and identity governance and administration (IGA) have converged into a single discipline rather than three separate ones. You cannot detect an anomalous federated sign-in without governance data telling you what "normal" access looks like for that identity, and you cannot contain a compromised OAuth grant without a PAM-style just-in-time revocation mechanism wired directly into the detection pipeline. Algomox's identity and PAM approach is built around exactly this convergence, and it is the architectural pattern the rest of this article walks through in detail.

Anatomy of federation trust: SAML, OIDC, and the assertion supply chain

SAML: the assertion is the crown jewel

In a SAML 2.0 federation, the identity provider issues a signed XML assertion after authenticating the user, and the service provider trusts that assertion based on a pre-established metadata exchange — specifically the IdP's signing certificate. This means the entire trust relationship reduces to two things: possession of the private key that signs assertions, and the service provider's willingness to validate the signature, the audience restriction, and the assertion's validity window. Golden SAML attacks — first widely documented in the wake of the SolarWinds campaign, where actors used compromised ADFS token-signing certificates to forge arbitrary SAML assertions for any user, including ones with no on-premises presence at all — exploit exactly this reduction. Once an attacker has the token-signing certificate, network-level controls are irrelevant; they can mint an assertion asserting they are a Global Administrator and no MFA prompt, no conditional access policy, and no log-in anomaly will necessarily fire, because the forged assertion looks identical to a legitimate one at every layer that matters to the relying party.

The operational lesson is that the ADFS or IdP signing key material deserves the same protection tier as a root certificate authority's private key: hardware security module (HSM) backing where possible, strict access logging on the key store, and a rotation cadence that is actually exercised rather than assumed. Detection has to happen at a different layer than the assertion itself — you need to correlate: was there a corresponding interactive authentication event on the IdP for this session? Is the assertion's NotBefore/NotOnOrAfter window unusually long? Does the issuing IdP's certificate thumbprint match the one in your asset inventory, or has it silently rotated? These are exactly the kind of cross-source correlations that a SIEM alone struggles with because they require joining identity provider audit logs, directory service logs, and relying-party sign-in logs on a common timeline — which is precisely the workload an AI-driven detection and correlation layer like XDR detection and response is designed to automate.

OIDC and OAuth 2.0: tokens, scopes, and the consent problem

OpenID Connect layers authentication on top of OAuth 2.0's authorization framework, and the resulting token economy — ID tokens, access tokens, refresh tokens — introduces its own distinct risk surface. The access token is a bearer credential: whoever holds it can use it, with no cryptographic binding to the original requester unless the deployment specifically implements sender-constrained tokens (DPoP or mutual-TLS token binding, both still inconsistently adopted). Refresh tokens are worse from a risk standpoint because they are long-lived by design, and in many real-world tenant configurations they simply do not expire, or expire only after many months of inactivity. An attacker who exfiltrates a refresh token through a compromised device, a malicious browser extension, or a phished OAuth consent flow can maintain persistent, silent access to a user's mailbox, files, and calendar without ever needing the user's password again, and often without triggering a single MFA challenge, because the refresh token grant is designed specifically to avoid re-prompting the user.

Consent phishing weaponizes this directly. Instead of harvesting a password, the attacker registers a malicious multi-tenant application in a cloud directory, gives it an innocuous name and icon, requests broad delegated scopes (Mail.Read, Files.ReadWrite.All, offline_access), and sends the victim a legitimate-looking consent link. If the victim clicks "Accept," the attacker's application receives a valid OAuth grant — no credentials were stolen, no malware was installed, and the access persists until the grant is explicitly revoked. This technique bypasses MFA entirely because MFA protects the authentication step, not the authorization grant. Illicit consent grant attacks have been observed at scale against Microsoft 365 and Google Workspace tenants precisely because most organizations have never inventoried, let alone reviewed, the third-party applications with standing OAuth grants against their tenant.

The defensive posture here has three concrete layers. First, restrict user consent: disable end-user consent for anything beyond a low-risk permission tier and route all other app registration requests through an admin consent workflow. Second, run a continuous inventory of every OAuth grant issued against every tenant — this is a governance function, not a one-time audit, because new grants appear daily from legitimate SaaS integrations as well as malicious ones. Third, treat scope creep as a first-class detection signal: an application that was granted Mail.Read six months ago and suddenly exercises Mail.Send, or a service principal that authenticates from a new ASN it has never used before, should generate an alert with the same priority as an anomalous human sign-in.

WS-Federation and legacy trust: the long tail

Many enterprises still run WS-Federation or WS-Trust alongside modern SAML/OIDC because a legacy line-of-business application was never migrated. These protocols carry the same fundamental risk — a signed token asserting identity claims that a relying party trusts based on metadata — but with weaker tooling for monitoring, rotation, and revocation. Any third-party identity risk assessment has to explicitly inventory these legacy trusts rather than assuming that "we migrated to Entra ID" or "we're on Okta now" means the old trust relationships were decommissioned. In practice, dormant WS-Federation trusts left active on a relying party are a recurring finding in incident response engagements: nobody remembered they existed, so nobody rotated the certificate or reviewed which claims the application accepted.

The non-human identity explosion

In most cloud estates, non-human identities — service accounts, managed identities, workload identities, API keys, CI/CD deployment credentials, and increasingly autonomous AI agent identities — already outnumber human identities by a ratio commonly cited between 10:1 and 50:1, and that ratio is climbing as organizations adopt microservices, serverless functions, and agentic automation. This matters because the governance and detection tooling most organizations have invested in was built around human identity lifecycle events: hire, transfer, terminate, review access quarterly. Non-human identities have no HR feed to trigger deprovisioning, no natural manager to attest to their continued need, and frequently no owner at all by the time anyone goes looking six months after the engineer who created them has left the company.

The risk profile of a non-human identity is often worse than a human one for three structural reasons. First, non-human credentials are commonly long-lived or static — an API key embedded in a configuration file or a service account password set to "never expire" — because rotating them without breaking a dependent system requires coordination that nobody wants to schedule. Second, non-human identities are frequently over-privileged by default: a CI/CD pipeline given a broadly scoped deployment credential because scoping it precisely was more engineering effort than the deadline allowed, or a service account granted domain admin because it was the fastest way to get an integration working during a migration project. Third, non-human identity compromise is much harder to detect behaviorally, because "normal" behavior for a service account can look exactly like exfiltration — large, regular, automated data transfers are the account's job description.

A rigorous non-human identity security program needs a few concrete mechanisms in place, not just policy language:

• Full inventory with ownership binding. Every service account, API key, and workload identity must have a named human or team owner recorded in the governance system, with an automated escalation if the owner leaves the organization.
• Credential rotation automation. Static long-lived secrets should be the exception requiring documented justification, not the default; secrets managers (Vault-style, cloud-native KMS-integrated) should issue short-lived, automatically rotated credentials wherever the downstream system supports it.
• Workload identity federation over static keys. Where the cloud platform supports it (AWS IAM Roles for Service Accounts, Azure Workload Identity Federation, GCP Workload Identity), federate the workload's identity through its runtime attestation (Kubernetes service account token, CI/CD OIDC token) rather than embedding a static key at all — this eliminates an entire class of leaked-secret incidents because there is no long-lived secret to leak.
• Behavioral baselining per identity, not per identity class. A service account's baseline is its own historical pattern of source IP ranges, destination APIs, and call volume — not a generic "service accounts are noisy, ignore them" rule that blinds detection to the one account behaving abnormally against its own history.
• Least-privilege scoping reviewed on a cycle, not once. Entitlement creep on non-human identities is just as real as on human ones; a quarterly access review cycle for high-privilege service accounts catches scope that was granted for a since-completed project and never revoked.

Third-party and vendor access: MSPs, SaaS integrations, and the supply chain

Third-party vendor access is a distinct risk category from federated protocol risk because the trust relationship is often contractual and operational rather than purely technical: an MSP with standing remote-management-tool access, a managed detection and response (MDR) provider with a service account inside your SIEM, a SaaS vendor's support engineer with a break-glass account into your tenant for troubleshooting, or a contractor onboarded through a partner organization's identity system rather than your own. Each of these relationships was almost certainly established for a legitimate operational reason, and each one is also a standing credential that, if compromised at the vendor's end, becomes a direct path into your environment — a risk category security researchers now routinely describe as identity supply chain risk, echoing the software supply chain concerns that followed high-profile build-pipeline compromises.

The 2021 Kaseya VSA incident and the broader pattern of MSP-targeted ransomware campaigns illustrate the mechanism precisely: attackers do not need to breach every downstream customer individually if they can compromise the single upstream tool or vendor that has standing administrative access to hundreds of customer environments simultaneously. The same logic applies to any SaaS vendor holding an OAuth grant, any RMM (remote monitoring and management) agent installed for support purposes, and any federated partner IdP trust extended for a joint venture or subsidiary relationship.

A structured vendor identity risk program addresses this across four dimensions:

1. Discovery and inventory. Enumerate every third-party identity with access to your environment — OAuth app registrations, external guest accounts in your directory, RMM agents, API integrations with standing credentials, and federated partner trusts. Most organizations discover during this exercise that the actual count is several times larger than what any single system of record shows, because vendor access accumulates through individual project approvals rather than a centralized process.
2. Tiering by blast radius, not by contract value. A low-cost SaaS tool with Mail.ReadWrite.All scope against your entire tenant is a higher-tier risk than an expensive vendor with narrowly scoped, time-boxed access to a single non-production system. Tier vendors by what their access can actually reach and do, not by procurement category.
3. Just-in-time and time-boxed access as the default. Standing vendor access should be the exception. Wherever the relationship allows it, replace always-on credentials with just-in-time elevation — the vendor requests access for a defined window tied to a specific ticket or change request, it is approved, granted, logged, and automatically revoked at expiry. This single pattern, implemented through a modern PAM architecture, closes the majority of the standing-access attack surface without requiring the vendor relationship itself to change.
4. Continuous monitoring of vendor identity behavior. Vendor accounts and service principals should be monitored with the same rigor as privileged human accounts, correlating source IP, time-of-day, and API call patterns against an established baseline, with automated session recording for any interactive privileged access.

This is also where exposure management intersects with identity: a vendor's OAuth grant or standing service account is, functionally, an externally exposed attack path into your environment, and it should be modeled and prioritized the same way you would model an internet-facing vulnerability. Programs built around continuous threat exposure management increasingly treat identity paths — including third-party ones — as first-class exposure items alongside unpatched CVEs, because in practice they are frequently the shorter, more reliable path to the crown-jewel asset.

ITDR architecture: detecting identity compromise in real time

Identity threat detection and response is the discipline of applying detection-and-response rigor — telemetry collection, correlation, alerting, automated containment — specifically to the identity plane, on the premise that credential and token abuse increasingly outpaces what endpoint and network detection can see. A mature ITDR architecture has to ingest and correlate at minimum: identity provider sign-in logs (interactive and non-interactive), directory service audit logs (Active Directory, Entra ID, Okta System Log), OAuth/OIDC token issuance and consent events, PAM session logs, and cloud provider IAM activity logs (CloudTrail, Azure Activity Log, GCP Audit Logs). None of these sources alone tells the whole story; the value is in the join.

Concretely, an ITDR pipeline needs to detect and correlate against patterns such as:

• Impossible travel and improbable access. A sign-in from Frankfurt eight minutes after one from Singapore is the classic example, but the more useful modern version accounts for known VPN egress points, corporate travel patterns, and known device trust to reduce false positives that have plagued this detection since its earliest SIEM implementations.
• Token replay without corresponding authentication. A session token or refresh token used from a new device or IP with no matching interactive sign-in event on the IdP is a strong signal of token theft — this is precisely the detection gap that pass-the-cookie and adversary-in-the-middle (AiTM) phishing kits exploit, since they steal a live session token after a legitimate MFA challenge has already succeeded.
• MFA fatigue and push-bombing patterns. A burst of MFA push notifications to a single user in a short window, especially outside normal working hours, is a leading indicator of an active credential-stuffing or password-spray attempt where the attacker already has a valid password and is trying to force MFA approval through repetition.
• Privilege escalation via group or role membership change. Any addition of an identity — human or non-human — to a highly privileged group, particularly outside of a documented change window or without a corresponding governance ticket, should generate a high-priority alert with automatic context enrichment (who made the change, from where, was it approved).
• Federation configuration changes. Any modification to IdP trust configuration, signing certificate rotation outside the scheduled cadence, or addition of a new relying party trust is a rare event in a stable environment and should be treated as inherently high-signal.
• Anomalous OAuth consent and scope changes. As covered above, new app registrations requesting broad scopes, or existing grants suddenly exercising scopes they have not used historically, warrant automated triage.

The hard engineering problem is not detecting any single one of these signals — most are a straightforward query against a single log source. The hard problem is correlating them across sources in near real time and suppressing the false-positive volume that naive rule-based correlation produces, especially in hybrid environments where the same human identity federates across an on-premises AD, a cloud IdP, and several SaaS SPs, each logging in its own format and time zone convention. This is precisely the workload that benefits from an AI-native correlation layer sitting across the telemetry rather than a fixed rule set per source — the same architectural principle underlying Algomox's AI-native stack, where identity signals are correlated alongside endpoint, network, and cloud telemetry in a single reasoning layer rather than siloed per-tool dashboards that a human analyst has to mentally join.

PAM modernization: from vaults to just-in-time everything

Classic privileged access management — a credential vault that checks out a shared administrative password and rotates it after use — solves the problem of static shared secrets, but it does not solve the problem of standing privilege. If an identity has permanent membership in a privileged group, vaulting the password does not reduce the blast radius of that identity being phished, because the attacker's goal is session access, not necessarily the raw credential. Modern PAM architecture has shifted the center of gravity from credential vaulting to just-in-time (JIT) privilege elevation: identities hold no standing privileged entitlement at all in steady state, and privilege is granted for a defined task, a defined duration, with an approval workflow and full session recording, then automatically revoked.

This shift matters enormously for third-party and non-human identity risk specifically, because it directly addresses the standing-access problem that makes vendor and service account compromise so damaging. A vendor support account that only exists as an active credential for the 45 minutes of an approved troubleshooting session, rather than as a permanently enabled account sitting in the directory, reduces the attack window from "always" to "occasionally, and logged." The same applies to service accounts: a CI/CD pipeline that requests a scoped, short-lived deployment credential through workload identity federation at build time, rather than holding a static key in a secrets file, has no persistent credential for an attacker to steal in the first place.

Building a JIT PAM workflow in practice requires several concrete components working together:

1. Zero standing privilege as the baseline state. Remove permanent membership in privileged groups (Domain Admins, tenant Global Administrators, cloud IAM admin roles) for both human and non-human identities wherever the operational model allows it, replacing it with an eligible-for-elevation state that requires an explicit request.
2. Request and approval workflow tied to a system of record. Elevation requests should reference a ticket, change record, or incident ID, not a free-text justification field that nobody reviews after the fact.
3. Time-boxed grants with automatic expiry. Elevation should default to the shortest duration that accomplishes the task — typically measured in minutes to hours, not days — and expire automatically rather than relying on someone remembering to revoke it.
4. Full session recording and command logging for interactive privileged sessions. This is both a detective control and a deterrent, and it is essential evidence during incident response when reconstructing exactly what a compromised privileged session actually did.
5. Break-glass procedures with heavier scrutiny, not lighter. Emergency access paths are a necessary exception to JIT, but they should trigger the highest-priority alerting and mandatory post-use review, precisely because they are the path most likely to be abused or left improperly secured.

PAM and ITDR have to be wired together, not run as parallel programs, because the value of JIT elevation collapses if the detection layer cannot see and react to elevation events in real time. A compromised identity that successfully requests and receives just-in-time elevation through social engineering of the approval workflow is a scenario that only shows up if the ITDR layer is watching the PAM system's own audit trail with the same scrutiny it applies to sign-in logs. This is the operational argument for treating identity security, IAM, and PAM as a single integrated program rather than separate tools with separate owners and separate dashboards.

Governance and lifecycle: the unglamorous work that prevents the incident

Identity governance and administration is where most third-party and federated identity risk is actually prevented, rather than merely detected after the fact, and it is also the discipline most often under-resourced because its output is an absence of incidents rather than a visible deliverable. A rigorous governance program has to answer, continuously and for every identity human and non-human: who is this, who owns it, what can it access, why does it have that access, and when was that access last validated as still necessary.

The joiner-mover-leaver (JML) lifecycle is the backbone of governance, and federated and third-party identities are disproportionately likely to fall through its cracks because they often do not originate from the authoritative HR source that drives automated provisioning. A contractor provisioned through a partner IdP federation, or a vendor support account created manually by an admin under deadline pressure, frequently has no corresponding leaver trigger — nobody in your organization gets an HR termination event when a vendor's employee who has access to your environment leaves that vendor. This is precisely why periodic recertification cannot be skipped for third-party identities even when it feels redundant for internal ones: it is the only backstop against an out-of-band deprovisioning failure at the vendor's end.

Access certification campaigns — quarterly or more frequent reviews where a manager or resource owner explicitly attests that an identity's access is still required — are the primary mechanism for catching this drift, but they are only effective if the reviewer is given enough context to make a real decision rather than rubber-stamping a list of names. A certification campaign that presents "Contractor X has Contributor role on Subscription Y" without any indication of when that access was last used, what it was granted for, or whether Contractor X's engagement has ended, will produce a 100% approval rate regardless of actual risk. Effective governance tooling enriches each certification item with last-used telemetry, business justification, and peer-group comparison (does this identity's access match the pattern of similar identities in similar roles), turning the review into an actual risk decision rather than a compliance checkbox.

Segregation of duties (SoD) analysis is the other governance mechanism with outsized value for third-party risk specifically, because vendor and integration accounts are frequently granted combined permissions that would never be approved for a single human role — for example, an integration account with both the ability to modify financial records and the ability to approve them, because the SaaS vendor's integration guide asked for the simplest possible permission set rather than the least privileged one. A structured SoD rule set, run continuously rather than as an annual audit exercise, catches this class of finding before it becomes an audit failure or a fraud vector.

Analytics and behavioral baselining: making detection precise instead of noisy

Rule-based identity detection — "alert if sign-in country changes," "alert if a service account calls an API it hasn't called before" — produces a volume of false positives that is well documented as a primary driver of analyst fatigue in SOC operations, and third-party and federated identity signals are especially prone to this because legitimate behavior is genuinely variable: a global consulting firm's contractors do travel internationally, and a legitimate SaaS integration does periodically add new API scopes as the vendor ships new features. The fix is not more rules; it is per-identity behavioral baselining combined with peer-group context, which is fundamentally a data and analytics problem rather than a rule-writing problem.

A workable baselining architecture tracks, per identity, a rolling statistical profile of: authentication source (ASN, geolocation, device fingerprint), time-of-day and day-of-week access pattern, resource access graph (which systems and APIs this identity typically touches), and privilege-elevation frequency and duration. Anomaly scoring then compares a new event against the identity's own history first, and against its peer group (other service accounts performing the same function, other contractors on the same engagement) second, and only escalates to a human analyst when both comparisons indicate genuine deviation. This two-stage comparison is what separates useful anomaly detection from noise: an identity's own history catches drift over time, while peer-group comparison catches cases where an individual identity's baseline has itself been slowly poisoned by an attacker who has had long-term, low-and-slow access.

Risk scoring should also be additive and contextual rather than binary. A single anomalous factor — a new device, say — is common and usually benign (a new laptop, a reinstalled OS). Multiple anomalous factors compounding on a single session — new device, new geolocation, off-hours access, and a subsequent privilege elevation request — is a very different risk profile and should trigger automated containment (step-up authentication challenge, session termination, or SOC escalation) rather than a routine alert queued for next-business-day triage. Building this kind of composite, weighted risk scoring across identity signals is exactly the kind of correlation problem where AI-assisted triage materially outperforms static rule thresholds, because the relevant combinations of weak signals number in the hundreds and shift as attacker tradecraft evolves — the same principle behind AI-driven XDR alert triage applied specifically to the identity domain.

Air-gapped, on-prem, and sovereign environment considerations

Federated identity architecture assumes, by default, connectivity to a cloud IdP and often to a vendor-hosted risk intelligence service, both of which are unavailable or explicitly disallowed in air-gapped and sovereign deployments common in defense, critical infrastructure, and regulated government environments. This does not eliminate third-party identity risk; it changes its shape. On-premises Active Directory Federation Services or a self-hosted SAML IdP still federates trust to internal relying parties, vendor remote-support tools still require some access path even in a segmented network (often through a jump host or a physically mediated transfer process), and non-human identities still proliferate across on-prem service accounts and air-gapped CI/CD systems.

The architectural adaptation required is that detection, governance, and PAM enforcement all need to run fully within the boundary, with no dependency on external cloud services for either the control path or the telemetry path. This means the identity signing keys, the correlation engine, the governance database, and the PAM vault must all be deployable on infrastructure the customer fully controls, with update and threat-intelligence feeds delivered through a one-way or manually mediated transfer mechanism rather than a live API call. Vendor support access into air-gapped environments deserves particular scrutiny: any remote-support tool or vendor account with a path into a sovereign environment is, by definition, the single highest-risk trust relationship in that environment, because it is the one connection point deliberately punched through an otherwise closed boundary, and it should be governed with proportionally higher rigor — time-boxed to the specific support engagement, physically or cryptographically mediated, and fully session-recorded with the recording retained inside the boundary.

Organizations building or evaluating identity security for these environments should treat "does this run fully disconnected, with no phone-home dependency for core detection and governance functions" as a hard requirement rather than a nice-to-have, because a platform that silently degrades or fails closed the moment connectivity to a cloud back end is severed is not actually deployable in the environment it claims to support.

Worked example: reconstructing a federated identity compromise

Consider a realistic incident pattern that ties the preceding sections together. A finance-department employee at a mid-size enterprise receives a well-crafted phishing email impersonating a document-sharing notification from a known vendor. The link leads to an adversary-in-the-middle proxy that sits transparently between the victim and the real IdP login page, relaying the victim's password and MFA approval in real time while capturing the resulting session cookie. The attacker now holds a live, fully authenticated session token — MFA was satisfied by the real user, so no MFA-bypass alert fires.

Using the stolen session, the attacker registers a malicious OAuth application against the tenant and grants it Mail.Read and offline_access scope through the now-authenticated session, then uses the resulting refresh token from a different network location entirely, no longer needing the original stolen session cookie at all. Over the following weeks, the attacker uses the persistent refresh token to monitor the finance employee's mailbox for wire-transfer approval threads, eventually inserting a convincing reply that redirects a legitimate vendor payment to an attacker-controlled account — a business email compromise pattern that required no malware, no password theft in the traditional sense, and no further interactive authentication after the initial token theft.

Reconstructing this after the fact requires exactly the cross-source correlation described earlier in this article: the IdP log shows a normal, MFA-satisfied sign-in from the victim's usual device and location (the phishing proxy relayed it faithfully); the directory audit log shows a new OAuth app registration and grant, timestamped minutes after that sign-in, from an IP address that does not match the victim's normal pattern; and the mail API access log shows a subsequent pattern of read access using the refresh token from yet another IP address, at a frequency and pattern inconsistent with the victim's own mail client behavior. No single log source makes this obvious; the correlation across the app-registration event, the anomalous subsequent API access pattern, and the divergence between the authenticated session's origin and the token's later usage origin is what actually surfaces the compromise, ideally before the fraudulent wire transfer completes rather than during the post-incident forensic review.

The preventive controls that would have interrupted this chain at multiple points are the same ones detailed above: disabling end-user OAuth consent so the malicious app registration requires admin approval; alerting on any new high-scope app registration within minutes of it occurring rather than discovering it in a monthly review; and applying phishing-resistant authentication factors (FIDO2/WebAuthn hardware keys) for finance-department identities specifically, which are immune to the credential-and-MFA relay technique used in the AiTM proxy step because the cryptographic challenge-response is bound to the origin domain and cannot be relayed by a proxy sitting on a look-alike domain.

Metrics that matter: measuring identity risk reduction

Identity security programs are frequently funded on qualitative risk narratives and then never measured against concrete operational metrics, which makes it difficult to demonstrate progress or justify continued investment. A defensible metrics set for a third-party and federated identity risk program should include at minimum:

• Standing privileged access count, trending toward zero. The number of identities (human and non-human) with permanent membership in privileged groups, tracked over time as JIT elevation replaces standing entitlements.
• Mean time to revoke. How long it takes, from detection or decision, to fully revoke an identity's access — including all federated sessions, OAuth grants, and cached tokens, not just the primary directory account, since incomplete revocation is a common finding in incident retrospectives.
• Percentage of third-party identities with a named, current owner. A governance data-quality metric that directly predicts how effective certification campaigns will be.
• OAuth grant inventory completeness and high-risk grant count. The total number of tenant-wide OAuth grants exercising high-risk scopes, trending down as consent restrictions and cleanup campaigns take effect.
• Non-human identities using static long-lived credentials versus federated workload identity. A migration metric tracking progress away from embedded secrets.
• Access certification completion rate and finding-to-revocation ratio. Not just whether certifications were completed on time, but what fraction of certified access items resulted in an actual revocation, which indicates whether reviewers are engaging substantively or rubber-stamping.
• Dwell time for identity-based detections. The gap between an anomalous identity event occurring and it being triaged, correlated, and acted upon — the metric that most directly reflects ITDR program maturity.

These metrics should be reviewed at the same cadence and with the same executive visibility as vulnerability management metrics, because identity risk reduction is at least as material to overall enterprise risk posture as patch compliance, and in most current threat landscapes considerably more material to actual breach likelihood.

Building the program: a phased implementation approach

Organizations starting from a low baseline — no formal ITDR capability, PAM limited to a credential vault, governance run as an annual spreadsheet exercise — should not attempt to implement every control described in this article simultaneously. A phased approach that delivers measurable risk reduction at each stage looks roughly like this in practice.

The first phase is discovery: build a genuine, continuously updated inventory of every identity type covered in this article — federated trusts, OAuth grants, non-human identities, third-party vendor accounts — because every subsequent control depends on knowing what exists. Most organizations underestimate this phase's difficulty; the inventory rarely matches what any single system of record claims, and reconciling directory data, cloud IAM data, and vendor-reported access lists typically surfaces significant discrepancies on the first pass.

The second phase is governance foundation: bind ownership to every identity discovered in phase one, establish the joiner-mover-leaver triggers (including the manual out-of-band process needed for third-party identities that do not flow from an HR feed), and run the first access certification campaign, even a rough one, to establish a baseline of how much unnecessary access currently exists.

The third phase is enforcement modernization: begin the migration from standing privilege to just-in-time elevation, starting with the highest-blast-radius identities (tenant global administrators, domain admins, third-party vendor accounts with broad access) rather than attempting a full enterprise-wide rollout at once, and in parallel begin migrating non-human identities from static credentials to workload identity federation wherever the platform supports it.

The fourth phase is detection and correlation: stand up the ITDR telemetry pipeline joining IdP, directory, OAuth, PAM, and cloud IAM logs, build the per-identity behavioral baselines, and integrate alerting with the SOC's existing triage workflow rather than standing up a parallel, disconnected identity-specific console that analysts have to check separately — integration with the broader agentic SOC workflow and unified NOC-SOC operations model is what makes identity detections actionable rather than yet another isolated alert source competing for analyst attention.

Each phase should produce a measurable output before the next begins, and the metrics defined in the previous section provide the scorecard for that gate. Organizations that attempt to build the detection layer before the governance foundation exists typically find that their ITDR alerts lack the context (who owns this identity, is this access expected) needed to triage effectively, which is the most common reason identity security initiatives stall after an initial tooling investment rather than delivering sustained risk reduction.

Frequently asked questions