What breaks when organisations only monitor the primary identity system and ignore connected SaaS and disconnected systems?

Why This Matters for Security Teams

Monitoring only the primary identity system creates a false sense of coverage. The directory may show who should have access, but it often misses how access is actually exercised across SaaS apps, partner tools, and disconnected systems. That gap matters because service accounts, API keys, delegated OAuth grants, and legacy local accounts can stay active long after central review processes have moved on.

NHIMG research shows why this is not a theoretical gap. The Ultimate Guide to NHIs reports that only 5.7% of organisations have full visibility into their service accounts, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In other words, the blind spot is often where real exposure lives, not in the main directory.

This is also where governance programs fail quietly. Teams may complete a clean access review for the core IAM stack and still miss shadow applications, duplicated credentials, and disconnected systems that never return telemetry to the same control plane. In practice, many security teams discover those paths only after an incident, rather than through intentional discovery.

How It Works in Practice

The operational fix is broader than “check more logs.” Security teams need continuous discovery across the identity estate, then correlation of entitlements, credentials, and actual usage across primary IAM, SaaS platforms, and systems that are only partially connected. That means inventorying the sources of identity truth and the systems that consume identity evidence, then reconciling them on a recurring basis.

Practically, this usually includes:

• Discovery of SaaS tenants, OAuth apps, SCIM connections, and dormant integrations.
• Identification of disconnected systems with local users, service accounts, or shared credentials.
• Review of delegated access, app-to-app trust, and long-lived tokens outside the directory.
• Correlation of identity changes with ticketing, offboarding, and exception workflows.

The point aligns with the NIST Cybersecurity Framework 2.0, which emphasises asset visibility, access control, and continuous monitoring across the environment, not just a single control point. It also matches NHIMG guidance in the Top 10 NHI Issues, where unmanaged secrets and poor visibility are treated as core exposure drivers rather than edge cases.

For auditability, teams should treat every identity-bearing integration as part of the access review population, even if it never appears in the central directory. Current guidance suggests prioritising SaaS admin consoles, API key stores, and legacy systems first, because those are common places where revocation fails to propagate cleanly. These controls tend to break down when disconnected systems retain local accounts that cannot be reconciled automatically because ownership and lifecycle data are missing.

Common Variations and Edge Cases

Tighter identity monitoring often increases operational overhead, requiring organisations to balance coverage against integration complexity. That tradeoff is especially visible when older platforms cannot support SCIM, modern logging, or automated revocation, leaving teams to choose between manual reconciliation and residual risk.

Best practice is evolving for environments with third-party SaaS sprawl and hybrid estates. In those cases, the main directory should be treated as one input, not the control boundary. A broader program should classify systems by connectivity, credential type, and revocation path so teams can see where the primary identity system is authoritative and where it is only advisory.

Edge cases also matter. Shared admin accounts, embedded credentials in scripts, and partner-managed integrations can survive normal recertification even when user access looks clean. The 52 NHI Breaches Analysis and the Snowflake breach material show how quickly overlooked identities can become incident paths when monitoring stops at the primary system.

In mature programs, the question is not whether a user exists in the directory, but whether the organisation can prove all active access paths are known, reviewed, and revocable. That becomes hardest in disconnected systems because identity evidence is fragmented and revocation often depends on manual intervention.

Related resources from NHI Mgmt Group

• What breaks when organisations only monitor endpoints and ignore SaaS identity governance for AI tools?
• What breaks when identity data is fragmented across HR, directory, and application systems?
• What breaks when organisations enforce identity governance only at onboarding and not throughout the access lifecycle?
• How do organisations evaluate whether identity governance is actually covering their disconnected application estate?