How should teams handle applications that cannot be enforced by IGA tooling?

How to govern applications that IGA cannot enforce

When an application sits outside enforceable IGA control, the practical answer is not to ignore it, but to govern it explicitly. The access model still has to be documented, the owner has to be named, and the application has to be treated as an exception with compensating controls that can actually be operated and reviewed.

The key distinction is between IAM and IGA Basics as the target operating model and the app’s real implementation. If the system cannot consume provisioning workflows or deprovisioning events, teams need a fallback process that preserves accountability, even if the control is manual rather than fully automated.

This is also where disconnected systems become a governance problem rather than a tooling problem. The right question is not whether the platform can be onboarded cleanly, but whether access changes, entitlement ownership and review evidence are still reliable enough to support operations and audit.

What the exception process should still control

An unenforced application still needs the same core governance outcomes: who owns it, who can approve access, what the entitlement set means, and how access is removed when people change roles or leave. If the application cannot support direct lifecycle enforcement, the fallback must define how accounts, roles and shared credentials are discovered, reviewed and revoked outside the tool.

That is why Entitlement Catalogue and Application Onboarding Guide is relevant here: the control gap is often a visibility gap first, then an automation gap. If you do not have a usable entitlement catalogue for the application, manual certification quickly degrades into a vague inventory exercise.

The governance record should also capture whether the application has group-based access, direct entitlement assignment, local admin roles, shared accounts, API keys, or service credentials. Those are all different review objects, and they cannot be treated as one generic access bucket if you want deprovisioning and attestation to mean anything.

Why review cadence and offboarding discipline matter

For these systems, the main control objective is not perfect automation, but reliable closure. That means periodic access certification, a named review cadence, and an explicit offboarding path for anything the IGA tool cannot touch. Without that, access tends to persist after job changes, vendor changes or application retirements, especially where local admin rights or shared credentials are involved.

Teams often underestimate how quickly exceptions accumulate when applications are outside the normal lifecycle. Joiner-Mover-Leaver (JML) Guide is useful because it frames the issue as lifecycle control, not just provisioning workflow design. If a leaver can still authenticate through a local account, the offboarding process is incomplete even if the HR record and central directory are clean.

A disciplined exception should also have an expiry date. If the compensating controls are manual, the review interval has to be short enough that the risk remains observable, and the exception should be reapproved rather than assumed valid forever.

Risk and Threat Considerations

Applications outside IGA enforcement create a predictable exposure pattern: access can outlive employment, role changes, vendor engagement or contract end dates. The risk is strongest where local accounts, shared credentials or application-specific roles are maintained outside central identity controls, because those paths are harder to detect and easier to forget.

Failure mechanism: Deprovisioning depends on human follow-through instead of a system-enforced event, so stale entitlements, orphaned accounts and unreviewed shared access persist after the need for access has ended.

Impact: Unnecessary access remains available for misuse, audit evidence becomes weaker, and offboarding errors can turn into prolonged unauthorized access or privilege creep.

Practitioner Guidance

What to verify: Confirm that every exception has a named system owner, a documented access model, a review cadence, and an explicit revocation path that names who removes access when the tool cannot. If any of those elements is missing, the exception is not governed well enough to rely on.

Decision rule: If an application cannot enforce lifecycle actions, treat manual certification and compensating controls as the control plane, not as a temporary workaround. If the app also uses shared credentials or local admin roles, prioritize credential inventory and offboarding steps before expanding the user population.

Practitioner takeaway: The control question is not whether IGA can automate the application, but whether the organisation can still prove ownership, review access on schedule, and remove it quickly when the business need ends.

Related resources from NHI Mgmt Group

• How should security teams handle disconnected applications that sit outside identity tooling?
• How should security teams handle IGA when key applications sit behind rigid network controls?
• What breaks when IGA software cannot govern applications outside SSO and federation?
• How should security teams handle applications that cannot be integrated into SSO?