How should teams govern non-federated applications that cannot use normal SSO?

How to govern non-federated applications without creating a permanent exception

When an application cannot use normal SSO, the control question changes from “Can we federate it?” to “How do we make access accountable, revocable, and reviewable anyway?” That means treating local credentials as governed assets, setting an owner, and defining the minimum access pattern the business will accept rather than letting the app’s limitations define policy.

The practical goal is to preserve the same discipline you would expect in a federated flow: one authoritative inventory, clear ownership, routine review, and fast removal when the user or account changes. The IAM and IGA Basics guide is useful here because the control problem is fundamentally about lifecycle and entitlement governance, not just login mechanics.

Teams should also distinguish between user access and application authentication. A non-federated app may still be acceptable if it sits behind a broker, vault, or access workflow that enforces policy at the point of use. That is where centralised passwords, token vaulting, session controls, and approval logic become the compensating control set.

What the control model should look like in practice

The strongest pattern is to move as much decision-making as possible out of the application and into the surrounding access layer. In that model, the app remains unchanged, but access is mediated by central policy, credential storage, and lifecycle automation. For many teams, the right intermediate target is not “perfect federation”, but “no unmanaged standalone secret and no orphaned access path.”

Use the application owner, not the end user, as the accountable party for exceptions. If the app cannot participate in modern federation, the owner should still be required to justify why local credentials exist, what they protect, and how they are rotated or retired. The Identity Provider and SSO Security Guide supports the broader operating model of hardening the surrounding access fabric, even when one application remains outside the normal federated path.

Where feasible, use role-based or group-based assignment to reduce one-off user grants, then pair that with time-bound access and documented exception handling. The governance issue is not just whether access exists, but whether teams can prove who can use it, why they can use it, and when that permission should disappear.

For applications that rely on shared credentials or API tokens, NHI Authentication Guide is a useful reference for the mechanics of vaulting, rotation, and machine-to-machine authentication patterns that reduce standing secret exposure.

Why exception sprawl becomes the real failure mode

The main risk is not the absence of federation by itself, it is the accumulation of unmanaged exceptions. Once a non-federated app is treated as a special case, teams often leave long-lived passwords in place, skip recertification, and miss revocation when people change role or leave. Over time, the exception becomes the control baseline.

That drift creates both governance risk and compromise risk. A local account with a static secret can outlive the user, the project, or the vendor relationship that justified it. Where a third-party or integration credential is involved, a compromise in one system can cascade into another through the same standing access path. Ultimate Guide to NHIs, Standards is relevant because the same control problems appear whenever credentials, rotation, and privilege are handled outside normal federation.

Failure mechanism: local or shared credentials remain valid after role changes, offboarding, or vendor changes because revocation depends on manual cleanup or app-specific processes rather than an authoritative lifecycle event. That leaves access live longer than the business expects, and usually longer than the risk owner can see.

Impact: dormant or overbroad access can be reused for unauthorized login, lateral movement, data access, or service abuse, and the organisation may not discover the exposure until an audit, incident, or account review forces a trace-back.

Practitioner Guidance

What to prioritise: inventory every non-federated application, classify whether it uses a human password, shared secret, token, or API credential, and assign a business owner who can approve exceptions. If the team cannot name the owner or the revocation path, the app is already a governance problem.

Decision rule: if the application cannot join SSO, require a compensating control before granting access, such as vaulting, rotation, group-based assignment, time-limited access, or mediated sign-in. If none of those exist, treat the access path as temporary and higher risk, not as an accepted permanent design.

What to verify: confirm that lifecycle events, especially joiner, mover, and leaver actions, actually trigger password reset, token revocation, or account removal in the target system. A control is not working if deprovisioning happens in the directory but not in the application.

Practitioner takeaway: Non-federated applications should be governed as exceptions with compensating controls, not as informal legacy islands, because the real test is whether access can still be revoked, reviewed, and explained when the credential or account outlives the user.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?