The SSO tax shows how secure login gets priced as leverage

At a glance

What this is: This is an analysis of the “SSO Tax,” where SaaS vendors reserve single sign-on behind higher-priced tiers and force identity teams to pay more for basic federated login.

Why it matters: It matters because IAM teams may be budgeting for security controls as if they were standard entitlements, when vendor pricing can block SSO adoption, widen shadow SaaS exposure, and slow consistent identity governance.

By the numbers:

• Airtable’s Team plan does not support SSO, while the Business plan costs 125% more to add it.
• Calendly’s Standard plan requires either a roughly $36-per-user annual add-on or a custom Enterprise plan starting at $15,000 per year to get SSO.
• The average enterprise runs over 300 SaaS applications, which makes even small SSO premiums compound quickly.

👉 Read Unixi's analysis of the SSO tax and SaaS identity pricing

Context

Single sign-on is a federation pattern that lets one authenticated session carry across multiple applications. In practice, it should reduce password exposure, simplify access, and strengthen IAM consistency across the SaaS estate, but many vendors now package it as a premium feature rather than a baseline security control.

That pricing model creates a governance problem for identity teams. When secure login is gated behind a higher tier, organisations may delay deployment, limit federation to only some apps, or tolerate weaker local authentication where SSO would otherwise be the default.

The result is not just a procurement nuisance. It changes how IAM programmes scope rollout, how SaaS owners negotiate contracts, and how quickly shadow applications can be brought under consistent identity control.

Key questions

Q: How should security teams deal with SaaS vendors that charge extra for SSO?

A: Security teams should treat SSO as a baseline control requirement and measure vendors against it during procurement. If an application gates federation behind a premium tier, teams should quantify the security and operational cost of keeping separate logins, then decide whether the app can be approved at all.

Q: Why does the SSO tax create IAM risk beyond the extra license cost?

A: Because it can delay federation, fragment authentication, and leave some applications on weaker local login paths. That makes central policy enforcement harder and increases the chance that shadow SaaS and inconsistent access controls persist across the estate.

Q: When should organisations pay for SSO and when should they walk away?

A: Organisations should pay when the application is strategically important, has meaningful user volume, or handles sensitive data that benefits from central authentication. They should walk away when the vendor pricing is disproportionate to the control value and forces broader tier upgrades just to secure login.

Q: What should IAM and procurement teams compare before accepting a premium SSO tier?

A: They should compare the total licence uplift against the governance cost of not federating the app, including support overhead, access review complexity, and exposure from local accounts. That comparison makes the trade-off visible to both security and business stakeholders.

Technical breakdown

How SSO federation works across the identity provider and SaaS app

Legacy SSO depends on an identity provider and a service provider exchanging trust artifacts, usually certificates or signed assertions, so the application can accept an external authentication decision. The user authenticates once, then the app trusts that assertion for session creation. That model improves security because passwords stay concentrated in the identity layer instead of being duplicated across dozens of SaaS services. The catch is that the federation setup itself can become a priced licensing feature rather than a technical default.

Practical implication: treat SSO as a control dependency in SaaS intake, not a nice-to-have feature to negotiate later.

Why SSO pricing creates governance drift in SaaS portfolios

When SSO sits behind a higher plan, identity governance becomes uneven across the application portfolio. Some apps get federated access, while others retain local credentials, separate login policies, or inconsistent MFA coverage. That split creates policy drift, especially in large SaaS estates where each application owner may accept a different trade-off between cost and control. In effect, access governance is no longer decided only by security architecture. It is partially dictated by vendor packaging.

Practical implication: map which SaaS contracts lack SSO and prioritise them by user volume, privilege, and data sensitivity.

Why integration-less SSO changes the economics of identity control

The article’s core architectural claim is that newer SSO models can bypass traditional app-to-IdP integration requirements. By using a browser-based or decentralised authentication layer, organisations can extend federated access without waiting for every SaaS vendor to support native enterprise SSO. That matters because it reduces the number of applications that sit outside the federation boundary. It also lowers the pressure to pay for enterprise tiers solely to unlock login controls.

Practical implication: evaluate whether an alternate federation layer can close coverage gaps in shadow SaaS without forcing plan upgrades.

NHI Mgmt Group analysis

SSO pricing is now an identity governance issue, not just a procurement issue. When secure login is monetised as an upsell, the IAM programme no longer controls adoption purely through policy and architecture. Contract terms start deciding which applications participate in federation, which creates uneven security baselines across the SaaS estate. The practitioner takeaway is that SSO entitlement must be treated as part of control design, not an afterthought in commercial negotiations.

