Start by mapping the full SSO requirement set, then test whether the current federation design can handle provisioning, deprovisioning, reporting, and ongoing application change without custom work for every app. If the answer is no, the organisation should treat scalability and operational burden as architecture issues, not just implementation details, and evaluate a cloud-based identity platform that reduces manual integration overhead.
Why This Matters for Security Teams
When ADFS starts breaking under cloud application growth, the problem is usually not “just federation.” It is a sign that the identity architecture cannot absorb provisioning, deprovisioning, reporting, and app-specific change without constant custom work. That creates brittle SSO, slows onboarding, and pushes teams into manual exceptions that weaken auditability. In practice, identity teams often discover the scaling limit only after application owners have already built workarounds that are hard to unwind.
NHIMG’s 2024 Non-Human Identity Security Report shows how often organisations struggle when identity controls lag operational reality, especially across hybrid and multi-cloud environments. The same pattern shows up in enterprise SSO: if the federation layer cannot support lifecycle operations cleanly, every new app increases security debt. That is why the first question is architectural, not tactical. Security teams should also pressure-test the model against known identity failures such as the Snowflake breach and the TruffleNet BEC Attack — Stolen AWS Credentials, where identity weakness became an operational problem quickly.
In practice, many security teams encounter federation scale limits only after application sprawl, exceptions, and manual provisioning have already multiplied.
How It Works in Practice
The first move is to inventory the full SSO requirement set before changing platforms. That means documenting which applications need SAML, OIDC, SCIM, step-up authentication, lifecycle automation, and reporting. It also means separating technical compatibility from operational fit: some apps can authenticate through ADFS but still require too much manual work to manage over time.
Once the requirements are clear, teams should test the current design against the work the identity team actually performs each day. A scalable federation model should handle:
- initial user and group provisioning without per-app custom scripting
- deprovisioning that reliably removes access when users leave or change roles
- change management when cloud applications update claims, connectors, or admin models
- consistent reporting for access reviews, audit evidence, and exception tracking
This is where current guidance suggests treating identity as an operating model, not a login project. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it pushes teams to map access control, account management, and auditability to measurable control outcomes. NHIMG’s The 2026 Infrastructure Identity Survey found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which is a strong signal that manual identity plumbing does not scale.
If the existing ADFS design requires a bespoke fix every time a cloud app changes its claims, lifecycle hooks, or trust model, then the architecture is already doing too much work at the wrong layer. These controls tend to break down when application owners can self-service new SaaS tools faster than identity teams can engineer and test each federation exception.
Common Variations and Edge Cases
Tighter federation governance often increases short-term migration effort, so organisations have to balance stability against the cost of continuing to patch an ageing design. Not every environment needs an immediate rip-and-replace, and best practice is evolving for mixed estates where ADFS still supports a subset of legacy apps.
The main edge case is a hybrid estate with a few deeply integrated on-prem applications that cannot move quickly. In that scenario, teams may keep ADFS for those legacy dependencies while shifting cloud applications to a platform that can better handle lifecycle automation and app change. Another variation is when the identity team is already committed to centralised conditional access, but the real bottleneck is poor provisioning discipline rather than federation itself.
There is no universal standard for this yet, but the practical test is simple: if cloud expansion keeps creating manual exceptions, brittle claims, or one-off connectors, the organisation should treat that as a scaling failure. NHIMG’s research on the 2026 Infrastructure Identity Survey also shows that 67% of organisations still rely heavily on static credentials, which reinforces why lifecycle automation matters even when the immediate question is federation. If ADFS is only serving as a temporary bridge, the transition plan needs ownership, timelines, and exit criteria rather than open-ended support.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity and access governance is central to ADFS scaling decisions. |
| NIST SP 800-63 | AAL2 | Federated SSO changes should preserve strong authentication assurance. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle gaps in workload and service access mirror human identity scaling issues. |
| NIST AI RMF | GOVERN | Architecture decisions should include governance, accountability, and oversight. |
Assign ownership for identity architecture decisions and measure operational burden explicitly.
Related resources from NHI Mgmt Group
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams manage cloud identities across multiple applications?
- How should security teams handle cloud secrets that are shared across applications and pipelines?
- How should security teams respond when phishing-as-a-service kits scale credential theft across cloud email environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
