Single sign-on rollouts are treated like commodity work inside most Australian IT teams. The vendor says it's a three-hour job. The project plan allows a week. Six months later, half the SaaS portfolio still isn't connected, three departments are running parallel login flows, and the ITSM queue has a growing tail of access complaints. SSO is genuinely simple in concept and genuinely tricky in practice, and the gap between those two things catches organisations repeatedly.
The problem isn't the protocol
SAML 2.0 and OIDC are mature, well-documented standards. The tooling around them from providers like Okta and Microsoft Entra ID is reasonably polished. The real source of SSO pain isn't the federation protocol. It's everything around it: ownership, SaaS coverage gaps, user provisioning, and what happens when the identity provider goes down.
Most teams begin an SSO rollout by connecting their highest-profile applications first. That's sensible. But they rarely complete a full inventory before starting, which means the project scope shifts constantly as someone discovers another tool that doesn't support SAML, or a vendor whose SSO support is locked behind a tier upgrade. Scope creep here isn't strategic. It's just unfinished homework.
Why SaaS coverage gaps persist
Not every SaaS application supports enterprise SSO. Plenty of tools, especially in the sub-$50/seat range, offer only password-based login or a rudimentary OAuth flow that doesn't integrate with a corporate identity provider. Australian IT teams often underestimate how many of these tools exist in their environment because the tools were procured outside IT through a credit card purchase by a team lead. This is the same problem explored in shadow IT in Australian organisations: the applications IT doesn't know about can't be connected to SSO, and discovering them mid-rollout is expensive.
The practical fix is straightforward: run a SaaS discovery exercise before writing the SSO integration backlog. Review credit card statements, query your browser proxy logs, and survey business units directly. A realistic application inventory takes two weeks. Skipping it costs months.
User provisioning is a separate problem
SSO controls authentication. It doesn't control authorisation. Connecting an application to your identity provider so that users can log in with a single credential is not the same as managing which users get access to what, or removing access when someone leaves the organisation.
SCIM (System for Cross-domain Identity Management) handles provisioning and deprovisioning, and it's a separate integration from SSO. Teams that complete the SSO connection and consider the job done frequently discover months later that former employees still have active accounts in downstream applications. The SaaS vendor's interface shows those accounts as authenticated via SSO, but the identity provider isn't pushing deprovisioning events because SCIM was never configured. This is a real audit finding. It shows up in ISO 27001 gap assessments regularly.
Configure SCIM in parallel with SSO. If a SaaS vendor doesn't support SCIM, document the manual offboarding process explicitly. Don't assume it will be handled.
The identity provider availability risk
An SSO rollout centralises authentication. That's the point. It also means the identity provider becomes a single point of failure for every connected application. When Okta or Entra ID has an outage, users can't access any SSO-connected tool. For organisations that have completed a thorough rollout, that list often includes email, ITSM, version control, and finance systems simultaneously.
This isn't an argument against SSO. It's an argument for resilience planning. Define which applications need a break-glass login procedure. Document local admin accounts for critical systems. Test those procedures before they're needed. Most teams don't test them. Most teams find out they don't work during an actual outage.
The availability risk compounds when organisations are also consolidating their SaaS vendor stack, reducing the number of separate login mechanisms that previously provided accidental redundancy.
Governance that actually holds
SSO rollouts without a supporting governance model tend to drift. The first six months see strong progress. Then a new SaaS tool is procured without going through IT, it gets set up with local accounts, and the SSO coverage percentage quietly falls. Without regular audits and a mandatory procurement step that checks SSO compatibility before a tool is approved, the estate degrades.
Three governance controls work in practice:
- An SSO compatibility check built into the SaaS procurement approval process, not as an afterthought but as a gate.
- A quarterly review of connected applications against the current SaaS inventory, flagging any new tools without SSO configured.
- A documented exception process for applications that genuinely can't support SSO, with compensating controls (dedicated passwords in a vault, MFA enforced at the application level, regular access reviews).
What licence tier surprises actually look like
Several major SaaS vendors gate enterprise SSO behind their most expensive plan. Atlassian's Data Center and Cloud products, Zoom, and several HR platforms all have SSO as a premium feature. The IT team discovers this mid-rollout when they attempt to configure the SAML connection and the vendor's admin console simply doesn't offer the option. The fix requires a licence upgrade. The budget wasn't set aside for it. The project stalls.
Audit the licence tier of every application against its SSO support documentation before the rollout starts. Vendors don't advertise SSO paywalls prominently. You have to look. The discovery is never a pleasant one during a project that's already live.
Testing is not optional
SSO integrations interact with the SaaS application's own session management, attribute mapping, and logout flows in ways that aren't always predictable. A user might log in successfully but land on a blank screen because the role attribute isn't being passed correctly. Single logout (SLO) might not work, leaving active sessions in downstream apps after the identity provider session ends. Attribute mismatches between the IdP directory and the SaaS app's expected format are common, especially when migrating from legacy Active Directory to a cloud identity provider.
Test each integration with at least three user archetypes: a standard user, an admin, and a new user being provisioned for the first time. Test the login flow, the logout flow, and the account creation flow before declaring the integration complete. It adds time. It prevents support queues.
SSO is not a set-and-forget control. The integrations need periodic review as SaaS vendors update their authentication implementations, as the identity provider's attribute schema changes, and as the organisation's access model evolves. Teams that treat it as a project with a defined end date typically find themselves back at the same problems twelve months later.