Who is accountable when a SaaS account is compromised because MFA was not extended to an unmanaged application?

Accountability usually sits with the security and identity teams that own access policy, but business app owners also matter when applications are purchased or administered outside IT. Organisations should define who approves exceptions, who tracks remediation, and who can accept residual risk. Clear ownership prevents MFA from becoming an aspirational control with no enforcement.

Why This Matters for Security Teams

When MFA is not extended to an unmanaged application, the failure is usually not just technical. It is an identity governance gap that leaves a SaaS pathway reachable through exceptions, shadow IT, or inherited trust. That makes accountability important because someone approved the access model, someone operated the application, and someone failed to close the control gap. In NHI terms, these are often the same conditions that let service account and tokens remain exposed long after the risk is known, as reflected in the Ultimate Guide to NHIs and the The 52 NHI breaches Report.

Security teams often assume MFA coverage exists wherever a corporate account exists, but unmanaged apps frequently sit outside standard IAM onboarding, procurement review, and conditional access policy. That leaves gaps between policy intent and real enforcement. Current guidance from the NIST Cybersecurity Framework 2.0 treats identity protection as a governance and risk function, not just an authentication setting. In practice, many teams discover the missing MFA control only after a SaaS account is used for unauthorized access, rather than through intentional application inventory and exception review.

How It Works in Practice

Accountability should follow control ownership, not just incident fallout. If the security or identity team defines MFA policy, they own the control design and enforcement path. If a business unit procures or administers the SaaS app outside IT, that owner typically owns the exception request, vendor configuration, and remediation coordination. If risk is formally accepted, the approver should be explicit and time-bound. This is consistent with NIST control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access enforcement, configuration management, and risk acceptance are separable duties.

In mature environments, the process usually includes three steps:

• inventory the unmanaged application and identify who controls authentication settings
• determine whether the app supports SSO, MFA, or federated identity, and record any exception
• assign a named owner for remediation, a deadline, and an escalation path if the risk remains open

This is also where NHI governance becomes practical. If the SaaS account uses API keys, service accounts, or delegated tokens, then the control failure extends beyond human MFA and into credential lifecycle management. The NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that ownership must include issuance, rotation, revocation, and offboarding, not just initial setup. Security teams should also document whether the app owner is allowed to bypass enterprise MFA controls, because unmanaged applications often become the place where exceptions quietly accumulate. These controls tend to break down when procurement, identity, and business ownership are split across multiple teams because no single group sees the full authentication path.

Common Variations and Edge Cases

Tighter MFA enforcement often increases operational friction, so organisations must balance fast business adoption against consistent identity control. The hardest cases are legacy SaaS platforms, contractor-owned tools, and acquisitions where the authentication model cannot be centrally changed. In those environments, best practice is evolving rather than settled: some organisations force federated access at the enterprise layer, while others allow limited exceptions with compensating controls such as device posture checks, short-lived sessions, and explicit review dates.

There is no universal standard for this yet, but guidance from NIST Cybersecurity Framework 2.0 and NHI research suggests the same operational principle: if an unmanaged app cannot support MFA, the exception must be owned, documented, and revisited. NHI breach patterns in 52 NHI Breaches Analysis show how quickly weak identity controls can turn into broader compromise when credentials are reused or overlooked.

The edge case that matters most is shared administration. When a SaaS account is jointly managed by IT and a business team, accountability can blur unless one team owns policy enforcement and the other owns business acceptance. That distinction should be written into the access policy, exception register, and incident response playbook.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised application principal is used to elevate access in Entra ID?
• Who is accountable when a web application leaks sensitive files or bypasses access controls?
• Who is accountable for governing AI security exposure in application security programs?
• Who is accountable when an approved AI application keeps access after the original business need has changed?