They should discover those applications, document who uses them, and decide whether to onboard them into governance or retire them. If the app remains outside central control, access reviews and deprovisioning will stay incomplete regardless of how strong authentication is elsewhere.
Why Unsynced Applications Become Governance Gaps
Applications that sit outside SSO are not just inconvenient, they create separate identity islands. Teams lose a reliable place to centralize provisioning, deprovisioning, and usage visibility, which means access can persist after role changes, app ownership can be unclear, and controls that work well for federated apps stop being complete across the estate.
That is why the first decision is not whether the app supports federation in theory, but whether the business can tolerate it remaining a local exception. If the answer is yes, the exception still needs a named owner, documented user population, and a clear control path for joiner-mover-leaver events.
How Teams Should Triage the Application Portfolio
Start by finding every non-SSO application and classifying it by business criticality, user type, and authentication method. A legacy internal tool, a vendor portal, and a small team-owned SaaS app may all be out of SSO for different reasons, but they should not be treated the same. The practical goal is to decide which systems can be onboarded to central governance quickly, which need compensating controls, and which should be retired because the operational burden is not justified.
Where onboarding is feasible, align the app to your broader workforce identity model and document the migration path. Where it is not, require an explicit exception that names the owner, the review cadence, the deprovisioning method, and the evidence the business will keep for access decisions.
What Good Control Looks Like When SSO Is Not Yet Available
Even without SSO, teams should preserve the controls that SSO normally enables: application inventory, ownership, access approval, periodic recertification, and timely removal when users depart. That means the app cannot be treated as a one-time setup. It needs a manual or semi-automated operating model that proves who has access, why they have it, and how that access is revoked.
For workforce identity programs, workforce identity security guidance is useful because it ties SSO, federation, provisioning, deprovisioning, and recovery into one control story. If the app remains outside central sign-in, the team should still match those lifecycle expectations as closely as possible.
When a non-SSO app is a candidate for future consolidation, the decision should be based on whether central control will materially improve review quality and termination hygiene, not simply on whether the app is popular. If the app cannot support reliable offboarding, it should remain a priority for onboarding or replacement.
Risk and Threat Considerations
Unsynced applications create predictable exposure because they often evade normal identity governance. Former users, contractors, or forgotten service accounts can keep access after central accounts change, and attackers who find one of these orphaned paths may bypass stronger controls elsewhere.
Failure mechanism: The app sits outside SSO, so provisioning and deprovisioning depend on separate processes, which are easier to miss, harder to audit, and more likely to drift over time.
Impact: Access reviews become incomplete, termination risk rises, and a compromised or stale account can provide persistent access that the central identity stack cannot see or revoke.
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-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Unsynced apps must still be inventoried to manage access and ownership. |
| PR.AA-01 — Identities and credentials for authorized users, services, and hardware are managed by the organization | The question is about managing application access outside central sign-in. | |
| PR.AA-05 — Access permissions and authorizations are defined, managed, enforced, and reviewed | Non-SSO apps still need access approval and periodic review. | |
| Recommendation — Inventory every non-SSO application and assign a named owner. Manage local app identities and credentials under a governed lifecycle. Define, review, and revoke access for each unsynced application. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Unsynced applications require account provisioning, review, and removal controls. |
| IA-5 — Authenticator Management | Local credentials and tokens still need governed handling when SSO is absent. | |
| Recommendation — Apply account management controls to every application account lifecycle. Control local credentials with issuance, rotation, and revocation rules. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Non-SSO apps need identity ownership and lifecycle governance. |
| A.5.18 — Access rights | The core issue is incomplete access review and deprovisioning outside central control. | |
| Recommendation — Document identity ownership and lifecycle for each unsynced application. Review and remove access rights for exceptions on a defined schedule. | ||
| CIS Controls v8 | CIS-5 — Account Management | The problem is incomplete lifecycle control for app access accounts. |
| CIS-6 — Access Control Management | Unsynced apps need explicit access governance even when central SSO is missing. | |
| Recommendation — Track, review, and disable application accounts that sit outside SSO. Enforce and review access for each non-SSO application exception. | ||
Practitioner Guidance
What to prioritise: Put the highest-value unsynced apps first, especially those with sensitive data, broad user populations, or weak evidence of clean offboarding. A low-value app with good local controls is less urgent than a critical app with no reliable user inventory.
Decision rule: If the app can be onboarded into SSO without breaking a core business process, treat onboarding as the preferred outcome. If not, require a documented exception with named ownership, periodic review, and a tested deprovisioning path.
What to verify: Confirm that the application owner can produce a current user list, show how departures are handled, and demonstrate that dormant access is removed on a schedule, not only when someone remembers to ask.
Practitioner takeaway: The real test is whether the team can still answer, with evidence, who has access, why they have it, and how it will be removed when circumstances change.
Related resources from NHI Mgmt Group
- How should security teams reduce false positives when checking MFA status across SSO-connected applications?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?