Who is accountable when a contractor uses a shadow SaaS app without MFA?

Why This Matters for Security Teams

A contractor using a shadow saas app without MFA is not just an access hygiene issue. It is an accountability failure. The security team, identity team, and business owner can all assume someone else is watching the edge of the environment, but the risk lands where governance stops. NIST’s NIST Cybersecurity Framework 2.0 is clear that asset visibility and access control only work when organisations can inventory and govern what is actually in use. That same principle applies to contractor access paths, especially when they bypass standard onboarding.

Shadow SaaS creates blind spots because it often sits outside procurement, SSO enforcement, and central logging. When MFA is missing, the app becomes a soft target for credential stuffing, session theft, and account takeover. NHIMG research shows how quickly token and API-based access can be abused in the real world, as seen in the Salesloft OAuth token breach and the BeyondTrust API key breach. In practice, many security teams encounter contractor shadow access only after an incident review exposes it rather than through intentional discovery.

How It Works in Practice

Accountability should be assigned across three layers: governance, discovery, and enforcement. The business owner is accountable for approving the contractor relationship. The identity team is accountable for making contractor identity controls mandatory. The security team is accountable for detecting unmanaged access paths and escalating exceptions. That division of labour only works when contractor access is treated like every other external identity, not as a temporary exception.

Practically, this means organisations need continuous discovery for SaaS usage, SSO coverage checks, and MFA enforcement policies that apply to contractor populations. If a contractor account exists outside the managed identity plane, the issue is not just that the app lacks MFA. It is that the organisation cannot prove who granted access, who reviewed it, or whether the account is still needed. Controls should include:

• Inventorying approved and unapproved SaaS applications through CASB, SSPM, or adjacent discovery tooling.
• Requiring MFA and conditional access for all contractor accounts wherever the platform supports it.
• Blocking business-critical data flows to apps that cannot meet baseline identity controls.
• Reviewing contractor access on the same schedule as employee access, including offboarding.

Where governance is mature, the control question shifts from “who owns the breach” to “who owns the exception.” That is the right framing. NHIMG’s Ultimate Guide to Non-Human Identities shows how access risk escalates when visibility is low and lifecycle controls are weak, and the same operational pattern appears in shadow SaaS environments. These controls tend to break down when contractors use self-provisioned apps outside procurement because the organisation has no reliable enforcement point before data exposure occurs.

Common Variations and Edge Cases

Tighter access control often increases friction for contractors, so organisations have to balance speed against assurance. That tradeoff is real, but current guidance suggests the exception process should be explicit rather than informal. If a shadow SaaS app is sanctioned after the fact, the responsible team should document why MFA is absent, what compensating controls exist, and when the access path will be retired or brought under standard identity governance.

There is no universal standard for every SaaS category yet, but the practical rule is simple: if the application stores company data or can be used to reach it, the absence of MFA becomes an enterprise risk, not a local inconvenience. This is especially true for third-party contractors, because their accounts often outlive the engagement, remain tied to shared business functions, or bypass internal monitoring entirely. The Snowflake breach illustrates how exposed access paths can become organisational events when identity hygiene is weak, even if the original mistake seems small.

Some organisations try to assign accountability solely to procurement or the contractor’s manager. That is incomplete. Procurement can help with vendor terms, but it cannot enforce MFA in a shadow app. The contractor’s manager can approve business need, but cannot substitute for technical control. The accountable security posture requires shared ownership, with identity and security teams responsible for making unmanaged access visible, reviewable, and revocable.

Related resources from NHI Mgmt Group

• How should security teams govern agent-native payments without creating new shadow access paths?
• Who is accountable when SaaS access is not revoked on time?
• What breaks when departments adopt SaaS tools without identity review?
• How should security teams identify shadow data across cloud and SaaS environments?