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.
What changes when federation is treated as a paid feature?
When federation is only available at a higher tier, the decision is no longer a simple product preference. It becomes a control and access-design question: the organisation is paying not just for convenience, but for the ability to keep access decisions centralised, reduce local password sprawl, and maintain a consistent authentication baseline across business applications.
That matters because the security value of federation is often indirect but real. It improves user experience, but it also reduces duplicated credentials, simplifies offboarding, and limits the number of places where access policy can drift. A licensing model that makes federation optional can quietly push teams toward weaker operational patterns if procurement treats it as a feature add-on instead of a security requirement.
For IAM teams, the key point is that the absence of federation changes the control posture of the application, not just the login experience. A non-federated app may force local accounts, manual provisioning, password resets, and slower revocation. Those are manageable for low-value tools, but they become hard to justify when the app carries meaningful business access or sensitive data. In practice, the licensing model may be asking the organisation to accept a control exception.
Where the licensing model becomes a governance problem
Paid federation features create a common governance trap: the business wants the application, the vendor wants the upgrade, and the security team is left deciding whether to absorb the risk or fund the control. That decision should be made explicitly, not hidden inside a software selection process. If the app touches important workflows, the question is whether the organisation is comfortable with the access model the base tier forces on it.
This is where identity architecture and vendor management intersect. Teams should assess whether the app can support federated login through an upgraded tier, a different integration path, or a replacement product with better baseline controls. If not, the lack of SSO may be acceptable only when the use case is narrow, the user population is small, and the app has limited blast radius if an account is compromised or difficult to revoke.
A useful way to frame the issue is to compare the long-term operational cost of weaker access control with the license premium. Sometimes the paid feature is cheaper than the extra support burden, manual joiner-mover-leaver handling, and higher exposure from local credentials. In that sense, federation is not a luxury feature, it is often part of the cost of operating the application safely at scale. See the broader identity and access trade-offs in IAM and IGA Basics and Identity Provider and SSO Security Guide.
How to decide whether to buy, replace, or accept the gap
The right decision depends on business criticality, user volume, and the strength of the alternative access path. If the application supports core operations, handles regulated or sensitive data, or sits in a high-churn user population, the absence of federation should usually trigger replacement or escalation rather than casual acceptance. If it is a niche tool with limited access and a small trusted user group, a documented exception may be reasonable.
Teams should also test whether the app’s federation gap is actually a proxy for deeper product weakness. Apps that charge extra for SSO sometimes also lag on lifecycle hooks, auditability, role design, or deprovisioning support. A product that cannot integrate cleanly with the organisation’s identity layer may be creating recurring risk, not just a one-time licensing nuisance. In those cases, procurement should weigh vendor fit as part of control design, not just feature comparison. The buying decision should be informed by IAM and Identity Provider Buyer’s Guide and the lifecycle discipline in NHI Lifecycle Management Guide.
There is also a practical exception rule: if the app cannot federate, but the organisation can compensate with tight role design, short-lived access, strong monitoring, and rapid offboarding, the residual risk may be acceptable for a bounded period. That should be treated as an exception with an expiry date, not as a permanent architecture choice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Federation decisions directly affect how users are authenticated to business apps. |
| IA-5 — Authenticator Management | Paid federation often forces local credentials or weaker account lifecycle management. | |
| AC-2 — Account Management | Non-federated apps complicate provisioning, revocation, and exception handling. | |
| Recommendation — Require federated authentication where the application supports organizational user access. Minimize local authenticator sprawl and manage any fallback credentials tightly. Tie application access to formal account lifecycle and revocation processes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about preserving a consistent access control baseline across applications. |
| A.5.16 — Identity management | Federation is an identity management control choice, not just a convenience feature. | |
| A.8.5 — Secure authentication | Federation gaps can push teams toward weaker local authentication patterns. | |
| Recommendation — Enforce a consistent access control requirement for business-critical applications. Standardize identity integration requirements in application procurement. Prefer secure, centrally managed authentication over app-local login schemes. | ||
Practitioner Guidance
What to verify: Confirm whether the application supports any standards-based federation path, what the base tier actually blocks, and whether the lack of SSO also means weaker provisioning or revocation support. If the app is business-critical, verify the impact on offboarding time, help-desk load, and account recovery before accepting the licensing model.
Decision rule: If the app handles meaningful business access, default to one of three outcomes: upgrade for federation, replace the product, or record a time-bound exception with compensating controls. Treat “we can live without SSO” as a temporary position that requires explicit risk ownership.
What practitioners underestimate: The hidden cost is often not the license delta, it is the operational drag of managing identities outside the standard access model. Once local accounts spread, the organisation usually pays more later in support effort, slower deprovisioning, and weaker assurance.
Practitioner takeaway: Pay for federation when it preserves the identity control baseline, not when it merely improves convenience. If the vendor prices SSO as an extra, IAM should decide whether that is a tolerable exception or a signal to walk away.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- How should security teams handle risks from AI browser extensions?
- How should teams handle secrets that have no obvious owner?
- How should security teams handle feature rollout when updates affect multiple applications at once?