Prioritising OAuth Exposure Across a Shadow SaaS Estate
A 2,300-person software company has sanctioned Microsoft 365, Salesforce and Workday, and a discovery sweep surfaced roughly 900 unsanctioned SaaS applications in use. SaaS security posture scanning returned four OAuth applications holding tenant-wide Graph permissions. One of them, a meeting-scheduling add-in, has mail.read and offline_access and was consented to by 410 users, including 12 in finance. The inline proxy sees only about 55% of SaaS sessions, because a large share of users connect from mobile devices that never traverse it, and there is no API connection to two regional Salesforce instances. Finance keeps a spreadsheet of vendor bank details in SharePoint and shares it externally about 30 times a month, currently with anyone-with-the-link permissions. The security team has 30 days and one engineer to reduce SaaS risk measurably.
1. Rank the four OAuth applications for remediation and justify the order using blast radius rather than severity labels.
Read the worked answer
Rank on four factors: permission breadth, token persistence, population consented, and data sensitivity of those users.
1. The scheduling add-in - remediate first. mail.read plus offline_access means refresh tokens let it read mail indefinitely, including after the user stops using it, and consent was granted by 410 users of whom 12 sit in finance. Blast radius is not the 410 mailboxes; it is every message those mailboxes will ever receive, retained for as long as the refresh token lives. Action: revoke consent grants, invalidate refresh tokens, and require admin consent for any reinstatement.
2. Any app with tenant-wide Graph permissions and no business owner. Tenant-wide means directory read across the whole company, which is reconnaissance material for phishing and lateral movement. If nobody will claim it, remove it.
3. Remaining tenant-wide apps with a legitimate owner. Constrain to the specific scopes needed, move to admin-consented and reviewed grants.
4. Apps with delegated, narrow scopes and an active owner. Queue for the next cycle.
Why permission breadth outranks user count: a low-consent app with tenant-wide directory read exposes every identity in the tenant, while a popular app with user-limited scopes exposes only its own users. Also flag that the add-in is likely the visible symptom - the sweep only finds apps that touch Graph, so ask what the equivalent is for Salesforce connected apps, which is a separate inventory.
2. Decide which risks you would address with the inline proxy and which with API-based controls, and state the coverage limits.
Read the worked answer
Inline proxy handles real-time flow control: blocking uploads to unsanctioned destinations, enforcing tenant restrictions so corporate identities cannot sign into personal instances of sanctioned apps, and stopping the paste-and-upload pattern as it happens. It is the only control that can say no before data leaves.
API-based controls handle state, not moments: discovering external sharing on SharePoint, revoking anyone-with-the-link permissions at scale, finding files with sensitive content at rest, and scanning historical exposure. This is where the finance spreadsheet belongs - you need a list of every link created and the ability to break them, and inline cannot see a link that was minted last month.
Coverage limits you must state to leadership:
- The proxy sees 55% of sessions. Any inline-derived metric is a sample, not a census, and mobile users are systematically under-represented.
- Two Salesforce instances have no API connection, so posture findings there are blind spots, not clean results.
- Neither control inspects a mobile app syncing directly to a SaaS provider over its own channel.
Implication for the 30-day goal: close the Salesforce API gap before reporting any improvement figure, otherwise your baseline moves for reasons unrelated to your work. Use the proxy for the three highest-value enforcement rules and spend the remaining time on the two API connections.
3. What should be done about the vendor bank-details spreadsheet shared with anyone-with-the-link 30 times a month?
Read the worked answer
Split this into an immediate technical action and a durable policy fix, and do not confuse the two.
Immediate (days): run an API query for every file matching the sensitive-content profile and every active anyone-with-the-link sharing link, prioritise those containing bank details, and revoke the links. Where recipients must retain access, replace with named-recipient links and a documented external-sharing allowlist for the finance domain. Enable link expiry so the pattern cannot silently recur.
Durable (weeks): the underlying problem is that a spreadsheet of bank details is a standing target. Push to move that data into a system with change control and dual approval for bank-detail edits - a shared spreadsheet cannot distinguish a legitimate vendor update from a fraudulent one, and payment-diversion fraud is the realistic threat here, not bulk exfiltration. In the meantime, apply a sensitivity label with encryption and an external-sharing restriction, and require the finance team to confirm the recipient out of band on every change.
What I would not do: block external sharing for finance outright. It will be routed around within a week via personal email, which is strictly worse and invisible. Change the default sharing setting and give a sanctioned path instead - the goal is that the safe action is also the easy one.