Identity programmes are increasingly exposed to feature-gated security debt. A vendor can expose the organisation to weaker authentication simply by withholding SSO from lower tiers. That produces a control gap that looks operational on the surface but is governance-driven underneath. The practical implication is that access architecture, vendor management, and procurement criteria need to be aligned before app approval.

Shadow SaaS becomes more expensive to govern when SSO is priced as a premium feature. If each new application requires a higher tier to support federation, teams may delay bringing it under central control. That incentivises unmanaged local accounts and fragmented authentication paths, which undermine the whole point of identity standardisation. The field should recognise this as a structural barrier to SSO coverage, not a technical limitation.

Universal SSO matters because coverage, not elegance, is the real control objective. The challenge is not whether one login experience looks better than another. The challenge is whether every application in the portfolio can be pulled into a common trust and session model without forcing budget trade-offs that weaken adoption. Practitioners should measure SSO by penetration across the SaaS estate, not by the quality of the demo.

SSO tax pressure will keep pushing IAM teams toward compensating controls. When federation is too costly in some tiers, organisations often fall back to weaker native login, shared admin accounts, or inconsistent access review practices. That is a predictable outcome of pricing friction in the control plane. The implication for identity leaders is to treat commercial lock-in as a recurring security design constraint, not a one-off negotiation problem.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly governance breaks down once access leaves the central identity boundary.
• That visibility gap is why teams should also read NHI Lifecycle Management Guide when they are trying to bring external applications and service identities under control.

What this signals

SSO coverage should now be tracked as a portfolio metric, not an application feature checkbox. If only some SaaS tools can join federation without a tier upgrade, identity teams need a view of where control coverage is being blocked by commercial packaging. That is the practical difference between having an IAM standard and actually enforcing it across the estate. For teams aligning to broader control sets, the NIST Cybersecurity Framework 2.0 framing around govern and protect fits this problem well.

Feature-gated SSO will keep amplifying shadow access unless procurement and IAM decisions are linked. Once local credentials remain the cheaper path, the organisation inherits more authentication silos, more admin exceptions, and more review overhead. The best response is to make federation support a mandatory intake criterion and to tie exceptions to explicit risk acceptance.

Identity teams should expect more control substitution across SaaS buying decisions. Where SSO is priced as an upsell, organisations often compensate with manual onboarding, policy exceptions, or higher operational tolerance for unmanaged apps. That is a fragile model, and it is exactly the kind of fragmentation that undermines centralised identity governance.

For practitioners

• Inventory SaaS applications that gate SSO behind paid tiers Build a contract-level view of which applications support federated login only on higher plans, then rank them by user count, privileged access, and data sensitivity.
• Embed SSO availability into procurement and renewal criteria Require SSO support as a baseline control in SaaS evaluations, and make renewal decisions depend on whether the vendor includes it without forcing plan inflation.
• Prioritise shadow SaaS first where local credentials still exist Use discovery and access review workflows to surface unmanaged applications that remain outside federation, then target those apps for central identity coverage.
• Model the cost of fragmented identity governance Compare the price of tier upgrades against the operational and security cost of maintaining separate authentication paths, then use that analysis in business-case reviews.

Key takeaways

• The SSO tax turns federation into a budget-driven exception, which weakens identity consistency across SaaS portfolios.
• When SSO is hidden behind higher tiers, the real cost includes fragmented authentication, slower rollout, and more unmanaged access paths.
• IAM teams need to treat SSO availability as a procurement control, not a feature comparison, if they want consistent governance.

Key terms

• SSO Gap: An SSO gap is any application or workflow that still requires direct credentials even though the organisation has deployed single sign-on elsewhere. These gaps matter because they create unmanaged access paths that must still be governed, audited, and revoked.
• SSO Tax: The SSO Tax is the extra commercial cost organisations pay when a SaaS vendor reserves SSO for a higher-priced plan or add-on. It is not a technical limitation, but a pricing barrier that can slow federation adoption and fragment identity governance across the application estate.
• Federated Identity Management: Federated identity management is the practice of allowing separate systems to trust a shared identity assertion or login. It reduces duplicate credentials and supports single sign-on, but it also requires careful control over trust boundaries, session handling, and revocation when partners or applications change.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.

What's in the full article

Unixi's full article covers the pricing and product detail this post intentionally leaves for the source:

• Plan-by-plan examples of where SSO is withheld until organisations upgrade to higher tiers
• A breakdown of how the SSO tax compounds across large SaaS portfolios
• Details on the alternative authentication approach Unixi describes for broader SSO coverage
• The article's calculator for estimating potential savings across a SaaS stack

👉 Unixi's full article explains the tiering examples, cost math, and alternative SSO approach in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.