How should security teams handle SaaS apps that do not expose usable APIs?

Why This Matters for Security Teams

SaaS applications without usable APIs are not just an automation inconvenience. They create an operating gap where identity, access, and data exposure still need governance, but the control surface is limited to what the vendor exposes. That is where teams often overreach by forcing a uniform automation model onto uneven platforms. Current guidance suggests a control-depth approach instead: assess whether the app supports direct policy enforcement, partial telemetry, or only human review. The risk is amplified in environments where SaaS is connected to non-human identities, because OAuth grants, service accounts, and delegated access can persist long after the original business need has changed. NHI Mgmt Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of blind spot that grows when SaaS tooling cannot be queried reliably.

Practically, this matters because SaaS risk is not binary. The absence of APIs does not remove the obligation to review entitlements, revoke stale access, or validate owners. It only changes how those controls are executed. In practice, many security teams encounter unauthorized persistence only after an app is already central to a workflow and not through intentional control design.

How It Works in Practice

The right model is to segment SaaS apps by control depth rather than by vendor name or business criticality alone. At one end are applications with robust APIs, where lifecycle actions, entitlement checks, and event logging can be automated. In the middle are apps with partial APIs, where some tasks can be machine-assisted but others still require manual verification. At the far end are apps with no usable APIs, where the control plan must rely on human review, owner attestations, admin console checks, and scheduled exception handling.

That approach aligns with the operating reality described in NHI guidance and in post-incident patterns such as the Salesloft OAuth token breach and the BeyondTrust API key breach, where delegated access and secrets handling mattered more than the presence of a polished integration. For SaaS without APIs, the practical control stack usually includes:

• Manual access recertification on a fixed cadence, with explicit owner sign-off.
• Exception registers that record why the app cannot be automated and when the exception must be revisited.
• Documented offboarding steps for accounts, tokens, and app-specific admin roles.
• Evidence collection from screenshots, exports, audit logs, or mailbox approvals when system-to-system integration is unavailable.
• Risk tiering that treats unsupported SaaS as higher-effort, not as exempt.

For these reviews, teams should still apply least privilege and short-lived access where the platform permits it, even if only through admin workflows rather than API calls. The external lesson from the Anthropic report on AI-orchestrated cyber espionage is relevant here: when automation is limited, attackers often exploit the messy human edges instead. These controls tend to break down when SaaS ownership is unclear and admins rotate frequently, because nobody can reliably attest to what access still exists.

Common Variations and Edge Cases

Tighter review discipline often increases operational overhead, requiring organisations to balance assurance against manual effort. That tradeoff is unavoidable for legacy or niche SaaS, but best practice is evolving toward risk-based exceptions rather than blanket approval. Where a vendor has no usable API, the absence of automation should not be treated as a technical excuse to skip review; it should be treated as a documented constraint with compensating controls.

There are two common edge cases. First, some SaaS tools expose read-only reporting APIs but not write actions. In that case, teams can automate evidence gathering while keeping provisioning and revocation manual. Second, some platforms support export files or SCIM-like partial syncs, but the data is incomplete or delayed. Current guidance suggests treating those feeds as advisory only until they are validated against admin-console truth.

This is also where ownership matters. If the app is business-critical but poorly instrumented, security teams should require an accountable system owner, a defined review cadence, and a named exception expiry date. If the app handles NHIs through OAuth grants, API keys, or bot users, the review must include token scope, expiry, and revocation paths, not just human sign-in accounts. NHI Mgmt Group’s research on the 52 NHI Breaches Analysis shows how quickly access paths become attack paths when stale credentials remain active. Where a SaaS platform cannot surface trustworthy state, the control breaks down in distributed enterprises with many app owners because the evidence trail becomes too fragmented to support timely decisions.

Related resources from NHI Mgmt Group

• How should security teams handle OAuth-connected apps that outlive their original business need?
• How should security teams make NHI best practices usable across the business?
• How should security teams handle risks from AI browser extensions?
• How should security teams handle local accounts in cloud and SaaS apps?