Who is accountable when SaaS access cannot be fully enforced under zero trust?

Why This Matters for Security Teams

When SaaS access cannot be fully enforced under zero trust, the risk is not just technical drift. It is an accountability gap. The organisation that owns the identity, policy, and business outcome still owns the decision, even if the vendor controls part of the access path. That means exceptions, compensating controls, and evidence retention become governance requirements, not optional hygiene.

This is especially important for non-human identities, where service accounts, API keys, and automation tokens often outlive the systems they were created for. NHI Mgmt Group notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation in the Ultimate Guide to NHIs. That aligns with NIST SP 800-207 Zero Trust Architecture, which treats continuous verification and policy enforcement as architectural responsibilities, not assurances that a vendor will close every gap.

In practice, many security teams discover the control gap only after a SaaS integration has already been approved and production access is already live.

How It Works in Practice

The practical answer is to separate ownership from enforcement. The SaaS provider may enforce part of the control plane, but the customer organisation remains accountable for access policy, least privilege, and exception handling. That means the business owner, security team, and identity team should be able to explain who can access what, why access exists, how long it lasts, and what compensating controls apply when the platform cannot fully express the policy.

For NHIs, that usually means combining policy review with runtime controls. The OWASP Non-Human Identity Top 10 highlights how overprivileged secrets and weak lifecycle management expand exposure. NHI Mgmt Group’s Guide to SPIFFE and SPIRE is useful here because workload identity gives teams a stronger basis for authenticating the calling workload itself, even when the SaaS side only supports coarse-grained access decisions.

• Document the exact SaaS limitation, such as missing attribute-based rules, weak conditionals, or no native JIT workflow.
• Assign a named control owner who approves the exception and signs off on compensating controls.
• Prefer short-lived, scoped credentials over long-lived static secrets where the platform permits it.
• Log the access path, vendor constraint, policy override, and review date as audit evidence.

In mature environments, this is paired with periodic recertification and policy-as-code outside the SaaS boundary, so the organisation can still enforce governance at the identity layer even when the application layer is limited. These controls tend to break down when the SaaS product only offers admin-level toggles and no exportable policy or audit trail, because exceptions cannot be independently verified.

Common Variations and Edge Cases

Tighter zero-trust governance often increases operational overhead, requiring organisations to balance stronger assurance against slower onboarding and more exception handling. That tradeoff becomes sharper when the SaaS provider is the only place where a control can be configured, because the customer may not be able to enforce every requirement directly.

Current guidance suggests treating these cases as shared-responsibility gaps rather than assuming the vendor “owns” the risk. For example, if the product cannot support context-aware authorisation or per-request checks, the customer should compensate with shorter token lifetimes, tighter network boundaries, and stronger monitoring. In some environments, there is no universal standard for this yet, especially where SaaS platforms expose only partial logs or limited conditional access.

NHI-heavy workflows need particular care because a single exposed automation credential can bypass the intent of zero trust entirely. The Ultimate Guide to NHIs — Key Challenges and Risks shows why visibility and rotation failures are common, and those weaknesses are amplified when SaaS enforcement is incomplete. For practitioners, the safest pattern is to treat the limitation as a known exception, not a hidden assumption.

If the SaaS cannot support the required control, the organisation must either wrap it with compensating governance or accept and record the residual risk explicitly.

Related resources from NHI Mgmt Group

• Who is accountable for access decisions under zero trust governance?
• Who is accountable when zero trust controls fail in SaaS governance?
• Who is accountable when zero trust controls fail to stop unauthorised access?
• Who is accountable for access control evidence under SOC and SOX?