The SSO tax shows how secure login gets priced as leverage

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: SaaS vendors reserve Single Sign-On for higher tiers and turn secure login into a pricing lever through the “SSO Tax.”.

Why it matters: It matters because IAM teams must treat authentication capability, licensing, and SaaS procurement as one governance decision, especially when secure login is deliberately gated behind commercial packaging.

By the numbers:

• The average enterprise runs over 300 SaaS applications, with 305 cited in Zylo’s 2026 SaaS Management Index.

Context

The SSO tax is the commercial penalty organisations pay when a SaaS vendor places Single Sign-On behind a higher-priced tier or a custom contract. In practice, that turns authentication design into procurement negotiation, even though the underlying issue is still identity governance and access control.

For IAM teams, the problem is not simply cost. When secure login is treated as a monetised add-on, organisations can end up accepting weaker access patterns, delaying federation, or leaving applications outside standard identity policy because the licensing model makes the control harder to justify.

Key questions

Q: What breaks when Single Sign-On is locked behind a higher SaaS tier?

A: When SSO is priced as an upgrade, organisations often leave apps on local credentials, delay federation, or accept exceptions that weaken identity governance. The technical control still exists in principle, but the commercial model makes it harder to deploy consistently across the SaaS estate, which creates fragmentation in access policy and offboarding.

Q: Why does charging extra for secure login create security risk?

A: Because it turns a basic authentication control into a commercial decision. Teams may keep separate logins, postpone standardisation, or avoid onboarding shadow SaaS into central identity controls, which increases the number of places where credentials and access rules must be managed correctly.

Q: How should IAM teams handle applications that make federation a paid feature?

A: They should treat those apps as governance exceptions, not routine purchases. If the application handles meaningful business access, the organisation should assess whether the absence of SSO is acceptable, whether the app should be replaced, or whether the licensing model is distorting the security baseline.

Q: What is the difference between SSO convenience and identity governance?

A: SSO convenience is about reducing the number of times users type credentials. Identity governance is about controlling who gets access, how that access is approved, how long it lasts, and how it is removed. A programme can have good convenience and still fail governance if lifecycle and entitlement controls are weak.

Technical breakdown

How SSO gating changes the identity control model

Single Sign-On is a federated authentication pattern, not a premium convenience feature. It lets an identity provider assert a user’s authentication state to a service provider so the user does not need separate credentials for every app. When vendors gate that capability by tier, the organisation is no longer choosing only an access control pattern, it is also inheriting a pricing dependency that can influence architecture, onboarding order, and standardisation across the SaaS estate.

Practical implication: treat SSO availability as part of application security requirements during procurement, not as an optional commercial feature.

Why tier-based pricing creates IAM drift

When SSO sits behind a higher plan, security teams may defer federation, keep separate local accounts alive, or postpone onboarding shadow SaaS into identity governance. That creates IAM drift, where the control plane says one thing but the application estate behaves another way. Over time, this widens the gap between policy and reality, especially in large SaaS portfolios where even small per-app exceptions accumulate into a fragmented identity surface.

Practical implication: inventory which apps still rely on local login and prioritise the ones whose pricing blocks standard federation.

Why certificate-based federation still matters

Traditional SSO depends on trust between the identity provider and the service provider, often established through certificates and federation configuration. That trust layer is what makes secure login portable across applications. If access to that layer is commercialised, the organisation is effectively buying back a control it already knows it needs. The technical issue is less about login convenience and more about whether identity assurance can be enforced consistently across the SaaS stack.

Practical implication: require security and identity architecture review for apps that use local accounts because federation was priced out.

NHI Mgmt Group analysis

SSO pricing is now an identity governance issue, not just a procurement issue: when secure login is sold as an upsell, organisations are forced to negotiate access control through commercial packaging. That changes how identity programmes are adopted, delayed, or bypassed. The result is governance distortion, where the cheapest plan can become the least secure operating model.

The SSO tax creates control-plane fragmentation: applications that should sit under a standard federation model remain on local credentials, separate admin flows, or ad hoc onboarding paths. That is not just inefficiency. It is a durable exception pattern that makes access reviews, offboarding, and policy consistency harder across the SaaS estate.

SSO should be evaluated as baseline access architecture: the moment a vendor prices federation as a premium tier, the organisation has to ask whether the application belongs in a standard identity programme at all. This is the kind of commercial constraint that can distort architecture choices more than technical limitations do.

Shadow SaaS becomes more likely when federation is monetised: if teams cannot justify the SSO uplift, they are more likely to leave smaller apps outside central identity governance. That expands unmanaged access paths and weakens the organisation’s ability to apply consistent IAM policy across the app portfolio.

Secure login has been turned into leverage: the article surfaces a named concept that deserves explicit tracking, the SSO tax. That is the point at which identity controls stop being purely technical safeguards and start functioning as commercial tollgates. Practitioners should treat that as a governance signal, not a pricing footnote.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

SSO pricing changes the shape of IAM exceptions: when federation is monetised, organisations tend to accumulate local-account workarounds, delayed integrations, and ungoverned SaaS islands. That makes identity standardisation harder to sustain and pushes access control decisions into procurement instead of architecture.

Commercial gating is now part of identity risk management: teams need to assess whether an application’s licensing structure is preventing the organisation from applying normal authentication policy. If SSO is treated as a premium feature, the control is already influencing security posture before implementation begins.

For practitioners

• Map SSO as a control requirement Define Single Sign-On support as a mandatory security and governance requirement for applications that handle business data or employee access, then align procurement reviews to that requirement.
• Flag pricing-driven exceptions Identify apps where federation is absent only because the needed tier is too expensive, and record those exceptions as governance risks rather than acceptable cost trade-offs.
• Prioritise shadow SaaS onboarding Bring unmanaged applications into the identity programme first where local login still exists and the SSO gate is delaying standard access oversight.
• Separate authentication from packaging decisions Require IAM and security reviewers to challenge whether a product tier boundary is masking a basic access control need that should already be standard.

Key takeaways

• The SSO tax is a governance problem because it turns a core authentication control into a pricing decision.
• When federation is monetised, organisations are more likely to keep local credentials, delay standardisation, and accept identity exceptions.
• IAM teams should evaluate SSO availability as a baseline control during procurement, not as an optional add-on later.

Key terms

• Single Sign On: Single Sign On is a login method that lets a user access multiple applications with one authenticated session. Technically, an identity provider issues a trusted authentication assertion or token after the user signs in, and connected services accept that proof instead of requiring separate passwords for each application.
• 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.
• SSO tax: SSO tax is the extra licensing, implementation, and consulting cost that organisations may face when a SaaS app only supports SSO in higher tiers or through difficult integrations. It is an identity governance problem because cost barriers can directly delay access standardisation.
• 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.

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.