Every SaaS integration your organisation approves is a door. Some doors open onto a well-lit corridor with guards and cameras. Others open straight into your customer data, your email, your identity provider. Australian IT teams are approving dozens of these integrations every quarter, and the security review most of them get is a checkbox on a procurement form.
Third-party SaaS integrations sit at a strange intersection: they're too low-profile to trigger a formal vendor risk assessment, yet they often carry OAuth tokens with broad permissions that last for years. The supply chain cyber attacks hitting Australian businesses increasingly route through exactly these connections, because they're trusted by the environment and largely invisible to traditional perimeter controls.
What makes SaaS integrations different from traditional third-party risk
A traditional vendor risk assessment asks whether the supplier has ISO 27001, how they store data, and whether they've had a breach. That process, slow as it is, at least happens. SaaS integrations frequently bypass it entirely. An employee connects a productivity tool to your Google Workspace or Microsoft 365 tenant in 30 seconds, grants it access to calendars, files, and contacts, and nobody in IT ever finds out.
The permission scope is where it gets dangerous. OAuth grants for many SaaS tools ask for far more than they need to function. A scheduling tool that needs calendar read access will often request calendar read-write access plus the ability to send email on the user's behalf. Most users click approve without reading the scope list. That token then persists until someone explicitly revokes it, which almost never happens.
Persistence is the second problem. A token granted in 2023 to a tool that the team stopped using in 2024 is still valid today unless IT has an active revocation process. Attackers who compromise a SaaS vendor's infrastructure can use those dormant tokens to move laterally into your environment months or years after the integration was last opened.
The red flags worth acting on immediately
Not every integration is a liability. The ones that warrant immediate scrutiny share a recognisable set of characteristics.
Overly broad OAuth scopes. Any integration requesting full mailbox access, the ability to delete files, or administrative permissions over your identity provider is a red flag unless you can articulate precisely why it needs that level of access. The vendor's documentation should explain each scope. If it doesn't, that itself is a red flag.
No documented data residency. Australian organisations handling personal information under the Privacy Act have obligations around where data goes. An integration that silently ships contact records or file contents to a US-based SaaS vendor without contractual data residency commitments creates compliance exposure, not just security exposure. Australia's Notifiable Data Breaches scheme applies to data that leaves your control through a third party as much as through a direct breach.
No named subprocessor list. Most enterprise SaaS vendors publish a list of the cloud services they use to deliver their product. If an integration vendor cannot produce one, they may be shipping your data to infrastructure you've never assessed and can't name.
Tokens that never expire. Some integrations issue tokens with no expiry and no refresh cycle. Check the OAuth token list in your Google Workspace admin console or Microsoft Entra ID tenant right now. You'll likely find tokens issued years ago to tools that no longer exist as companies. Revoke them.
No incident notification clause. Every integration that touches personal data or critical systems should carry a contractual obligation for the vendor to notify you within 72 hours of a suspected breach affecting your data. If the terms of service don't include this, you're not on the vendor's notification list. You'll find out about their breach on the news.
Where Australian IT teams typically lose visibility
The discovery problem is real. Most organisations don't have an accurate list of active SaaS integrations across their environment. Shadow integrations, approved by individual users or teams without IT involvement, are genuinely common. A 2025 report from Grip Security found that the average enterprise has roughly 10 times more SaaS integrations than its IT team knows about. That figure reflects global data, but Australian enterprises have no structural reason to be different.
The problem compounds in Microsoft 365 environments. Azure AD (now Entra ID) enterprise apps and OAuth consents can be granted by end users if the tenant's user consent settings allow it. Many tenants that started with permissive settings during COVID-era remote work deployments never tightened them. Auditing consent grants in Entra ID should be a quarterly task, not a one-off exercise.
Google Workspace has similar exposure. The Admin Console's "Connected Apps" view often surprises IT teams who run it for the first time. Apps connected by individual users appear alongside IT-approved integrations, and there's no visual distinction between a vetted internal tool and an unreviewed third-party service.
What a baseline integration security review looks like
You don't need a full vendor risk management program to reduce exposure from SaaS integrations. A baseline review covers five things:
- Enumerate all active OAuth tokens and connected apps in your IdP, at least quarterly
- Classify each integration by the data it can access (public, internal, confidential, personal)
- Revoke tokens for integrations no longer in active use
- Restrict user consent in Entra ID and Google Workspace so new integrations require IT approval
- Require a data processing agreement for any integration touching personal information
The enumeration step alone produces useful findings in almost every organisation that does it properly. Expect to find integrations nobody remembers approving, tools that have since been acquired by other vendors, and OAuth scopes that are far broader than the integration's stated purpose.
Connecting integration risk to your broader security posture
SaaS integration security doesn't sit in isolation. It feeds directly into your identity security posture. A compromised integration token that has access to your HR system or financial platform bypasses MFA entirely, because the token was granted through a legitimate consent flow. This is one of the reasons identity-based attacks targeting Australian organisations are so effective: the attacker arrives looking like a trusted application, not a suspicious login.
Monitoring matters here too. Integration activity should appear in your SIEM. If your logging pipeline doesn't include OAuth token usage events and third-party app access logs from your IdP, you're missing a significant class of lateral movement. Many forensic investigations of SaaS-routed breaches find that the malicious activity was invisible in the logs for weeks, because the integration traffic was categorised as normal system behaviour.
The practical starting point is simpler than most teams expect. Pull the connected apps list from your IdP today. Count how many you can actually name and justify. That number tells you more about your integration risk than any questionnaire.