When IGA cannot govern outside SSO and federation, offboarding, role changes, and access reviews become incomplete. Former employees can retain access in apps the platform never discovered, movers keep outdated permissions, and reviewers approve access they cannot properly evaluate. The result is manual remediation, weaker evidence for audits, and persistent over-provisioning that undermines the programme’s control objectives.
Why This Matters for Security Teams
When IGA only governs applications behind SSO and federation, it creates a false sense of coverage. The control plane may look complete, but the real estate of access is wider: legacy apps, SaaS services with local accounts, API-driven integrations, admin consoles, and partner-facing systems often sit outside the discovered perimeter. That gap undermines joiner-mover-leaver controls, recertification, and audit evidence.
This is not a theoretical edge case. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, and those blind spots often mirror the same discovery problems in application governance. That is why guidance in the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both emphasize visibility and continuous control over point-in-time approvals.
In practice, many security teams discover the missing applications only after an offboarding event, an audit exception, or a privilege review has already exposed the gap.
How It Works in Practice
Effective governance starts by accepting that SSO federation is only one access pattern, not the whole identity estate. IGA tooling must inventory non-federated applications, local directories, service desks, shared admin portals, and any system where access is granted outside the federated trust boundary. Without that discovery layer, access certification becomes a partial exercise: reviewers can only attest to what the platform knows, not what the business actually uses.
Practitioners typically need three operating changes. First, establish application ownership and authoritative sources for entitlements so shadow access can be mapped back to a human owner. Second, add remediation workflows for non-SSO apps, including local account disablement, manual token revocation, and evidence capture for auditors. Third, align review cycles to actual risk rather than system convenience. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs highlights how lifecycle control depends on complete discovery, while NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces access enforcement and accountability as core control outcomes.
- Discover apps outside SSO, including local-auth, legacy, and partner-connected systems.
- Map each app to an owner who can approve, revoke, and attest access.
- Automate offboarding where possible; use manual exception handling where automation is not available.
- Track remediation separately from certification so unresolved gaps do not disappear in a clean review.
Controls tend to break down when an organisation runs hybrid estates with locally managed accounts, because the governance tool cannot revoke what it never authenticated or discovered.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance complete coverage against the cost of manually reconciling legacy systems. That tradeoff is real, especially when application teams resist modernisation or when a business unit relies on a vendor-hosted system with limited administrative APIs.
Best practice is evolving for these cases. Some organisations treat non-SSO applications as exceptions with compensating controls, while others build parallel governance workflows outside the main IGA suite. There is no universal standard for this yet, but audit defensibility improves when the exception process is explicit, time-bound, and owned.
NHIMG research on the Top 10 NHI Issues shows how access blind spots compound when discovery and lifecycle controls are incomplete, and the same pattern applies to non-federated applications. Organisations should also account for app types that do not fit standard review logic, such as break-glass accounts, shared service identities, and third-party support access. In those environments, certification alone is not enough; revocation verification and periodic technical validation become necessary.
The strongest programmes accept that the IGA tool is a governance layer, not a source of truth for every entitlement. When a platform cannot see or manage outside SSO, the control objective shifts from elegant automation to provable completeness through alternative coverage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is essential when apps sit outside SSO and federation. |
| NIST SP 800-63 | Federation gaps often leave unmanaged local credentials outside identity proofing. | |
| NIST AI RMF | Incomplete governance weakens accountability and monitoring across the identity lifecycle. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires access decisions beyond a narrow SSO trust boundary. |
Treat non-federated app accounts as governed identities with defined issuance and revocation steps.
