What breaks when SaaS access is reviewed app by app instead of as connected relationships?

Why app-by-app review misses the real access picture

SaaS access does not behave like a pile of independent logins. The material question is how one identity, consent grant, or integration can extend into another system through shared authentication, delegated scopes, inherited roles, or connector trust. A clean review in one console can still leave effective access intact elsewhere because the governing relationship is not visible inside a single app.

That is why the review unit has to match the access unit. When a business process spans a CRM, a ticketing tool, a file store, and an automation platform, each system may show only part of the permission chain. The missing context is often the part that matters most: who can act through whom, and what downstream systems inherit that authority.

Relationship-based review also changes how you interpret “unused” or “dormant” access. An account can look inactive in one SaaS product yet still retain value through a connected app, refresh token, API grant, or delegated admin path. IAM and IGA Basics is useful here because it frames access review as entitlement and relationship governance, not just row-by-row record checking.

What gets missed when identities and integrations are not modelled together

The first blind spot is inherited privilege. A user may not have direct rights in the target app, but a group membership, service connector, or upstream role can still confer access indirectly. The second blind spot is shared tokens and OAuth grants, where one approved integration becomes a reusable access path across multiple systems. The third is delegated access, where an action performed “by” one app is actually executed through another app’s authority.

Those patterns are especially common in SaaS-to-SaaS integrations, because modern platforms are designed to trade convenience for delegation. SaaS-to-SaaS and OAuth App Governance Guide is the right lens for consent scope, token risk, and revocation, while Authorisation Models Guide helps distinguish direct roles from relationship-based access that only appears when systems are evaluated together.

App-by-app review also misses the practical difference between assigned access and effective access. A permission that looks narrow in one control panel may be broad once a connector, token, or automation chain is considered. That is why governance has to answer a graph question, not a spreadsheet question: what can this identity reach, through which trust paths, and with what inherited authority?

Why the false-confidence problem is so persistent

Individual app reviews often satisfy a compliance ritual without reducing blast radius. Each owner can truthfully say “my console is clean” while the enterprise still contains dormant tokens, overbroad integrations, and hidden privilege paths. The illusion is strongest when reviews focus on users only and ignore connected apps, machine actors, and third-party grants that are not obvious in the human access report.

That false confidence is not theoretical. BeyondTrust breach 2024 shows how a compromised access path in a support workflow can become a privileged entry point into a far wider environment. ShinyHunters Salesforce data theft campaign 2025 shows how malicious connected apps can turn an approved relationship into bulk export capability. The control lesson is the same in both cases: the risky object is often the relationship, not the single account record.

Governance therefore has to treat access review as continuous blast-radius management. If a token, connector, or delegated grant survives a review, the question is not merely whether it exists, but what other systems it can now reach and whether that reach is still justified.

Practitioner Guidance

What to prioritise: Review the highest-risk relationships first, meaning connected apps, delegated admin paths, shared service credentials, and any integration that can move data or change configuration across multiple SaaS platforms. Those paths usually carry more effective privilege than a standard user assignment.

What to verify: For each approved relationship, verify the granting identity, the target system, the scope, the expiry or rotation state, and the revocation path. If you cannot quickly answer who can revoke it and what breaks when it is revoked, the access model is not sufficiently governed.

Common mistake: Treating access review as a per-application attestation exercise. The safer pattern is to review the chain of authority, because the dangerous condition is often a valid permission in one app combined with a trusted connector in another.

Practitioner takeaway: The unit of control is the relationship graph, not the isolated account, so the review process should prove effective reach and revocation across connected SaaS systems before it accepts any access as low risk.

Related resources from NHI Mgmt Group

• What breaks when third-party SaaS access is never reviewed?
• What breaks when access relationships are only reviewed through spreadsheet exports?
• What breaks when connected products rely on standing access instead of time-bound access?
• What breaks when SaaS access reviews focus only on accounts instead of entitlements?