Who is accountable when a service app deletes MFA factors and enables downstream federation abuse?

Accountability sits with the team that owns the service application, the identity platform team that approved its scopes, and the security function that defined monitoring and review thresholds. In federated systems, no single product owns accountability for the chain, so governance has to be explicit.

Why This Matters for Security Teams

When a service application can delete MFA factors and then use federation to reach other systems, the issue is no longer just access control. It becomes an identity governance failure across the app owner, the identity platform, and the monitoring function. This is the kind of chain that turns a single over-permissioned service account into a cross-domain compromise. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why service app authority must be treated as a first-class security boundary.

The practical mistake is assuming the platform team or the product owner can each explain the whole blast radius. In federated environments, deletion of MFA factors is often a privileged action that can weaken downstream trust even when the original app looks “legitimate.” Security teams should map who approved the app’s scopes, who owns the federated trust relationship, and who is accountable for detecting abnormal identity lifecycle changes. That is the model reflected in NHI Mgmt Group’s Ultimate Guide to NHIs and in control expectations from NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams encounter the real ownership gap only after federation abuse has already been used to move laterally.

How It Works in Practice

Accountability in this scenario should be assigned by control plane, not by convenience. The service app team is accountable for the code, configuration, and approved privileges of the application itself. The identity platform team is accountable for the scopes, consent, policy enforcement, and any privileged capability that allows MFA factor deletion. The security function is accountable for control design, alert thresholds, review cadence, and escalation paths. That division matters because the failure often occurs across multiple systems rather than in one product.

Operationally, teams should document three things: who can request the privilege, who can approve it, and who must detect misuse. For service apps that can mutate identity state, best practice is to require explicit change approval, short-lived administrative privilege, and continuous audit logging tied to identity events. Controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support this with privileged access review, auditability, and account management expectations. NHI Management Group’s research on the Microsoft Midnight Blizzard breach illustrates why identity actions must be monitored as part of the attack chain, not as isolated admin events.

• Define a named owner for the service application and a separate owner for the identity policy it can influence.
• Treat MFA factor deletion, token minting, and federation changes as high-risk actions requiring step-up review.
• Log the original actor, delegated authority, and downstream identity target in the same event trail.
• Review whether the app really needs persistent privilege, or whether JIT access can replace it.

These controls tend to break down in legacy federation stacks where delegated admin rights, weak API governance, and sparse audit trails make it impossible to attribute the identity change to a specific accountable owner.

Common Variations and Edge Cases

Tighter federation control often increases operational overhead, requiring organisations to balance fast service automation against the risk of identity abuse. That tradeoff is especially visible in environments with many tenants, multiple IdPs, or application-to-application trust chains. Current guidance suggests that no single control is sufficient when an app can both modify factors and trigger downstream sign-in behavior.

There is no universal standard for this yet, but the direction is consistent: privileged service apps should be constrained by explicit scope, time-bound authorization, and tamper-evident logging. If the app is acting through a delegated admin model, accountability may extend to the human approver as well as the service owner. If the federation trust is brokered through another platform, that platform team becomes accountable for safe trust configuration, even if it did not initiate the abuse. This is why the governance model described in NHI Mgmt Group’s Ultimate Guide to NHIs should be paired with formal control assignments from NIST and with an incident review process that traces who approved the capability, not just who triggered the alert. The hardest cases are service apps embedded in CI/CD or ticketing systems, because ownership and privilege often drift faster than the security review cycle.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• What does AI model abuse reveal about the current NHI threat surface?
• Why is the abuse of NHIs a priority for security teams?
• Why can a single SaaS app create such a large blast radius?